Questions about X, Y and Z rotation properties

[RoyBU]

I have a couple questions about how the "rotation" transform works.

 

1. Under the "Transform" property for the typical object in a chor are the "translate", "scale" and "rotate" properties. If I click the little triangle next to each, I can get the X, Y and Z (or X and Y for scale) listed separately. If I then click on just one of the dimensions under translate or scale, the graph for just that dimension will show up in the timeline and I can add or manipulate its keyframes. HOWEVER, if I click on just one dimension for the "rotate" property, I get nothing. The only way I can manipulate a dimension for rotate is to click on "Rotate" and get all three dimensions in the timeline. Usually this is fine, but when all three dimensions are the same value at the same point in time, it can be difficult to select the one I want. Why can't I choose one to work with individually like I can with translate and scale?

 

2. In addition to the X, Y and Z dimensions for rotation there is a fourth (appears as a white line in my timeline) whose purpose escapes me. When I change X, Y or Z this white line moves and if I move the white line my object rotates, but what is it meant for?

 

Thanks in advance.

[robcat2075]

I have a couple questions about how the "rotation" transform works.

 

 

1. The behavior you describe seems like a bug. You might report it to www.hash.com/reports

 

In the mean time you can get access to individual rotate channels by expanding your PWS outline and selecting one:

 

[attachmentid=23283]

 

2. XYZ and W are channels for "Quaternion" interpolation. I've never seen an intelligible explanation of how it works, but you will never get "gymbal lock" on bones that use Quat. You can right click on that "rotate" transform property and choose "vector" or "Euler" interpolation, which use plain old XYand Z, but those can get gymbal lock. "Euler" is quite good for things that need to rotate on one axis only, like propellers.

 

Quat is harder to edit but I've found small changes can be made safely by just moving the XY or Z keys.

[ypoissant]

1. The behavior you describe seems like a bug. You might report it to www.hash.com/reports

This is not a bug. What happens is that the rotation manipulators as well as the rotation edit boxes all allow the user to do the rotation in Euler because this is the most intuitive for direct manipulation and since it is directly manipulated and not animated, it cannot gimbal lock. But the resulting rotation is stored as Quaternipon so that we don't have gimbal lock during animation. So even though you manipulate the X, Y Z rotation axis, the actual stored data is X, Y, Z, W and those are the channels you get in the timeline.

 

Now, even though both rotation spaces ave an X, Y and Z channels, those channels only roughly correspond to their alter ego. That is why, if you select one of the X, Y or Z edit boxes, you don't get the corresponding X, Y or Z channel to edit.

 

Quaternion is just the name given to a vector that lives in 4 dimensions (X, Y, Z, W)

 

Why the Quaternion system?

 

Imagine a clock needle in a 2D animation that turns in clockwise direction. That is what we are used to see. Now imagine the same clock needle turning in the counter-clockwise direction. Is that a problem with the clock? What if the clock was simply turned away so we now see it from the back? If the clock needle is a 2D animation, then we cannot know (unless we observe that the clock numbers are reversed) but if the clock is an actual object in 3D, it is easy to see that it was turned away. This ambiguity in 2D becomes evident in 3D. The same idea exist in 3D. Some rotation directions are ambiguous in 3D but become evident in 4D.

 

Here is anoter curiosity of the 3D rotation system. Stand up with your right arm dowm and the palm facing left (facing your thigh). Now rotate your arm around the X axis 90° while keeping the arm and hand twist as rigid as possible so that the arm extends in front of you and the palm still facing left. Now rotate the arm around the Y axis 90° so that it extends right of you with the palm facing front. And now rorate the arm around the Z axis 90° so the arm rests again on the side of the body but note that the palm is still facing fromt. Now repeat the same thing but rotating the arm around the Z axis first, then around Y and finally around X and notice that now the palm is facing back. This shows that the order of rotation is important in 3D. Depending on the chosen axis order, even if the rotations are the same angles on each axis, the end result will be different.

[RoyBU]

Thanks for the thorough explanation. I can't claim to understand it all, but it makes more sense and is less of a mystery than before. And I tried the arm rotation example -- very interesting!

[robcat2075]

1. The behavior you describe seems like a bug. You might report it to www.hash.com/reports

This is not a bug. What happens is that the rotation manipulators as well as the rotation edit boxes all allow the user to do the rotation in Euler because...

 

But even if the bone is using Euler interp, channels are not displayed.

 

 

Why the Quaternion system?

 

...Some rotation directions are ambiguous in 3D but become evident in 4D.

 

The problem with that explanation is that we don't need a 4th D to describe translations, which could also be ambiguous depending on the observer, and when we do rotations on the screen we are able to unambiguously get any angle we want with just 3 dimensions.

[ArgleBargle]

Yves, that's the best description I've read of that. It's tough to wrap your head around a 4th dimension (and I'm not totally sure I have it perfectly) but that clock analogy was great.

[ypoissant]

But even if the bone is using Euler interp, channels are not displayed.

In that case, it's probably worth an A:M report.

 

The problem with that explanation is that we don't need a 4th D to describe translations, which could also be ambiguous depending on the observer,

The same ambiguity exist for translation. I just used the rotation as an example because the clockwise and counterclockwise rotation is easy to relate to. I could just as well use the translation if I could find an easy to relate to real world translation example. I could have used the typewriter carriage right translation but how many people still remember those devices?

 

That was an attempt to explain the ambiguity that can be solved by adding an additional dimension. That was not an attempt to explain the gimbal lock issue. I could not come up with a simple explanation of the Gimbal Lock issue and I didn't think it usefull to give yet another opaque mathematical explanation here.

 

and when we do rotations on the screen we are able to unambiguously get any angle we want with just 3 dimensions.

Exactly. But when you manually rotate an object on the screen, you are actually doing that from a 2D projection. There are some rotations that you just cannot get in one single manipulation. You need to rotate, click somewhere else on the manipulator, which, in effect, resets the whole system, and rotate again, etc. It is impossible, from a 2D projection, to get into a 3D Gimbal Lock.

 

The Gimbal Lock issue is really only an issue when the computer is doing the rotation interpolations on 2 dependent 3D systems. One reason why the Gimbal Lock issue is confusing is because it comes from using two dependent 3D systems where one 3D system is rotating inside the other 3D system. Even using a real gimbal mechanism as an example, the issue is still quite abstract unless we actually have the mechanism in our hand or a 3D animation of it is made (but don't count on me for that. I've seen animation of the Gimbal Lock issue but they were incomplete).

 

Anyway, here is an illustration of a true 3D Gimbal mechanism. To help see the Gimbal Lock explanation, I will use the labels OG, MG and IG axis to reference the mechanism axis themselves and I will use the X, Y and Z axis to reference the fixed world 3D space axis (and note that the X, Y, Z axis labels in the illustration are not the ones we are used to and I will use the ones depicted in the illustration).

 

Rotate the mechanism 90° around its MG axis until the LM axis is aligned with the OG axis and then rotate the mechanism 90° around its OG axis. In this configuration, there is no way that we can rotate the mechanism around the global Z axis unless we break the whole device. In this particular configuration, we are left with only two effective axis of rotaton. We lost one degree of liberty. This is exactly the "Gimbal Lock" configuration. In order to get out of that situation, a human will figure that we need to first rotate the mechanism around its OG axis. But a simple interpolation program cannot figure that. And guess what they do to avoid this situation in a real Gimbal device? They add a 4th axis called the redundent axis.

 

Here is the NASA article from where those illustrations come from.