Physics Simulation Forum

I've been putting together a skeletal animation/dynamics system using two identical skeletons. One skeleton's joints are keyed/animated. Each of the second skeleton's bones (section between each joint) are set up as a rigid body with a btGeneric6DofConstraint between each rigid body pair.

Each frame, I calculate the proper orientation of each joint's constraint from the keyed/animated skeleton, and set the driven skeleton's 6DOF constraint joint angular limits. This works great within a limited range of joint orientations.

Unfortunately, once a joint exceeds +/-90 degrees, the constraint goes haywire. I finally looked at the source for the btGeneric6DofConstraint and found that the y-axis is limited to +/-PI/2, explaining the strange behavior.

For now I am planning to rotate the joint space such that the y-axis maps to each joint's twist axis (which should never exceed +/-90 degrees). Hopefully the x and z axis limit of 180 degrees will avoid this problem... If not, I'm not looking forward to rolling my own custom constraint code.

To the Bullet developers: is there any plan to increase the angular limit range for future Bullet revisions? Or, to create a quaternion based "orientation-matching" constraint? This would be extremely useful for me, and I imagine, for others in the future.

Well, the major issue here is probably that the 6DOF Constraint animations are not "quaternion based" but "Euler axis based". Is that the reason of your "limited" range of joint orientations ?A quaternion-based hinge constraint would be very useful indeed (and it would require just one motor instead of the 3 in a 6DOF constraint): basically, as far as I can understand it, this "quaternion hinge" should be able to change its "hinge axis" based on a "starting" orientation quaternion and a "target" quaternion (without doing any "slerp" rotation, just setting up a motor for it); if somebody knows how to implement it, he's welcome (but I guess it would still be difficult to add "Euler angles limits" to such an implementation: so there are some advantages in sticking to 6DOF constraints after all...).

As far as the 360° rotation around the Y axis with the current implementation of the 6DOF constraint, it's possible and it's working good. See this link: http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=4457 (it seems to work with the X or Z axis free, since the Y axis must always be in [-SIMD_HALF_PI,SIMD_HALF_PI] ). I suggest you use a recent Bullet version for this fix (viewtopic.php?f=9&t=5046&hilit=spinning+like+crazy).

PS. You may try the code I posted some time ago as a guideline: http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=7676&p=27180&hilit=limits#p27180

Thanks for your response - yes, the main problem seems to be that the constraint solver uses Euler angles, and in order to avoid orthogonality problems, one axis must always be limited to +-90 degrees (as you noted). Unfortunately, in my case your proposed solution will not work. As far as I have researched, all solutions involve allowing one axis to freely rotate. I need to lock down all axes, with each axis low/high limit set to a single value in the range [-PI, PI]. In essence, I need to constrain the rigid body to a single rotation matrix in a full sphere range of rotation. In Bullet, there is currently no solution for this type of problem, but it seems to me that it would be a common desired feature in many physics simulation projects.

So far, it seems the best solution would be a quaternion-based 3DOF (rotation only) constraint. This is discussed by Claude Lacoursière in his PhD thesis "Ghosts and Machines", as noted by Erwin here:

PhD thesis on numerical methods for rigid bodies

Dirk Gregorius posted a response here on gamedev.net, referencing the book "Game Physics Pearls", which has a chapter on the topic of quaternion constraints. In the post he mentions that he implemented a rigid body engine using quaternion constraints, and the solutions are more stable vs Euler angle constraints.

I am going to order a copy of the book and take a look. Has anyone else either implemented this or thought of doing so? This would be a really cool addition to the Bullet physics library - 3DOF or 6DOF quaternion based constraint, thereby avoiding range limitations to angle limits.

Well, actually all that (I think) I've managed to do is to replace a rigidBody->setAngularFactor(0,1,0) with a "one axis free" 6dof constraint and that seemed to work in almost the same way. I haven't tried to lock the Y axis to a different limit range (>90 degrees) so I don't know it it works.

Basically I've implemeted this replecement as a test using this demo as a starting point http://bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=17&t=7855 (the demo uses the Y "angular factor" to prevent the ragdoll from falling) and it seems to work. The advantage is that I can lock the Y axis while walking so that the character can keep a precise direction, and I can apply a velocity motor to it while the right or left keys are being pressed to make it turn right or left.

Of course it's still Euler axis based, but it works when the character is perfectly vertical.

Thanks for the documentation you're posted; it seems interesting.

Useless to say that I would appreciate a similiar addition too.

I just came into this issue, and to be honnest, I didn't expect such a restriction in such a hi-end physic engine

Now, in my case I have been able to easily implement a workaround (frame basis change), however, I would second the need for a unrestricted 6 DOF constraint !

Still ,thanks guys for your work

At some stage I'll look into implementing a quaternion constraint. There is plenty of other work first though.

What about the btConeTwistConstraint? You use a quaternion to set the motor target.
Wouldn't that be the 3DOF quaternion constraint you are talking about? If not, what would be the difference?

I tried the btConeTwistConstraint and it will point to the direction set by a quaternion via setMotorTarget. Unfortunately I am unable to control the motor force, so it is always at maximum and the rotations are almost immediate. m_maxMotorImpulse is only used for the obsolete constraint solver. And if I turn the obsolete solver on the body attached to the constraint will just vanish with m_maxMotorImpulse >= 0
Would it be hard to make the motor force adjustable? I looked through the code, but my understanding about bullet's inner workings and physics (engines) in general is way too low to make the right changes.