I was wondering.. would it be better to have a few large meshes around 2 million polys loaded at game initialization for the game terrain/world, or tons of small tiles around 2000 polies streamed in as the player moves around?
Of coarse all of the polys wouldn't be rendered at once, most of them would be culled at any one time.
0
Few large meshes vs tons of small ones for world.
Started by Butabee, Jan 26 2011 06:44 PM
3 replies to this topic
Sponsor:
#2 Members - Reputation: 189
Posted 26 January 2011 - 08:03 PM
it's better to split the world in chunks/cells/whatever, about 10000 vertices each.
With the 2million approach, in order to implement culling, you would have to test each triangle (too much checks)
With the chunks, you will cull whole sets of polys. Check quadtrees or octrees
With the 2million approach, in order to implement culling, you would have to test each triangle (too much checks)
With the chunks, you will cull whole sets of polys. Check quadtrees or octrees
#3 Members - Reputation: 110
Posted 27 January 2011 - 01:03 AM
You should find your own optimal numbers, as any number given by anyone here (just like 10000 vertices each) will not take into consideration how thick your vertices are. I suppose that having only few meshes with many polys is bad in spite of culling, while having too many meshes will make a render calls using all your CPU and not using your GPU as much as it can be used.
I would consider drawing some example camera frustrum on a piece of paper from up-down perspective (taking into cosideration far clipping plane distance) and trying to find out how you should split that terrain that:
- large part of it laying outside frustrum can be removed from rendering pipeline by just throwing away those chunks
- number of chunks will not exceed say 100 or something similar (you do not want to use all available render calls for just a terrain)
As a result you should have size of a single terrain chunk relative to camera far clipping plane distance.
What I would seriously consider is using some type of terrain LOD (Level of Detail) so you are able to display large area using less vertices for distant parts of it, while using more vertices (being more accurate) for close ones. Unfortunately that would require further analyse and a bit more implementation, but you would limit number of required render calls and vertices used (for far areas you could group 4 chunks in a single "low detail chunk" that would have around the same number of vertices as a single regular chunk.
I would consider drawing some example camera frustrum on a piece of paper from up-down perspective (taking into cosideration far clipping plane distance) and trying to find out how you should split that terrain that:
- large part of it laying outside frustrum can be removed from rendering pipeline by just throwing away those chunks
- number of chunks will not exceed say 100 or something similar (you do not want to use all available render calls for just a terrain)
As a result you should have size of a single terrain chunk relative to camera far clipping plane distance.
What I would seriously consider is using some type of terrain LOD (Level of Detail) so you are able to display large area using less vertices for distant parts of it, while using more vertices (being more accurate) for close ones. Unfortunately that would require further analyse and a bit more implementation, but you would limit number of required render calls and vertices used (for far areas you could group 4 chunks in a single "low detail chunk" that would have around the same number of vertices as a single regular chunk.
