Jump to content
  • Advertisement
Sign in to follow this  
Limitz

GPU centric terrain rendering

This topic is 4406 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

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.

Share this post


Link to post
Share on other sites
Advertisement
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.

Share this post


Link to post
Share on other sites
Thanks for the responses...

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 :)


Share this post


Link to post
Share on other sites
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).

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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)

Share this post


Link to post
Share on other sites
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?

Share this post


Link to post
Share on other sites
Quote:
Original post by Limitz
I have been thinking about that, but don't you get problems with flickering in the distance because there are multiple traingles per pixel?
Are you sure the flickering isn`t caused by Z-fighting due to Near/Far plane of the frustum ?

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.
But 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 ;-)
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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!