Spiritus Astrum

I have not been able to fix the current issue with the Spherical Terrain Project. I feel that I am very close, but I cannot seem to get the terrain to subdivide correctly.

The below video illustrates what I mean. As the camera moves further away from the terrain, the nodes at the back should stop rendering. This happens to most of the nodes. However, some of the nodes are rejected from the render list incorrectly, such as a node in front disappearing from view before a node behind it.

This is the problem that I am having issues fixing. I  will continue working on it for the time being, but I may not be able to crack this.

I believe I have figured out why the spherical terrain parsing system doesn’t work properly.

I have closely examined the nodes stored in the quad tree during the call to build the renderlist.

What is happening is that higher level nodes are being rejected because their distance is greater than the view distance, this is correct. However, it turns out that some of the child nodes of those higher level nodes have distances less than the view distance, which means that they should be subdividing or rendering, but they are not, because they have been excluded from the search.

This leads to not all of the nodes rendering correctly, which I believe leads to the striping effect that I am seeing.

If this is correct, then it should be fixable. I should be able to, for the moment at least, just find the closest point in the node to the players position, and if they is within the players view distance, I subdivide the entire node. This is a little messy and inefficient, since it involves additional distance checks for every point in the node, but it should work for now.

I have made some changes to the subdivision code which have addressed the optimisation issues.

I can now subdivide the terrain into without processing every node, but, in addition to some other logical issues, there is also a more serious problem.

It seems that when I parse the tree correctly (Subdividing only required nodes) the terrain does not smoothly fade in and out of view. It seems to render in strips, such as in the images below.

I am not certain how to fix this, or even if it can be fixed. I am concerned that this could be a serious logical flaw.

I am reasonably confident that this can be fixed however.

Upon further testing, it seems that my solution to the parsing and optimisation problem was not actually correct.

Even though it did work, when I analysed the number of calculations performed by the function I saw that there was one calculation for each node in the quad tree.

This means that it did not actually produce any noticeable benefit or performance boost. I do feel that I am very close to figuring this out, however, and I am currently in the process of refactoring the code to solve this.

Since the quad tree parsing algorithm uses recursion, this is not nearly as easy as it could be. I am looking into other parsing options (such as using a stack) as well as modifying the logic in my current code.

I believe I have finally achieved proof of concept with the spherical terrain using CLOD! After 82 posts, including 49 specific to CLOD, I think I am finally there (or almost, at least).

At the below video shows, I have successfully implemented a system whereby the terrain will dynamically change detail levels as the camera gets closer and closer to the world, and switch back again as it moves away.

The change is actually far more seamless than I thought! I was concerned that there would be problems at the edges, where the different levels of detail meet (for example, when the terrain close to the camera is rendering at a higher detail level than the terrain far from the camera), however this does not appear to be a major issue.

There is a visible border between the detail levels, which is to be expected, since I haven’t added any edge stitching yet, but in general the transition is very smooth.

Most importantly, the frame rate seems to be very consistent. I have not done full benchmarks at high resolution yet, but from the low resolution tests that I have done so far, the framerate does not seem to drop very much as the new tiers are paged in. This is all very encouraging.

There is still a lot of work to be done however. Firstly, at the moment, the transition is controlled by an If/Else statement with fixed distance variables, i.e, if the player is less than 5000 units away, display the lowest tier, once they are within 4000 units, transition to the next tier, etc etc. Obviously, this will not work for the final version of the terrain since I will not know exactly how many tiers they will be (the number of tiers will depend on the max resolution of that particular terrain) and in addition, I don’t want to hard code the distance values, these should be dynamic.

I also need to find a way to scale the terrain to realistic planet sizes. This will require finding a way to dynamically generate and add points to the quad tree, since generating enough points to render and entire planet cannot be done all at once. I will probably use my current code until the player gets close to the planet, and then begin generating points dynamically and adding just the points close to the player to the quad tree. This should allow far greater detail without having to load all points into the quad tree at once in the beginning of the simulation.

I also have to texture the terrain, and make sure that the terrain rendering and collision work at realistic sizes (this will involve dealing with 32-bit precision issues). I will also have to make sure the terrain works in multiplayer.

I have created a very short video clip showing off the subdivision code as it is now. I am only rendering  one face of the quad tree, but the subdivision seems ok. The terrain is being divided into quads based on the proximity of the player to the camera.

The main issues now are that the terrain is not seamlessly integrating the multiple levels of detail (The terrain in the video is only rendering one detail level), also, the terrain seems to subdivide in reverse order. The more complex tiers are rendered the further the player move from the camera, and the less complex tiers are rendered as the get closer. I am not certain why this occurs, but I am making progress with this.