Gimbal Lock is another topic that I find many new and even veteran animators don’t fully understand how and why it occurs and how to control it. There appears to be myths, not as many as there used to be, that animators and artists have as to what is really happening when they rotate an object. I should note that this article is not aimed at programmers or math nerds.

Myths:

1. If you rig your character with Y pointing down the bone you will not get gimbal lock.
2. If your software of choice isn’t Y up then it will have problems with gimbal lock.
3. If you animate in local space you will not get gimbal lock.
4. The new piece of software that I’m using has gimbal lock issues but the other one didn’t.
5. If you rotate around X before Y it will not gimbal lock.
6. Redbull limits the effects of gimbal lock.

To be able to dispel the myths we first need to know what a gimbal is and what is means to be locked. If you really want to dive in deep go here, how ever I can not be held responsible for nose bleeds and migraines that may be a result of doing so, https://en.wikipedia.org/wiki/Euler_angles . Since this is a guild for animators and artists and not meant in any way to be a mathematical explanation I suggest you read on and save yourself the pain.

So there is this really old guy named Leonhard Euler that worked out all sorts of the mathematics that we use today in modern 2D and 3D graphics applications and he did it in the early 1700’s with nothing but a sharp pencil and no google searches. One of the bits of math that is used in every 3D package these days are Euler (oiler) rotations. Euler rotations use XYZ axes that we know and love, and hate, to animate with. Euler rotations allow for us to have separate function curves for each axis so timing can be worked out with slow in’s or auto smooth tangents and the like. The inherent problem with Euler’s rotations is gimbal lock and it doesn’t mater what piece of software you use or what axis points where, if you are using Euler rotations you will get gimbal lock if you do the correct set of steps. There is no way to stop it but there are ways to control it or limit how badly it will affect your animation.

What is an Euler rotation and how does it work?

Euler rotations use XYZ axes to control each axis. You can think of the axis order as being in a hierarchy of (Grand Child -> Child -> Parent), so X is parented to Y, Y is parented to Z and Z is parented to what ever the parent node is in the scene. The best way to visualize this is to set your rotations to use gimbal instead of Local, Parent, View or any other axis as none of the others mean anything at all in the grand scheme of things. So in your package of choice rotate your object around the Z axis, you can see that the rotation controls for X and Y both rotate with it. Now try rotating the X axis in the same way and you can see that Y and Z don’t rotate with it. This is because Z was the parent and the children followed along but X is the grand child and ran off without it’s parents like they do in the mall. So now try the same thing with Y. Y is the parent of X so X will rotate with Y but Z does not rotate. If you rotate Y 90° it will rotate X right on top of Z so both X and Z if rotated would no create the exact same result.

I should note that in modern 3D applications it is possible to change the axis order for an Euler rotation. This means that instead of an order of XYZ it could be XZY which will change the resulting rotation. I stated above that if you rotated Y it would rotate X onto Z how ever with an axis order of XZY it is the Z axis that will cause gimbal locking. So it is best not to say that Y will cause gimbal and better to state that it is the middle axis of any given axis order that will cause it.

Y down the bone..

3D software defaults to X down the bone and I have heard others say that if you change it to Y down the bone you will not have gimbal issues. These sort of statements can’t be further from the truth, gimbal lock always happens if you are using Euler rotations and rotate the middle axis 90° so there is no way around it. That being said pointing Y down the bone might limit the problem in a specific joint but in no way is it a solution that will always solve gimbal locking. With X down the bone you could just change the axis order for the joint and produce the exact same result. This is the solution that I will usually use as I want consistency for the animators in how controls will function but also reduce gimbal issues.

Software that isn’t Y up..

This statement that I have heard more than once is the most ridiculous thing that I have ever heard. Since all transforms are in the space of their parent the identity matrix of the software has exactly zero effect on the end result. Also the argument for Y or Z up is also just as ridiculous and has no bearing what so ever on the effectiveness of the tools you are using.

If you animate in local space..

This is another comment that I hear a lot that really makes no sense what so ever as well. Lets consider that everything in 3D space has to be relative to something else. So an object in the scene that has no parent is really just parented to the world node and every transform on the object is relative to the world. If the object is in a hierarchy with other objects then it is relative to the parent object. Changing from one space to another to manipulate the objects transform does not change what it is relative to and therefor does not change the values that are created. As for Euler rotations, if you rotate the middle axis of the node 90° then you end up in gimbal lock even if the mode you are in is something else as it has no effect on the actual numbers that are being stored. Transform spaces like Local, World, View are just there to make our lives easier and do not represent the true numbers that we are working with. As far as Euler rotations are concerned gimbal is the only mode that means anything real at all.

This new piece of software has gimbal issues and the other one didn’t.. (Insert software of choice here)

Like I have stated above, the equations for Euler’s rotations were created in the early 1700’s long before you and I were trying to animate 3D characters. There are only so many algorithms for dealing with rotations and if it is an XYZ type rotation that you are working with it was written by Euler. This means that all software that is using Euler’s rotations have exactly the same issues. It is just that you are now noticing that the wacky rotations that you are seeing are not your fault or the new character rig that you are working with has not been created to limit the effects of gimbal lock.

If you rotate X before..

I think by now you see my point, it just doesn’t mater as rotating X with an axis order of XYZ will have no effect on the rotation of Y or Z. There is no way to stop the problem.

Redbull..

I have heard on the internet that Redbull has wings, therefor I have concluded that this statement only holds true when animating birds and airplanes. After all, who can argue with the internet.

Possible solutions

If you are working with spherical joints like a shoulder or hip you can often end up with issues when poses are pushed and there isn’t much that you can do about that. There are Euler filters that try and unwind the problem in the graph editor but it doesn’t always produce the results that we are after but can help reduce the issues. Good character rigs that have limited the effects will make all the difference.

Another solution is to use an animation layer that has the rotation order changed to one that will not cause the problem for the animation you are trying to achieve. You could also blend from one layer to another as you enter the part of the animation that is causing the most problems. This can be a little hard to control if you have not done it before but I have used this trick on many occasions with great success.

Avoid using Euler rotations all together is another solution. I will discuss Quaternion rotations in another tutorial in more detail but the advantage to these rotations is they don’t have any axes at all and can’t have gimbal lock. Down side is they don’t have any axes at all and you can’t work with function curves either. They are far better for some things and not so good for others. If you are working with characters you probably want function curves to control the tangents. But if you are trying to animate a ball rolling around the floor of a gym a Quaternion is a far better solution and the rotation of the ball could even be automated to roll correctly. For the most part animators are reluctant to use them because they don’t understand how they work.

Become a brain surgeon, it takes less years of practice then being a good animator.