Can someone explain rotation axes?

[rebar]

can someone explain rotation axes to me. I am confused by the fact that I can rotate on an individual axis from the channel box and even put the x axis directly on top of the z axis. Are there any pitfalls from this that I should be aware of when animating.

thanks

[nonquad]

Pitfall is an understatement.

Overlapping axes cause a situation called "gimbal lock" -- a long standing source of frustration to animators everywhere.

But to really understand a problem you first have to clearly define the goal that the problem is obscuring.

The goal is, to describe an object's orientation in terms of numbers - so that abstract math operations can be applied to it; like (for animators) smooth interpolation.

If you had decent math in high school, the name Euler should sound familiar. He's one of those folk heroes in the academic world I guess. Anyway he was the guy who realized that any orientation could be described in terms of a sequence of rotations around three axes (and thereby reduced to 3 numbers). That's why we call the 3 rotation values on an object the Euler angles.

Imagine you are in the barrel of a main gun on a battleship. The turret can rotate left and right. That's one axis. The gun inside the turret can elevate or depress; that's the second axis. So with two axes, the gun can point you in any direction. Finally, you could roll clockwise or counterclockwise inside the barrel; that is your third axis. * Between those three rotations you can achieve any orientation... but...

Now imagine the gun is pointing straight up, and you want to lean to your right. Unfortunately (as you noted) two of your axes are overlapping (the turret rotation and your axis of roll inside the barrel) and the axis you want to move in isn't mechanically available. The only way for you to rotate to your right, is for the turret to turn right, while the gun lowers, and you roll counterclockwise in the barrel -- all simultaneously. Thus, an operation which ought to be one simple planar rotation becomes a real pain in the ass. Not to mention this complex relationship is no longer very clean numerically. That's gimbal lock.

As you can see, it's a problem tied directly to the system of Euler angles. If you think on it a bit longer, you will notice that the order of the rotations matters a lot. Each axis in the stack gets progressively less dependable.

To some extent you can use this knowledge to avoid trouble. For example if you intend to animate a car, it would make sense to put the Y axis in control. This way the car can only gimbal lock if it faces nearly vertical, which is unlikely for a car and thus probably not an issue.
Rotations are applied in reverse. So on the object's attribute tab you would select a rotation order of XZY or ZXY.

Still, Euler angles are a dirty system. Ideally, you should never have to worry about gimbal lock in any situation. You should always be able to describe an object's orientation with clean numbers that interpolate properly (which btw Euler angles don't).

The solution is a mathematical construct called a quaternion -- so called because it is comprised of four numbers. Unfortunately I can't really describe how quaternions work because I'm still trying to understand myself.
They are functionally similar to system that uses three numbers to describe the vector, and a fourth to describe rotation around that vector -- but I think the math for quaternions is deeper. I've coded some quaternion stuff myself based on information on the web; so I've researched and hashed over the equations thoroughly... and still don't really understand what's going on.

Anyway I digress.

The point is, you can use quaternions to avoid gimbal lock. Take any keyframed rotation in the graph editor and select curves->change rotation interp->synchronised quaternion.

However, as the "synchronized" name suggests, quaternions cannot be reasonably be edited on a component level. So you have to give up on graph editor tangent tweaking if you want to use quaternion interpolation; your only controls will be to change a keyframe from linear to smoothed interpolations.

*as a side note, some scientists use a two-axis, three rotation system... something like YZY. I guess it works, but I don't really understand the advantages. It doesn't seem as friendly as Euler angles and can't be as powerful as quaternions...

Anyway I hope that my rambling has given you something to think about.

[rebar]

thanks!

[warpcat]

Not that the previous description was bad by any means, but here's a practicle way to describe it in Maya:

If you're using Euler rotations (and you should be), the XYZ rotations happen in order, based on the Rotate Order of the node. You can find the Rotate Order in the Attribute editor. By default, it's XYZ. Realize that each axis, X, Y, & Z, could be considered it's own "node", and can only rotate on the axis it describes. What you end up with is a rotation hierarchy.

You'd think that if it was listed as XYZ, X would be the parent of Y, and Y the parent of Z. In fact, it's the exact opposite... I call it an "inverted hierarchy". Meaning, Z is the parent of Y, Y is the parent of X. If you rotate on Z, it in turn changes the orientation of the Y and X "nodes". When you rotate on Y, since it is the child of Z, it only effects the orientation of the X "node". And rotating on X dosen't effect the orientation of either the Y or Z, since it's Y's child.

Maya makes this really easy to visualize through the "rotate gimbal" tool. This tool will show you the three discreet gimbal planes in action, and how the rotation of one axes modifies that of another based on the "inverted hierarchy". It's also the way the rotation data is stored... when you're changing values in the channel box, you're actualy rotating the individual gimbal planes of the transform, or vice versa.

Rotate your object, turn on the Rotate Gimbal tool. While the object is still selected, in the Attribute Editor, change it's rotation order. You'll see the gimbal planes flip around each other, since they'll now be solved in a differnt order.

I hope this shed some more light on the subject.

[nonquad]

In reply to: If you're using Euler rotations (and you should be)

Do listen to warpcat. I made quaternions sound too good; like an easy solution to all your potential gimbal woes. The truth is I was getting carried away.

I like the technology, but the truth is, quaternions are a wondertool that just isn't quite ripe yet. We need a better way to control their tangency before they become really practical for animation.

Basically, with maya's current implementation, the only time quaternions are worth using is when you are stuck with gimbal lock that cannot be avoided by changing rotation order. Which is rare. Most objects tend to have a natural axis or plane of motion; so about 95% of the time you can 'hide' the gimbal lock along the least used direction, and usually it will never be a problem again.

And also (having experimented with quaternions quite a bit) I can tell you they have some annoying limitations. For example, quaternions give a true spherical interpolation of coordinates, unlike euler angles which interpolate per-channel. Sounds good, right? The downside is, if you want a quaternion driven object to roll, you have to key it three times per rotation to keep each arc less than 180 degrees; otherwise it will interpolate in the oppsoite direction to take the shortest path.

But the main thing is, quaternions in maya 4.0 were buggy as all heck. The interpolation would sometimes 'wig out' uncontrollably (I don't know how else to describe it) and sometimes the animation would just fail to save properly - and the next time you open your file all of your rotations are in the wrong direction. Those kinds of frigtening bugs made me give up on quaternions for the time being, despite loving the concept. I have not yet fully evaluated them in 4.5 though. I still have hope.

However. Having made those concessions, allow me to predict that the implimentation of quaternions in maya (and in all software) is destined to evolve. Whereas Euler angles have inherent, sometimes crippling limitations, and the system has little room left for improvement. The issues with quaternions will resolve over time; the issues with Euler angles are fixed and insurmountable. I put my money that in a few years, quaternions will be the default interface for character animation. So even if the system is limited in its current form, I think it is a concept worth learning about and getting to know.

Also even now, despite their present limitations, quaternions are a very attractive option for volitile objects with no 'safe' axis to hide the gimbal lock on. For example I'm seriously considering switching to quaternions for my default system for IK hands (provided I don't encounter as many bugs in 4.5); IK hands routinely pass through every axis in the course of their motion, and gimbal lock more than the average object... they seem like a good candidate for quaternion interpolation.

Also ... it's a bit outside the topic, but quaternions are at the heart of some really jawdropping modern fractal art. Check this stuff out:
http://www.hypercomplex.org/http://www.hypercomplex.org/

[warpcat]

Agreed. When 4.0 came out with Quats I thought all my old problems had been solved. Wrong. The biggest issue I have with their implementation in Maya (asside from the 180 deg. flipping issue...) is the fact they're still pretty easy to wig out. If you keyframe up a typical gimbal lock situation from a euler solution, but have your keys set to quaternions (which would mean no gimbal locking allowed....), looking in the graph editor will show some pretty crazy curves (or, the euler representation of a quat. solution). Not only that, but the way the rotation is interpolated will cause the object to jitter all over the place. I'm going to switch to paper mache....