[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

*To*: linuxgames@sunsite.dk*Subject*: Re: Camera thoughts*From*: Steve Baker <sjbaker1@airmail.net>*Date*: Mon, 01 Apr 2002 19:02:13 -0600*Delivered-To*: archiver@seul.org*Delivered-To*: mailing list linuxgames@sunsite.dk*Delivery-Date*: Mon, 01 Apr 2002 20:03:43 -0500*Mailing-List*: contact linuxgames-help@sunsite.dk; 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*: linuxgames@sunsite.dk*Sender*: steve@seul.org

"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 > terms of yaw, pitch and roll (for simplicity in terms of user input), > 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 to doing: 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: http://www.sjbaker.org/steve/omniv/eulers_are_evil.html ...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 : <sjbaker1@airmail.net> WorkMail: <sjbaker@link.com> URLs : http://www.sjbaker.org http://plib.sf.net http://tuxaqfh.sf.net http://tuxkart.sf.net http://prettypoly.sf.net http://freeglut.sf.net http://toobular.sf.net http://lodestone.sf.net

**Follow-Ups**:**Re: Camera thoughts***From:*"Miguel A. Osorio" <maos@gbl.com.br>

**References**:**Re: Camera thoughts***From:*"Miguel A. Osorio" <maos@gbl.com.br>

- Prev by Date:
**Re: Camera thoughts** - Next by Date:
**Re: Camera thoughts** - Prev by thread:
**Re: Camera thoughts** - Next by thread:
**Re: Camera thoughts** - Index(es):