Results 1 to 7 of 7

Thread: INV_BIND_MATRIX arrays

  1. #1
    Junior Member
    Join Date
    Jan 2011
    Posts
    13

    INV_BIND_MATRIX arrays

    I know that each joint has his own the inverse binding matrix. But in the Collada format in the element "controller" there are inverse binding matrices for each bone in this element. But a bone could be in different controllers several times. And the inverse binding matrices of this bone in each of this controllers must be the same. Is it correct or there are other circumstances which are influencing to this matrices? If there aren`t than it is a simple repetition and an information redundancy in the Collada files.

  2. #2
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771

    Re: INV_BIND_MATRIX arrays

    Each controller is independent and defines its own influences.

  3. #3
    Junior Member
    Join Date
    Jan 2011
    Posts
    13

    Re: INV_BIND_MATRIX arrays

    You, may be, did not understand me. In each controller the joint name (id, name, sid, this is not important) or simple the joint may be repeated. But the inverse binding matrix of this joint must be invariable. So is it a simple repetition and an information redundancy in the Collada files?

  4. #4
    Senior Member
    Join Date
    Aug 2004
    Location
    California
    Posts
    771

    Re: INV_BIND_MATRIX arrays

    Quote Originally Posted by Itun
    But the inverse binding matrix of this joint must be invariable.
    Sorry, your assumption here is not true between controllers. Each skin controller defines its own set of influences in COLLADA. The <joints> element describes the relationship between joint nodes and inverse bind matrices for a given controller.

  5. #5
    pondwater
    Guest

    Re: INV_BIND_MATRIX arrays

    Im sorry to revive an old thread but i'm just wondering if you could clarify something for me.

    You state that each skin controller defines its own set of influences in COLLADA with <joints> describing the relationship between joint nodes and inverse bind matrices.

    So does this mean that it could be possible for the same joint can have different inverse bind matrices depending on the skin controller? I'm assuming so which is why they wouldn't be stored in the along with the joints in the visual_scene node.

    I always thought the inverse bind matrix of a joint is simply the matrix to reverse its bind pose transformation (thus setting it to 0,0,0 in model space). So i'm confused as to how a it could have multiple inverse bind matrices.

  6. #6
    Junior Member
    Join Date
    Sep 2012
    Posts
    3

    Re: INV_BIND_MATRIX arrays

    OK, this is going to be somewhat lengthy, I hope I got your question (and the answer) right.

    Skinning is a process for geometry deformation by attaching the vertices of a 3D model to the joints of a skeleton, then linearly weighting vertices to the joints of a posed skeleton. In the COLLADA spec, this process actually is specified in 2 parts:
    a) the <skin> controller (child of <controller>) specifies the vertex-joint attachments, and for each joint, its inverse bind pose matrix which converts vertices from model space to joint space;
    b) the <skeleton> (child of <instance_controller>) that defines the root of the joint nodes hierarchy (these nodes are of type="JOINT", and its sid attribute maps to the corresponding joint in the skin controller).

    Remember, in COLLADA you can only animate nodes, not the skin controller directly. When you instance a skin controller, you must also specify a <skeleton> element to make the connection between a skin controller instance and the animable nodes hierarchy.

    Sharing is mutual between skin controller and skeleton: the same skin controller can be paired with multiple skeletons using <instance_controller>; conversely, the same skeleton can be paired with multiple skin controllers, too (at least in theory).

    A joint in a <skin> controller only defines its geometric information: the name of the joint, the vertices attached to this joint, and the inverse bind pose matrix. A node in visual scene is associated with this joint in a <skin> controller by sid-matching, and the node hierarchy of the skeleton itself defines a hierarchical transformation pipeline that can be animated.

    Back to your question. Yes, a joint in a node hierarchy can have different inverse bind matrices on different skin controllers if the skeleton that contains the node is paired with multiple skin controllers. But as far as one skin controller is concerned, you always have one set of joints, each joint is associated with only one INV_BIND_MATRIX.

    Hope that makes sense. I would also recommend reading the <skeleton> section in http://www.khronos.org/files/collada_spec_1_5.pdf (p. 5-131).

  7. #7
    Junior Member
    Join Date
    Aug 2012
    Posts
    5

    Re: INV_BIND_MATRIX arrays

    A quick comment from a co-worker to complete this answer:
    "I would clarify more by saying that the IBM (inverse bind matrix) depends of the skin AND the joint.
    So it is not just because this is a fixed joint that you'll get the same IBM. It depends on the skin."

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •