Replacing a VBO in an existing VAO

Question

I have a VAO with VBOs for various vertex attributes: vertex positions, vertex normals, and the element array VBO (all STATIC_DRAW), such that rendering an instance simply requires:

glBindVertexArray(vao);
glDrawElements(GL_TRIANGLES, <count>, <type>, 0);

However, I want to draw multiple instances of an object (I'm restricted to the OS X GL 3.2 core profile BTW) with different vertex texture (s,t) coordinates for each instance. The texcoord VBOs use the STREAM_DRAW hint (although I might get away with DYNAMIC_DRAW).

Is it more efficient to bind the VAO, bind the current texcoord VBO, and set the attribute pointer via glVertexAttribPointer, finalize the VAO with glBindVertexArray(0) and draw the new instance with different texture coordinates? Or does the cost of updating a VAO make this a poor approach? What about updating the texcoord VBO with glBufferSubData in a bound VAO?

I'd really appreciate some feedback before benchmarking separate approaches, since the wrong choice will result in significant refactoring.

Kramatorsk

Been looking for more information about this. I'm in the process of upgrading my engine to GL3.2 myself, so will try to post about my findings. – Subordinate

@Subordinate - did you find anything interesting? – Kramatorsk

I've ended up with the "create lots of VAOs"-approach. I do still have the ability to mess with VAO bindings if needed, but haven't had any performance issues with it yet. To be fair, I only have a handful of instances were the same mesh uses different data for a specific attribute. – Subordinate

Answer 1

Simply create multiple VAO. vertex array objects are lightweight, and they are used to setup vertex arrays all at once...

A VBO can be bound to multiple VAO, making your life easier and faster.

If you want, at some point, another attribute configuration, throw away the old VAO and create a new one.

Lekishalela

This is something I considered: VAO setup is not time-critical - it's setup code, but if the texcoords change, a VAO must be created or updated during the rendering loop. My understanding is that VAO setup does a lot of work to validate the buffers, bounds, and internal consistency, so that it can be used efficiently at the expense of initialization costs. – Kramatorsk

If you can't create all needed VAO at setup time, your only option is to profile the VAO create/update solutions and VBO update solution. I've never noticed latencies cause by VAO initialization at loop time, but this is very application specific. – Lekishalela

Luca, thanks for your own observations. VAOs are certainly lightweight, there's a good pseudo-code example here, and the same amount of (shared) VBO data will exist in my code anyway. Have you found switching between multiple VAOs to result in significant latency? Or am I contradicting myself in that VAO bindings should be efficient after the expense of the setup. – Kramatorsk