Optimizing vertex buffers

That's the common first way to start a tiled terrain. Good thinking that there is an optimization though, because there is. What I did was to make a vertex buffer that contained an entire playing field of quads. As you move around, you keep track of your position. So, if you move to the right 1 quad, you're now at position (1,0), so you'll be able to access your texture array (which will tell you what textures to put where at 1,0).

First, create (or reuse/add to) an index buffer.
Starting at texture 0, determine if any of the quads in the current view use texture 0.
If so, add that quad's 6 vertices to the index buffer. You can't optimize with 4 vertices, because the texture coords will differ between quads.
If not, then move to texture 1.
Check to be sure you haven't already added all of the quads to the index buffer. If you have, exit the loop.
Draw this index buffer.
Repeat.

One way you can optimize is to cache the textures that will be used in each visible scene. Something I just thought of, but haven't done, might be to use bit masking.

As a simple example, say you have 8 textures, and so an 8 bit number could be used to represent the 8 textures simultaneously.
At position (0,0), you determine which of the 8 textures are in that scene, then store those in the 8-bit number. You probably don't want to do this for every single section (1,0), (2,0), (3,0), etc. You could further simplify it by storing the texture ids for each major section.

For example, say you have 50x50 quads on the screen. At position (0,0), you have 25 quads left, 25 up, right, and down. If you move 50 to the right, you'll be at (50, 0). This will be an area that has completely new textures, none of the texture from the first 50x50 grid will be in this area (well they could be, but you don't know for sure.) You can stagger the 8-bit number to only be at (0,0), (50,0), (-50,0), (0,50), (0,-50), (50,50), (-50,-50), (-50,50), (50,-50). This is a full 9 point super-grid. When you're between (-49,-49) and (49,49), you can use the 9 point super grid 8-bit numbers to determine which textures are in this area. Simply LOGIC OR the 8-bit numbers from all 9 grids together, and you get a number with 8 bits telling you which of the 8 textures are used in that entire area. Now here's the kicker. This doesn't seem useful for 8 textures, but this prevents you from looping through the 50x50 quads for each texture (if you aren't using some, why do it?). Now, if you jack the 8 textures up to 128, you'll need 16 bytes or 4 32-bit numbers to represent the 128 textures. Consider looping through 128 textures for a 50x50 quad when only 28 of the textures are used in that area, or you could just grab the 4 32-bit numbers and logical OR them and know exactly which textures to sort through.

Long explanation, and I'm in a hurry because lunch time is up, but I hope it helps. I would have liked to write out some pseudo-code, but let me know if you don't follow. Sorry for the rushed response!

You might want to batch quads that have the same textures, you might be able to create a texture atlas.


If use an atlas you might be able to do the whole terrain with one triangle dump. Since it looks as if older hardware can handle: 65535 triangles.
http://www.seiken.co.uk/momm/forum/index.php?showtopic=5262&st=0

[Edited by - Aiursrage2k on September 15, 2005 2:59:22 PM]