ConeTwist Constraint: issues and improvements
Posted: Wed Jan 21, 2009 3:36 pm
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
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