[Papervision3D] Rotating around world axis

[Tim Knip]

sorry, bug in graph :-)

z
|
*----x
rotateY 90 results in:
    x
    |
z---*
a further rotateZ 90 results in:
    y
     |
z---*

2007/11/13, Tim Knip <tim.knip at gmail.com>:
> Hello,
>
> All rotations are already done using quaternions.
> So gimbal-lock should *not* be appearing, and afaik it doesn't.
> Your sample-swf behaves absolutely normal.
>
> There is no such thing as 'axis becoming parallel' or 'losing an axis'
> as you state.
> Again: everything behaves as it should:
> z
> |
> *----x
> rotateY 90 results in:
>      y
>      |
> x---*
> a further rotateZ 90 results in:
> y__*
>      |
>      x
> Now for your problem... see above graph...
> Where it boils down to: you need to understand that after one
> rotation, any following rotation might not be what you expect...
>
> Tim
>
>
> 2007/11/13, pokypin <dustin at curiousmedia.com>:
> >
> > I have done some more research and discovered a name for the problem I keep
> > running into. The problem is apparently known as gimbal lock, and is also
> > apparently an inherent flaw in using Eular angle calculations. From what I
> > have found, gimbal lock is unavoidable using Eular angle calculations. By my
> > understanding gimbal lock occurs when two axis become parallel, resulting in
> > the equivalent of losing 1 axis. Also by my understanding this occurs
> > because in the Eular system, rotations are calculated on the XYZ axis in
> > order, not simultaneously. The most basic step to solving this problem seems
> > to be using Quaternion angle calculations instead. From what I understand
> > Quaternion rotation calculations are all made simultaneously, thus avoiding
> > gimbal lock.
> >
> > I was able to find a few threads where the issue was discussed by what
> > seemed to be members of the PV3d team. From what I found, it seems,
> > Eular/Matrix3D calculations were chosen because they were less complicated,
> > and also less CPU intensive.
> >
> > Anyways, that was probably a very crude and bad explanation, but I think I
> > basically understand the problem. Am I right to assume that if papervision
> > was modified to use Quaternion angle calculation instead, then gimbal lock
> > would not occur? While I think I understand, I definitely do not have the
> > knowledge necessary to make such a modification.
> >
> > So I suppose I could restate my question to: Does anyone know how to easily
> > modify papervision to avoid gimbal lock, by using Quaternion or any other
> > method? I don't know how many aspects would be involved to truly port
> > everything over to Quaternion, but all I am really interested in is doing 90
> > degree rotations on any axis without running into gimbal lock. Using too
> > much cpu doesn't scare me away at this point, I just want to see it work. I
> > feel like I may be rambling now, but I just wanna do "SIMPLE" rotations! :P
> >
> > Ok, so for everyone to see it in action I have created a sample:
> > http://www.dustinbahr.com/pv/gimbalLock.html
> >
> > Pressing x, y, or z, will do a 90 degree rotation on the appropriate axis.
> > red = x, green = y, blue = z. To see gimbal lock occur is very simple. Press
> > y to rotate around the y axis, then try pressing either z or x. You will see
> > that they both rotate around the "x" axis. (note: if you press z first you
> > will see that it actually is trying to rotate around the z (blue) axis.)
> > --
> > View this message in context: http://www.nabble.com/Rotating-around-world-axis-tf4486910.html#a13731436
> > Sent from the Papervision3D mailing list archive at Nabble.com.
> >
> >
> > _______________________________________________
> > Papervision3D mailing list
> > Papervision3D at osflash.org
> > http://osflash.org/mailman/listinfo/papervision3d_osflash.org
> >
>