– Gimbal lock and Euler Rotation
– Setting rotation order on a Camera
– Setting Rotation Order on Controls
Euler Rotations otherwise known as Gimbal is a common method animators use for rotating objects in 3d space, this is what’s really happening under the hood.
When modelling rotations aren’t a problem as local and world manipulators work great. However once we start to animate orientation keyframing over time the automatic inbetweening of orientation becomes more problematic.
Local And World Manipulators And An Animation Problem
Leonhard Euler (pronounced Oiler) is a famous Swiss mathematician and physicist who lived in the 1700’s. He’s responsible for loads of discoveries in mathematics.
As it turns out it’s rather tricky to mathematically describe an orientation in 3d space. This is a problem that’s plagued man well before the time of computers.
Euler’s solution was to set a “rotation order” for xyz rotations and calculate based on angles. It’s the “rotation order” that’s important for us to remember.
But first lets take a slight diversion as there’s 2 common ways to calculate an orientation in 3d space
2. Euler (gimbal)
Another method called “quaternion’s” is used in some programs such as 3dsmax’s biped. If you’ve come across TBC rotations (tension continuity and bias) your program is most probably calculating in quaternions.
However it’s pretty much agreed that most animators prefer Euler over Quaternions. Quaternions lack the intuitive control of Euler. Maya uses Euler.
Quaternions use vector math. A vector is a fundamental concept in 3d, it’s one of those words that sounds complicated but it’s really very simple. It’s simply a direction in 3d space.
Vector Directions And Quaternion Orientation
Gimbal uses angles though, not vectors. So getting back to Leonard Euler and his rotation order…
Euler found you could describe an orientation in 3d space with 3 angles, xyz. But more importantly he found that it matters what rotation order you use. For example if you rotate an object
x 15° then y 21° then z 80°
you will describe an entirely different angle to
z 80° then y 21° then x 15°
Why Rotation Order Matters
This is a problem that has it’s roots in mathematics. Many mathematicians have tried to think of better ways to describe 3d orientation but non have surpassed Euler for the most intuitive method. So animators commonly choose this method as our preferred orientation method.
Euler or Gimbal
It doesn’t matter which term you choose. Euler Rotations or Gimbal Orientation, these are titles that describe exactly the same thing. Euler invented the math, gimbal is the method. We can use either title.
So the order of rotation matters. It must be specified. There’s 6 variations.
In maya that can be found in the attribute editor under the first tab (transform node) of each object.
Euler came up with a nice little equation for specifying all of this you can find all of that here on the wiki page, but it’s not really important to us as animators. We just have to know how it works visually.
Gimbal Manipulator and Gimbal Lock
To see this in practice we use the gimbal manipulator. This is the true mathematical orientation of our object in maya. And at it’s most extreme we can hit gimbal lock.
Gimbal Manipulator = hold e and click hold LMB > Gimbal
Gimbal Lock occurs when two axis combine. This can always happen on one axis no matter the order of rotation.
Why is gimbal a problem?
Gimbal is a problem because we get unexpected results while rotating between keyframes. This is demonstrated easily in the following example with a camera in Maya and default (incorrect) rotation order.
It also has consequences for posing and rigging tools such as “pose based deformers” which use the orientation of an object mathematically in order to automatically correct the deformations of a pose. Another example of which gimbal plays a part is in object flipping, when an object flips 180 on twist in automatically driven objects, though this has to do with other things too.
A good way of thinking about Gimbal
A very handy method for understanding gimbal is in a simple parenting structure. Parent 3 torus to each other in the form of a rotation manipulator. Lock off the other axis of each torus.
The order of rotation can be thought of as the parenting structure.
X is a child of Y is a child of Z
Unfortunately this is written backwards in Maya if you’re thinking about a parent structure.
The order XYZ means that Z is the parent, Y child and X the baby on the bottom.
Solutions To Gimbal – Rotation Order
There’s various solutions and work arounds when it comes to the gimbal problem. Most problems are solved simply by choosing an appropriate rotation order. The most common example is found in Maya’s default cameras, the default “rotation order” for a camera is quite clearly incorrect.
The correct camera rotation order in Maya is ZXY… well 99% of the time. So it’s advisable to always change it when animating cameras.
Solutions To Gimbal – Rotation Order After Animation
there are certain scripts we can use to change Rotation Order after animating. This preserves the keyframes however the in betweens might change.
The scripts by Morgan Lumis are found here…
Local Download right click here…
1. Convert Rotation Order Script – ml_utilities.py
2. Convert Rotation Order Script – ml_convertRotationOrder.py
Here’s another video on the rotation order, this time with a full character, this one over at Ianimate.
Solutions To Gimbal – Roto Object
If our rotation order is good or can’t be changed we can fix the problem area of animation with a roto object. We can animate the roto object as we want then manually line up the objects by eye or with constraints.
Solutions To Gimbal – Euler Filter
In animation we can get strange values while animating. It’s good to know about the Euler filter which can solve incorrect tweening in certain situations.
Solutions To Gimbal – Pose Based Deformers
We can model correction fixes to poses that automatically update called “pose based deformers” or psd’s. But gimbal causes problems because it’s angles aren’t be reliable.
braverabbits SHAPES 2 uses psd’s in it’s weighted drivers, it’s commonly what I’ll use. But we can make psd’s in Maya nodes though it’s relatively slow on rigs.
Create a pose reader with native maya nodes.
unfortunately psd’s are a workaround in certain scenarios and not a global fix so go over this whole gimbal page a few times before you understand this area as it’s unfortunately very foundational to both rigging and animation. At first it can be a very puzzeling abstract concept but with time and the proper understanding gimbal really isa very simple concept at it’s heart.