Page 1 of 1
Bug in btHingeConstraint constructor ???
Posted: Tue Oct 24, 2017 8:24 pm
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;
Re: Bug in btHingeConstraint constructor ???
Posted: Wed Oct 25, 2017 12:27 am
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());
Re: Bug in btHingeConstraint constructor ???
Posted: Wed Oct 25, 2017 7:36 am
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???
Re: Bug in btHingeConstraint constructor ???
Posted: Wed Oct 25, 2017 4:25 pm
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.