Terrain rendering

I''d use Alt 2...

I''ll explain why.

1) Loading an entire vertex buffer for 1024x1024x32x6 (size x, size y, vertex byte count, vertex per tile) = way too much memory usage (around 201 megabytes) That is not counting textures, models, etc.

2) A copy of the terrain needs to be in system memory in case people ALT-TAB. Alt-tabbing will force you to flush the video cards memory, and then repopulate it when focusing back. So, now you need 201 megabytes of system RAM to hold that terrain along with 201 megabytes of video memory. Not only that but alt-tabbing is going to take a long time to flush/reload the data. Ever notice that sometimes games take a few seconds to come back after alt-tabbing. Thats why.

3) You remove the ability to have a seemless or circular world. Lets say you want an expansion pack that increases the size of the world, with the current system, you are limited by system and video card ram, so you are stuck at that size (1024x1024). Lets say you want to increase 2048x2048... You can''t. It would take a gig of Ram. Instead you should load in chunks around the player that can load/unload in another thread. The end result should be the same to the player, but you can make the playing field as big as you want, without being limited by resources.

It might be a little more complicated to use alt-2 but I''d suggest doing it that way.

My grid will be 1025 * 1025 = approx. 1 million vertices, these are shared between tiles, so isn''t the bytecount 1025x1025x32 = circa 32 meg?

Still, it''s a fairly big chunk of memory. The questions is if OpenGL/DirectX can load parts of the buffer or if it needs to load the entire buffer at once...

Chunks/tiles will be culled by view frustum and index buffers placed "on top of" parts of the giant vertex buffer.

Alt. 2 is probably easier to code tho, since then each index buffer would "fit" exactly on top of the tiles vertex buffer; for Alt 1 i''ll need to do some offsetting to get to the correct vertices.