I can''t figure out a good way to do it quickly and efficiently. My current approach is to fill up an index/vertex buffer for each patch of terrain, render, and keep going. Unfortunately this really limits the size of the patch since I can''t fit everything on the video card. How do the commercial games render so much stuff without getting eight frames per second? I was thinking I might be able to use a vertex shader for my heightmap since each unit is equal to 1 unit on the heightmap and reduce the size of the vertex buffer by 3. It''s the index buffer that really hurts though... I know using 16-bit indices will speed things up but that also increases the number of batches I have to render. Ideas?

In my experience, the problem is not rendering the vast amounts of vertex data... that''s impossible w/ current hardware. The problem is digesting te vast amounts of papers, sites, tutorials that have been written on precisely this subject: smooth LOD degradation of terrain, culling, etc.

For instance, there''s a good article on Gamasutra called "Real-Time Dynamic Level of Detail Terrain Rendering with ROAM" which is useful on the subject.

If this is not trying to do, maybe post a more detailed explaination of the problem.

Tom

Ahh, forgive me. I forgot my initial calculations... 8 fps with 2.05 million triangles per frame isn''t too bad I suppose . I was going to implement that quadtree based algorithm (looks similar to ROAM). I get fairly good performance when I stick to about 130,000 triangles per frame (about 100 fps) so I should be good to go. Is 12.5 megabytes of vertex data plus 1.5 more for the indices (or .75mb if I go with 16-bit indices) for the terrain too much to ask?

CLOD and ROAM have become outdated. They do a lot of computation on individual triangles and aren''t suited for current video cards. Look up "Chunked LOD" and "Geomipmapping".