Re: Setting listener orientation

Peter Soxberger wrote:
> Hi!
>
> I guess this is an often asked question but I didn't found any useful information for this problem:
>
> I have the position (.x, .y, .z,) and the angles/orientation (.pan, .tilt, .roll) of the camera of a grafic engine. Setting the OpenAL listener position is easy. But how do I set the orientation?
>
> alListenerfv(AL_ORIENTATION, ListenerOri);
>
> This is the function but I don't know how I have to convert the angles into an "at" and "up" vector.
>
> Could anybody tell me how this works? Btw. I have no clue what is ment by an at and up vector. Why doesn't OpenAL use angles for the orientation?
>   

"At" means the vector pointed forward, and "up" is the vector pointed 
up.  If you imagine your head as the listener, the at vector would go 
from the center of your head through your nose, and the "up" vector is 
an orthogonal vector through the top of your head.  I believe both of 
these should be specified as unit vectors.

The problem with Euler angles (pan, tilt, roll) is that they are 
ambiguous.  There are literally an infinite number of ways to specify 
any particular orientation using Euler angles.  Also, there are as many 
as 24 different ways to interpret Euler angles.  In an OpenGL/OpenAL 
application you might think of them as a Y-axis rotation, followed by an 
X-axis rotation, then a Z-axis rotation, but there is no written 
convention that says it has to be this was.  You could also interpret it 
as ZXY, XYZ, or even XYX, YXY, etc.  Also, when you rotate around Y 
first, does the following X-axis rotation apply to the original X-axis 
(static coordinates), or the newly-rotated X-axis (rotating 
coordinates)?  Instead of adopting and documenting all of these details, 
its much easier to use the at/up vector convention.

Worst of all, it's easy to get into mathematical instabilities using 
Euler angles.  Take an orientation of (0, 90, 0) degrees (using the YXZ 
convention with rotating coordinates).  Now, imagine you want to pan 
left.  The problem is that your Y axis has now lined up exactly with 
your Z axis, so it's now completely ambiguous whether you intend to pan 
or roll.  This is called "gimbal lock".  If you implement this in 
software, it almost never goes well (believe me, I've tried  :-) ).

This web site has a good description of Euler angles, the ambiguities 
and issues, and alternate methods of specifying orientation:
http://www.euclideanspace.com/maths/geometry/rotations/euler/index.htm

The at/up vector convention avoids all of these issues.  Another 
possibility would be to use a rotation matrix or a quaternion for 
orientation, but the two vector form is a bit more straightforward.

--"J"

_______________________________________________
Openal mailing list
[email protected]
http://opensource.creative.com/mailman/listinfo/openal