Problem: Blender export and parent relations (nodes)

Tauran
2013-07-10
2013-07-12
  • Tauran

    Tauran - 2013-07-10

    I have the following problem.
    Two cubes scaled to 0.5 and moved (<1, 0, 0> and <0, 3, 0>),
    then parented together.

    Parent:

    <matrix sid="transform">0.5 0 0 1 0 0.5 0 0 0 0 0.5 0 0 0 0 1</matrix>
    

    From assimp:
    5.000000e-01 0.000000e+00 0.000000e+00 1.000000e+00
    0.000000e+00 5.000000e-01 0.000000e+00 0.000000e+00
    0.000000e+00 0.000000e+00 5.000000e-01 0.000000e+00
    0.000000e+00 0.000000e+00 0.000000e+00 1.000000e+00

    Child:

    <matrix sid="parentinverse">2 0 0 -2 0 2 0 0 0 0 2 0 0 0 0 1</matrix>
    <matrix sid="transform">0.5 0 0 0 0 0.5 0 3 0 0 0.5 0 0 0 0 1</matrix>
    

    From assimp:
    1.000000e+00 0.000000e+00 0.000000e+00 -2.000000e+00
    0.000000e+00 1.000000e+00 0.000000e+00 6.000000e+00
    0.000000e+00 0.000000e+00 1.000000e+00 0.000000e+00
    0.000000e+00 0.000000e+00 0.000000e+00 1.000000e+00

    Now the second matrix should be:
    mTransformation
    "The transformation relative to the node's parent"
    It's value is parentinverse * transform, but it is not the correct result.

    Where is the error here?

     
    Last edit: Tauran 2013-07-10
  • Tauran

    Tauran - 2013-07-10

    Now I found a case where even the inverse parent matrix seems to be wrong (coming from blender).

    <matrix sid="transform">-0.13 1.04348e-7 0 -2.99497 -1.04348e-7 -0.13 0 0 0 0 0.13 2.2 0 0 0 1</matrix>
    
    <matrix sid="parentinverse">-4.92121e-6 7.692308 0 -23.07692 -7.692308 -4.92121e-6 0 1.47636e-5 2.27374e-13 -4.76837e-7 7.692308 -16.92308 0 0 0 1</matrix>
    

    Inverse of
    -0.130 0.000 0.000 -2.995
    0.000 -0.130 0.000 0.000
    0.000 0.000 0.130 2.200
    0.000 0.000 0.000 1.000

    is
    -7.692 0.000 0.000 -23.038
    0.000 -7.692 0.000 0.000
    0.000 0.000 7.692 -16.923
    0.000 0.000 0.000 1.000

    I made a very hackish change in assimp and calculated the inverse matrices myself and get correct transformations with this approach.

    diff --git a/code/ColladaParser.cpp b/code/ColladaParser.cpp
    index 442896a..0b99214 100644
    --- a/code/ColladaParser.cpp
    +++ b/code/ColladaParser.cpp
    @@ -2346,7 +2346,19 @@ void ColladaParser::ReadSceneNode( Node* pNode)
                            if( IsElement( "lookat"))^M
                                    ReadNodeTransformation( pNode, TF_LOOKAT);^M
                            else if( IsElement( "matrix"))^M
    +                       {^M
    +                               int attrSID = GetAttribute( "sid");^M
    +                               const std::string s = mReader->getAttributeValue(attrSID);^M
                                    ReadNodeTransformation( pNode, TF_MATRIX);^M
    +                               if (s != "transform")^M
    +                               {^M
    +                                       for (uint i = 0; i < 4; ++i)^M
    +                                       for (uint j = 0; j < 4; ++j)^M
    +                                       {^M
    +                                               pNode->mTransforms.back().f[i * 4 + j] = (i == j) ? 1.0f : 0.0f;^M
    +                                       }^M
    +                               }^M
    +                       }^M
                            else if( IsElement( "rotate"))^M
                                    ReadNodeTransformation( pNode, TF_ROTATE);^M
                            else if( IsElement( "scale"))^M
    
     
  • Thomas Ziegenhagen

    What exactly are you talking about? What were you trying to achieve, what did you get, what did you expect instead?

    Currently I'm just guessing, but maybe you got the Collada spec wrong. A node can declare a series of transformations of various kinds, for example Translation, Matrix, Quaternion Rotation, Axis/Angle rotation, and so on. The Collada spec demands all these to be concatenated from last to first. If you load a Collada file using Assimp, the Assimp loader will do exactly this: concatenate all the transformations in the specified order of sequence. You will never get a separate "parentinverse" matrix anywhere, it's multiplied into the overall node transformation.

     
    • Tauran

      Tauran - 2013-07-11

      Thanks for you answer.

      What exactly are you talking about? What were you trying to achieve, what did you get, what did you expect instead?

      I am trying to figure out why I get wrong transformations and not
      mTransformation
      "The transformation relative to the node's parent"

      I guess you are referring to Collada Spec page 139.

      The <node> element represents a context in which the child transformation elements are composed in the order that they occur. All the other child elements are affected equally by the accumulated transformations in the scope of the <node> element. The transformation elements transform the coordinate system of the <node> element. Mathematically, this means that the transformation elements are converted to matrices and postmultiplied in the order in which they are specified within the <node> to compose the coordinate system.

      So if a node has ordered matrices M1, M2, M3. I calculate M1 * M2 * M3 = M (postmultiplied).
      M would be the relative transformation of the child, otherwise it would probably be a bug
      in Blender's collada exporter?

       
      • Thomas Ziegenhagen

        Well... there's still way too much data missing for me to tell what's going on there. And I'm honestly not going to query any further. Start reporting your issue fully without jumping to conclusions, and I might be able to help you. For starters, post the Collada file so I can see for myself, and upload an image of how it looks correctly in your modelling application, and how it actually looks like when you're rendering it.

         
  • Tauran

    Tauran - 2013-07-12

    It's ok. I filed a bug report for blender...

     

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks