Sign in to follow this  
pondwater

Assimp, Collada and Inverse binds

Recommended Posts

I'm confused with how Assimp deals with the Bind Shape Matrices (not to be confused with bind transforms for bones/joints) for COLLADA models.

 

Normally this bind shape matrix is baked into the vertices, either before or during the skinning calculations. But for some reason Assimp bakes it into the inverse binds.

 

In the ColladaLoader.cpp:

// apply bind shape matrix to offset matrix
aiMatrix4x4 bindShapeMatrix;
bindShapeMatrix.a1 = pSrcController->mBindShapeMatrix[0];
bindShapeMatrix.a2 = pSrcController->mBindShapeMatrix[1];
bindShapeMatrix.a3 = pSrcController->mBindShapeMatrix[2];
bindShapeMatrix.a4 = pSrcController->mBindShapeMatrix[3];
bindShapeMatrix.b1 = pSrcController->mBindShapeMatrix[4];
bindShapeMatrix.b2 = pSrcController->mBindShapeMatrix[5];
bindShapeMatrix.b3 = pSrcController->mBindShapeMatrix[6];
bindShapeMatrix.b4 = pSrcController->mBindShapeMatrix[7];
bindShapeMatrix.c1 = pSrcController->mBindShapeMatrix[8];
bindShapeMatrix.c2 = pSrcController->mBindShapeMatrix[9];
bindShapeMatrix.c3 = pSrcController->mBindShapeMatrix[10];
bindShapeMatrix.c4 = pSrcController->mBindShapeMatrix[11];
bindShapeMatrix.d1 = pSrcController->mBindShapeMatrix[12];
bindShapeMatrix.d2 = pSrcController->mBindShapeMatrix[13];
bindShapeMatrix.d3 = pSrcController->mBindShapeMatrix[14];
bindShapeMatrix.d4 = pSrcController->mBindShapeMatrix[15];
bone->mOffsetMatrix *= bindShapeMatrix;

 

Is there a specific reason for this? Because this results in a unique set of inverse binds for EACH MESH. So each set of inverse binds is stored with their respective mesh, instead of a global set with the skeleton.

 

I cannot for the life of me understand why Assimp does this. Why not bake them with the vertices instead, or simply store them somewhere.

Share this post


Link to post
Share on other sites

<quote>Normally this bind shape matrix is baked into the vertices, either before or during the skinning calculations.</quote>

Binding that into the mesh data is not very clever. For a start, that would remove the ability to instance geometry (i.e. 1 x shin pad geometry, instanced twice for left & right leg, both instances bound to the rig using different weights). Once upon a time, DCC packages would only let you create one bind pose per skeleton. These days they allow for multiple bind poses per skeleton (such that each skinned mesh can be bound with the skeleton in a different position). There are numerous reasons as to why this is useful (although I'll spare you the details). To answer your question, the way assimp stores the bind pose is actually a fairly decent approach if your aim is to support all DCC apps (maya/max/etc). In your case, you only need one bind pose, so there's a little too much data for you liking. The simple way around this would be to write a small tool that loaded the assimp definition, transformed all meshes into world space, and then construct a new bind pose from that (which you can write out to a file for your engine).

 

 



 

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this