Terrain Rendering Techinques
I need a advise from people that have implemented terrain systems, wich techinque is best for games?
Until now I have found:
1- Geometry Clipmaps: http://research.microsoft.com/~hoppe/
Need shader 3 for best performance (I only have shader 2) and eats alot of memory, because of the static vertex buffer
2- SOAR: http://www.gvu.gatech.edu/people/peter.lindstrom/software/soar/
CPU intensive
Another implementation: http://web.interware.hu/bandi/ranger.html
3- Vvox: http://users.belgacom.net/gc610902/
CPU intensive and uniform mesh
4- ROAM2: http://www.cognigraph.com/ROAM_homepage/ROAM2/
CPU intensive, complicated
Forgot some nice one?
I think the best is 1, but all have nice results. I´m having a hard time to pick one. Need advises. :)
They have each their merits, and work in different ways. It depends entirely on what you're doing, what kind of a game you're making. There is no absolute solution for all kinds of games. Perhaps you want performance, maybe you want quality. You might want vast terrains, or just a small piece of land. It depends.
That said, I've heard the first technique, geometry clipmaps, gives large, detailed terrains, and works well with modern graphics cards.
That said, I've heard the first technique, geometry clipmaps, gives large, detailed terrains, and works well with modern graphics cards.
Thanks for the reply James Trotter
I need large terrains, but not veeery big, someting like Far Cry, performance is a must and need to run in shader model 2 at least.
The techinque is for a engine, so its not for a specific game right now. Thats why I´m having a hard time to choice one. I need the most flexibly one.
The first (Geometry Clipmaps) is very nice, but the performance and amount of memory in video card is my concerning. Does someone have read the paper and had the some concernings?
Someone know the techinque that Far Cry use?
Some of this techinques was used in commercial games?
I need large terrains, but not veeery big, someting like Far Cry, performance is a must and need to run in shader model 2 at least.
The techinque is for a engine, so its not for a specific game right now. Thats why I´m having a hard time to choice one. I need the most flexibly one.
The first (Geometry Clipmaps) is very nice, but the performance and amount of memory in video card is my concerning. Does someone have read the paper and had the some concernings?
Someone know the techinque that Far Cry use?
Some of this techinques was used in commercial games?
You forgot to have Geomipmapping and ChunkedLOD on that list. Do you not like either of these?
Stay away from CPU bound terrain algorithms especially if you want a large terrain. Far Cry uses 1024x1024 maps on a scale of 2 in order to make the terrain seem huge.
Stay away from CPU bound terrain algorithms especially if you want a large terrain. Far Cry uses 1024x1024 maps on a scale of 2 in order to make the terrain seem huge.
That Geometry clipmap thing can be implemented without vertex shaders.
Hoppe has a paper on it halfway down that page. It's the best large-landscape rendering technique I've seen thus far.
Hoppe has a paper on it halfway down that page. It's the best large-landscape rendering technique I've seen thus far.
I've done the quadtree chunked version in the past. Personally it's the crack fixing that's the biggest pain - I used vertical skirts to hide them, but that doesn't work very well with non-heightfield terrain.
That's why I like the xvox technique - crack-fixing just works - there's no figuring out which LOD levels adjacent chunks are at and generating strips to patch the gaps and then submitting of these extra strips to the GPU - that's the biggest pain in any terrain renderer IMO. I haven't implemented xvox, but I spent a fair bit of time extending the idea to an ABT built from a non-heightfield.
I'm not sure why you say it's cpu intensive though ? As far as I can tell each frame you decide which chunks are to be rendered at which LOD level based on distance from viewer and then simply submit the chunks to the GPU - the vertex shader does the rest.
That's why I like the xvox technique - crack-fixing just works - there's no figuring out which LOD levels adjacent chunks are at and generating strips to patch the gaps and then submitting of these extra strips to the GPU - that's the biggest pain in any terrain renderer IMO. I haven't implemented xvox, but I spent a fair bit of time extending the idea to an ABT built from a non-heightfield.
I'm not sure why you say it's cpu intensive though ? As far as I can tell each frame you decide which chunks are to be rendered at which LOD level based on distance from viewer and then simply submit the chunks to the GPU - the vertex shader does the rest.
Far Cry uses Geomipmapping with pre-computed (i guess) index arrays
to handle the stitching when LOD is different between patches (instead
of calculating stitching every frame), which looks much better
than adding "skirts" at the borders (that many other solutions use).
The technique works very well together with a Quadtree for culling.
The only problem I see is the fact that it is a regular grid. For games
like Far Cry this isn't a problem, but if you are planning to use the
solution in urban/city planning, things like roads, pavements, streets
and tunnels together with demands on accurate heights and slopes at
specific locations tend to make it a "little" more complicated. However,
it is patch-based so replacing certain area with regular and accurate
"city" geometry is pretty simple.
If you want something up and running that, in fact, is a very good solution
in a short time Geomipmapping with pre-computed indices to handle
the stitching is the way to go.
/Mike
to handle the stitching when LOD is different between patches (instead
of calculating stitching every frame), which looks much better
than adding "skirts" at the borders (that many other solutions use).
The technique works very well together with a Quadtree for culling.
The only problem I see is the fact that it is a regular grid. For games
like Far Cry this isn't a problem, but if you are planning to use the
solution in urban/city planning, things like roads, pavements, streets
and tunnels together with demands on accurate heights and slopes at
specific locations tend to make it a "little" more complicated. However,
it is patch-based so replacing certain area with regular and accurate
"city" geometry is pretty simple.
If you want something up and running that, in fact, is a very good solution
in a short time Geomipmapping with pre-computed indices to handle
the stitching is the way to go.
/Mike
My understanding of geomipmapping is that it uses fixed size chunks everywhere which is ok - because with current h/w you can have alot of tris per chunk and so the total number of chunks across terrain is not that big. However if you find you are using alot of cpu by submitting (see http://developer.nvidia.com/docs/IO/8230/BatchBatchBatch.pdf) too many chunks per frame (eg, you've got a large terrain) then a quadtree of chunks can be used (ie, the chunks get bigger with distance from viewer) - that's what the chunked LOD does. Then fixing cracks using offline computed indices does become a pain in terms of developer time spent on it - you've got special corner cases, etc - which is why skirts are used, they're independant of the LOD level of the adjacent chunk - and they can look just fine if you make sure the cracks aren't more than a few pixels big. And also skirts are part of the chunk and don't need to be submitted separately to the chunk and so don't increase the number of draw calls. The downside is they don't work too well for non-heightfield terrains.
So, yeah, I'd look at the BatchBatchBatch paper, work out the optimum number of tris per chunk, use that to determine fixed geomipmap-style chunk dimension and then determine number of total chunks across terrain (which is (terrain_width/chunk_width)^2) - if that number is too high then quad-tree chunks might be better.
So, yeah, I'd look at the BatchBatchBatch paper, work out the optimum number of tris per chunk, use that to determine fixed geomipmap-style chunk dimension and then determine number of total chunks across terrain (which is (terrain_width/chunk_width)^2) - if that number is too high then quad-tree chunks might be better.
Does someone know wich one have the best performance?
Geometry Clipmaps: http://research.microsoft.com/~hoppe/
or
SOAR: http://www.gvu.gatech.edu/people/peter.lindstrom/software/soar/
Geometry Clipmaps: http://research.microsoft.com/~hoppe/
or
SOAR: http://www.gvu.gatech.edu/people/peter.lindstrom/software/soar/
Everyone has already told you which one performs better. It is quite obvious especially in a game scenario that a GPU-based terrain algorithm is going to decimate a CPU-based terrain algorithm.
SOAR is CPU-bound and is great for visualizations but bad for games. I would still rather be using GeoClipmaps in any case. The real viable options are GeoClipmaps, GeoMipmaps, ChunkedLOD if you want large terrain and in a game setting (if you are counting the popular published approaches). Other than clipmaps you are looking at completely wrong algorithms to be used in a game with the type of terrain you are after.
SOAR is CPU-bound and is great for visualizations but bad for games. I would still rather be using GeoClipmaps in any case. The real viable options are GeoClipmaps, GeoMipmaps, ChunkedLOD if you want large terrain and in a game setting (if you are counting the popular published approaches). Other than clipmaps you are looking at completely wrong algorithms to be used in a game with the type of terrain you are after.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement