Which LOD technique is a triangle saver

Any mesh reduction method usually has this objective, for example: https://github.com/sp4cerat/Fast-Quadric-Mesh-Simplification (This one trades speed vs. accuracy)
But it's offline preprocessing te generate various discrete LODs. Notice also Simplygon has a free option now: https://www.simplygon.com/

For continuous LOD at runtime, you could store a precomputed tree of edge collapses, hhttps://en.wikipedia.org/wiki/Progressive_meshes (the older game 'Messiah' used this to get very detailed models for its time)

Beside mesh reduction / simplificaton, there is also 'remeshing', wich are methods to generate a completely new mesh. Usually harder to implement, and most proposed methods aim for equally sized triangles / quads. More interesting if you need to reduce details, which is the harder problem than increasing them.

Also various isosurface extraction algorithms exist with adaptive detail, e.g. http://transvoxel.org/ or (to some degree) https://www.voxelfarm.com/index.html

Finally there exist methods of dynamic displacement mapping which tessellate more on visible edges or detailed regions, often implemented on GPU using tessellation shaders.

And ofc. there are other represeantatioons of geometry, like voxels or point cloud hierarchies. Because they have no connectivity LOD is easy with those.

Or is it just about heightmaps? You did not mention but your given examples indicate so.
In this case you could adapt existing algorithms to your objective quite easily? I think ROAM already did so, but i don't know much about height map methods.

...you may need to tell a bit more about your goals / requirements to narrow discussion :)

JoeJ said:

Any mesh reduction method usually has this objective, for example: https://github.com/sp4cerat/Fast-Quadric-Mesh-Simplification (This one trades speed vs. accuracy)
But it's offline preprocessing te generate various discrete LODs. Notice also Simplygon has a free option now: https://www.simplygon.com/

For continuous LOD at runtime, you could store a precomputed tree of edge collapses, hhttps://en.wikipedia.org/wiki/Progressive_meshes (the older game 'Messiah' used this to get very detailed models for its time)

Beside mesh reduction / simplificaton, there is also 'remeshing', wich are methods to generate a completely new mesh. Usually harder to implement, and most proposed methods aim for equally sized triangles / quads. More interesting if you need to reduce details, which is the harder problem than increasing them.

Also various isosurface extraction algorithms exist with adaptive detail, e.g. http://transvoxel.org/ or (to some degree) https://www.voxelfarm.com/index.html

Finally there exist methods of dynamic displacement mapping which tessellate more on visible edges or detailed regions, often implemented on GPU using tessellation shaders.

And ofc. there are other represeantatioons of geometry, like voxels or point cloud hierarchies. Because they have no connectivity LOD is easy with those.

Or is it just about heightmaps? You did not mention but your given examples indicate so.
In this case you could adapt existing algorithms to your objective quite easily? I think ROAM already did so, but i don't know much about height map methods.

...you may need to tell a bit more about your goals / requirements to narrow discussion :)

I think I already narrowed it very down, to the question of which LOD technique (there is not much of them), is (or aren't any) the most Triangle saver. Like for example chunked LOD or CDLOD creates max resolution around the camera not taking into account the height map (its fixed gird, for example 16x16). Where sometimes it's an overkill, because the area is flat orsmth. From what I read ROAM, could be a candidate but it's implementation kills my brain, I don't get it doesn't matter how much times I read the papers :(((

No, you still did not narrow it down. If you want better help, give better information, like:

Simple heightmap terrain? Or terrain with cliffs, holes, caves...?

Offline preprocess or at runtime? Guess the latter, but is the terrain static or can the player deform / change it at runtime?

How should we know any of this? (Likely i can not help, but others might if you answer this...)

Every LOD technique is a compromise between detail level, triangle reduction, and computation time. You can always reduce the triangle count by reducing the detail level, but don't forget about computation time. Improving the quality of the LOD (i.e. the amount of detail per triangle) could easily be more computationally expensive than just rendering a larger number of triangles.

Yeah, my suggestion would be that you actually implememt one of these to understand how they work. And fear no graphics pipeline, doing this all on the CPU isn't a very performant approach these days (waiting for correction here :-)).

Cdlod for example knows no mesh preparation, like the matrix knows no spoon. There is only a single regular grid the size of a node (let's say 16*16 or 32*32). I find it difficult to imagine how a continuous morphing of vertices could be done on irregular meshes, without creating special cases like following a curvature, avoiding artufacts like popping and seams and so on. Otoh, it only needs a heightmap to generate all the data. A simplification and mesh preparation step is unnecessary and would actually generate unnecessary data and computation.

What if i tell you that one could render 3 million triangles (only very basic shading) with 2000fps on a gtx 970, a 6700k single threaded, unoptimized, compiled with full debug info and no optimization ? And due to an error in my selection algorithm i accidentally rendered 60 million triangles still with 30 fps ...

Chunked lod otoh has an extensive step of mesh preparation where such a step actually makes sense and to my knowledge is done, but i have no personal experience with this. And chunked lod is more complex, slower and needs more bandwidth than cdlod. Can't say much about geometry clipmapping, only that it also prepares (regular ?) meshes and morphs between lod levels. But there one has the task of generating buffers that are filled on one side and emptied on the other while the camera moves, right ? So your framerate will probably suffer here as well from traffic that other algorithms try to avoid.

Closing with: actually implement one of those (or another) lod algorithm.

@trsh wrote:

chunked LOD or CDLOD creates max resolution around the camera not taking into account the height map

Btw., cdlod does take into the heightmap to estimate the distance between a vertex and the camera pos by sampling the heightmap twice, once to estimate a position before the morphing, a second time after the morphing to determine the exact height. Morphing is limited to the flat plane, but i have seen suggestions to do it really 3 dimensional. For me and my 2d heightmaps that would be overkill right now.

Cdlod's downsides are: It can only morph from a higher to the next lower lod level. Morphing needs a certain depth, a number of vertices over which it spreads (let's say a third of the depth range of a given level). One cannot squench 6 lod levels into a map of 512/512, that would lead to visible cracks because the depth is insufficient. And looking along a hidden slope into a valley will hide the morphing range, because it is only distance dependent.

Otoh, the parameters for the lod, the ranges of the lod levels, the parts of a level over which morphing takes place, and the view range that determines how densethe lod levels are can be changed on the fly. It takes no time, because the selection algorithm only looks at distances, not at the data.

There is no super cow ...

frob said:

trsh said:
I have read about (CDLOD, Chunked LOD, Geo. mipmappings) all increase details (triangles) near to the camera view, but do not really care if that detail is needed

Actually, this has been researched too and used in several games.

View-dependent level of detail takes into account many factors. Visual error is one big factor; sharp changes on the profile edge of an object have a high visual error and thus move to higher detail, smooth transitions on the profile edge have a low visual error and thus get reduced. Similarly, geometry being viewed directly parallel to the screen has very low visual error and drops in detail.

For modern games, view-dependent LOD is often a bad fit because of the hardware. The systems are designed to have large fixed models sent to the graphics card, then manipulate those models through shaders and other parameters. Changing the mesh is CPU intensive and bandwidth intensive, it is far easier for games to swap objects based on distance. This was an active topic in games in the 1990's and early 2000's as 3D graphics cards were being introduced --- mostly dealing with terrain --- when it was more efficient to reduce the number of polys on the CPU first, but with the hardware changes it is now rarely done. Go back 15 years and you'll find view-dependent rendering was present in nearly every large terrain system, attempting to predict which distant mountain ranges needed updating and prefetching, which valleys could be culled on the CPU, which nearby ground could be dropped to flat land as it had no interesting geometric features.

It is still an active topic in offline rendering, large data set rendering, and in remote rendering. Search the web for view-dependent LOD, view-dependent rendering, and mesh refinement models, and you'll find plenty to keep you reading.

Interesting. I will sure do a search as You suggested, I mean while maybe u have some know links/resources to share on this theme?

trsh said:
mean while maybe u have some know links/resources to share on this theme?

Yes, and in fact, that's what I wrote: Search the web for view-dependent LOD, view-dependent rendering, and mesh refinement models, and you'll find plenty to keep you reading.

Those are the search terms. Use them.