> Well, each additional object state does not have a big cost by itself, but it adds up and we already have lots of stuff in C4Object. Whether it's in C4Object or another class is not really important.

Thing is that StdMeshInstance is only instantiated for each object that actually uses a mesh, not for _every_ object. It currently duplicates all the vertex data already, by the way (for example to avoid sorting the faces when nothing changes from frame to frame).

> Another thing is that we probably want to store the vertex data on the GPU, because that's the most efficient way to use contemporary GPUs, and preferably neither once for every object nor recalculated every frame. Interpolating between two vertex sets can be done with a vertex shader. I think some games also do the bone animation stuff with vertex shaders, but that is more complex.

Hm, I don't understand how we can avoid uploading the vertex set to the GPU every frame when not also doing the bone animation in hardware. But wouldn't this just involve uploading the transformation matrix for each bone of the current animation (each frame), assuming the vertex bone assignments are somehow known already?

> I think without that, the two or more animations cannot share triangles, so that the drawing function can use one set of precalculated vertex data for one animation and one set for the other.

What is possible already (and is used by the Monster) is that one vertex can belong to multiple bones, and thus can be influenced by multiple animations, even if each animation uses different bones.