GPU centric terrain rendering
Author
Hi,
I'm working on the terrain-engine of my game-engine and i can't really decide what to use. At first i thought about using ROAM as i have done before, but i read about a GPU centric approach where terrain geometry is stored as small (17*17) blocks of triangle strips on the GPU. A terrain data set of 257*257 vertices would take 700 KB of GPU memory. And it supposedly outperforms roam by a factor of 2, while having a load time of 0.01% on the GPU where roam would take 10-20% percent load time on the cpu.
What do you think about this approach, has anybody actually done this? Pro and Cons? Are there some more technical articles about this method?
Greetings.
A 257x257 grid is only 131,072 triangles. Modern hardware can spit that out with very little problem. Break that up into nicely culled patches (17x17 = 512 tris per batch) and you have a very fast system.
Personally I would use bigger patches...33x33 = 2048 tris per batch or 65x65 = 8096 tris per batch to use the vertex buffer optimally.
edit: Don't get me wrong, LOD is still usefull for very high polycount terrains, or if you have a low budget for your terrain. But if you just want to throw a bumpy grid at the screen, just do it.
edit2: spelling, grammar.
Personally I would use bigger patches...33x33 = 2048 tris per batch or 65x65 = 8096 tris per batch to use the vertex buffer optimally.
edit: Don't get me wrong, LOD is still usefull for very high polycount terrains, or if you have a low budget for your terrain. But if you just want to throw a bumpy grid at the screen, just do it.
edit2: spelling, grammar.
Or, try some of these ideas if you really want to be GPU-centric http://www.vterrain.org/LOD/Papers/. "Geometry clipmaps: Terrain rendering using nested regular grids" is where I started.
tj963
tj963
Author
Thanks for the responses...
That's a good idea.
I don't get what you mean by low budget? Do you think the quality will be lower with this technique than with f.i. ROAM?
I read the article about geometry clipmaps, i was definitly going for LOD anyway, since i don't want artefacts and flickering in the background. However i thought about chunked LOD, which wouldn't really allow for that many lods as in nested grids.
What do you think about this technique quality wise? I just want the best algorithm for my engine :)
Quote:Original post by WarAmp
Personally I would use bigger patches...33x33 = 2048 tris per batch or 65x65 = 8096 tris per batch to use the vertex buffer optimally.
That's a good idea.
Quote:
edit: Don't get me wrong, LOD is still usefull for very high polycount terrains, or if you have a low budget for your terrain. But if you just want to throw a bumpy grid at the screen, just do it.
I don't get what you mean by low budget? Do you think the quality will be lower with this technique than with f.i. ROAM?
I read the article about geometry clipmaps, i was definitly going for LOD anyway, since i don't want artefacts and flickering in the background. However i thought about chunked LOD, which wouldn't really allow for that many lods as in nested grids.
What do you think about this technique quality wise? I just want the best algorithm for my engine :)
By "low budget" he means you are limited to a small number of polygons.
I prefer chunked LOD over geomipmapping for rendering large terrains. As the rendering distance (r) increases, the number of draw calls for geomipmapping is O(r2), but only O(log r) for chunked LOD. I'm skeptical of geo-clipmaps because it requires dynamic buffers (but I haven't tried it and other like it).
I prefer chunked LOD over geomipmapping for rendering large terrains. As the rendering distance (r) increases, the number of draw calls for geomipmapping is O(r2), but only O(log r) for chunked LOD. I'm skeptical of geo-clipmaps because it requires dynamic buffers (but I haven't tried it and other like it).
While I'm not clear on all the terminology, here is my view: If you have a bounded world, that is its not infinte, or extremely large, just render one giant mesh brute force out to horizon (with or without clipping)...this is what i do in my own engine.
If you have a very large world, break the terrain to small grid sections as described above, and have one large low-poly terrain rendered beyond the nearest cells.. I think Oblivion solved this in the best way currently.
Also, there is no reason your terrain has to be a perfect grid, as I imagine future terrain being just arbitrary meshes like everything else.
If you have a very large world, break the terrain to small grid sections as described above, and have one large low-poly terrain rendered beyond the nearest cells.. I think Oblivion solved this in the best way currently.
Also, there is no reason your terrain has to be a perfect grid, as I imagine future terrain being just arbitrary meshes like everything else.
Quote:Original post by Matt Aufderheide
While I'm not clear on all the terminology, here is my view: If you have a bounded world, that is its not infinte, or extremely large, just render one giant mesh brute force out to horizon (with or without clipping)...this is what i do in my own engine.
Indeed!
With precomputation you can get a decimated TIN which looks indistinguishable from the original mesh with perhaps as little as 5% of the original vertices (this of course depends on the method of decimation and the terrain itself). The key point here is that all of these real-time LOD schemes really do a very bad job at approximating the terrain at the lower details, they sacrificed quality for simplicity. So if you use geoclipmaps or ROAM or whatever and render X triangles per frame, you'd probably be able to render the scene without LOD at a much higher quality while still only drawing X triangles (because you're simply doing a better job at decimating the terrain since you can do it offline).
So, for the vast majority of games (i.e. when you're not modelling an entire planet or something) you're going to get far better performance *and* quality by just pre-generating a really optimized and good looking terrain mesh (which can even have overhangs!) and rendering it brute force without any LOD at all.
there is a GPU centric approach to terrain rendering in the book ShaderX3, although the focus of the article is more on the fact that it can be done, rather than terrain rendering itself (IMO). Not too sure if there are more resources online about it though :-/ (cos I'd be interested, myself)
Author
Quote:Original post by sebastiansylvan
So, for the vast majority of games (i.e. when you're not modelling an entire planet or something) you're going to get far better performance *and* quality by just pre-generating a really optimized and good looking terrain mesh (which can even have overhangs!) and rendering it brute force without any LOD at all.
I have been thinking about that, but don't you get problems with flickering in the distance because there are multiple traingles per pixel?
Quote:Original post by LimitzAre you sure the flickering isn`t caused by Z-fighting due to Near/Far plane of the frustum ?
I have been thinking about that, but don't you get problems with flickering in the distance because there are multiple traingles per pixel?
Quote:Original post by sebastiansylvanBut you can have overhangs even with heightmaps through vertex shaders. Just try to look at it from different standpoint and the idea suddenly comes up ;-)
So, for the vast majority of games (i.e. when you're not modelling an entire planet or something) you're going to get far better performance *and* quality by just pre-generating a really optimized and good looking terrain mesh (which can even have overhangs!) and rendering it brute force without any LOD at all.
Though, editing it is possible only through your in-game editor (pulling vertices to form overhangs - but that`s still better than trying to match the texturing of the overhang mesh with your terrain in a classic method).
EDIT: Typos
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
