Quaternions/Gimbal Lock (elementary question)
Steve T
part of becoming competent in the graphics area.
My issue concerns Euler matrices, Quaternions, and Gimbal lock. I have
examined all the requisite websites and looked through past group
postings, but am still in need of help. This question may be
elementary, but I think it might help quite a few people.
I am working on implementing rotations (just mathematically, no use of
a particular rendering API), and have a good understanding of Euler,
Axis Angle, and Quaternion representations of rotations, but I am
struggling A LOT trying to get an intuitive grasp of the
manifestations of Gimbal lock and solving gimbal lock with
quaternions.
My Goal
=======
1. I want to come up with an example of rotating one vector into
another that "should" work, but is prevented from working by Gimbal
lock when using Euler rep.
2. Next, I want to implement that series of rotations using Euler rep
to confirm that lock has ocurred and verify the undesirable result.
3. I want to implement the same thing via composition of quaternions
and show the the "correct" result is reached.
My Understanding of Gimbal Lock (feel free to comment/correct me on
this!)
===============================
Gimbal Lock: a loss of degree of freedom (singularity) that occurs
when representing rotations using a 3 DOF representation (e.g. Euler
Matrices). The idea is that if a rotation folds one axis into another,
a degree of freedom is lost, and the ability to rotate around one of
the axes is lost. I have read many gyroscope explanations that speak
of the physical gimbals that get locked together (which makes some
sense), but I am having trouble visualizing things in a CG context.
A Book's Explanation
====================
Classic graphics text Moeller/Haines has a page where they give the
following example, which I rrepeat to highlight my problem of
understanding. Imagine a RIGHT HANDED coordinate system on this
page:+X right, +Y up, +Z coming out of page. Now picture a statue head
skewered on the Y axis, looking in the +X direction (looking to your
right). NOTE: Rotations described are +=CounterClockwise wrt observer
on + side of axis of rotation. Moeller/Haines set up the following
situation: assume we are using Euler rep, and that we position via
rotations in Y,Z,X order. First, we do NO ROTATION about Y; second, we
rotate -90 degrees around Z (taking the Y axis onto the X axis, and
making the head be face down looking at the floor). The authors
contend that we are now in lock due to folding of Y onto X, and that
we have lost ability to rotate about X (because rotations around X are
now around Y)...and they lose me there at the end!
QUESTION 1: can someone please illustate the lock situation described
above by giving an example of an orientation of the statue that we can
NOT achieve now given this lock situation?
QUESTION 2: can someone please describe for me a simple example that
fits the requirements of goals 1,2,3 in "goals" section above?
QUESTION 3: any other insights, observations that you may have that
helped you understand this phenomenon would be appreciated!
Thanks very much in advance!
Steve T.
Hans-Bernhard Broeker
> I am working on implementing rotations (just mathematically, no use of
> a particular rendering API), and have a good understanding of Euler,
> Axis Angle, and Quaternion representations of rotations, but I am
> struggling A LOT trying to get an intuitive grasp of the
> manifestations of Gimbal lock and solving gimbal lock with
> quaternions.
You're actually contradicting yourself there, to some extent. You
can't really have a good understanding of Euler angle until you've
grasped what a gimbal lock is, and why exactly it happens.
> My Goal
> =======
> 1. I want to come up with an example of rotating one vector into
> another that "should" work, but is prevented from working by Gimbal
> lock when using Euler rep.
Gimbal lock doesn't exactly prevent motion completely --- Euler angles
do cover all possible orientations of the object under study. It's
actually more like a break-down of continuity of the mapping from
orientations to Euler angle triplets. It expresses itself in the fact
that, to rotate the object by an infinitesimal angle around a certain
direction given in world coordinates, with the object in a certain
current orientation, you have to change 2 Euler angles by a large
amount (90 degrees, typically).
The classic example are "aircraft Eulers", i.e. the angles used to
describe the orientation of a plane: yaw (or "heading") gives the
compass direction, "pitch" the angle of the plane's forward axis
relative to the horizon, and "roll" the angle of rotation around its
forward axis. The gimbal lock orientation is at pitch = +/- 90
degress, i.e. when the plane is flying straight up or down. This has
the roll and the heading axis parallel to each other (both point up).
For each such orientation, there's an infinite set of pairs of yaw and
roll angle that correspond to it.
Now, let's arbitrarily assume that both roll and yaw are currently
zero, and pitch at +90 (the plane flies straight up, its belly to the
north, the right wing extended to the east). Now rotate the plane an
infintesimally small angle around the local "up" axis of the plane,
i.e. the direction connecting the pilot's seat-of-pants to his head,
let's say to move the nose a little westward. Suddenly, the new
orientation corresponds to yaw=90 degrees (west), roll=90degrees (righ
wing up). Or you turn right a tiny bit, and it's yaw=-90 (east),
roll=-90 (left wing up). Pitch still almost exacly 90 degrees (nose
up) in both cases.
If you try to actually do that, with an object mounted in a set of
gimbals according to these three angles, you've just had to swing 2
gimbal a quarter turn, to achieve an infinitesimal movement of the
mounted object. For an object with non-zero inertial mass, that means
you need infinite force to get it there in finite time.
Or, put differently, if you grab the plane (not one of the gimbals)
and try to move it like that, it won't budge, because all axes of
rotation they have are orthogonal to your momentum, which means their
angular accelaration caused by your torque is zero. I.e. none of the
gimbals will begin to move, no matter how hard you try to turn the
object they hold --- the gimbals appear locked. But only in this kind
of situation, and only in one particular direction you try to move the
plane.
> QUESTION 1: can someone please illustate the lock situation described
> above by giving an example of an orientation of the statue that we can
> NOT achieve now given this lock situation?
Wrong question. It's not that you can't achieve a new orientation at
all. It's just that the way direct way there is surprisingly long, in
parameter space. Mathematically, it's a coordinate singularity at the
borders of parameter space.
--
Hans-Bernhard Broeker (bro...@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.
Just d' FAQs
>I am working on implementing rotations (just mathematically, no use of
>a particular rendering API), and have a good understanding of Euler,
>Axis Angle, and Quaternion representations of rotations, but I am
>struggling A LOT trying to get an intuitive grasp of the
>manifestations of Gimbal lock and solving gimbal lock with
>quaternions.
Probably you have read the discussion of quaternions in the FAQ, but
if not, please do. There a distinction is made between the locking up
of physical gimbals and the mathematical phenomenon we call by the
same name.
"5.25 What’s the big deal with quaternions?"
<http://magic-software.com/Resources.html>
The essence of our mathematical gimbal lock is that "The map is not
the territory". We can illustrate the issue with something much more
familiar than abstract rotation space, then transfer our results.
EARTH MAP
Consider the surface of the Earth, idealized as a smooth sphere. It is
continuous and identical everywhere. Now consider a typical map where
one direction is longitude and the other is latitude. In the vicinity
of Geneva, latitude 46.12N and longitude 6.09E, we are happy. We can
change latitude a little and we move as expected; and we can change
longitude a little and again move as expected. So here the map is like
the territory, and reflects the underlying local R^2 topology of the
sphere. Not so at the poles.
At the North Pole, latitude 90.00N, the globe itself is identical to
the vicinity of Geneva. Yet when we change longitude, we do not move!
Clearly the problem is not with the globe, nor with the gyrations of
any physical apparatus. The problem is with our map.
In fact, we are assured by topologists that such failure cannot be
avoided no matter how we associate points in R^2 with points on the
sphere. The two surfaces are not "homeomorphic" and certainly not
"diffeomorphic"; no continuous invertible mapping exists.
Yet we know that the 3D coordinates of points on a sphere vary easily
and smoothly everywhere, with no trouble spots. The third coordinate
may seem redundant since we really have only 2 degrees of freedom; but
it keeps us out of topological trouble.
GIMBAL LOCK
This, then, is what mathematical gimbal lock is all about.
Rotations in 3D have their own intrinsic structure of neighborliness,
of what's near what, just as the globe does. Euler angles do violence
to that structure; quaternions don't.
And, in fact, the analogy is remarkably close, because the topology of
3D rotation space is almost exactly that of a sphere in 4D. We must
quibble with "almost" because opposite points, antipodes, should be
treated as the same point. We can't see that locally, though it does
have global consequences. Quaternions give 4D coordinates for points
on that "hypersphere", with q and -q giving the same rotation. Euler
angles slice it up much like latitude and longitude.
For a topologist, 3D rotations look like RP^3, real projective space
of three dimensions. Quaternions are simply homogeneous coordinates, a
simple and natural choice. Euler angles use R^3, which necessarily
tears the space.
Euler angles come in many variations, each with its own trouble spots.
But all of them have something like a "North Pole", where the map goes
wonky on us.
<http://www.catb.org/~esr/jargon/html/W/wonky.html>
SO WHAT
Does this mean Euler angles are evil and we should never use them? No,
of course not. After all, we routinely use north-south/east-west maps
to find our way around a strange place, so long as that place isn't in
the vicinity of one of the Poles. However, it does mean that when we
have an application that may take us *anywhere* in rotation space, as
often happens, we prefer quaternions.
We should also note that quaternions have other benefits besides the
absence of gimbal lock. Some are noted in the FAQ.
Steve Titus
"Hans-Bernhard Broeker" wrote
>
> You're actually contradicting yourself there, to some extent. You
> can't really have a good understanding of Euler angle until you've
> grasped what a gimbal lock is, and why exactly it happens.
>
Fair enough :-).
>
> The classic example are "aircraft Eulers", i.e. the angles used to
> describe the orientation of a plane: yaw (or "heading") gives the
> compass direction, "pitch" the angle of the plane's forward axis
> relative to the horizon, and "roll" the angle of rotation around its
> forward axis. The gimbal lock orientation is at pitch = +/- 90
> degress, i.e. when the plane is flying straight up or down. This has
> the roll and the heading axis parallel to each other (both point up).
> For each such orientation, there's an infinite set of pairs of yaw and
> roll angle that correspond to it.
>
> Now, let's arbitrarily assume that both roll and yaw are currently
> zero, and pitch at +90 (the plane flies straight up, its belly to the
> north, the right wing extended to the east). Now rotate the plane an
> infintesimally small angle around the local "up" axis of the plane,
> i.e. the direction connecting the pilot's seat-of-pants to his head,
> let's say to move the nose a little westward. Suddenly, the new
> orientation corresponds to yaw=90 degrees (west), roll=90degrees (righ
> wing up). Or you turn right a tiny bit, and it's yaw=-90 (east),
> roll=-90 (left wing up). Pitch still almost exacly 90 degrees (nose
> up) in both cases.
>
Hans-Bernard, thanks for your excellent description! -- this now makes sense
to me: when we're nose-up, the roll and yaw are synonymous, and for any
nose-up orientation (say, wings parallel to horizon), I could specify it
with a pair roll, yaw (in the case of wings parallel to horizon, this pair
would have to fulfill roll + yaw = 0). Your description also explains well
the +90 and -90 discontinuities.
Remaining Difficulty: Local vs. World Axes
=============================
It seems that the aircraft example makes sense because two of the axes are
fixed "world" axes: the "up" axis (to which heading/yaw is referred), and
the "horizon" axis (to which pitch is referred). The roll, however, is
relative to the forward axis of the plane, which moves with the plane and
hence is free to coincide with the other axes and cause the lock
(incidentally, we can also gimbal lock at yaw=+-90, where pitch and roll
become synonymous, correct?).
I think the terminology of "Rotation Matrices" vs."Euler Angles (Euler
Transform)" is causing my confusion. QUESTION: When we talk about Euler
angles, are we ALWAYS implicitly talking about the situation we discussed
above -- i.e. the angles are understood to be with respect to two fixed
world axes (pitch, yaw) and one local "object" axis (roll) ???
Final Issue: relation to graphics
=====================
Typically, a scene to be rendered is stored as a bunch of objects, each
described in its local coord system. To compose a scene, each object is
placed in the scene using an object-specific modeling transformation that
translates, rotates, and perhaps scales the object (i.e. converts object
local coords to world coords). Let's talk about the rotational part of that
transformation in light of what we've talked about above. The rotational
(upper left 3x3 portion of the transform) angularly orients the object with
respect to the world X,Y,Z coords, right? Of course, this 3x3 matrix may
have initially been created by composing 3 rotations in some order, and can
also be decomposed into such, but the bottom line is that this transform
simply orients the object with repect to 3 FIXED world axes -- not two fixed
and one local as with the airplane, right? (I think of this matrix as the
composition of 3 rotation matrices...one for each world axis).
Now, when we are animating some tumbling object in a CG scene, we are simply
letting its local-to-world transform described above vary with time. This
seems to be the area where everyone is dealing with gimbal lock, etc., but
it seems to me that the "aircraft" gimbal lock could NOT occur in this case,
because we have 3 fixed world axes (i.e. the roll axis is not object local
like with the plane!). In this case, the +-90 blinking in and out of
existence should not happen, because axes will never coincide -- correct??
Thanks much!
Steve
Steven An
lock as well, and it took me a long time to get it, so I'll try to
explain how I got it.
Concerning your Goal #1) The "I'm busy leave me alone" answer is "No
such rotations exist". Using Euler angles, there is always a way to
rotate one vector into another (with equal length and with the same
origin of course..).
This is because Gimbal lock is something that only happens when you
rotate something in a certain way. When you rotate something to one
orientation, sometimes it won't be possible to rotate into some other
orientations unless you undo the first one. This is gimbal lock.
So your first goal should really be: Come up with an exmaple of
rotating one vector into another that does not work (due to Gimbal
lock) when the Y-axis rotation is rotated to 90 degrees. The answer
would be, any rotation that invovles rotating along the X-axis. (So
here's your answer to #2 really).
To visualize this, imagine a plane flying towards you (ie. out of the
screen). Then it yaws so it now points to the right of your screen
(Y-axis rotation of 90 degrees). Now ask yourself this: What if you
wanted to make the plane roll? Assume the order of rotation is X, Y,
Z. I reccomend you write a quick program (use the GLUT teapot if you
don't have a plane model, heh) and put yourself in this situation
(remember OGL applies matrices in reverse order, so do your glRotate's
in reverse order). Then continue reading if your mind doesn't go
"OH!!!" :D
The intuitive answer (and also the quaternion answer) is to just
rotate it along the X-axis now. But try doing this (in the program
you just wrote)...you'll see that rotating along the X-axis actually
causes the plane to tilt...and (here's the big kicker) so does the
Z-axis! WTF!?!?!? Gimbal lock!
Of course, if you were allowed to rotate all axis's freely, you could
eventually figure out how to have the plane point to the right and be
rolled. But obviously if you're writing a program/game and the user
encountered the above situation..they'd be very pissed/confused and
never use your software again :) And of course, if your gyro scope
works this way..bad stuff would happen.
Using quaternions, the intuitive answer would be the actual answer!
Rotating it along the X-axis would actually make it roll.
The key take-away is this: Gimbal lock occurs when you rotate
something a certain way, not when you're just given a goal to rotate
to. It's really more of a user-interface issue (and a big one). But
of course, quaternions have other big advantages too (like rotation
interpolation).
Alright hope that helps...good luck.
sti...@synopsys.com (Steve T) wrote in message news:<b09d9ad.04061...@posting.google.com>...
Just d' FAQs
wrote:
>Now, when we are animating some tumbling object in a CG scene, we are simply
>letting its local-to-world transform described above vary with time.
Yes, the object rotates with respect to the world, as described by a
time-varying transform.
>This
>seems to be the area where everyone is dealing with gimbal lock, etc., but
>it seems to me that the "aircraft" gimbal lock could NOT occur in this case,
>because we have 3 fixed world axes (i.e. the roll axis is not object local
>like with the plane!). In this case, the +-90 blinking in and out of
>existence should not happen, because axes will never coincide -- correct??
None of the 24 Euler angle systems mix local and global axes. All axes
are local or all three are global. For the record, the 12 orders are:
xyz, yzx, zxy, xzy, zyx, yxz,
xyx, xzx, yzy, yxy, zxz, zyz
The system used to describe the "attitude" of an airplane is normally
axes with respect to the aircraft. Roll is rotation around the axis
from tail to nose, pitch is around the axis from wingtip to wingtip,
and yaw is around the axis from wheels to canopy (roughly). Beginning
with the aircraft aligned to the world axes, first we yaw to get our
heading, then we pitch to aim the nose, then we roll.
But there's more to the story.
In any Euler system we must be careful with composition. We know with
a matrix that if we multiply the current orientation matrix by some
incremental rotation we will get a new orientation matrix. With Euler
angles it's not so simple. If our current orientation is given by an
angle triple like (r,p,y), and we turn using incremental rotation with
triple (a,b,c), the result is NOT triple (r+a,p+b,y+c).
Euler angles may be a triple of numbers that look like a vector, but
they do not add like vectors. If they did, a system like xyx wouldn't
make any sense, because the last x rotation would just be absorbed
into the first x rotation.
Think about a sequence of six rotation matrices.
X1 Y1 Z1 X2 Y2 Z2
If we could swap the order of 3D rotations, we could rewrite this as
X1 X2 Y1 Y2 Z1 Z2
This is what it would mean to add two Euler triples. Unfortunately, we
*cannot* reorder 3D rotations.
ADVANCED
There are two, rare, exceptions. If all the rotations are around the
same axis, then we're back to the 2D case where order doesn't matter.
Or if all the increments are truly infinitesimal, which only happens
when we're doing calculus, then the errors of this approximation are
doubly infinitesimal and can sometimes be ignored.
Readers who are interested in the infinitesimal case might enjoy the
Baker-Campbell-Hausdorff formula (or Campbell-Baker-Hausdorff, or
Campbell-Hausdorff) for "adding" tangent vectors in a Lie algebra:
u (+) v = u + v + 1/2 [u,v] + 1/12 [u,[u,v]] - 1/12 [v,[u,v]] - ...
Here [u,v] denotes the "commutator" of u and v, which for 3D rotations
is simply the cross product u X v. Lie groups and their Lie algebras
may be a little intimidating, but here we can think of vectors u and v
as angular velocities which we want to combine.
This quantifies the baffling claim "infinitesimal rotations commute",
which is hard to reconcile with the fact that *finite* rotations
definitely *do not* commute. All the commutator terms are at least
"second-order" small.
Hans-Bernhard Broeker
> It seems that the aircraft example makes sense because two of the axes are
> fixed "world" axes: the "up" axis (to which heading/yaw is referred), and
> the "horizon" axis (to which pitch is referred).
No. They can both be considered to be done with respect to local axes
of the plane (wing axis, and belly-to-top-side axis) with equal
justification, and they usually are.
Or you can consider all three rotations being done around a world
axis, if you want to:
roll: around horizontal to the north
pitch: around horizontal to the west
yaw: around the vertical
in that order, with the plane starting out level, pointing north.
> (incidentally, we can also gimbal lock at yaw=+-90, where pitch and roll
> become synonymous, correct?).
No.
> I think the terminology of "Rotation Matrices" vs."Euler Angles (Euler
> Transform)" is causing my confusion. QUESTION: When we talk about Euler
> angles, are we ALWAYS implicitly talking about the situation we discussed
> above -- i.e. the angles are understood to be with respect to two fixed
> world axes (pitch, yaw) and one local "object" axis (roll) ???
No. See above. Euler angles means you fix a sequence of three
rotations, either all around local axes, or all around world axes, and
vary only the amount of rotation around each.
And concerning animation: the reason Euler angles are pretty much
useless for animation of freely rotating objects is not gimbal lock,
but rather the fact that there's no sane way to combine two rotations
given as Euler triplets (one for the current position, the other
representing the rotation by its angular velocity accumulated over
some time) into a new Euler triplet, other than transforming both
inputs to some other representation (quaternions or matrices),
multiplying those, and then transforming the result back to Eulers.
All those transformations from Euler to something else and back again
would be wasteful. They can be avoided by maintaining the current
position and its change per timestep in matrix or quaternion form, so
that's what people do.
Stephen Titus
>
> To visualize this, imagine a plane flying towards you (ie. out of the
> screen). Then it yaws so it now points to the right of your screen
> (Y-axis rotation of 90 degrees). Now ask yourself this: What if you
> wanted to make the plane roll? Assume the order of rotation is X, Y,
> Z. I reccomend you write a quick program (use the GLUT teapot if you
> don't have a plane model, heh) and put yourself in this situation
> (remember OGL applies matrices in reverse order, so do your glRotate's
> in reverse order). Then continue reading if your mind doesn't go
> "OH!!!" :D
>
> The intuitive answer (and also the quaternion answer) is to just
> rotate it along the X-axis now. But try doing this (in the program
> you just wrote)...you'll see that rotating along the X-axis actually
> causes the plane to tilt...and (here's the big kicker) so does the
> Z-axis! WTF!?!?!? Gimbal lock!
>
Thanks, Steven, this makes good sense. I think we are getting to the
heart of my issue, which I think is the local vs. global axis stuff. My
mind does go OH!!, but there is a catch: I can't get MY implementation
of rotations (which is just the stock set of typical XYZ rotation
matrices), to do this!
Let me re-iterate your scenario in precise terms, so we are for sure on
the same page:
* +Z out of paper, +Y up, +X to the right.
* Initial orientation: plane out of paper, +Z axis coming at me through
its nosecone, x axis skewering the wings.
* First rotation: YAW the plane 90 deg around Y (point it right)
* Second rotation: (which we would THINK was a roll) 90 deg around X
* Assumption: the order of rotation is XYZ
A naive non-gimbal savvy person would think that the plane would end up
with its nose pointing down X axis and wings through Y axis so that the
top of pilot's head would be facing us...
OK...I went ahead and constructed 3 simple rotation matrices, Z=0 deg,
Y=90 deg, X=90 deg. Just so we know it is not my matrix implementation
screwing us up, here they are :
Transform Z=0 Matrix (ident):
[ 1.000 0.000 0.000 0.000 ]
[ 0.000 1.000 0.000 0.000 ]
[ 0.000 0.000 1.000 0.000 ]
[ 0.000 0.000 0.000 1.000 ]
Transform Y=90 Matrix:
[ 0.000 0.000 1.000 0.000 ]
[ 0.000 1.000 0.000 0.000 ]
[ -1.000 0.000 0.000 0.000 ]
[ 0.000 0.000 0.000 1.000 ]
Transform X=90 Matrix:
[ 1.000 0.000 0.000 0.000 ]
[ 0.000 0.000 -1.000 0.000 ]
[ 0.000 1.000 0.000 0.000 ]
[ 0.000 0.000 0.000 1.000 ]
Now, let's consider a single point: the tip of the nosecone of the
plane, which will start out at z=1: homoegeneous rep nose = [0 0 1 1]'.
Let's re-create the series of rotations you describe by doing the
following matrix multiplications one-by-one:
newnose = [X][Y][Z] nose
NOTE: matrices are XYZ left to right in mult because we want to do what
you describe above: first rotate by Z (do nothing in this case), then
rotate around Y (make nosecone point right), then rotate around X (which
IF the locking is happening, should result in nosecone pointing in Y
dir, because we would be "tilting" 90 degrees).
What I get is:
Vector N at start:
[ 0.000 0.000 1.000 1.000 ]
Vector N after Z=0:
[ 0.000 0.000 1.000 1.000 ]
Vector N after Y=90:
[ 1.000 0.000 0.000 1.000 ]
Vector N after X=90:
[ 1.000 0.000 0.000 1.000 ]
The final X did not "tilt" the plane, in fact, since the nosecone is
along the X axis after the "yaw", it just stayed put...just like you'd
expect!
If I do this with a point like [0.1 0 1.0 1] (a point slightly to the
right of center of the nose), the final X rotation does indeed rotate
about X (I will spare you the output on that one).
I realize that this is all insanely simple, and that there is something
huge I am missing, but I want to work this out with simple matrices,
after which I will let the API do all the work.
As I have said, your example makes PERFECT sense IF, WHEN WE DO THE YAW,
THE X AXIS ROTATES AND THE Z AXIS STAYS PUT, which results in X and Z
coinciding -- but this only happens if the X axis is a "local" plane
axis, while the Z axis is a "world" out-of-paper axis!
The results of my experiment seem right to me, because my axis are all
fixed, "world" axes, so I can't make one coincide with another...
Steve
Stephen Titus
>
> Or you can consider all three rotations being done around a world
> axis, if you want to:
>
> roll: around horizontal to the north
> pitch: around horizontal to the west
> yaw: around the vertical
>
> in that order, with the plane starting out level, pointing north.
>
I think the key thing I was missing is the specification of order. I was
about to claim that the whole locking scenario we discussed earlier (
the plane nose-up, belly north, let's move the nose a bit to the west )
will not occur for the 3 world axes case... my logic was "if ROLL is
around horiz to the north, then if we've pitched our plane 90 degrees,
then all we need to do is roll it a bit in the pitched position to get
the nose to move west!"
...but I see now that if ORDER is RPY, of course we can not do
that...what was happening is that I was allowing my brain to permute the
Euler triple in a suitable way so that lock would not occur. Darn brain!
The order issue is also explains why the simple experiment that I
proposed to Steven in this thread behaves the way it does...
Thanks, Hans-Bernhard.
Steven An
rotations! You should be doing this:
newnose = [Z][Y][X] nose
So you apply the X rotation FIRST, and then my example will work :)
(AND REMEMBER: OGL applies the rotations, well all matrices in
general, IN REVERSE ORDER!! So if you did glRot.(X..); glRot.(Y..)
glRot.(Z..), OGL would do the Z rotate first!)
Of course, if you did newnose = [X][Y][Z] nose, gimbal lock would
still occur. Try pitching the plane (ie. make the pilot look up and
down) now! You can't; you can only roll!
Yes, you can sorta think of this as a local vs. world thing. Just
remember, it's all in the ORDER of rotation. The X-axis does get
rotated by the Y, but so does the Y-axis by the Z (using my original
assumed order). And this is the fundamental problem with Euler
angles...the axis aren't independent. With quaternions, everything
stays put as you would expect them to. This is why quaternions are so
much more intuitive (which is somewhat ironic, cuz quaternions are
based on 4D math, which is anything but intuitive).
Stephen Titus <ti...@nospam.com> wrote in message news:<40cb2...@news.unc.edu>...
Steve Titus
made everything fall into place for me. I was letting my mind permute orders
when convenient so that I was mentally avoiding lock... :-)
Now it makes sense...
Thanks to all who helped me out!
ST
"Steven An" <stev...@uclink.berkeley.edu> wrote in message
news:4953656d.0406...@posting.google.com...