[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Camera thoughts
- To: email@example.com
- Subject: Re: Camera thoughts
- From: Steve Baker <firstname.lastname@example.org>
- Date: Mon, 01 Apr 2002 19:02:13 -0600
- Delivered-To: email@example.com
- Delivered-To: mailing list firstname.lastname@example.org
- Delivery-Date: Mon, 01 Apr 2002 20:03:43 -0500
- Mailing-List: contact email@example.com; run by ezmlm
- Organization: Steve at Home
- References: <20020324121825.45B303726@gate.home.lan> <3CA5E9F6.378233F2@airmail.net> <3CA25F7D.F61C5667@gbl.com.br> <3CAA65DA.E2EB8A5B@airmail.net> <3CA33202.17A7DE48@gbl.com.br> <3CAB917F.49D7DA4E@airmail.net> <3CA86780.3BC23E15@gbl.com.br>
- Reply-To: firstname.lastname@example.org
- Sender: email@example.com
"Miguel A. Osorio" wrote:
> Steve Baker wrote:
> > > With the camera model I described, would that be replacing the GLU
> > > function call by three glRotates (about the three camera axis) and one
> > > glTranslate?
> > Well, not exactly I suggest that...
> Err... Sorry for pulling your leg a little longer, but how about if
> using quaternions? I mean, if I *do* want to express the rotation in
> I'm thinking I could encode these three rotations into three
> quaternions, multiply them all, and compose a rotation matrix based on
> the result quaternion - would that be a reasonable approach ?
Quaternions are a useful way to combine rotations - but there is no point
Eulers -> Quaternions -> Matrix
...that's just equivalent to doing Euler -> Matrix.
The problems are all in the fact that there are *many* representations
of a particular rotation using Eulers - but only one with a matrix.
So, Eulers are fine for *storing* angles - but useless for doing math
on them. You can convert your Eulers into either a quaternion or a matrix
then do the math on this new representation and convert them back again.
To see what I mean, do the exercise with the paper plane in my Euler FAQ:
...in that example, we took an initial rotation angle (expressed in Eulers)
then ADDED some angles to it. Doing the addition in Euler angles resulted
in a nasty confusing mess.
You have to realise that there are multiple ways to express a single rotation
in Eulers. For example, if you do your rotations in the order Roll/Pitch/Heading
then R=180,P=180,H=0 yields the same position as R=0,P=0,H=180. But if you
are in that position and you use your joystick to roll the camera by 10 degrees
and if the software does Euler angle math then in the first case, you'll have
a rotation or R=190,P=180,H=0 and in the other you'll get R=10,P=0,H=180 which
are NOT the same rotation!
This confuses the poor user no end. He does some complicated camera move to
get into some position - but what happens when he moves the joystick subsequently
depends on HOW HE GOT THERE?!? So doing math in Eulers doesn't really work.
However, if you convert R=180,P=180,H=0 and R=0,P=0,H=180 into *either* a
matrix *or* a Quaternion - you'll end up with the exact same numbers in either
case. Then if you take that 10 degree Roll angle and convert *that* into either
a matrix or a quaternion, you can do the math and you'll get the exact same
answer in both cases. You can even convert either a matrix or a quaternion
back into Euler angles - and the system will still work.
----------------------------- Steve Baker -------------------------------
Mail : <firstname.lastname@example.org> WorkMail: <email@example.com>
URLs : http://www.sjbaker.org
http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net