Read bone length

  • On 23/03/2016 at 14:01, xxxxxxxx wrote:

    User Information:
    Cinema 4D Version:   R15 
    Language(s) :     C++  ;

    I have a question regarding the way I'm supposed to read the length of a bone when using Melange.
    Do I have to read the value from the "Tweights" tag of the mesh using the "JointRestState" struct?
    Also, is this value "To child" or "From parent"? Is there a way to convert?

  • On 24/03/2016 at 07:49, xxxxxxxx wrote:


    you should be able to read the length from the joint directly.
    Like so:

    GeData d;
    if (op->GetParameter(ID_CA_JOINT_OBJECT_LENGTH, d))
    	printf("\n - CAJointObjectData Length = %f\n", d.GetFloat());

  • On 24/03/2016 at 08:56, xxxxxxxx wrote:

    Yes, I tried that, and I only get 0 values.

    BTW, for my joint objects, when I do:


    I'm always getting 5100, which is Opolygon, instead of Ojoint. Of course this BaseObjects came from the Execute specific for Ojoint in my code:

    class AlienJointObjectData : public JointObjectData
    	INSTANCEOF(AlienJointObjectData, JointObjectData)
    	virtual Bool Execute();

    Is this a bug? Could it be related to the 0 values I'm getting for bone length?

  • On 26/03/2016 at 11:39, xxxxxxxx wrote:

    Are you sure you're returning the JointObjectData from AllocAlienObjectData() for Ojoint and not Opolygon? And return true from JoinObjectData::Execute()?

  • On 26/03/2016 at 14:29, xxxxxxxx wrote:

    Yes, and yes.

    NodeData *AllocAlienObjectData(Int32 id, Bool &known)
    (...)some other code here(...)
        NodeData *m_data = nullptr;
        switch (id)
            case Ojoint: m_data = NewObj(AlienJointObjectData); break;
        return m_data;

    The id here ir the right one, but then when the Execute is called, the node type is the wrong one:

    Bool AlienJointObjectData::Execute()
    	BaseObject *bo = (BaseObject* )GetNode();
    	std::string name = bo->GetName().GetCStringCopy();
    	int type = bo->GetType();
    	(...) some other code (...)
    	return true;

  • On 01/04/2016 at 06:39, xxxxxxxx wrote:


    sorry, it took me so long to answer.
    Finally I had time to test it.
    Here it seems to work out of the box. I used the commandline example code included in the Melange archive (by the way I used the latest Melange version 16.008_156273 for my tests).
    I simply added the code from my first post to AlienCAJointObjectData::Execute(). It worked right out of the box and printed the length of the joints. Checking the type in there, worked like charm as well, op->GetType() correctly delivered Ojoint.
    So I'm actually not quite sure, what's going wrong on your end. I'd recommend to check with the commandline example as I did and then compare your implementation against it.

  • On 01/04/2016 at 08:05, xxxxxxxx wrote:

    Hello again,

    So I just tested it with the command line example, and I get the same problem, joints detected as polygon objects and length 0. So I assume this was a bug already fixed in the latest versions. I'm using 15.0_131581, I guess I have to update the libs.


    EDIT: aside from the SDK issue, I had this on my BaseObject *AlienRootObject::AllocObject(Int32 id)

    case Opluginpolygon:	baseobject = BaseObject::Alloc(Opolygon); break;

    I have no Idea why this was there, and why it makes the Ojoint become a Opolygon.

  • On 06/04/2016 at 09:18, xxxxxxxx wrote:

    I did check our changelists and didn't find anything regarding the length of joints.
    Did you make any progress?

  • On 22/04/2016 at 08:47, xxxxxxxx wrote:


    Yes, it's working now after removing the line:
    case Opluginpolygon: baseobject = BaseObject::Alloc(Opolygon); break;

    from: BaseObject *AlienRootObject::AllocObject(Int32 id)

    I have no clue why I had this line there, but now it's fixed.

    There's something strange though, I have a simple model with a few bones created in 3DSMax, I saved it to FBX, imported it in Cinema4D and then saved it again in C4D format.
    When I read the bone length from the FBX file, I get values 7 times higher than the values from the C4D file. Everything else is the same, normals, vertices and so on.
    I checked both files in txt format, and confirmed that the lengths are different 7 times lower for C4D.

Log in to reply