Jump to content

  • Log In with Google      Sign In   
  • Create Account

FREE SOFTWARE GIVEAWAY

We have 4 x Pro Licences (valued at $59 each) for 2d modular animation software Spriter to give away in this Thursday's GDNet Direct email newsletter.


Read more in this forum topic or make sure you're signed up (from the right-hand sidebar on the homepage) and read Thursday's newsletter to get in the running!


Assimp, Collada and Inverse binds


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
1 reply to this topic

#1 pondwater   Members   -  Reputation: 191

Like
0Likes
Like

Posted 21 December 2012 - 07:31 PM

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.



Sponsor:

#2 RobTheBloke   Crossbones+   -  Reputation: 2341

Like
0Likes
Like

Posted 24 December 2012 - 08:33 AM

<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).

 

 



 






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS