Vertex Buffer Object Design for my Engine

[Sarah22]

I'm creating a graphics engine right now that handles both OpenGL and Direct3d. For now, I'm creating the OpenGL part because I'm more familiar with it.

Few minutes ago while building up the interface, I came up with the problem that if I should just have one vertex array/buffer object. If I should just build a huge container that has all the vertex, index, texture coord, and etc on it then pass it to the gl*Pointer then let it draw.

I'm asking this because on my previous application, I have maybe 3 classes that calls glVertexPointer. One for my terrain and 2 for those static/animated objects.

Thank you
Sarah

[Yomboprime]

I'm converting my engine to the new OpenGL api (changing from fixed function pipeline to VAOs, etc)

I'm considering using one buffer object per 'engine object'. That is, per different one, wich I can clone to get different 'instances' (though I'm not using OpenGL instancing)

Just wanted to show my perspective :)

[randall]

If all data is static (won't change during runtime) I would suggest using one buffer object.

[IneQuation.pl]

The way I solved it in my game engine is to have the geometry first loaded into the system RAM, and once the level is done loading, "commit" all of it into a single VBO. I have 3 separate VBO pairs - one for terrain, one for static and one for animated geometry (static and animated geometry are separated because they have different data structures).

The pitfall of this approach is that you can't add new geometry to the level; you have to reload it. It's OK for most applications, though - it can only hurt if you have lots of procedurally generated geometry that changes on-the-fly.

Hope this helps. :)