Batching vs. Culling

one way (but this might be even slower than a lot of calls with low poly counts):

have a preallocated index array the size you consider "good" and use triangle lists (no strips).
when a leaf is not culled, memcpy its indices to the allocated array and draw it when its full. but you will have to test if the overhead of many calls to draw is worse than copying all the buffers around. also: i think there is an extension that would let you draw multiple arrays with one call. multi_draw_arrays if im not mistaken though i dont know if that only works with vertex buffers.

Memcpy''ing all of the non-culled triangles is about the best I came up with, too. I couldn''t do that as a triangle strip, though, certainly not without a per-frame method to rebuild the index buffer, so I''d have to go with triangle lists. I think this is the method I''ll try. Memcpy is pretty quick, and it woudl allow me to batch the polys, which I think would give me the best speed boost.

dont worry about the strips too much.. usually a tri list is as fast or faster if youre building it in a way that will reuse as many vertices as possible while they are still cached.

Here's an update:

I implemented simple brute-force terrain from a heightmap, as a triangle list. Ran ok (30+ fps) at 32x32 and even 64x64, but became a pig at 128x128 (under 20 fps). The vertex buffer is one vertex per heightmap pixel - no additional tesselation. I am not doing any culling, either, other than back-face culling.

I looked into using a triangle strip for each tile, which would cut the vertex count down by a third, but I couldn't figure out how to set the vertex normals - as a list I set each vertex normal to the face normal for the triangle they defined. Anyone know how to set vertex normals in a triangle strip?

I've heard that brute force is making a "comeback" of sorts against the various CLOD methods. What am I missing about brute force - I don't think it is feasible even for my relatively small terrains.

My next step is to do a quad tree and cull everything that's not visible. That should give me a good bump in FPS. Maybe after that I'll do some CLOD.

[edited by - SDyer on May 18, 2003 2:23:08 PM]

*bump*

One last try to hear from someone who is knowledgable on brute force terrain rendering, specifically how it can be effectively used for larger terrains.

As I see it now, to render even a 128x128 terrain I''m having to go with some sort of CLOD.

hm.. im having a terrain made up of 3x3 sectors of 512x512 size. one of them could be displayed at highest detail (barely), but you still need some kind of lod. the "brute force" method in this case is that you dont start generating your geometry every frame (like with roam), but instead have one vertex buffer and different index buffer for differend lods (skipping more and more vertices). geo mipmapping is what you''re looking for in this case ,-)

of course you should still use culling (though a single 128x128 patch shouldnt be that slow).

for strips you need to have one normal for each vertex, else its more than one vertex and strips wont work. you would therefore use the average normal (or drop the normal and use a normal map and per pixel lighting.. its faster than vertex lighting anyway ,-) )

i admit my terrain looks kind of small with the reduced visibility, but that was necessary to hide the loading of new sectors. potentially the terrain is endless (using the same height map for every sector which would should of course be changed to use a world map of height maps).

the loaded terrain is 1539x1539 at any time, using brute force culling (faster than a tree for this size) and brute force lod (if you want to call geomipmapping brute force).

but consider that even ut2003 is using 256x256 heightmaps without any lod at all. small terrains really shouldnt be a problem.