P-152: Virtual World Concept Update 66: Chunked Levels of Detail Using Quad Trees Part 34

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.