Let’s put it that way:
- When using “Euler Angles”, which are the easiest to grasp and use, there is nothing that can be done about gimbal lock. Other software has built in workarounds like “Up Vectors” and such, but there is no REAL way around this problem - it is in the math.
The core problem is, that you need a way to express angles that is stable and leads to the same orientation, no mater how you apply it - foreward, backward etc.
Test it yourself: rotate your hand 90° on x, then on y then on z. Memorize where you landed. Now go back to the start and rotate your hand 90° around y, then x, then z. You reach a different orientation.
This is the core of the problem: how do you express angles in a way that is defined in an absolute way so it works for animation equal how you play it back. Mr. Euler found a solution which works nicely - but when some axes reach ±90°, there is an completely undefined singularity = Gimbal Lock.
(BTW: The same happens in a real-world cardan joint.)
So this isn’t about a fault in messiah, but about one of the most discussed problems in 3D math and there are only workarounds, no solutions.
I am all for implementing the workarounds into the core, but they will lead to other problems and aren’t something that just works out of the box.
(As you found out when you added the knee constraint expression)
- The only alternative I know of is using “Quaternions”, which basically are euler angles with a fourth dimension of rotation added. Think about it like you are moving the one critical axis into that fourth dimension that isn’t used anyway and may gimbal lock until hell freezes over - who cares
Messiah already allows to use Quaternions in the graph editor for objects…
The math is more complicated and slower, but with todays machines, this isn’t critical anymore.
BUT and this is a big BUT: since there is one dimension “unused/undefined”, the other three show extreme values and jumps in their graphs at certain values. While the actual rotation is much smoother, more continuous and more along the lines you would expect when interpolated, working with the graphs is a mess. So often you will first do the animation with Euler Angles and then switch to Quaternions when finished…
There were a lot of discussions about this topic in the past, which did lead to the Quaternion option in the graph. Someone from pmG stated that the expressions all use Quaternions internally. I have no way to validate that, but from my experiences, I honestly doubt it. :shrug:
I am also unsure if effects like the motion dynamics use Quaternions?
So I am 150% with you that all possible measures should be taken to prevent such problems as with your simulation, which was in no way extreme.
All dynamics should use Quaternions since their graphs don’t matter much anyway. If they already do and this isn’t a solution to the flipping, I think it would be extremely important to explore built in options for workarounds. I personally found all the effects that show this problems a major pain or even pretty unusable - more pain than it’s worth.
From my experience, Flex, FlexMotion and MotionDynamics are haunted the most, but everything using curves is basically prone to that problem.
A statement from pmG about this topic would be highly appreciated! :applause:
Best regards,
