Finally, after a lot of researching I can conclude that, as some one said before, There is not universally "best" method. But my research led me to the knowledge of the following things:
Depending on the mesh you will finally use:
- Spherified Cube: any LOD method with quadtree implementation will work just fine, you just have to take care on special cases like borders between faces, in wich case, your quadtree has to have a pointer to the neighbor in the adyacent face in each level.
- Any other: I think that ROAM (newer version 2.0 or any other extension as BDAM, CABTT or RUSTIC) will do well, however, these algorithms are hard to work with, require more memory and are a bit slower than other aproaches with cubes.
There are many LOD methods that can fit well, but my personal top 5 are:
- Continous Distance-Dependent LOD (CDLOD)
- GPU Based Geomety Clipmaps (GPUGCM)
- Chunked LOD
- Rendering Terrains with OpenGL GPU Tessellation (Book: OpenGL Insight, Chapter 10)
- Geometrical MipMapping
Each one offers an unique way to render terrains, for example, CDLOD has a very easy implementation using shaders (GLSL or HLSL) but is also capable to be implemented on CPU (for legacy hardware) however the goal on Planet Rendering is to explode the best on moderns GPUs, so GPUGCM is the best when you want to squeeze your GPU. They both work very well with data-based, procedural or mixed (terrain based on fixed data or heightmaps and detail added with procedural work) rendering of large terrains.
Also Spherical extension to the basic Geometrical Clipmaps method exists but has some problems because the planar samples of the heightmap has to be parametrized using spherical coordinates.
Chunked LOD, in the other hand, is perfect for legacy hardware, doesn't need any GPU side calculations to work, it's perfect for large datasets but can't handle procedural data in real time (maybe with some modifications, it could)
Using Tessellation shaders is another technique, very new, since OpenGL 4.x came out, in my opinion it could be the best, but, we are talking about Planet Rendering, we encounter a problem that other methods can handle very easy and it is about precision.
Unless you only want your precision to be 1Km between verticies, go for Tessellation shaders. The problem with really big terrains with this method is that jitter is kind of hard to solve (or at least for me, since I'm new to tessellation shaders).
Geomipmapping is a great technique, takes advantage of the quadtree and has a low projected pixel error, but, for planetary rendering you will need to set at least 16+ levels of details, that means you will need (for stitching pourposes) some extra patches to connect different levels and take care of your neighbor's level, this can be tedious to solve, especially using 6 terrain faces.
There is another method, very particular in its own: "Projective Grid Mapping for Planetary Terrain" excellent for visualization, but has its disadvantages, if you want to know more, go to the link.
Problems:
Jitter: Most of today’s GPUs support only 32-bit floating-point values, which
does not provide enough precision for manipulating large positions in planetary scale terrains. Jitter occurs when the viewer zooms in and rotates or moves, then the polygons start to bounce back and forth.
The best solution for this is to use "Rendering Relative to Eye Using
the GPU" method. This method is described in the book "3D Engine
Design for Virtual Globes" (I'm sure you can find it on the internet
aswell) in where basically you have to set all your positions with
doubles on CPU (patches, clipmaps, objects, frustrum, camera, etc)
and then MV is centered around the viewer by setting its translation
to (0, 0, 0)T and the doubles are encoded in a fixed-point
representation using the fraction (mantissa) bits of two floats, low
and high by some method (read about Using Ohlarik’s implementation
and The DSFUN90 Fortran library).
Although the vertex shader requires only an additional two
subtractions and one addition, GPU RTE doubles the amount of vertex
buffer memory required for positions. This doesn’t necessarily double
the memory requirements unless only positions are stored.
Depth Buffer Precision: Z-fighting. As we are rendering very large terrains, in this case: planets, the Z-buffer has to be HUGE, but it doesn't matter wich values you set for znear and zfar, there will always be problems.
As the Z-buffer depends on a float point interval, and also it is
linear (although perspective projection is non linear) values near
the eye suffer from Z-fighting because the lack of precision 32-bit
floats have.
The best way to solve this problem is to use a "Logarithmic Depth
Buffer"
http://outerra.blogspot.com/2012/11/maximizing-depth-buffer-range-and.html
A logarithmic depth buffer improves depth buffer precision for
distant objects by using a logarithmic distribution for zscreen. It
trades precision for close objects for precision for distant objects.
Since we are rendering with a LOD method, far objects require less
precision because they have less triangles.
Something important to mention is that all the methods listed (except for the projective grid) are very good when doing physics (collisions mostly) because of the Quadtree base, that is something mandatory if you plan to make a game.
In conclusion, just check all the options available and go for the one you feel more confortable, in my opinion CDLOD does a great work. Don't forget to solve the jitter and Z-buffer problems, and most important: have fun making it!
For more information about LOD check this link.
For a complete demostration about spherifying a cube check this link.
For a better explanation about solving jittering and Z-Buffer precisions, check this book.
I hope you find this little review useful.
