Manage VBO/VAO in a graphic engine

Question

I'm trying to make a 2D Graphic engine for training me. I've actually made it with immediate draw and I've made the renderer outside (so I can switch between OpenGL and DirectX).

How can I manage Vertex Buffer Object and Vertex Array Object? I've made a geometry object, and I don't think VBO and VAO need to be here.

It is the work of my renderer to manage the scene? (Group object in a large VBO, hide object out of screen, Order object by transparency, …)

More explications on my architecture:

• Spacial : Spacial element containing spacial elements (like a node).
• Mesh : Object with a geometry and a material
• Scene : Manage spacial element (like mesh) and lights.
• Renderer : Draw the given scene (mesh and lights)

Where I should manage buffers (Index buffer, Vertex Object Buffer and Vertex Array Buffer)? In first, I started to put them in the Geometry class, but it seem obvious because a buffer can stock multiple Geometry object.

So, I'm thinking to put buffers in a buffer manager (in the scene object) -> Scene can manage meshes (order + static/dynamic to regroup them in buffers).

What do you think about that?

Thanks!

Answer 1

If this is for desktop OpenGL or OpenGL|ES 3 and you're doing a common 2D sprite-style engine, you won't have a lot of repeat geometry. Everything is quads. You only need a single vertex buffer and index buffer (describing a quad). Use instancing to put all the transformation matrices for your scene objects into a single buffer and then draw that single quad X times (where X is the number of sprites you're drawing) with a single draw call. No need for dynamic buffers, no need to store buffers with "sprites," etc. Even with a fairly complex multi-part sprite animation system, each part is typically just a single quad, all arranged in a tree. You can still render multiple sprites/parts with a single draw call.

Generalizing to 3D (and some more complex 2D needs), each mesh would store the VBO of its attributes and an index buffer. Your renderer would try to group these together to use instancing; that is, if you're drawing 20 copies of the same mesh, only call draw once but use instancing to make that draw call draw all 20 copies. In 2D, there may be some use for this for more complicated objects, like paths or shapes that you need to triangulate, though usually sprites are enough.

For older OpenGL support or OpenGL|Es 2 you can't use instancing. In this case, just keep a single "large enough" VBO for a decent number of sprites. When your scene draws, first insert a transformed quad into the buffer for each object. That is, transform the vertices of a standard (-1,-1),(+1,+1) quad on the CPU to get the world positions of the quad representing that object, then copy those vertices into the VBO (and update the index buffer too, of course). Then draw that single buffer. You may need to split up rendering if your buffer can only hold X objects but you have X+Y objects to draw. E.g., if your buffer can draw 1000 but you have 2456, you'd make three draw calls: one for the first 1000, another for the second 1000, and a third for the remaining 456. In your VBO building loop, just check if the buffer is full after adding each object, and if so, draw and flush the buffer.

Just remember to discard the buffer before reusing it that same frame using glBufferData(vbo_id, 0, NULL, GL_DYNAMIC_DRAW) otherwise you'll stall the pipeline (you can't update a buffer while the GPU is rendering from it). You that call or the newer GL API to discard buffers (I forgot what it was), not glDeleteBuffer, which is something else entirely (recreating a new VBO every time is much slower than discarding a buffers contents).

Answer 2

It depends on how large your buffers are going to be, their usage, and how you work with your shaders.

If you have large static buffers then you should really be grouping them with your mesh and then have your renderable nodes reference their mesh, but since you are talking about 2d I can't imagine this is going to be your style. For 3d meshes that makes a lot of sense though.

For 2d I personally would just create 1 giant dynamic usage buffer that holds enough for say 10k objects, so 10000x2x3 points assuming you are basically working with 2d sprites. Then just you could update sub-sections of that buffer which lines up to an object or the whole thing. This would mean that each renderable scene node would have something like a offset into the buffer.

It may not be efficient for updating and may be difficult due fragmentation and order dependent transparency but it would be pretty efficient for rendering if you could use texture lookups and render it all in a single shader with a single call. If transparency is a big issue you can just be lazy and use multiple layers - thus multiple buffers or calls - like they've done in 2d games for generations.