how show terrain be represented in an engine?
Author
I'm currently working on a 3D Engine and I've hit a wall as to how I should represent the terrain in the world. The clear things up, I would like to know the most efficient way to represent it for speed purposes. Right now I am debating on whether or not I should make it a subclass of my object class or make it completely separate. The way things work at the moment is an object is placed into the octree. If I represented the terrain as an object, I'd have to break the terrain into separate meshes.
What is the most efficient way to reresent terrain in a 3D engine?
Well, it depends. Are you after maximum CPU efficiency? Shader efficiency, vertex efficiency?
Most games are CPU bound at their default res, so the most efficient way to render it is probably to render the whole thing as one object.
Of course if its too big, you may start to become shader or texture bound. Plus its often a pain to deal with the whole world as one big piece of stuff.
So, it typically makes sense to break terrain or other world geometry into chunks. In my engine, I break the world up into 16x16x16 meter chunks. There are about 4-8 non-empty chunks in view at any one time.
This is also convenient, b/c each chunk can have its own lightmap, it may have its own aabb tree, etc.
What I would do is choose a largish child node of the octtree, and store terrain chunks in there. The lowest level of the tree ( often holding small groups of triangles ) can be used for collision purposes.
Most games are CPU bound at their default res, so the most efficient way to render it is probably to render the whole thing as one object.
Of course if its too big, you may start to become shader or texture bound. Plus its often a pain to deal with the whole world as one big piece of stuff.
So, it typically makes sense to break terrain or other world geometry into chunks. In my engine, I break the world up into 16x16x16 meter chunks. There are about 4-8 non-empty chunks in view at any one time.
This is also convenient, b/c each chunk can have its own lightmap, it may have its own aabb tree, etc.
What I would do is choose a largish child node of the octtree, and store terrain chunks in there. The lowest level of the tree ( often holding small groups of triangles ) can be used for collision purposes.
Author
Cool. Thanks for the help. I've been bashing my head against the wall trying to figure out the best way to do things, without coding each way and finding out. Thank you for the reply, I'll give it a shot.
In fact, terrain rendering is a complicated subject always subject to massive research...
At the time of this writing, there doesn't exist a single perfect solution, but multiple solutions with their respective pros and cons. ( see www.vterrain.org as a starting point !!! it is an excellent summary of most of the existing techniques )
Some of the questions you must ask yourself are :
- Does the terrain need to be dynamic ? ( e.g. craters created by explosions ... )
- Is your bottleneck on the CPU-side or on the GPU-side ?
- Are the terrain extents to be virtually infinite ( and streamed from disk as needed ) or limited to what can fit in memory ?
- Do you want to handle Level Of Detail transitions ( Also know as LOD morphing ) to avoid sudden popping when a part of the terrain switch from one detail of level to another one.
( Note that in practice it is not ALWAYS easy to code and isn't always necessary ... e.g. Far cry does NOT morph between LODs but you don't see so much popping ... check for yourself )
- Do you want to represent planar terrains or entire planets (that is spheres with displacement)
...........
Now my little bit of advice : there are actually 2 popular techniques in the field of real time terrain rendering ( referenced on www.vterrain.org ) :
- GeoMipmapping
- ChunkedLOD (which I find better than geomipmapping since it makes better usage of hardware, because it always sends triangles in optimal and nearly constant batch sizes)
On my current project I'm using a variation on chunkedLOD algorithm, but instead of optimizing the patches based on their flatness, I always use full regular grids of vertex, because it simplify the algorithm a bit and allows me to make the terrain dynamic. ( which is a benefit when you want explosions to make craters AND allows natural edition of your terrain in your level editor )
Florent Tournade
At the time of this writing, there doesn't exist a single perfect solution, but multiple solutions with their respective pros and cons. ( see www.vterrain.org as a starting point !!! it is an excellent summary of most of the existing techniques )
Some of the questions you must ask yourself are :
- Does the terrain need to be dynamic ? ( e.g. craters created by explosions ... )
- Is your bottleneck on the CPU-side or on the GPU-side ?
- Are the terrain extents to be virtually infinite ( and streamed from disk as needed ) or limited to what can fit in memory ?
- Do you want to handle Level Of Detail transitions ( Also know as LOD morphing ) to avoid sudden popping when a part of the terrain switch from one detail of level to another one.
( Note that in practice it is not ALWAYS easy to code and isn't always necessary ... e.g. Far cry does NOT morph between LODs but you don't see so much popping ... check for yourself )
- Do you want to represent planar terrains or entire planets (that is spheres with displacement)
...........
Now my little bit of advice : there are actually 2 popular techniques in the field of real time terrain rendering ( referenced on www.vterrain.org ) :
- GeoMipmapping
- ChunkedLOD (which I find better than geomipmapping since it makes better usage of hardware, because it always sends triangles in optimal and nearly constant batch sizes)
On my current project I'm using a variation on chunkedLOD algorithm, but instead of optimizing the patches based on their flatness, I always use full regular grids of vertex, because it simplify the algorithm a bit and allows me to make the terrain dynamic. ( which is a benefit when you want explosions to make craters AND allows natural edition of your terrain in your level editor )
Florent Tournade
A few more precisions and advices :
While designing your terrain engine, don't forget that you will need to do collision detection and texturing / shading.
- It is commonplace to use a normal map texture for the terrain instead of using vertex normals, because it will make LOD switching much less noticable. (variations (in time) in lighting are much more noticable than variations in heightfield sampling frequency)
- I don't yet have the answer to this question, but which LOD will you use for collision detection ?! You could use the same LOD as the one that is rendered, but what will happen when switching collision mesh LOD ? In fact, some object could become interpenetrating the terrain or floating above, which will have to be handled correctly by your physic.
In the other hand if you always use the same LODs for collision ( high LOD, mid LOD or low LOD ? ) will you have enough memory to store them all ? ( this is a serious problem when designing an infinite terrain system ( as I am actually doing ) )
- If you want to handle infinite worlds, you'll have to handle floating point precisions issues ( precision get bad when using high float numbers ). However there exist some work around, I have read a great article called "Solving accuracy problems in large world coordinates" in the book "Game programming GEMS 4"
- Once again, I don't know if I'm objective, but you should seriously look after chunked LOD, in my humble opinion it is full of pros and nearly free of cons. (except it's static nature which can be worked around as I do by using regular grids for your patches).
. Chunked LOD is VERY hardware friendly.
. Texturing with chunkedLOD is quite straight-forward and texturing LOD is parrallel to geometric LOD in this technique
. As I already said, it also lends itself naturaly to streaming in and out of memory : a great benefit if you plan to have huge terrains rendered
(see Ulrich paper for more details http://www.tulrich.com/geekstuff/chunklod.html )
Florent Tournade
(Currently unemployed game developper)
While designing your terrain engine, don't forget that you will need to do collision detection and texturing / shading.
- It is commonplace to use a normal map texture for the terrain instead of using vertex normals, because it will make LOD switching much less noticable. (variations (in time) in lighting are much more noticable than variations in heightfield sampling frequency)
- I don't yet have the answer to this question, but which LOD will you use for collision detection ?! You could use the same LOD as the one that is rendered, but what will happen when switching collision mesh LOD ? In fact, some object could become interpenetrating the terrain or floating above, which will have to be handled correctly by your physic.
In the other hand if you always use the same LODs for collision ( high LOD, mid LOD or low LOD ? ) will you have enough memory to store them all ? ( this is a serious problem when designing an infinite terrain system ( as I am actually doing ) )
- If you want to handle infinite worlds, you'll have to handle floating point precisions issues ( precision get bad when using high float numbers ). However there exist some work around, I have read a great article called "Solving accuracy problems in large world coordinates" in the book "Game programming GEMS 4"
- Once again, I don't know if I'm objective, but you should seriously look after chunked LOD, in my humble opinion it is full of pros and nearly free of cons. (except it's static nature which can be worked around as I do by using regular grids for your patches).
. Chunked LOD is VERY hardware friendly.
. Texturing with chunkedLOD is quite straight-forward and texturing LOD is parrallel to geometric LOD in this technique
. As I already said, it also lends itself naturaly to streaming in and out of memory : a great benefit if you plan to have huge terrains rendered
(see Ulrich paper for more details http://www.tulrich.com/geekstuff/chunklod.html )
Florent Tournade
(Currently unemployed game developper)
Author
Awesome! Thanks for the reply. I'm gonna check these places out. I've actually, jus started programming a simple racing game for my graphics class, that'll use a quadtree for partitioning. The problem i've been having on the computers in the lab is that they are so slow . . . I believe they are p3 800 mHz processors with what I can tell, little graphics memory, so I can't really show off too much stuff.
Hi,
i am also in the process switching from geomipmapping to something like chunklod. How do you integrate a chunklod terrain in a physics middleware without alot of data redundancy? The chunks are gpu friendly - sure, but not really suitable for feeding in a physics engine like novodex or something similar which tends to keep a local optimized copy. The only solution i found so far is just hold a restricted physics representation of the terrain, say some chunks around the viewer. The question is, while its possible to render massive terrains, if its possible to provide a collision mesh for them?
After hijacking, some notes to the original question :)
While geomipmapping and chunklod seem pretty popular these days, you might also want to consider geometric clipmaps (hoppe) which makes pretty fast update and is synthesis-friendly, which is imho a very critical feature for detailed terrains. (http://research.microsoft.com/~hoppe/)
Since you asked for a efficient representation, i think clipmapping makes a very efficent representation, combined with wavelet (or similar) compression.
Any comments or ideas?
thanks alot.
regards,
stephan
i am also in the process switching from geomipmapping to something like chunklod. How do you integrate a chunklod terrain in a physics middleware without alot of data redundancy? The chunks are gpu friendly - sure, but not really suitable for feeding in a physics engine like novodex or something similar which tends to keep a local optimized copy. The only solution i found so far is just hold a restricted physics representation of the terrain, say some chunks around the viewer. The question is, while its possible to render massive terrains, if its possible to provide a collision mesh for them?
After hijacking, some notes to the original question :)
While geomipmapping and chunklod seem pretty popular these days, you might also want to consider geometric clipmaps (hoppe) which makes pretty fast update and is synthesis-friendly, which is imho a very critical feature for detailed terrains. (http://research.microsoft.com/~hoppe/)
Since you asked for a efficient representation, i think clipmapping makes a very efficent representation, combined with wavelet (or similar) compression.
Any comments or ideas?
thanks alot.
regards,
stephan
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
