CPU/CPU Level of Detail

Hello , this time my Question maybe more of a theoretical one. For the last couple of weeks i have been exploring the options i have as far as LOD is concerned. First and foremost i am looking for a LOD that will simplify my terrain (or high poly model) the thing is that i don’t want to generate different level of details for the terrain but i rather want to have it be dynamic generated, something like the ROAM algorithm where just the part of the mesh i am looking is high poly and the rest is not. In time i may also implement progressive meshing or just different level of details for each mesh as usual. But for now i am looking for something like ROAM. I read somewhere that it is old and not recommended way to go , why is that ?

PS: That would be the GPU / CPU LOD . Spelling mistake in the title , sorry !

I strongly recommend you to avoid ROAM. It is an ancient method, from the time when GPUs are slow and the minimization of the number of triangles drawn was of high priority.
However, nowadays GPUs are extremely powerful. It is harder (and more important) to feed them properly than to digest millions of triangles. ROAM is a CPU based LOD algorithm that places the burden on traversing triangle-hierarchies and mesh optimization on the CPU side.

Yea i pretty much got that and i also prefer a GPU based Level of Detail , but i was giving ROAM as an example. I need something that does the same job as ROAM. Meaning the closest part of the mesh is rendered at full resolution and the rest of the mesh depending on the distance from the camera.

If roam is not prefered what similar technique should i use , be it CPU or GPU based. Here i found some geometry shader based lod http://rastergrid.com/blog/2010/10/gpu-based-dynamic-geometry-lod/. But it is not exactly what i need

First, we should clarify whether you need a terrain LOD scheme or a general mesh LOD scheme. The techniques used in these two schemes are quite different. Although it seems easier to deal with the terrain than with general 3D mesh, it is not the case (if done correctly). The terrain is visible in any part of the scene and resides far into the distance. As far as you can see.

More or less all LOD algorithms do the same (exact) thing. What does it mean “full resolution”? If I’m high above the surface (let’s say 100000m) why should I use 10cm terrain resolution? The metrics used for choosing LOD scheme should select the proper LOD.

For the terrain rendering, I prefer clipmaps. The chunked LOD algorithm is still in use in various applications, especially if they download chunks through the network connections. There is also some hw tessellation methods, like this included in the DX11 SDK. Or if you need a pixel-precise rendering or there is a triangle-throughput limitation (hi-resolution screens), the usage of ray-cast methods or hybrid ones may be a preferable solution. However, there is a problem of fetching data. Nobody can convince me that there is a better method than clipmapping for that for the terrain without holes or overhangs.

I haven’t tried that algorithm. Why it is not what you need? In order to boost performance, you should think about optimizing patches, not discrete triangles. Batched Dynamic Adaptive Meshes (BDAM) is a newer algorithm than ROAM, but still pretty old. Maybe you are looking for something like that. Or a C-BDAM version…

Here is a visualization at what i am thinking about , maybe the clip will explain that better. - YouTube i am trying to explain starts at 1:05.

OK! That is ROAM. If you need it, you could implement it. What’s the problem?
It isn’t efficient, or GPU friendly. But if you need ROAM’s way of terrain rendering be free to implement it.

The problem was as i stated above . "Are there any more efficient ways to implement such a method , be it GPU or CPU "

Your question is like someone asking “Is there a more efficient way to implement Bubble Sort?” Well… no, there isn’t. Oh, there are other, far superior sorting algorithms. But then they wouldn’t be Bubble Sort anymore.

The efficiency problems with ROAM are part of the algorithm. The part of ROAM that makes it ROAM is also what makes it inefficient on modern GPUs. You can’t take the parts of ROAM you like and discard the ones you don’t.

You can choose a different algorithm for LOD terrain. You could chunk your terrain and have different mesh LODs; you could rely on tessellation shaders and noise functions to create greater details; or any number of other things.

But that wouldn’t be ROAM anymore. They would not be “such a method”.

So what are you looking for? Ways to make ROAM faster, or any mesh LOD-ing technique? Because you’ve been provided with several suggestions for the latter.

[QUOTE=Alfonse Reinheart;1281174]Your question is like someone asking “Is there a more efficient way to implement Bubble Sort?” Well… no, there isn’t. Oh, there are other, far superior sorting algorithms. But then they wouldn’t be Bubble Sort anymore.
[/QUOTE]

My Question was more like: “Is there a more efficient way to implement sorting”.That is why i said method and not the algorithm i did not mean ROAM it self. I would imagine that another similar technique exists (or not?!) Here is the deal, what i got and what i need.I have a large terrain packed with rather big amount of vertices and i need some sort of LOD algorithm to help me reduce the amount of those vertices based on the following condition.

  • Assume The main camera will be always above and in view of the said terrain. Here as you might conclude several versions of the terrain with “low poly count” (rendered based on the distance from mesh to the camera) will simply not cut it because the camera will be literally on top of the terrain. That is why i gave ROAM as an example of what i need, the “parts” of the mesh closest to camera are passed as LOD0(no poly reduce at all) and the rest of the mesh gets gradually reduced based on the distance from LOD1 to LODN

PS: Take this simple example. I have a 1km x 1km terrain containing huge amount of vertices.
-Its position is at (0,0,0).
-The camera moves above the terrain in the range (0-1km,0-maxHeight,0-1km);
-Render LOD0 if distance(d) from camera is 0m < d < 250m
-Render LOD1 if distance(d) from camera is 250m < d < 500m
-Render LODN …

Rendering different version of the entire terrain and displaying them wont work because If i move the camera around in the range specified above i will actually be above the terrain when this happens and that is not the desired result. I would rather have the part of the mesh i am above be rendered with its full capacity and the rest reduced to some LODN

Thank you for the refresher, but we know what terrain LODing is.

My point is that you’ve been pointed towards several techniques already that fit your criteria:

For the terrain rendering, I prefer clipmaps. The chunked LOD algorithm is still in use in various applications, especially if they download chunks through the network connections. There is also some hw tessellation methods, like this included in the DX11 SDK. Or if you need a pixel-precise rendering or there is a triangle-throughput limitation (hi-resolution screens), the usage of ray-cast methods or hybrid ones may be a preferable solution. However, there is a problem of fetching data. Nobody can convince me that there is a better method than clipmapping for that for the terrain without holes or overhangs.

So look into those. I like the clipmap idea, but I personally like the idea of using hexagons rather than squares.