Astral Realms

While researching texturing techniques to use with Spherical Terrain, I came across a technique called TriPlanar Texturing,or Triplanar Projection.

This looks like it will work perfectly with the project I am developing. THIS is an excellent introduction to the technique.

Triplanar texturing basically renders the texture three times, once from the direction of each axis (X,Y,and Z). This produces a final texture with minimal distortion. Triplanar texturing is a procedural technique, making it suitable for my purposes. It does not require a UV map, the only data is needs is the list of World-Space coordinates.

This means that a lot of very powerful things can be done with this technique that would be impossible with a conventional texture (which would require the manual generation of a texture map). In addition to being generated dynamically, Triplanar projection should be able to perform per-vertex texturing operations The most basic example of this would be selecting a texture based on the height of a given vertex. Higher vertices would be rendered with a snow or rock texture, while lower ones would be grass or sand.

However, real-time per-vertex texturing could also be used to create charring on the ground underneath a forest fire. As the fire spreads, the textures changes from soil or grass to burnt, charred, earth. I could also simulate the gradual build up of snow during a snow storm, from small patches of snow to a completely snow covered area of terrain. My project will be a completely realistic simulated world, and so plants will scatter their seeds to the wind, resulting in new plants growing where those seeds land. This could cause areas of empty soil to slowly become green, as grasses and weeds grow and die off.

This technique, (and all procedural texturing techniques) have tremendous power, and, since it uses a shader, you also get all of the other benefits of shaders as well, such as reflection, refraction, etc etc. Shaders are discussed in much more detail on other websites. I had planned to integrate my terrain system with T3D’s existing material system, which heavily uses shaders. I should be able to use this system to implement triplanar texturing.

The way I would use it in a procedural universe environment would be to give each plant type a texture library. There would be a library for Ice Planets, Desert Planets, Temperate planets, etc, which would contain all of the textures that that planet is allowed to render (An Ice planet, for example, would not be able to use grass textures). This texture library would consist of images generated manually. Once this texture library has been loaded, some of those textures will be chosen to be drawn at different points on the planet.

All of these textures will have a “render priority”, so, for example, rock will always render before soil, and soil will always render before snow. This means that when these textures are combined, you end up with a realistic looking texture. I am currently looking into a technique called “Texture Splatting” to combine the multiple textures together. I can also use alpha transparency to make certain textures more or less visible than others. This would contribute to the overall effect that I wanted to create at that particular location.

Triplanar texturing is quite slow, however, since the texture has to be rendered three time. This may end up being a problem, but it is definitely worth trying.

I have confirmed my hypothesis regarding the cause of the rendering issues with the spherical terrain.

I loaded all of the points into a global data structure, and then rendered a set of points (which I manually specified) from that buffer.

As the images below prove, the resulting terrain rendered correctly. The below images were taken at different resolution, using the same data structure. I am only rendering one face of the terrain, but it is clear that each image is a distortion free rendering of the terrain at that resolution.

I now just need to solve the indexing problem with the quad tree so that I can render each tier dynamically from the quad tree itself.

I have done some debugging using the log files that I have generated, and it seems that the values that are in the renderlist are actually not what I expected. They don’t match the sequence of values that were generated at the beginning, which means something is definitely going wrong in the function to load the values into or out of the quad tree.

It seems that the loading function for the quad tree is loading the values from the beginning of the points list. This is a problem, because the quad tree loading function is a recursive function, meaning it does not process tier 1, then tier 2, then tier 3, etc. It actually steps through the nodes from one tier to the next and back again, processing all nodes in a more roundabout way.

I thought I had solved this problem with the way I was loading the nodes into the tiers, but it seems I have more work to do here.

There are a large number of extra verts in the final tier of the spherical terrain that are not being loaded into the renderlist. I believe this is because the code is loading the correct number of verts for the given tier, say, 64, for example, but it is loading those points from the wrong part of the points list.

When loading the quad tree, all of the points are stored linearly in a points list, so tier 1 is points 0-3, tier 2 is points 4 –  20, and tier 3 is points 21 – 85.
The code should be loading to and from tier 3 by working with the 64 points from 21- 85. However, if the indexing is wrong, it could load from 0 instead, and return points 0-64, which would fit the results that I am seeing.

I need to confirm that this is indeed what is happening, and then fix it, before I can progress with the prototype.

I believe my hypothesis is correct, in that the issues I am having are with the indexing of the verts as they are being loaded into and out of the quad tree.

I have made some progress in solving these issues, as can be seen in the below screenshots. However, there are still some issues with vertices being placed incorrectly.

At higher resolutions, the problem reoccurs, with visible distortion in the spherical terrain. Verts are either being rendered in the wrong order, or several tiers are still being rendered at once.

I am confident that this is a fixable problem, but I will need to do more extensive debugging to solve it. I have written some code to save a list of the vertices to a file at several places in the code: At the beginning, when the vertices are first generated, When the vertices are loaded into the quad tree, and at the end, when the renderlist is populated.

I can now compare them with WinMerge, a very useful dif tool for comparing multiple files.

I have implemented my solution to get the multiple detail levels working, and I have modified the rendering function to only render the world with specific levels of detail.

The system seems to be mostly working, but the world still has the visible distortion visible in my previous set of images. This distortion seems to be less prevalent the lower the detail level is.

I believe this must have something to do with the complex algorithm that I am using to “select” the correct tier from the spherical terrain. The algorithm must be accidentally selecting nodes from other tiers as well, resulting in distortion to the terrain mesh.

I will need to investigate this further, this needs to be corrected before I can move on with the Chunked Level of Detail System.

I believe I have managed to get multiple detail levels working.

I have not yet implemented the code to add each detail level to each tier of the quad tree successfully, but I have produced a pointslist which I believe contains all detail levels up to and including the max detail level specified by the used.

So, if the user specifies a detail level of 1024, the pointslist will contain a spherical terrain with a resolution of 1 node, 4 nodes, 16 nodes, 64 nodes, 256 nodes, and 1024 nodes. Each node has four points, which will have two more points added to allow them to be rendered, as I discussed previously.

The images below seem to show the multiple levels of detail all rendering at once, which is correct at this point. However, I will not know if this system is working correctly or not until I load the nodes into the quad trees properly. I will then need to modify the rendering function to render only specific levels of detail, to test this code.

If it works, I can move on to the final step in the prototype, which is the distance based optimisation algorithm.

I have finally implemented quad-based rendering!

The images below show the terrain looks identical to what it used to look like before all of this work, however, there have been massive changes made to how it all works.

There is still some relatively minor distortion, which seams to be occur only along the seams of the quad spheres faces. This, I believe, is due to vertices and/or faces on both sides of the quad sphere boundary being duplicated. Since both faces occupy the same space, distortion occurs, due to Z-fighting.

There may also be some issues with collision detection in certain parts of the terrain, but I can address these issues later.

In addition to extensive bug fixes, optimisations, and improvements to the algorithm, each node in the quad tree now contains six points, which are used to draw two triangles, or one quad, per node. This is a vital step, because in order to subdivide the terrain based on the distance of the player, each of the quad trees nodes needs to be able to, essentially, render the entire face of the terrain.

This means that from an extreme distance, the terrain will render using only a handful of quads, and as the player gets closer, it will subdivide only those quads close enough to the player, producing a highly optimised, but also a high quality terrain mesh.

The next step is to implement the “Levels of Detail” that I require for this to work. At the moment, I am creating a list of terrain vertices at the most complex level of detail, and rendering all of them. I now have to generate a list of terrain vertices for each level of detail in the quad tree. For example, I will have a list of points generated for just one node, and for 4 nodes, then 16, then 64, then 256, then 1024, etc.

Once all of these points are generated and stored in their respective quad trees (each face has it’s own quad tree now, and I have to generate a list of points for each face separately), I can write a distance-based optimisation function which only subdivides a higher level node if it is close enough to the player. If this works, I should essentially have a spherical terrain implementation. There will still be a lot of work to do with optimisations, texturing, and scaling (I want to be able to scale the terrain to realistic planet sizes, that will be another challenge!) but the prototype should be done.

I have fixed the minor bug that was preventing the last face from drawing, and I have copied the changes to the second of the six faces that form the quad tree.

So far, the new system seems to be working very well, but I won’t know if it has worked for sure until I can get all six of the faces rendered, and the perlin noise applied.

I am confident that this new approach will work, however. There are no visible issues with the two sides of the quad sphere that I have added so far.

I have finally made a breakthrough with regards to the quad rendering.

As can be seen from the images below, I can now render an entire face of the quad sphere in quads, as opposed to tris.

The solution I used was to add six points to each node, instead of four, in order to draw two triangles, forming the quad. Using an index buffer would have been more efficient, and I may implement this technique in the future, but the system seems to work quite well as it is for now.

I used to have two loops in the code to create the geometry: One to create the list of points for each face, and another loop that would iterate through that list of points and rearrange them so that they had the correct “winding order” to be drawn.

This was obviously very inefficient, however, since this was being done only once (on loading the game) it wasn’t a major problem. I have since fixed this however, making the code much more efficient.

There is one minor bug in the code, and that is that the very last face of the quad sphere is not showing up. The loop seems to terminate one step too soon. The cause of this is rooted somewhere in the quad tree initialisation functions, and may take a little time to track down, but it should not be too difficult.

Once I have that bug fixed, I can copy my code changes to the other 5 faces of the quad sphere, and I should then be ready to move on to the next major step of the project: Generating multiple detail levels.

I have succeeded in drawing my first quad!

This may seem like a trivial matter, but it took considerable effort to get this far. In addition to the extensive modification and bug fixes that I wrote about before, I also had to modify the entire algorithm that creates the data points, to ensure they are compatible with the new system.

I eventually arrived at a situation where I had four points for each node that I wanted to render, which is what I wanted. I then needed to render these four points as a quad, which I assumed would be a simple task.

In actual fact, it turned out to be quite complex. Everything in computer graphics in rendered with triangles, which require three points. So, to render a quad using two triangles, I would need six points, not four, with two points being reused.

I looked into a few different ways of solving this problem, including using GFXTriangleLists as a rendering method, and using an index/primitive buffer.

I am confident that the index buffer idea would have worked, but it would have required even more changes to the codebase to implement that. I decided for now to just create four points, as normal, then, when I am loading the points into the quad tree node, I will duplicate two of them, so I will have six points stored per node instead of 4. During rendering, I should then be able to draw those six points as two triangles.

I don’t know if this is going to work yet, but I am reasonably confident.

There is still a lot of work to be done on this, but I feel I am making significant progress.