View Full Version : rig without gimbal

02 February 2009, 02:47 PM
hi guy!!
i am an animation student and i want rig a character but when i animate often i fall in gimbal in the arm, but i see that some rig don't fall in gimbal when i spin the arms and other rig have an additional control against gimbal...

my question is that can i rig my character for don't fall in gimbal arm's?

02 February 2009, 08:35 AM
Study and learn Rotation Orders and youll be at least 75% there.

Personally Ive never understood the reason for using the gimbal mode at all, at least not in Maya with the "Euler filter" ....


02 February 2009, 01:29 PM
in maya 8.5 euler filter can't work ...but there are more trick for rigging? in this moment i can rig a human character.. but i want add this control

02 February 2009, 01:30 PM
Well Euler filters help sort it out but doesn't stop the problem from happening. So using Gimble mode will let the creator of the rig see where the gimble is happening. Most packages I know have the Euler filter these days and the artists should be using it when ever they run into the problem.

02 February 2009, 07:05 PM
So using Gimble mode will let the creator of the rig see where the gimble is happening.

Yes, here I totally agree with u Paul. I allways use it when Im setting up the rigs, its up to the rigger to minimize Gimbal Lock imo.

But does the people that animate with your rigs animate in gimbal mode? If so, what are there argument for using it instead of local?

// Otto

02 February 2009, 03:27 AM
I use gimbal for setup and animation. I also know a few folks who animate in gimbal mode, however I've found setting it to 'local' is the animator norm!

It is up to the rigger to minimize gimbal lock happening, however a plus for rotating in gimbal mode is that it allows you to see exactly what will be happening to your curves. Switching to local or something like that will give you all 3 axis of rotation all the time, but it doesn't stop gimbal from happening.

As for the main question, if you're getting gimbal lock happening most of the time try changing the rotation order of that control. Hopefully that should minimize most of the issues!

02 February 2009, 02:18 PM
Well I think that most animators don't understand Gimble mode and want local and think that if they work in local then the rotations are local. Those that do understand it will do as Stewart suggests he does and works in local until there is a problem and then use Gimble to see if you can get around it. Like anything it is a one tool to help catch problems before they arise or secondly, to help correct issues once they do.

02 February 2009, 07:58 PM
i have spoken with many Animation Mentor animators and more oh they use gimbal rotation because they can see immediatly when they fall in a gimbal...but how can i create a control that can switch by attribute the rotation order?

02 February 2009, 08:39 PM
Sorry, I misread your previous post to asking how to change the rotation order, not how to create a control for it.

02 February 2009, 11:59 PM
i have spoken with many Animation Mentor animators and more oh they use gimbal rotation because they can see immediatly when they fall in a gimbal...but how can i create a control that can switch by attribute the rotation order?

You don't. Changing the rotation order once animation has started is not a good idea.

If you're rotation order is good on the initial rig there shouldn't be too much of a problem overall. I mean, folks have been animating with gimbal locking issues for a while!

However, as a fix you could add a group, or another control or something, that sits above the problematic control in the hierarchy. This will not fix your gimbal problem, but it would allow you another control to animate on once you hit gimbal with the main control... Be warned, if you are handing this to animators make sure you let them know about the extra control, and that they don't need to key it straight off the bat!

02 February 2009, 01:36 AM
If you are in Max you can just add another controller in the list and set it to active with the needed axis order. I have had to do this with objects that are tumbling. If you are using animation layers then you can set one layer up with the secondary axis order just in case.

02 February 2009, 02:18 AM
Controlling your Gimbals and rotation order is confusing at first but once you understand the problems and why it locks and how the correct rotation order helps prevent this it makes sense and easy to solve.

First part is understanding that Gimbals lock up. They are meant to. The trick is what order does the fail or locking occur. All rotation done ends up being a rotation of the Gimbals anyway. Local and World rotation move the gimbals under a different axis determination but still just move the gimbals. This is why animators like using the Gimbals and not the Local or World as they are deceiving to what is really happening and having a correct rotation order allows you to work like this.

Think of the pelvis to start with, you need to figure out what order of axis' do you want to fail first, second and last and build the joint and the controller in such a way to minimize this occurring.

Lets say the pelvis follows the same rotation order as the world space so that Y is the aim axis pointing up and down. So when you rotate the Y axis you want the Z and the X to also move when you rotate left or right. That means you want the Y axis to fail last.

Now the pelvis leaning forwards and back is rotating X and leaning side to side would rotate Z. Now you pick who fails first and then second. The best part is is that it really does not matter which one fails before the other since the most important part was determining who fails last.

Now you can see this when you move to Gimbals mode of rotation. If in Maya make a poly cube at the center and switch into Gimbals in the rotation sub menu and open the Attribute editor for the poly cube. By default it will be at XYZ rotation order. Rotate the Y gimbals. Notice that the X gimbals goes along for the rotation but the Z does not. Now switch the rotation order to ZXY and rotate the Y gimbals again. Now the X and the Z go along for the ride. Whatever axis is listed last in the rotation order is the one that fails last.

If you do not set the Y to fail last then when you rotate on Y the X and the Z get in the same direction after a 90 degree rotation. Then if you try and rotate the X or the Z it is hard to determine who is turning and you create Gimbals Lock.

If this box was the pelvis then putting the controller and the joint to a Aim axis of Y and a Rotation Order of ZXY it is unlikely that the pelvis would gimbals lock. Since every time you rotate on Y, Z and X move as well. If this was the wrist the principal is the same. You want the wrist when twisted or rotated along Y for the X and the Z gimbals to move as well.

How do you determine what it should be and needs to be? That is up to you. Some people build joints so the X is always the Aim axis, some do the spine section with Aim as Y and the rest as X and some just make Y the Aim for every joint. It can be the Z if that's what you want. It really does not matter what you decide (other than it should be consistent) but how you make controllers and set the order is determined by this.

Beside determining the order you want the most important part is the controller that moves the joint and the joint itself should have the same rotation order. It's important so let me repeat it. The JOINT and the CONTROLLER MUST have the SAME rotation order. So if your spine joint is ZXY then the controller parented to that joint should also be set to ZXY. In almost every case and every situation what ever axis is the Aim axis is the one you want to fail last.

I hope this helps some of you to understand this better and not be totally confused. The Jason Scheilfer series Animator Friendly Rigging explains this as well in the first chapter or two.

02 February 2009, 03:08 AM
Thanks for the awesome post and taking time to make it.

02 February 2009, 04:54 PM
ok ...i have understand perfectly what is gimbal.... but i don't have really understood the order rotation...

this is a shot of norman a pixar class rig... you can see that in the shoulder there are two controller... gimbal and normal... what is the different i watch this for more minute ..but i don't understand the difference.... and if it help me, how will make it.. (

02 February 2009, 07:48 PM
Gimbal is losing a degree of freedom. Here is an excellent explanation of it from Fahrenheit Digital (amazing tutorial videos).

Sorry, the video had random zooming that was ruining what he was talking about, rediting the video and uploading again.

Let's try it agian:

05 May 2009, 02:09 AM
You don't. Changing the rotation order once animation has started is not a good idea.

Actually changing rotation order on the fly could work. With xform command you can use a flag that lets you change rotation order without affecting the pose.

I wrote a script some time back to change rotation order in an animated scene. Because I changed the rotation order in the rig which was referenced by animators and needed to make sure their animation remains unchanged after rotation order changes.

05 May 2009, 04:23 AM
The issue with gimbal is crucially, in the fact that the rotational space the object works in does not update after each successive axis' direction change. A good analogy of it in terms of a matrix is when it is squew'd and not orthoganalized.

Eventually if you squew a matrix until it becomes a plane about an axis - for example the z axis folding flat onto the x, you basically lose a degree of freedom. In this case the rotation about the z becomes the x rotation. And the y stays as is.




So the key around this or to reduce the issue, is in you axis order have the most problematic axis initiated last.

This problem is not fixed in quaternions either, there rotation (not really a rotation more a spin about a direction) exist inside one hemisphere - reaching the equator of one flips it to the other.

The only way around it is to change the reference space after each successive direction, blending between quaternion frames (frenet) etc, etc.

05 May 2009, 05:05 AM
To me, gimbal is THE problem in rigging. I have to think of the rotation order in the creation of every joint......For most of the joint in biped rig, the problem could be avoided since most joints are either have one degree of freedom(elbow, knee) or not flexible in all 3 axis (hand), or by using IK (spine rigged with spline IK).

For those joints that will need to be in FK and flexible in all 3 axis(shoulder, hip), I usually pass the rotation of one axis to its child. Sometimes I use quaternion-like solutions by setting an aim and a up vector, usually used in moving the entire character, when they need to swim or fly in the scene. It's not hard to find a working way to deal with gimbal, but I have to be careful, one mistake could cause chain reaction sometimes...

CGTalk Moderation
05 May 2009, 05:05 AM
This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.