Hi everybody, recently i’ve had to code a tool that among other things, changed the rotation matrix multiplication order in a control to avoid gimbal lock.
I’m sure you are all familiar with quaternions and their major advantage which is precisely expressing 3d rotations that avoid this gimbal lock.
Despite they where discovered by Hamilton in the XIX century i believe its use hasnt been applied since relatively late, for example, back in the 50s 60s the aircrafts’ navigation systems still used the euler angles to specify the orientation of the plane.
There are a bunch of methods to specify 3d rotations: euler angles, cosine direction matrices, homogeneous 4x4 rotation matrices, quaternions…
So my question is: Why in such DCCs like Maya we still have to deal with matrices rotation orders that suffer from gimbal? Wouldnt it be easier if the use of quaternions was spread all along the entire software? The people at Autodesk must have a good reason for this, it’s just that it puzzles me a bit.
Is it because of legacy code? or maybe what i can think of most probably is that expressing rotations in euler angles/rotation matrices is far more intuitive and visualizable than it is using quaternions… But if this is the case, wouldnt it be possible to receive as input the rotation in euler angles, convert it to quaternions, perform the rotation and then convert back to euler angles? is it because hardware like graphics processors are more prepared to perform 4x4 matrix multiplications?..While rotation in a matrix takes 16 floats/doubles, a quaternion is more compact and only needs 4 numbers…
Now i hope i’m not being too naïve laying this question on the table.
It actually all goes back to the mid 90’s when (then) Alias started Maya as the “modern” update to PowerAnimator. The brought in a bunch of CG artists and animators to provide feedback, and one of the really consistent bits of feedback was that animator’s love their F-curves. The prime mover in this as I recall was, if I remember it right, Chris Landreth http://chrislandreth.com/
The problem is that quaternions represent a complex number that can’t be broken back down into F-Curves in a simple, linear fashion: changing just one value of the quat doesn’t give you a predictable behavior (well, changing the W component does, although even there the same W-change applied to different XYZ will look quite different). So, if you want to set keyframes that have human-readable meanings you need eulers or something that behaves like eulers – the main alternative would be something like Max’s TCB controller in which the ‘value’ of the key is just a rotation and what you control with curve-like behavior is the rate at which you interpolate between those keys.
The matrix is really the ‘base’ representation, since no matter how you specify your rotation data you need to convert it into a linear system of equations to actually transform points and matrices are a very flexible, elegant way to chain those together. Maya eulers and quats both get baked into matrices before being applied to actual render geometry; they’re basically “interfaces” for manipulating the 4x4 matrix which is all the system cares about when rendering geometry to the screen.
So, if you could find a more human-readable interface for change-over-time in rotations, you could dispense with eulers: they are really a surface level phenomenon. But they are extremely hard to do away with, since (a) there’s no comparable standard for displaying or talking about quat differences, (b) controlling the rate of change over time is a major issue for any animator, and f-curves are a clever way to represent that 4th, invisible dimension in an intuitive way and (c) animators, generally, are such ultraconservatives that even a completely better alternative will take 20 years to catch on
It’s been a while, but I remember Character Studio 1.0 had a weird fcurve display in trackview in Max 2.0/2.5. I think it may have horizontally been a slope from 0 to 1 or something and each key had a bezier handle to tweak the timing. They took it out for subsequent versions. I googled it and couldn’t find any proof, but I’m not imagining it!
Maybe someday we can ditch 2D curves for 3D motion paths.
there was that thing with the + characters arranged to show the derivative around the keyframe. I actually used a lot of that on HalfLife. It was ugly but it actually solved the problem if you could think about it abstractly. But most people don’t.
The guy that wrote Maya easily could have put it in, every flight simulator made have a free rotator that gets over gimbal lock. Theres actually no problem editing with gimbal lock if you do it properly, Just get the origin angle right first, and its probably less confusing working in a gimbal situation.
[QUOTE=jiceq;28900]But if this is the case, wouldnt it be possible to receive as input the rotation in euler angles, convert it to quaternions, perform the rotation and then convert back to euler angles? [/QUOTE]
That’s exactly what happens in 3DS Max.
If you select any object and get it’s <object>.rotation value it’s a world space quaternion.
On top of this Max puts controllers that convert to/from Euler Values (or TCB or whatever)
But pretty much it’s that Euler X Y Z in degrees is what animators understand.
Most people can’t visualize quats.
