Ogre Forums

Hello,

in old Ogre you could change the operation type of a buffer after it was created.
The way I understand it, you can't change vaos after they have been created, so I assume you would have to copy the buffers and create a new vao to
change the operation type. However, I am not sure what the best way to copy them is, as there doesn't seem to be a copy method. It would be very
helpful if someone could give me a code example on how to do that. Thanks in advance.

Hi!

Late answer:

I'm looking at the code, the operation type cannot be dynamically changed.

As for cloning with a new type:
Please note the new Vao and the old Vao will both share the same vertex and index buffers. Some classes (such as Ogre::Mesh) own both the Vao and the buffers. So when the mesh is destroyed, it will destroy both the vao and those buffers.

Thus in that case the new vao you created will now cause a crash if you attempt to use it, because it references vertex and index buffers that were destroyed.

If you need full copies you'll have to clone the buffers as well (which you can do using buffer->copyTo()), but note this consumes a lot more RAM.

The implementation of VertexArrayObject::clone performs copies for you if requested, but unfortunately does not allow you to change operation type (this is a bit of an oversight). You're free to contribute an overload to VertexArrayObject::clone which allows changing the op type.

I can only find copyTo in Depthbuffer (in 2.1) and 2.2. Am I correct to assume that this was implemented only after 2.1?

One of our use cases was using the same vertex buffer twice with different index buffers - to highlight certain edges. For now I just create a new vertexbuffer with the special set of vertices. I tried to clone the SubMesh or Vao of the SubMesh but it seems the Vao is immutable.
What is the use case for cloning a Vao, when you can't alter it?
It seems logical for a Mesh object to own its Submeshes and for the Submeshes to own the underlying buffers. In ogre1 you would generate such shared buffers in the Mesh itself. I was looking for the rationale why this isn’t permitted anymore, but could find any information on it.

Vaos sharing the same vertex buffer while an index buffer only uses a region of it is supported. In fact we use it for LODs.

However during unload, SubMesh::destroyVaos assumes submeshes only share vertex buffers with LODs of the same submesh.

If your Vaos share the same vertex buffer between different submeshes, SubMesh::destroyVaos will try to delete the same vertex buffer twice (i.e. memory corruption).

You can avoid this if you manually cleanup the Vaos before Ogre gets the chance to call SubMesh::destroyVaos though.

What is the use case for cloning a Vao, when you can't alter it?

As stated before, not being able to change the operation type during cloning was an oversight. You're free to contribute an overload to VertexArrayObject::clone which allows changing the op type.

It seems logical for a Mesh object to own its Submeshes and for the Submeshes to own the underlying buffers. In ogre1 you would generate such shared buffers in the Mesh itself. I was looking for the rationale why this isn’t permitted anymore, but could find any information on it.

It made loading mesh from files more complex, made ownership of the buffers more loose, and also destruction was more complex.

But more particularly, it caused major confusions in DCC (Digital Content Creation) pipelines. For example modelling programs have no notion of sharing geometry between submeshes (it makes no sense), yet several exporter plugins purposely forced all geometry to be shared between submeshes. I don't know why they did this (perhaps someone thought it was a performance optimization) but it only causes additional trouble during load, and can force 32-bit indices (which is bad) if the submeshes, when combined, exceed 65535 verts.

This is a rarely used feature that caused more trouble than what's worth. But as I just mentioned, Vaos actually do support sharing vertex buffers; hence any advanced user can still take advantage of it (as long as they're careful not to double free the vertex buffers).

Cheers