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;
Bug in btHingeConstraint constructor ???
-
- Posts: 849
- Joined: Tue Sep 30, 2014 6:03 pm
- Location: San Francisco
Re: Bug in btHingeConstraint constructor ???
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());
-
- Posts: 3
- Joined: Wed Jan 02, 2013 10:28 am
Re: Bug in btHingeConstraint constructor ???
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???
so that moves the pivot into world space,m_rbBFrame basis will still be in local space of A.
right???
-
- Posts: 849
- Joined: Tue Sep 30, 2014 6:03 pm
- Location: San Francisco
Re: Bug in btHingeConstraint constructor ???
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.
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.