Hello everyone. The collada skinning equation is the following:

v +={[(v * BSM)IBMiJMi]* JW}

[li]n : The number of joints that influence vertex v[/li][li]BSM: Bind-shape matrix[/li][li]IBMi: Inverse bind-pose matrix of joint i[/li][li]JMi: Transformation matrix of joint i[/li][li]JW: Weight of the influence of joint i on vertex v[/li][/ul]
So far I understand. What I do not understand is how this applies when a particular bone is son of another bone.

Should I do this?

v +={[(v ParentBSM BSM)ParentIBMiIBMiParentJMiJMi]ParentJW JW}

Or, what do I have to do so that the transformations of the children are done well in relation to the parents?

Thank you very much for your help.

If I’m not mistaken there is code here (https://sourceforge.net/p/collada-dom/code/HEAD/tree/trunk/rt/src/CrtController.cpp) where I’ve implemented this for arbitrarily parented skeletons and morph targets.

I think normally you roll IBMi and JMi together somehow, so they are one matrix. Then you multiply as a chain just like with static geometry. Depending on how things are set up I think IBMi may be optional. BSM is probably optional too. This is not really a COLLADA problem. But there you are :slight_smile:

P.S. These are all conveniences for artists. An efficient animation isn’t parented, and doesn’t require bind-poses, etc. You want to get rid of all those things if your application is not arts software.

EDITED: In that link… don’t read the following comment… It’s driving me mad now trying to think of what I had to say!
//COLLADA uses the concept of a “base mesh” but it
//is really no different from another target. Most
//systems won’t make this distinction, since there
//is a need to blend key frames when all are equal.

I am going to try. Thank you very much for your response, friend :slight_smile:

This is good question I think,

I guess BSM and IBMi are in world space (I’m not sure for certain), in this case there is no need to ParentBSM and ParentIBMi, but JMi is joint transform (in scene graph?) and that is hierarchical so ParentJMi is needed (assuming we are speaking for world-space skinning). JW is weight of a specific joint so why do we need to ParentJW? I guess we don’t.

Here what I did:


jointMatrix[i] = jointTransformInWorldSpace[i] * skin->invBindPoses[i] * skin->bindShapeMatrix
JMi  = jointTransformInWorldSpace[i], joint transform (not inverse) in scene in world space
IBMi = skin->invBindPoses[i], comes from collada file, see INV_BIND_MATRIX input in <joints> element
BSM  = skin->bindShapeMatrix, comes from collada file, see <bind_shape_matrix> in <skin> element
JW   = WEIGHTS in shader
n    = used as 4 for now like vec4.

Vertex Shader:



layout (std140) uniform JointBlock {
  mat4 uJoints[JOINT_COUNT];

in uvec4 JOINTS;
in vec4  WEIGHTS;




  mat4 skinMat;

  skinMat = uJoints[JOINTS.x] * WEIGHTS.x
          + uJoints[JOINTS.y] * WEIGHTS.y
          + uJoints[JOINTS.z] * WEIGHTS.z
          + uJoints[JOINTS.w] * WEIGHTS.w;

  pos4  = skinMat * pos4;
  norm4 = skinMat * norm4;




  gl_Position = VP * pos4;


  gl_Position = MVP * pos4;


I used jointMatrix as uJoints in vertex shader.

In the future I may update my implementation to improve or fix bugs…

@Recep, hey, just FYI I’ve been developing COLLADA-DOM again what seems like all through December and January. It’s driving me nuts to get it off my back. The new round of code started back further, in October. I took a break shortly after, but after beginning again sometime in December I have just been trying to find a stopping point. Everything in the new code I would file under advanced XML features/facilities (https://sourceforge.net/p/collada-dom/discussion/531263/thread/6445b0224b/)

@Mick P. It is good to see you are working on that project again, hope you will finish all parts as soon as possible for production use.

Off-topic: I think it works under release-builds and GCC. It’s far surpassed the original library, and has included all of the original features since I completed the ZAE feature some time ago. I’m not 100% about GCC, but if the CMake build mode (Release, Debug, etc.) is left blank, it builds without debug data, and is faster, so probably there is inlining. It’s worth noting if so, because often times release builds (with optimization) don’t work because lots of C++ created complicating factors (type-aliasing being a big one.)

Anyway, I uploaded the new, annual update (https://sourceforge.net/p/collada-dom/code/934/) a few days ago. I’m really burned out on it. There’s a lot of new features I’m documenting here (https://www.khronos.org/collada/wiki/ColladaDOM_3) right now, but they are not necessarily reflective of the focus of the new code. Mainly the new code adds XMLNS namespaces, and puts forward a way to retain empty and default attribute values that was absent. But a lot of innovations rose up out of the milieu too amid the grueling 2+ month process. The objective is for a professional grade XML content development library. It’s not for converting or displaying COLLADA documents or anything like that. It’s more about document correctness, in and out, and creating an atmosphere where applications like COLLADA can scale up to the same degree that HTML has been able to.

EDITED: Just wanted to say, I could never get away with updates like this with a regular opensource “project” online, with multiple parties involved (usually just people with nothing better to do than drag their feet to ensure nothing ever improves/evolves) and I think that’s a damning fact for opensource. After years of observing software development in public, I think that single developer is the right way to develop software. If only because people are so flawed.

EDITED: Here are some of the new sections in the wiki reference:


I don’t know… there will probably be more. The dev-log (discussion link) is the best source for blow-by-blow details.

EDITED: Here is a new example header. I will probably make a new topic in the SF forum to describe the update… after I can lick my wounds.