Finally, after many studies, I can conclude that, as someone said earlier, there is no universal “best” method. But my research led me to know the following things:
Depending on the grid, you will finally use:
- Spherified Cube: any LOD method with quadtree implementation will work very well, you just need to take care of special cases, such as borders between faces, in your case your quadrant should have a pointer to a neighbor in an adyacent face at each level.
- Any others: I think that ROAM (newer version 2.0 or any other extension like BDAM, CABTT or RUSTIC) will succeed, but it’s difficult to work with these algorithms, it requires more memory and a little slower than other tests with cubes.
There are many LOD methods that can fit well, but my personal top 5 is:
Each of them offers a unique way of rendering landscapes, for example, CDLOD has a very easy implementation using shaders (GLSL or HLSL), but can also be implemented on a processor (for outdated equipment), however, the goal in Planet Rendering is to explode the best on modern graphics processors therefore GPUGCM is best when you want to compress your GPU. They both work very well with data-based, procedural or mixed (terrain based on fixed data or height maps and details, complemented by procedural work) rendering large landscapes.
There is also a spherical extension to the base geometric method of Clipmaps, but it has some problems because flat height map samples must be parameterized using spherical coordinates.
Chunked LOD, on the other hand, is ideally suited for legacy equipment, does not require any computations on the GPU side, it is ideally suited for large datasets, but cannot process procedural data in real time (perhaps with some changes, it could)
Using Tessellation shaders is another method, very new, since OpenGL 4.x came out, in my opinion, it may be the best, but we are talking about Planet Rendering, we are faced with a problem that other methods can handle very easily and this concerns accuracy .
If you don't want your accuracy to be 1Km between vertices, go for Tessellation shaders. The problem with really large areas with this method is that jitter is hard to solve (or at least for me, as I am new to tessellation shaders).
Geomipmapping is a great technique, it uses square and has a low predicted pixel error, but for planetary rendering you will need to set at least 16 levels of detail, this means that you will need (for embroidery) some additional patches to connect different levels and care for the next level It can be tedious to solve, especially using 6 surfaces.
There is another method, especially in its own form: "Projective grid display for planetary terrain" is great for visualization, but has its drawbacks, if you want to know more, follow the link.
Problems:
Jitter . Most modern GPUs only support 32-bit floating point values, which does not provide sufficient accuracy to manipulate large positions on a planetary scale. Jitter occurs when the viewer approaches and rotates or moves, then the polygons begin to come back and forth.
The best solution for this is to use the "Rendering regarding the use of eyes" GPU ". This method is described in the book" 3D Engine Design for Virtual Globes "(I'm sure you can find it on the Internet as well), where basically you have to install all your positions using doubles on the CPU (patches, clip cards, objects, frust, camera, etc.) and then MV is centered around the viewer, setting its translation to (0, 0, 0) T, and the doubles are encoded at a fixed point representation using fractions bit (mantissa) from two floats, low and high by some method (read about the use and implementation of Ohlariks library DSFUN90 Fortran).
Although the vertex shader requires only two additional subtractions and one addition, the RTE GPU doubles the number of vertices in the buffer memory needed for positions. This does not necessarily double the memory requirements if only positions are not saved.
Depth buffer accuracy : Z-fight. Since we create very large landscapes, in this case: planets, the Z-buffer should be HUGE, but no matter what values you set for znear and zfar, there will always be problems.
Since the Z-buffer depends on the interval of the swimming point, the linear (although perspective projection is non-linear) near the eyes suffers from Z-fights, because 32-bit floats have a lack of accuracy.
The best way to solve this problem is to use the "Logarithmic Depth" Buffer " http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html
The logarithmic depth buffer improves the accuracy of the depth buffer for remote objects using the logarithmic distribution for zscreen. This is Trade Accuracy for close objects for accuracy for remote objects. Because we render using the LOD method, distant objects require less because they have fewer triangles.
It is important to note that all of the above methods (with the exception of the projective grid) are very good at performing physics (mainly collisions) because of the Quadtree base, which is something mandatory if you plan to make a game.
In conclusion, just check all the available options and go for the one you feel more comfortable in my opinion, CDLOD does an excellent job. Do not forget to solve problems with jitter and Z-buffer, and most importantly: have fun with it!
For more information on LOD, check this link .
For a complete demo on spherical cube, check out this link .
For a more in-depth explanation of the Z-Buffer jitter and precision solution, check out this book .
I hope you find this short review useful.