rendering a scene graph with a constant number of draw calls

My app’s renderer does some batching of geometry but the draw calls issued are still proportional to scene graph size. I’m still CPU bound, because of scene traversal, among other things. I can continue to optimize that, but I also wanted to consider other options.

The vast majority of geometry doesn’t change between frames, so I’m wondering if this sort of architecture would be a good idea:

To render a frame:

[li]The renderer processes a list of scene changes and updates the VBO(s) representing the entire scene[/li][li]The renderer calls glDrawElements a constant number of times (not proportional to scene size) to render all geometry[/li][/ol]

VBOs of different usage (GL_STATIC/DYNAMIC/STREAM_DRAW) could be used according to the frequency with which things in the scene change.

The main upside is that there’s potentially very little work outside of GL to be done each frame if not much has changed. But if the tessellation size of something in the scene has changed, then there’s possibly a lot of shuffling and re-indexing of the VBO to be done.

Any thoughts appreciated! :slight_smile:

Thinking a bit more: if I were to use a dynamic allocation scheme for regions in the VBO, then I would only need to shuffle around the index buffer when something changes size.