Terrain Question
Author
Hello!
I wanted to know which is the better way to go for terrain rendering...
1. create a vertex buffer for the complete terrain and let each tile have an index buffer?
or
2. create a vertex buffer for each tile?
The first method reduces vb switches but the second takes less RAM as I do not have to use 32 Bit indices...
So what is the better solution?
Naturally you'd want to avoid vertex buffer switching. So, depending on your terrain-lodding algorithm you have to choose the best choice. Consider packing several tiles into one VB but use as many VBs as required. Or, use one dynamic VB and stream the data from your memory (with 8 byte terrain vertex, you can stream pretty much of vertices from memory without a great performance hit).
For example, if you have a dynamic lodding, you might find using VBs difficult. One possibility would be to create several different LODded versions of the tile and then use some sort of caching method for keeping the tiles in the buffers.
Few things to consider:
- size of the terrain
- LODding algorithm / amount of terrain LOD changing over a time
- precision of the terrain presentation
Cheers !
It might be useful if you define what your goal is. Do you want a dynamic terrain that you can easily manipulate, one that prioritises performance, one with a low memory footprint?
I wrote a couple of journal entries on vertex cache optimization for efficient terrain rendering here. Since writing that article I've managed to draw huge terrains divided into 128x128 blocks (128x128 is the limit for a 16bit IB) - one VB and one IB per block. ISTR my last test ran out of VRAM before I ran out of performance [wink]
In light of that work I'm less inclined to bother with terrain LOD on modern GPUs. Terrain LOD still has its uses, but a few recent tests I've done has shown that the cost of editing/uploading modified LOD data is often more expensive than just brute-forcing [oh]
hth
Jack
I wrote a couple of journal entries on vertex cache optimization for efficient terrain rendering here. Since writing that article I've managed to draw huge terrains divided into 128x128 blocks (128x128 is the limit for a 16bit IB) - one VB and one IB per block. ISTR my last test ran out of VRAM before I ran out of performance [wink]
In light of that work I'm less inclined to bother with terrain LOD on modern GPUs. Terrain LOD still has its uses, but a few recent tests I've done has shown that the cost of editing/uploading modified LOD data is often more expensive than just brute-forcing [oh]
hth
Jack
I have spent some time working on real time terrain rendering, and trying to optimize it. (I'm not saying any of my ideas are good or valid just that I have spent some time on it.)
My current solution is Geo Mip Mapping or a variant of it.
Currently what I have set up is a 1025x1025 height map. I then break the map down into 128x128 sections and store each of these sections into a Vertex Buffer. I then further break down the 128x128 sections into what I call patches which have a set of index buffers that map to each patch.
The set of index buffers never change, I just map the appropriate index buffer to the appropriate patch since all of the vertex buffers are theoretically the same with different data. The index buffers have several levels of detail and mesh on the edges depending on the level of detail of neighboring patches. several index buffers per level of detail for all of the meshing.
At runtime I then determine the level of detail of each patch and then check each patches neighbor to determine the meshing it should have to prevent cracks.
It's kinda a brief explanation about my process of rendering terrain, but I think it has pretty good results.
So, to answer your question directly, I think it is better to break the terrain down into several large (128x128 verts to support 16bit indexing) then create a set of index buffers that match that vertex buffer to further break it down to do culling and other things.
My current solution is Geo Mip Mapping or a variant of it.
Currently what I have set up is a 1025x1025 height map. I then break the map down into 128x128 sections and store each of these sections into a Vertex Buffer. I then further break down the 128x128 sections into what I call patches which have a set of index buffers that map to each patch.
The set of index buffers never change, I just map the appropriate index buffer to the appropriate patch since all of the vertex buffers are theoretically the same with different data. The index buffers have several levels of detail and mesh on the edges depending on the level of detail of neighboring patches. several index buffers per level of detail for all of the meshing.
At runtime I then determine the level of detail of each patch and then check each patches neighbor to determine the meshing it should have to prevent cracks.
It's kinda a brief explanation about my process of rendering terrain, but I think it has pretty good results.
So, to answer your question directly, I think it is better to break the terrain down into several large (128x128 verts to support 16bit indexing) then create a set of index buffers that match that vertex buffer to further break it down to do culling and other things.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
