I've been brainstorming a while here, but I keep going in circles and could use some outside input.


I am making a custom engine for my game and I want to do my own code for animation skinning and maybe also some animation editing.


Typically it looks like file formats have just the mesh and the animation stored in separate files and both of them refer to the joints directly in the file. Sometimes they are all together in just one file. This is kind of a mess because you not not just waste a lot of space but because changing animations even slightly becomes a big pain, and any PERCEIVED difference you have in the joints leads to complete garbage. In the past while using Collada, this was a big nuisance to me.


I was thinking maybe it makes sense to store the skeleton separately from all of this. That way I can attach the animations to the skeleton and edit them at will, without worrying about the mesh details at all. And most importantly share them between multiple meshes. Especially in the sense of clothing to mount onto a character. So in code I want to be able to simply have some function like skeleton::mountMesh() and then whatever animations I play for the skeleton and any blending, will also be applied to everything mounted to it.


I guess it's an organizational problem more than anything. It seems like this will make it harder to keep track of everything. I guess if I retain a joint name in all three files then that should be enough to sort everything out, but maybe I am barking up the wrong tree.


Anyone used this approach or know of a format that does?

Skeletons are part of the model data and belong in the same file. In order to share animations between different models you need only a special set of offset matrices post-applied to your otherwise standard matrix set. There is minimal (no) benefit in sharing a skeleton between meshes and it will only serve to complicate your data/file structures.


L. Spiro

Skeletons are part of the model data and belong in the same file. In order to share animations between different models you need only a special set of offset matrices post-applied to your otherwise standard matrix set. There is minimal (no) benefit in sharing a skeleton between meshes and it will only serve to complicate your data/file structures.


L. Spiro

Well, I already stated what the benefits would be. That is not really a question let alone the question I asked, the question is how to implement it best and what will be needed.

Thanks for trying anyway though, I guess.

So for example with collada, every time you export the skeleton it is seen as a completely different skeleton for silly reasons such as the order you click on something.

Now say you want to have various items of clothing mounted to a player model. The skeletons and animations should be exactly the same. They are exactly the same in the application they were created in. Yet due to some minor difference in the export process then they all get twisted up. There is no ready way to tell which is the 'wrong' one. In fact there is not a wrong one per se but you have one animation which is 'wrong'.

So you create one character with 10 sets of clothing. There's really just one skeleton, and perhaps a dozen animations. But on the disk and in memory you have 130 skeletons stored (one in each animation file and one in each mesh file). One or two are likely 'wrong' and will not play correctly. This is also a lot of wasted space. Even more so because some of the clothing aticles would be a pair of pants for example and be binded to only a tiny portion of the skeleton.

The fact it doesn't work this way in animation tools is probably a good indicator it is artificial and not something really needed. In maya the skeletons are nothing to do with the objects. What the heck would they be like that for? If you want to use the skeleton and all the animations attached to it you simply smooth bind the mesh to them.

I am planning to do the same in my engine. Though I am not sure whether it makes more sense to store the jointnames or simply store the weight indices of the skeleton (as maya does) and then rebuild the weights if the skeleton changes.

So for example with collada, every time you export the skeleton it is seen as a completely different skeleton for silly reasons such as the order you click on something.

Now say you want to have various items of clothing mounted to a player model. The skeletons and animations should be exactly the same. They are exactly the same in the application they were created in. Yet due to some minor difference in the export process then they all get twisted up.

When you're importing the skeletons, can't you sort the nodes into some kind of deterministic order, and then assign deterministic IDs to them?

If skeletons in two files are missing bones (e.g. It's common for the animation to contain bones that are not present in the model) then just match up the bones between the two files using the names of the nodes, and build a lookup table that converts bone IDs in one file to IDs in the other.