Bug in btHingeConstraint constructor ???

Post Reply
John82
Posts: 3
Joined: Wed Jan 02, 2013 10:28 am

Bug in btHingeConstraint constructor ???

Post by John82 »

For constructor btHingeConstraint::btHingeConstraint(btRigidBody& rbA, const btTransform& rbAFrame, bool useReferenceFrameA)
In File /src/BulletDynamics/ConstraintSolver/btHingeConstraint.cpp line 182

m_rbBFrame is been set to m_rbAFrame,

shouldnt it be m_rbBFrame = m_rbA.getCenterOfMassTransform() * rbAFrame;
User avatar
drleviathan
Posts: 849
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

Re: Bug in btHingeConstraint constructor ???

Post by drleviathan »

It looks like m_rbBFrame is adjusted later in that ctor:

Code: Select all

    ///not providing rigidbody B means implicitly using worldspace for body B

    m_rbBFrame.getOrigin() = m_rbA.getCenterOfMassTransform()(m_rbAFrame.getOrigin());
John82
Posts: 3
Joined: Wed Jan 02, 2013 10:28 am

Re: Bug in btHingeConstraint constructor ???

Post by John82 »

m_rbAFrame is in local space of A,

so that moves the pivot into world space,m_rbBFrame basis will still be in local space of A.

right???
User avatar
drleviathan
Posts: 849
Joined: Tue Sep 30, 2014 6:03 pm
Location: San Francisco

Re: Bug in btHingeConstraint constructor ???

Post by drleviathan »

Yes, that is what it looks like to me.

Looking in more detail at btHingeConstraint and its base class btTypedConstraint... it appears that btTypedConstraint keeps around a static "fixedBody" that is uses as a proxy for the ObjectB when the ObjectA is hinged to the world. ObjectB is probably located at the world's origin with identity rotation (I'm guessing here since I didn't follow that thread of code, but it makes sense), so effectively what is happening in this case is: the effective ObjectB-local axis of rotation is being set to agree (in the world-frame) with whatever is the current (world-frame) orientation of the ObjectA-local axis.

In other words: at the moment the hinge is created both world-frame-transformed versions of the local axes (A and B) are parallel to each other.

Or to put it yet another way: it works out because ObjectB in this case always has the identity transform: there is no need to explicitly compute the inverse transform from B's local-frame to world-frame.
Post Reply