Hello, I'd like to know more about the nature of a certain piece of data in skeletal model formats that we tend to run into making games.

For a while already, I had assimp as a dependency to my framework. I used it with success to import models with geometry and textures, and the mesh hierarchy. I also made skeletal animation work, for the most part (example, all mixamo meshes work perfectly). There's a bit of theory here that I don't understand and I'm suspecting that the reason that SOME meshes aren't working fine for me is because I fail to understand this.

For those unfamiliar with it, assimp prunes all bones from the skeleton in the file that do not directly influence a mesh. That means that while loading the bone hierarchy, we will only get “influencing” bones from it. For models where these happen to be all the bones required, that's easy, just read them and chuck them in your own format while keeping the hierarchy intact, yada yada… this I had working for a long time.

For models where that's not the case, we need to seek upwards from loaded bones and get all their parents, stopping when we hit another bone or skeleton root (which is, usually, a child of the scene root but not always). Guessing what the skeleton root is can be magic across various formats… but mostly stopping one level away from root node works. This step is fairly easy, we just basically need to connect the graph and read in transformations.

Now here's the problem - sometimes, these missing bones HAVE animation channels in the animation that's loaded. In order for animations to work right, -IF- I am right (might be different for these bones), we need to use the bone offset matrix (or whatever you like to call it, shifts from mesh space to bone space). I know how to calculate this matrix for the newly found bones, thanks to @buckeye ‘s posts around here (thanks a lot), and it comes out the same when testing against assimp’s precalculated matrices for existing bones.

But… calculating that bone relies on the matrix of the mesh that the bone is influencing. Sometimes, these missing bones are parents to several “branches” of the skeleton which in turn each affect different meshes. This seems nonsensical. How can I calculate the offset matrix for them if they affect multiple meshes, this implies you might need multiple ones for bones like that, which is something I never saw.

I must be misunderstanding something here. Do these “non-influencing” bones maybe not need the offset matrix at all? Do I just keep it identity and the animation is already made in such a way they work without it? I have been suffering through trying to fix these edge cases for days and honestly I'm no closer to fixing it.

I have identified the error that was producing bad results in some of the meshes. Some are decidedly just corrupted / badly exported files as none of the “official” viewers i tried (blender, ue4, fbx review etc.) played them right. I know this might look a bit soon but in fact I was looking for the error for quite some time, and the error was, as it happens (too many times) in entirely another place.

Turns out this all works without me calculating offset matrices for those missing bones. Strange but I'll take it. However, I would still be curious as to why that works that way.
Are the intermediate bones animated in such a way that you don't need to use the offset matrix? My guess is because they don't end up transforming vertices directly, and vertices are the entities that really need the bone offset matrix to go to the origin before being animated, while these bones can just work in parent's local space right off the bat. If anyone understands this better, I'd still like an explanation out of curiosity.

Here I wrote a quite long explanation on mOffsetMatrices, maybe it is helpful to you: https://github.com/assimp/assimp/issues/2773​​

I also run into the problem of missing bones in animations, this topic might shed some light on the issue: https://gamedev.net/forums/topic/704491-importing-skeleton-from-assimp/​ I'd recommend to study the source of assview (linked in that topic) which clearifies things that are not explained in the documentation.

Cheers,
bzt