Assimp Skeletal Animation Follies

Started by
10 comments, last by Enalis 11 years, 9 months ago
I've gone through all of the motions of adding skeletal animation with assimp to my game engine, but it seems I'm not quite generating transforms correctly or something. I have my AssimpImporter.h/cpp source file which reads all of the data and stores it in the data structures in Animation.h/cpp.

Basically I store a tree of Bones for the bind pose and each bone knows it's parent and children, as well as it's bind pose offset matrix which I believe are pre-multiplied, but I'm not sure.

I also store an "Animation" which has for each bone id a vector of time stamp/transform component pairs.

When animating, I pass a timestamp into the animation and it loops through those components for each bone and generates a list of transforms and returns those.

Then I take those and for each one multiply up the tree of bones starting with that bone's bind pose matrix.

The issue is that my model goes from nicely rendered static model to a mess of data with some unanimated parts blatently showing just fine like my character's head just floats around in the mess of triangles, fully in tact.

I've verified by other means that I'm sending in the weight and bone index data property as vertex attributes.

Basically I need someone to take a look at the way I'm calculating my bone transforms and double check my math, hopefully given some knowledge of assimp and glm going together.

here are links to my github page's code for the relevant files...

My Transform Generation is in Here: (Ignore the fact that it prints lots of junk)
https://github.com/p...Source/Math.cpp

Assimp Loading Code:
https://github.com/p...simpInterface.h
https://github.com/p...mpInterface.cpp

Animation Code:
https://github.com/p...ics/Animation.h
https://github.com/p...e/Animation.cpp

Thanks ahead of time for any insight, as I'm at a loss...
If you want any screenshots, do't' hesitate to ask!
Douglas Eugene Reisinger II
Projects/Profile Site
Advertisement
Have you tried something very simple, like using one bone and one triangle that is animated?

Doing that, define two key frames (with no empty frames in between). One that is the same as the rest position, and one that is simply translated in 'x' (or whatever). Check if this works. After that, test a rotation, without translation.

When you got one bone working, try two bones, where one is the parent of the other. This means the transformation matrices have to be cascaded to get the second one. The mesh can still be very simple, like a quad.

It took me a lot of effort to get it working, and I documented some of the effort at http://ephenationopengl.blogspot.se/2012/06/doing-animations-in-opengl.html.
[size=2]Current project: Ephenation.
[size=2]Sharing OpenGL experiences: http://ephenationopengl.blogspot.com/
Thanks for the advice, I already just ran across your blog yesterday and really clarified how to translate some of the data like quaternions and matrices from assimp to glm for me. I'll likely make a very simple model in blender tonight and give it a go. Thanks for the advice! One quick question, do you have to multiply both the bind pose matrices up the tree as well as the matrices generated from the frame data? Also, is the bind pose in inverse format, and if so do I need to un-invert it?

When you mention cascaded multiplication, do you mean having to multiply up the tree or down it?

Thanks again!
Douglas Eugene Reisinger II
Projects/Profile Site
I think the following:
[source lang="cpp"]

glm::mat4 Utility::GenerateTransform(glm::vec3 translate, glm::vec3 scale, glm::quat rotation){
glm::mat4 scaling_matrix = glm::scale(glm::mat4(1.0f), scale);
glm::mat4 rotation_matrix = glm::toMat4(rotation);
glm::mat4 translation_matrix = glm::translate(glm::mat4(1.0f), translate);
glm::mat4 out = scaling_matrix * rotation_matrix * translation_matrix;
return out;
}
[/source]
May be in the wrong order. I use the following logic:
[source lang="cpp"]

glm::mat4 mat = glm::toMat4(rotation);
mat[3][0] = translate.x;
mat[3][1] = translate.y;
mat[3][2] = translate.z;
mat = glm::scale(mat, scale);
[/source]
[size=2]Current project: Ephenation.
[size=2]Sharing OpenGL experiences: http://ephenationopengl.blogspot.com/
So that got me a lot closer, in fact the head of my model is now in the right place and animates properly, but there's still most of the model is messed up. I'm guess that because the head is correct, it's probably the root bone, and that I'm not multiplying down the tree properly.
Douglas Eugene Reisinger II
Projects/Profile Site
Looks like I missed this part of your post which clears things up, I'll try this right now!




Mesh matrices are relative to the Scene, and has to be computed just like the bones. If that isn't done, all meshes will be drawn over each other, at the same position.
Each node inaiNodeAnim has a matrix that transforms from the parent. To get the transformation matrix of Bone2, a matrix multiplication is needed: Scene*Armature*Bone1*Bone2. This is true for the bind pose, as well as for the animations of bones. But when computing animation matrices, data from aiNodeAnim is used and replace the data from aiNode. When testing that animation works, start with defining an animation at the same rotation, location and scaling as the bind pose. That would give bone replacement matrices that are the same as the originally defined in aiNode.

The above matrix multiplication gives the absolute matrices for each bone. But that can't be used to transform the mesh vertices yet, as it will give the animated locations of the bones. The mesh absolute rest position is Scene*Mesh. Instead of using the mesh transformation matrix from the node tree, a new mesh matrix is computed based on the bones and an offset. There is a matrix that is meant for exactly that, and it is the offset matrix inaiBone. The new mesh matrix is Scene*Armature*Bone1*Bone2*Offs. This is the bone matrix that shall be sent to the shader.[/quote]

EDIT: As it turns out, I think I had this right all along, although, I don't think I'm pulling in the scene nodes all the way to the root, just the root bone's node. This may be the issue, although in my head I thought, if the root bone is the beginning of the model, then why would I need anything above that.
Douglas Eugene Reisinger II
Projects/Profile Site
...
Also, is the bind pose in inverse format, and if so do I need to un-invert it?
No.
When you mention cascaded multiplication, do you mean having to multiply up the tree or down it?[/quote]
Matrix multiplication is associative, which means (A*B)*C=A*(B*C), but not commutative (A*B is not equal to B*A). That means you may go top down, or bottom up, as long as you always have the parent matrix on the left side.
[size=2]Current project: Ephenation.
[size=2]Sharing OpenGL experiences: http://ephenationopengl.blogspot.com/
Hmm... That makes sense but I'm pretty sure I'm already doing that. I seriously suspect that it's because I'm only multiplying up to the root bone and not the root scene node. I'm gonna try your suggestion of doing a simple test with blender.
Douglas Eugene Reisinger II
Projects/Profile Site
Finally got it... it was this snippet


void AnimationState::Update(float frame_time){
EG::Dynamics::Animation *animation = animations->Get(current_animation);
float animation_duration = animation->GetDuration();
animation_time += frame_time;
if (animation_time > animation_duration) {
animation_time = glm::mod(animation_time, animation_duration);
}
// Traverse Tree and Multiply Aptly, as well as apply Bind Pose Properly
std::vector<glm::mat4> unmultiplied_transforms = animation->GetTransforms(animation_time);
for (unsigned int i = 0; i < unmultiplied_transforms.size(); i++) {
Bone *b = animations->GetBindPose()->GetBone(i);
glm::mat4 offset = b->GetOffset();
glm::mat4 result = glm::mat4(1.0f);
std::vector<glm::mat4> stack;
while (b) {
//offset = unmultiplied_transforms[b->GetId()] * offset;
result = unmultiplied_transforms[b->GetId()] * result;
b = b->GetParent();
}
transforms = result * offset;
}
}


Before I was using the offset to store the value, but I realized the matrix math didn't work that way...
Inside the while loop it was:
offset = bone_matrix * offset;

Thank you so much for you help! Seriously!!!

And to anyone else stuck on this, always feel free to visit my github project and look at the code yourself. It may not be the best or most efficient, but it's a jumping off point. :)
Douglas Eugene Reisinger II
Projects/Profile Site
Side note... the code I currently have does not work with the intel hd 3000, which claims to support opengl 3 but appears to be missing some key features.
Douglas Eugene Reisinger II
Projects/Profile Site

This topic is closed to new replies.

Advertisement