I'm currently looking at Geometry Clipmaps (Hoppe). It has a really nice, fast and intuitive lod and frustrum culling system. It uses vertex texture lookups and only a few draw calls per frame.

http://research.micr...pe/proj/gpugcm/

On draw call count.

Having a lot of draw calls is not so bad in GL.... at least it was not when I stopped using it. Regardless of what performance might be... is performance enough?
If memory serves GL is (or was) very fast at issuing draw calls, the difference against D3D9 was incredible for short batches.
I'd just keep going for the time being, benchmark and see.

I use direct3D 9 currently so batches can often be a problem for me (I have some Atoms around, those are incredibly limiting). What I did is to put every lod level in the same buffer. That way, if two nearby tiles have the same lod, I can merge two batches into one.
The method does not always works, I'd say the performance benefit has been lower than expected. Drivers have also improved and changing buffers is not much of a problem nowadays, even on old drivers (but I still save on them for the good of Atoms).

On big terrains and reductions.

I'm not really on the dynamic buffer approach. Keep everything static first if possible.
I'm afraid it is necessary to write a second terrain system for large terrains. If the asset fits the memory, use a static, chunked mode. If it doesn't use streaming geoclipmaps.
It is worth noticing that to partition an IB nobody requires to actually split it in multiple IBs, just working on the draw call data will deliver the same (albeit I might be misunderstanding what you're writing).
For example consider four chunks
AB
CD
If their indices are sequential and they end in the same LOD bucket then they can be drawn in a single call, where [font=courier new,courier,monospace]DrawCall(ABCD)[/font] can be trivially inferred.
It is also possible to do it the other way around, figure out [font=courier new,courier,monospace]DrawCall(A)[/font] from [font=courier new,courier,monospace]DrawCall(ABCD)[/font], but I'd prefer the former.

A long question with a likely long complicated answer. For context I am using OpenGL 3.3+.

I am already able to take a height field and generate a terrain. I've subdivided it into a quad tree structure for frustum culling. The method is simple and likely a performance killer. Each leaf in the quad tree has its own vertex buffer and index buffer (so VOA object in OpenGL). When I traverse the tree I end up having many draw calls (bad). There is no LOD yet.

What is the best approach here to gain some performance but also get LOD in there?

One approach would be to traverse the quad tree building a dynamic vertex buffer each frame. This will get me one draw call but seems awfully slow. It might solve problems with a giant list of vertices where I can queue up vertices up to some max, draw, then queue the rest and draw.

Another approach. I could use a global vertex buffer for the entire terrain (set once, reside on GPU). This single global vertex buffer seems problematic for large terrain. The height fields are very large, 2048x2048 for example. Each quad tree leaf can contain a set of index buffers, one for each LOD.

I believe each index buffer for each LOD is identical for each node. So I need to just store a small list of index buffers to select from when rendering a node.

This logic becomes circular as I try and choose between multiple draw calls or batching into fewer draw calls. Should this even be a concern.

I googled around a bunch, read some articles. There seems to be a ton of approaches. I became rather confused on when to combine what methods. I'm hoping someone here can scope my thoughts, push me towards one method to try out.

Any articles you have found useful covering this stuff would help.


Thanks!