So I'm using Assimp to convert models into my own format, and things work fine if I use Assimp's animation data format. This would store absolute transforms per keyframe relative the the parent bone.

For reasons relating to blending animations and flexibility, I was making my format use transforms relative to the bind pose instead, and this was working very nicely for some models.

I was experimenting with converting md5 models and the Doom 3 player character and hell knight work fine. I got their run straight animations working. The pinky demon though kindof explodes.

I've noticed that the bind pose for the player and the hell knight are 90 degrees perpendicular to their walk straight animation. While the model faces down z, its animation goes down the x axis. The pinky demon, however, faces down the x axis in its bind pose and moves in the same direction.

This ends up making the pinky demon kindof awkwardly moonwalk sideways while also twisting a few bones a bit more than they should be.

One of the artists on our team gave me an animation that explodes similarly once the root bone starts to move in some direction.

The only connection I've made so far is my format only works if the model faces down z and has the root bone translate along x.

I've spent hours trying to debug the math myself. Maybe there's something I'm not understanding about transforms and am making the wrong assumptions about something?

Nice, did you work on Assimp?

I'm still working on the converter but I made it so you can import multiple files at once, which is great for things like Md5 models that I'm using for fun.

I keep my mesh, animation, skeleton, and bind pose files separate. I was hoping that using relative bone transforms I could do something similar to what they did in Gears of War, have female and male characters use the same animations but with slightly different bind poses, and just use relative transforms. I'm not 100% sure this will work, but using relative transforms definitely made my animation code simpler as well.

The skeleton file would keep all bone names to indices and parent hierarchy. The bind pose file would just have bone index to bind pose and offset matrix per bone. I computed the offset matrix manually rather than using the built in assimp bone offset since some nodes didn't have bones referenced from the mesh data. The animations file would just have a bone index followed by its keys, allowing for an animation to not have data on all bones, but only the ones affected by that animation.

Every time you use the exporter, you would either import a previously created skeleton file, or generate a new one based on all scene files imported. This would find all bones in all files and assign indices to them. This ensured that tag bones like SOUL_CUBE_ATTACHER in the Doom space marine would export if I import both the md5mesh file and the md5anim file. The problem before was the md5mesh file held the bind pose needed for the skeleton but assimp wouldn't have reference to some of these extra bones for attaching weapons that were present in the animation file until I made it so I can import both an md5mesh file and an md5anim file at the same time.

When I'm computing the animation keyframes, for each bone, I decompose the bone transform into the translation, scale, and rotation components using the matrix decompose method that comes with Assimp. Then for each key, I compute the translation, scale, and rotation that's relative to those components and export that.

I'm still not sure what would actually cause the animation itself to get a bit weird with the problem that I'm having. It doesn't really explode, it's just some translations seem to be in the wrong coordinate space or something like dpadm450 said. I'm pretty sure that the way I wrote the converter should get around the problems you described would happen because I allow multiple files to be imported at once.

I did find that you can't always consistently decompose a matrix. Like I'd have some translation, rotation, scale, multiply those all together to get a matrix, decompose, and get slightly inverted rotations and scales that would lead to the equivalent matrix if multiplied together again.