Hi,

I've learned a lot from all the posts by Ockham and others on gimbal lock. I believe I understand most of it, but I'm still a bit confused and was wondering if I could get some help.

My impression is that the reason for the gimbal problem in Poser is that the mix between local y and global x/z sometimes makes the y-axis coinside with the x-axis or the z-axis, and that if we used either all local or all global we would be OK. Is that correct?

I'm still a bit confused about the body/hip relationship. Ockham says that the solution to gimbal in Poser is to use yRot on the body and x/zRot on the hip. Is that because the local y-axis of the body is always equal to the global y-axis? Or does it have something to do with parenting?

Thanks!

Helmer

I will try and explain it in the simplest way.

Poser reads the CR2 file, and reads it from the top down. So it may read the y-rotation, then the x-rotation, then the z-rotation. Gimbal lock occurs when the one rotation affects the rotation of the next one in the wrong way. For instance if you have the wheels on a vehicle, you want the x-rotation to happen first, to roll the wheels, and the y-rortation to turn them left and right second. If it happens the wrong way round, the wheels will wobble when they roll, so you need to change the order in which Poser reads the rotations in the CR2 file. Luckily this is at the botton of the joint editor tab, where you can set the order to X,Y,Z or Z,Y,X or Y,X,Z., etc.

I am sure Dr Geep can make a picture, but if he doesn't, I will make one and paste it here if you still don't understand.

Try this one.

Gimbal Lock Explained

cheers,
dr geep
;=]

Hi,

Thanks to Helgard and Dr Geep for the replies.

I believe I have a reasonably good understanding of the general concept of gimbal lock. My problem is with how it works in Poser.

Why does Ockham and other say that using yRot on the body and x/zRot on the hip will solve it?

I don't think I understand the relationship between body and hip.

Thanks!

Helmer

The Body is the parent of the Hip.

The Hip is the parent to the rest of the body parts.

You can see the relationships in the Hierarchy Editor.

cheers,
dr geep
;=]

Quote - The Body is the parent of the Hip.

The Hip is the parent to the rest of the body parts.

That's interesting. I always thought the BODY was on top of everything.

That explains some oddities as well :o) Thanks!

The reason that this body-y hip-x/z rotation avoids gimbal lock is obvious.  With only one or two rotations, gimbal lock can never occur.  And since the BODY and hip are somewhat synonymous  (not the same thing, but usually the same center point for rotations), you have two places to do rotations.  Splitting the rotations 1-2 or 2-1 across the BODY and hip avoids the lock.

BODY is the top of each figure; think of it as the root body part.

Dr. Geep,

Thank you so much.  Very clear and very informative.  This user usually always translates and/or rotates the hip as whatever pose is the end result can be saved to the Pose library.  I think BODY poses do not save so that if you are doing a scene with two characters or have one character in a scene/set prop and want that figure to interact in a certain way the hip must be translated/rotated to save that pose to the library.  That is not to say that I sometimes do not simply yRotate the BODY in order to achieve a certain angle to the camera.

Ran into trouble with rotation in Poser before and now I have a name for it: Gimbal Lock.  Cool.

PS: I think I HAVEN'T had the problem in trueSpace (but that software has plenty of other animating issues).

Best Wishes and thanks again Good Doctor. - Rªnce

Hi kuroyume,

Thanks for your posting. I think I was making it too complicated. Is what you're saying that the point is that I isolate y from x/z, and that either y on BODY and x/z on hip or y on hip x/z on BODY both will work?

Thanks!

Helmer

You just need to isolate a rotation so that another doesn't rotate into alignment with the other axis.

The best solution to gimbal lock (other than using Quaternions instead of Euler angles) would be three objects in a hierarchy, each one representing one of the rotation axes:

X-rotation object
   Y-rotation object
      Z-rotation object
         Whatever object is avoiding gimbal lock.

Performing only the designated rotations on these would never cause gimbal lock - but it is a bulky solution.

Geep's link explains the phenomenon rather well.  Gimbal lock has to do with rotation orders (which axis is rotated when when the program is determining the final angle the object will be facing).  Think of it this way.  Take your right hand and point the thumb up, index pointing, and middle pointing left (half bent).  Middle = X, Thumb = Y, Index = Z.  And we'll say that this is the order of rotation (X, then Y, then Z).  Rotations are always around the axis (around the finger).  So, a Z rotation (index finger) has the 'picking your nose' twisting (sorry about the visuals there).

Let's say that the X (middle) rotation is 0 degrees.  But the Y (thumb) rotation is 90 degrees.  The Z (index) rotation is now pointing where?  Isn't that the same place where the middle finger was pointing?  Now both rotations (X and Z) are rotating along the same line (they are no longer distinguishable).  The same can happen for any pair of axes (Y and Z) or (X and Y).

Robert

Hi Kuroyume,

Thanks for the help! My understanding is that part of the problem is that the term "gimbal lock" actually refers to two related problems.

1. When parametrizing rotations using Euler angles, the problem is that we are tied down by a specified order of rotations. The advantage of using quaternions is that then there is no rotation sequence, since everything is done in one step.

2. The original gimbal problem has, as far as I understand, to do with the fact that, kind of like in Poser, the gimbals are different. If we look at the picture of the plane in < http://www.fho-emden.de/~hoffmann/gimbal09082002.pdf >,
   the yaw is linked to the table, so it is global, while the roll and the pitch are local.  In this case, the problem is that we get coinciding axes. The roll (local) and the yaw (global) may coincide.

To be honest, I'm not sure if I really understand the picture in
< http://www.hq.nasa.gov/office/pao/History/alsj/lm_imu.gif >,
but I believe that there is a similar thing going on there, namely that the gimbals are somewhat different.

I believe that it is misleading to talk about Euler angles and quaternions when talking about gimbal lock in Poser. In Poser we are not tied to any specific order. However, the y-local, x/z-global design, obviously leads to the same kind of problem as in 2.

So my understanding is that in Poser the problem that can happen is that y and x can coincide or y and z can coincide.

To be honest, I still don't fully understand exactly why the BODY/hip trick works, but it seems that it somehow separates y from x/z.

Thanks!

Helmer

I'd watch the terms 'local' and 'global'.  In 3D mathematics and CG, global means the absolute reference system (world coordinate system) and there are no 'local' world coordinate systems.  There is a global space and local spaces below it.  Local spaces are arbitrary with respect to or relative to some coordinate basis within the absolute global space.  A set of rotations is either defined in the global space or a local space (there is no hierarchy per se).  One could start with an object whose coordinate basis coincides with the global system and after the first rotation, it is no longer coincident (and then call it local).  This is incorrect.  You were always in local space - and coincidences happen. :)

The 'hierarchy' is more of an ordering of rotational bases and how the system is affected by each rotation.  With rotations and translations, you can take it with you (as it were).  When you translate an object along an axis, you are changing the origin of its local coordinate space.  The next translation occurs from there (and not from 0,0,0).  Same with rotations, except that translations are commutative (order doesn't matter).  Each rotation is modifying the object's local coordinate system within the global system.  Poser may not have a specific order, but you must specify a specific order and that is enough to allow gimbal lock.  Quaternions avoid gimbal lock by using a homogenous coordinate to do interpolative rotations within a 4-dimensional coordinate basis (see Ken Shoemake for in-depth explanation).  In other words, it is not misleaing to talk about Euler angles in Poser, no matter the rotation order, whether it be XYZ XZY YXZ YZX ZXY ZYX XYX XZX YZY YXY ZXZ or ZYZ (these are all Euler angle orders, although the latter six are not valid Poser rotation sequences).

Hi Kuroyume,

Thanks for all your comments!

I agree that what I wrote earlier was wrong. My thinking was correct, but the keyboard was moving faster than my brain! :-(

But I'm still a bit confused about the meaning of  "joint order" in Poser. I assume that it refers to the Euler angle convention, but does it also affect how the three rotations are carried out, meaning whether they are local or global? It seems to me that y local and x/z global (meaning that yRot is with respect to a local y axis while xRot and zRot are with respect to the global x and z axis) is the default in Poser, but can I change this by changing the joint order of an object?

Thanks!

Helmer

Nope.  Don't think about it that way. The rotations start off aligned with the world coordinate system, but then not always.  For instance, a body part that has 'orientation' on its JP starts at that angle (respective to the world system) as its 0,0,0 rotation.  The first rotation in the order is with respect to the initial orientation and each successive rotation from the previous.

Joint order is precisely this.  For a YXZ order, the first rotation is Y, then (from there) X, and then (from where these two end up) Z.  Realize that the object's coordinate system is being rotated, so that a -90d Y rotation causes the X axis to be aligned with the "original' Z axis of the object.  You have to think about the axes (the three mutually perpendicular lines) being rotated in succession - from wherever they end up when it's their turn to be rotated.
Changing the joint order changes how the three rotations are carried out.

A few additions: 1. I think gimbal lock occurs when you apply 3 axial rotations on the same object. Therefore, you can avoid gimbal lock when you apply several rotations on different (parented) objects like BODY and hip. 2. The rotation system used in most 3D apps is not the genuine Euler angles system, but the so called Tait-Bryant system (3 rotations, 3 different rotation axes). Gimbal lock works differently in the Euler angles system (3 rotations, 2 different rotation axes). More information is here http://www.univie.ac.at/cga/faq/angles.html http://mathworld.wolfram.com/EulerAngles.html 3. In Poser, the conventions (sort order of rotation axes) are called "rotation order". The convention is defined by the sort order of the channels in the script (document or library code). You can apply the Tait-Bryant conventions (xyz, xzy, yzx, yxz, zxy, zyx) interactively in the Joint Editor. 4. Some advanced 3D animation programs can apply the Tait-Bryant system or the Euler angles system. In the Euler angles system, the first and third rotation is about the same axis (xyx, xzx, yxy, yzy, zxz, zyz). You can implement real Euler angles in Poser: You modify the channel code and include two xRotate channels or two yRotate channels etc., for example rotateX xRot rotateY yRot rotateX xRot2. Be sure to use a unique channel name for the third rotation channel. 5. All Cardanic rotation systems (Tait-Bryant as well as Euler angles) show gimbal lock under certain conditions. 6. In Poser, you are not limited to 3 rotation. You can include 4 or more rotation channels in the channel code of a single object. (I don't think any other 3D animation software can do this.) You can for example use a 5 parameters system rotateX lRot rotateY pRot rotateZ zRot rotateY yRot2 rotateX xRot2. Using this rotation system you always have 3 DOFs (degrees of freedom) and no gimbal lock at all. In terms of spherical coordinates, you can create all Great Circles and all Small Circles on the sphere with a single object, as shown in the above picture.

Hi VK,

Thanks for your post.

I'm a professor of mathematics, so it took me some time before I understood that CG people used three axes when they talked about Euler angles!

To me its natural to think in terms of DOFs, and think of the rotation order as how you parametrize an arbitrary rotation and break it into a sequence of rotations. At first I was confused by how "simple" rotations about one axis could cause problems, but then I realized that if you use global coordinates, your starting point may already be in a gimbal lock position.

I liked your picture!

Helmer

Hi guys,

I just realized that I was wrong. It is not true that the X-rotation always is global (when using YXZ rotation order).

I decided to sit down and really do the math. I wanted to make sense of the experiments conducted by Ronstuff at http://market.renderosity.com/mod/forumpro/showthread.php?thread_id=984280

Summary: When using the YXZ rotation order, Y-rotation is around the local Y-azis, Z-rotation is around the global Z-axis, and X-rotation gives a global rotation, not around the X-axis, but around the axis that results when you apply the Z-rotation to the X-axis. If the Z-rotation is zero, then the X-rotation is global. If the Y-rotation is zero, then the X-rotation is local.

I thought I'd share it with the forum. It may be a bit more math than some of you feel like, but I will try to keep it simple.

I will assume that Poser uses the rotation order YXZ. That means that every rotation is decomposed as

R(V, s) = R(Z, a) R(X, b) R(Y, c).

Here R(V, s) means rotation of s degrees about the vector V. I read products of rotations from right to left. In other words, every rotation can be written as first a rotation around the Y-axis, then around the X-axis and finally around the X-axis. All the rotations are around the GLOBAL axes.

Rotations don't commute, but here is a general product rule

R(V,s) R(W,t) = R(R(V,s)W,t) R(V,s).

If you manage to penetrate the mathematical notation, it simply says that first rotating around W and then around V, is the same as first rotating around V and then rotating around the vector that is obtained when you apply the V-rotation to W.

I will start with a rotation

R(V,s) = R(Z,a) R(X,b) R(Y,c),

and change the Z-rotation to R(Z,a+d). Now

R(Z,a+d) = R(Z,a) R(Z,d) = R(Z,d) R(Z,a),

so

R(Z,a+d) R(X,b) R(Y,c) = R(Z,d) R(Z,a) R(X,b) R(Y,c) =
R(Z,d) R(V,s).

This simply says that changing the Z-rotation from a to a+d adds a global Z-rotation of d. Just like Ronstuff said.

Now let us change the Y-rotation to R(Y,c+d). Then we get

R(Z,a) R(X,b) R(Y,c+d) = R(V,s) R(Y,d).

Now we use the product rule above and get

R(V,s) R(Y,d) = R(R(V,s)Y,d) R(V,s).

But what is R(R(V,s)Y,d)? Again, if you can penetrate the notation, it simply says rotate d degrees about the vector you get when you apply (R(V,s) to the Y-axis. If you think about this, you will see that R(R(V,s)Y,d) R(V,s) simply is the local Y-rotation of d. Again, just like Ronstuff said.

Notice how extra factors at the left (end) give global rotations and extra factors at the right (beginning) give local rotations.

Now let us change the X-rotation to R(X,b+d). Then we get

R(Z,a) R(X,d) R(X,b) R(Y,c),

and if we apply the product rule we get

R(R(Z,a)X,d) R(Z,a) R(X,b) R(Y,c+d) = R(R(Z,a)X,d) R(V,s).

So changing the X-rotation gives a global rotation of d, but not around the X-axis but around the axis that results when you apply R(Z,a) to the X-axis. This again agrees with what Ronstuff said! (Except that there was a typo in his summary, which mixed up Y and Z when describing how the X-axis behaves.)

If zRot is zero, then R(R(Z,a)X,d) = R(X,d) so we get a global X-rotation.

If yRot is zero, then we get R(Z,a) R(X,b) R(X,d), and since the extra term is on the right, it represents a local X-rotation.
 
If you're still alive, you may also want to know that instead of bringing the R(X,d) term to the left to get a GLOBAL X rotation, we can bring it to the right. Some funky application of the product rules gives R(V,s) R(R(Y,-c)X,d), which means that you get a LOCAL rotation around not the X-axis, but the vector you get when you apply a rotation of -c around the Y-axis to the X-axis.

OK, this was probably more than you wanted to know, but I thought it may be of interest to some.

If you want to change this behaviour, you can manipulate the rotation order in the joint editor.

Helmer