ConeTwist Constraint: issues and improvements

[eddybox]

Hi,

I've been working on the ConeTwist constraint lately, and have some additions and fixes I'd like to submit.

Additions:
- I've added motorization. (only to the "obsolete" solver version so far.)
- I've added damping. (ditto)
- I've reworked the limit softness. (ditto)


Fixes:

- More accurate/stable swing-twist limit calculations. The existing cone/twist decomposition method was giving some wonky results in certain regions (the limit region looked more like a diamond than an ellipse), which became more apparent upon motorization. I now decompose the relative body rotation using quaternions instead of dot products. basically, q_AB = q_cone * q_twist. where q_AB is the relative rotation of body B wrt A in constraint space. I compute q_cone using shortestArcQuat(twist_axis_definition, twist_axis_current), and q_twist from the other two. There are some other subtleties that come afterwards wrt corrective axes so the two components don't interfere with one another.

- Visualization. (btw, in general the visualization additions are great!) The geometric technique used to visualize the conetwist is not the same as that used by the constraint itself. (so the limit problems with the old technique don't show up.) Also, the cone limit itself isn't just an ellipse, it's an ellipse embedded on the surface of a sphere. Imagine swing limit 1 of greater than 90 degrees (say, 120) and limit 2 less than 90 (say, 30) degrees. it can't be drawn/represented as a cone. Instead I've added some code to the constraint which allows limit "querying" which the visualizer can use.

Any questions/comments? Should I go ahead and submit a first (partial) version as a patch?

Thanks,
Eddy

[mhx]

Nice to see that someone got around to improve on my old constraint, I quit the gaming industry before I hade the chance to do so.

Anyways, Before I quit was planning to implement a swing-twist decomposition for the conetwist constraint but in a slightly different manner to what you are describing. Instead of calculating the swing and then twist by multiplying relative rotation by inverse swing,
one can decompose the relative quaternion into swing and twist directly. Have a look in "Quaterions and Rotation Sequences" by Kuipers and look for "orthogonal factorization". With some trig-based simplification, you can get a cheaper but also more exact decomposition of swing & twist.

I'm not sure how it behaves compared to what you have now, but it was a lot more stable and computationally efficient than the old dot product thingy.

Cheers,
Marcus.

[rponomarev]

Hello,

Eddy, could you please post your ConeTwist improvements code here (as an attached ZIP, if possible)?
It will be nice to have a more stable solution for this constraint
I'm going to rework its visualization as well, so your code will be very helpful.

Thanks,
Roman

[eddybox]

Hi Roman,

I've submitted a patch file to the issue tracker: http://code.google.com/p/bullet/issues/detail?id=180

And thanks for the reference Marcus. I wish I had time to look into it, but time is super tight at the moment. (Barely enough to submit the patch!) So in the meantime, any comments on the technique I've used?

Thanks,
Eddy