Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
On 11/07/2009 08:03 PM, John Denker wrote: I wrote: I'm gradually figuring out a little bit of what the viewer code is doing. In particular: As for the basic cockpit lookfrom view, the viewer.cxx reference frame for attitudes is as follows: Suppose you are over the Gulf of Guinea, at (lat,lon) = (0,0). Then the reference frame orientation can be achieved via: -- The aircraft X-axis (nose) headed south. -- The aircraft Y-axis (starboard wingtip) pointing up. -- The aircraft Z-axis (belly) pointing west. Equivalently, but with less stress on the passengers, suppose you are over the Indian Ocean, at (lat,lon) = (0,90). Then the reference frame for attitudes can be achieved via: -- Heading = south. -- Pitch = level flight. -- Bank = level flight. On 11/06/2009 02:48 PM, Tim Moore wrote: You need to show your work :) The behavior reported above was observed using the feature I implemented whereby the orientation quats are exposed in the property tree. Erik committed the code, so anyone can easily replicate the observations. Also the observed behavior is entirely consistent with the apparent intent of the viewmgr.cxx code, as I read it. OK, I now see what you're saying: a zero view orientation implies those attitudes at those locations. It's not a surprising result; when working with an earth-centered frame, the orientation of the view is often non-intuitive. I was confused by your use of reference frame above. Although the orientation value is zero where you describe, I/we never think of those configurations as reference as it's not that useful. Better to think of the earth centered frame or the local relative frame as a reference. Note: Since there was some criticism of one of the property names I used, and more importantly some quite useful criticism of the underlying concepts and interpretation, I have submitted a follow-on patch that should fully deal with these issues. http://www.av8n.com/fly/fgfs/viewframe.patch This doesn't agree with my understanding of viewer.cxx, but I didn't write it. This is what I thought was going on: The basic reference frame for all geometry is your Earth Centered - Earth Fixed frame. Right. ECEF is the first item on my list of reference frames documented at http://www.av8n.com/physics/coords.htm I reckon the real issue here is not ECEF itself, but rather the fact that as mentioned at http://www.av8n.com/physics/coords.htm#sec-orientation to describe the orientation of a body in space, you need *two* things, not just a set of coordinates (and the vector basis induced by those coordinates), but also a set of identifiable axes attached to the body. Yes, and in the case of the viewer, it's not well documented that the body axes are the OpenGL viewing axes. If you use the conventional aviation body axes, i.e. X=forward, Y=starboard, Z=belly then the standard orientation, achieved by aligning the body axes with the ECEF axes, corresponds to flying at (lat,lon) = (0,0) with nose = vertically up starboard wingtip = east belly = north After this, the rotation from an X-forward Z-down frame to the OpenGL Z-back Y-up frame is added in. I agree with that ... except perhaps for the words after this. My point here is that viewmgr.cxx converts to OpenGL coordinates fairly early ... and in particular Erik's new code passes around the OpenGL representation and does lots of calculations using that representation. Quite understandably, he found some of this surprising and confusing. In terms of the viewer, it's the last rotation applied to form the view orientation, so I'm comfortable in saying it is applied late. If you want to do further calculations with the view orientation in some other frame of reference you might think the OpenGL rotation is applied early. In particular, if you align the OpenGL axes i.e. Xprime=starboard, Yprime=top, Zprime=aft with the ECEF axes, then you get exactly the orientation described in my previous note and quoted above. It may seem implausible, unconventional, and/or inconvenient, but it *is* what the code is using. The more unconventional and implausible something is, the more important it is to document it. My recent patch contains a bunch of explanatory comments. I'm still not seeing why this is so implausbile, unconventional, etc. Not only is the OpenGL convention common in the world of, well OpenGL, but in simulation in general you have to deal with different reference frames all the time and get used to moving between them. In the end I suppose is a matter of better documenting the viewer conventions; we could also expose the view orientation pre-OpenGL rotation if it is useful to do so. Also, in my recent patch, I took steps to cancel out the OpenGL transformation, so that the exposed quats use the conventional aviation body axes. This should make it easier to
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
I wrote: I'm gradually figuring out a little bit of what the viewer code is doing. In particular: As for the basic cockpit lookfrom view, the viewer.cxx reference frame for attitudes is as follows: Suppose you are over the Gulf of Guinea, at (lat,lon) = (0,0). Then the reference frame orientation can be achieved via: -- The aircraft X-axis (nose) headed south. -- The aircraft Y-axis (starboard wingtip) pointing up. -- The aircraft Z-axis (belly) pointing west. Equivalently, but with less stress on the passengers, suppose you are over the Indian Ocean, at (lat,lon) = (0,90). Then the reference frame for attitudes can be achieved via: -- Heading = south. -- Pitch = level flight. -- Bank = level flight. On 11/06/2009 02:48 PM, Tim Moore wrote: You need to show your work :) The behavior reported above was observed using the feature I implemented whereby the orientation quats are exposed in the property tree. Erik committed the code, so anyone can easily replicate the observations. Also the observed behavior is entirely consistent with the apparent intent of the viewmgr.cxx code, as I read it. Note: Since there was some criticism of one of the property names I used, and more importantly some quite useful criticism of the underlying concepts and interpretation, I have submitted a follow-on patch that should fully deal with these issues. http://www.av8n.com/fly/fgfs/viewframe.patch This doesn't agree with my understanding of viewer.cxx, but I didn't write it. This is what I thought was going on: The basic reference frame for all geometry is your Earth Centered - Earth Fixed frame. Right. ECEF is the first item on my list of reference frames documented at http://www.av8n.com/physics/coords.htm I reckon the real issue here is not ECEF itself, but rather the fact that as mentioned at http://www.av8n.com/physics/coords.htm#sec-orientation to describe the orientation of a body in space, you need *two* things, not just a set of coordinates (and the vector basis induced by those coordinates), but also a set of identifiable axes attached to the body. If you use the conventional aviation body axes, i.e. X=forward, Y=starboard, Z=belly then the standard orientation, achieved by aligning the body axes with the ECEF axes, corresponds to flying at (lat,lon) = (0,0) with nose = vertically up starboard wingtip = east belly = north After this, the rotation from an X-forward Z-down frame to the OpenGL Z-back Y-up frame is added in. I agree with that ... except perhaps for the words after this. My point here is that viewmgr.cxx converts to OpenGL coordinates fairly early ... and in particular Erik's new code passes around the OpenGL representation and does lots of calculations using that representation. Quite understandably, he found some of this surprising and confusing. In particular, if you align the OpenGL axes i.e. Xprime=starboard, Yprime=top, Zprime=aft with the ECEF axes, then you get exactly the orientation described in my previous note and quoted above. It may seem implausible, unconventional, and/or inconvenient, but it *is* what the code is using. The more unconventional and implausible something is, the more important it is to document it. My recent patch contains a bunch of explanatory comments. Also, in my recent patch, I took steps to cancel out the OpenGL transformation, so that the exposed quats use the conventional aviation body axes. This should make it easier to interpret the displayed properties. I realize most folks were not born with the ability to look at a quat and understand what it means, but it is a skill that can be learned. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
Erik Hofman wrote: Thanks to the help of Tim I am now really close to properly aligned, positioned and orientated sounds. Now for the bad part, except for Tower View and Fly-By View the orientation (and relative position) seem to have no effect? At least I've found the reason for this; I passed the wrong position to the listener; for some reason this one was always at the aircraft's fdm location.. Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
Erik Hofman wrote: Erik Hofman wrote: Thanks to the help of Tim I am now really close to properly aligned, positioned and orientated sounds. Now for the bad part, except for Tower View and Fly-By View the orientation (and relative position) seem to have no effect? At least I've found the reason for this; I passed the wrong position to the listener; for some reason this one was always at the aircraft's fdm location.. And now the Doppler effect is also fixed (sort of). I needed to multiply the velocity vector by 100 to get some sort of Doppler effect going on. Calculating the length of the velocity vector gave me 10 times lower than expected already. Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
On 3 Nov 2009, at 13:01, Erik Hofman wrote: And now the Doppler effect is also fixed (sort of). I needed to multiply the velocity vector by 100 to get some sort of Doppler effect going on. Calculating the length of the velocity vector gave me 10 times lower than expected already. Tends to point to a units error in the velocities ... but I guess (hope!) they're in metres per second? -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
James Turner wrote: On 3 Nov 2009, at 13:01, Erik Hofman wrote: And now the Doppler effect is also fixed (sort of). I needed to multiply the velocity vector by 100 to get some sort of Doppler effect going on. Calculating the length of the velocity vector gave me 10 times lower than expected already. Tends to point to a units error in the velocities ... but I guess (hope!) they're in metres per second? The unit used by OpenAL (as we use it) is indeed in meters (per second). Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
Hi Erik, Erik Hofman schrieb am 03.11.2009 14:01: And now the Doppler effect is also fixed (sort of). I needed to multiply the velocity vector by 100 to get some sort of Doppler effect going on. Maybe you are calculating the velocity as m/frame instead of m/s? Or you transformed the m/frame to m/s by multiplying by dt instead of a division by dt? Best regards, Maik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
Maik Justus wrote: Hi Erik, Erik Hofman schrieb am 03.11.2009 14:01: And now the Doppler effect is also fixed (sort of). I needed to multiply the velocity vector by 100 to get some sort of Doppler effect going on. Maybe you are calculating the velocity as m/frame instead of m/s? Or you transformed the m/frame to m/s by multiplying by dt instead of a division by dt? The speed is supplied by the FDM (I think, at least by FlightGear). I don't calculate anything special (except for unit conversion). Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
Hi Tim and John, First, thanks for looking at this, it has really given me headaches. Tim Moore wrote: Assuming you want the orientation and position of the listener, and the positions of the sources, to match those in the visual world, you should just use the absolute position and orientation in the corresponding FGViewer object i.e., what you get from FGViewer::getViewPosition() and FGViewer::getViewOrientation(). You don't need to worry about the local reference frame, view position and orientation offsets, or the rotation between OpenGL and aerospace coordinates; that is all included in those position and orientation values. Then the vectors you need for the OpenAL orientation are: SGVec3d lookAt = viewOrientation.back_transform(-SGVec3d::ec3); SGVec3d lookUp = viewOrientation.back_transform(SGVec3d::ec2); Ok, I'll test this right away. Now, there's a problem with using Cartesian coordinates directly: a single precision float doesn't have enough precision to represent positions near the earth's surface to better than a few meters. This is likely to be an issue for sound sources near the listener, like cockpit sounds and engine noises. So, the simplest coordinate system to use has its origin at the listener's position, but is oriented with the global Cartesian system. The position you set in OpenAL for the sound sources would just be the relative position of the source with respect to the listener i.e., sourcePos - listenerPos. That's one thing that has concerned me also and I have made preparations to make this easy. While setting the listener position and orientation and source positions is simple, you will need to transform the velocities of the listener and sources from the local earth frame to the global Cartesian frame. Looking at src/Model/acmodel.cxx, you have a velocity in the local frame as (speed_north, speed_east, speed_down) in feet per second. To transform that to the global frame: SGQuatd hlOr = SGQuatd::fromLonLat(_position); SGVec3d globalVelocity = hlOr.back_transform(localVelocity*SG_FEET_TO_METER); If you can point me to the code where you calculate the positions of local sources from the model, I'll take a look at that too. The local source positions are set in simgear/sound/xmlsound.xml but they are just offsets to the model in a normal situation and don't change during the simulation(yet). Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
John Denker wrote: A possibly helpful discussion of rotations can be found at http://www.av8n.com/physics/rotations.htm Thanks for the hints and links John, I really appreciate it. It covers various ways of representing rotations, including product-of-vectors i.e. Clifford algebra i.e. quaternions, matrices, Rodrigues vectors, and Euler angles. It discusses how to compute with such things, and how to convert from one to another. If any of it seems unduly unclear, please let me know. PS You'll have more luck googling for information if you stick to the standard spelling of _quaternions_. While this isn't exactly what I meant when I asked for 'at' from quaternations it does explain why I saw a lot of talk about them when searching for it, but no reeal explanation. Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
Tim Moore wrote: Assuming you want the orientation and position of the listener, and the positions of the sources, to match those in the visual world, you should just use the absolute position and orientation in the corresponding FGViewer object i.e., what you get from FGViewer::getViewPosition() and FGViewer::getViewOrientation(). You don't need to worry about the local reference frame, view position and orientation offsets, or the rotation between OpenGL and aerospace coordinates; that is all included in those position and orientation values. Then the vectors you need for the OpenAL orientation are: SGVec3d lookAt = viewOrientation.back_transform(-SGVec3d::ec3); SGVec3d lookUp = viewOrientation.back_transform(SGVec3d::ec2); Yes, finally! Thanks Tim I doubt I would have ever gotten this without any help. Now only directional sounds should be fixed. Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
Thanks to the help of Tim I am now really close to properly aligned, positioned and orientated sounds. Now for the bad part, except for Tower View and Fly-By View the orientation (and relative position) seem to have no effect? Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Call for Help (SoundSystem listener orientation)
At this time I've tried about everything to get the listener orientation aligned properly. What's needed it converting the ViewOrientation matrix (quaternation) and/or ViewOrientationOffset matrix (quaternation) to align with OpenGL and get the look-at and look-up vector from it. the look-at vector should match the OpenGL view vector and the up-vector is the perpendicular vector pointing out of the top of the listeners head. It looks like I'm really close (for testing I've commented out some position offset and velocity vector code) but to me it's not yet 100% right, as if I'm missing something. I would really appreciate it if someone who knows his way around this could take a look at SGSoundManager::update_pos_and_orientation() in SimGear/simgear/sound/soundmgr_openal.cxx View related values are set in FlightGear/src/Main/viewmgr.cxx: both recalcLookFrom() anf recalcLookAt() Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
On Sun, 2009-11-01 at 18:28 +0100, Erik Hofman wrote:
At this time I've tried about everything to get the listener orientation
aligned properly. What's needed it converting the ViewOrientation matrix
(quaternation) and/or ViewOrientationOffset matrix (quaternation) to
align with OpenGL and get the look-at and look-up vector from it.
the look-at vector should match the OpenGL view vector and the up-vector
is the perpendicular vector pointing out of the top of the listeners head.
It looks like I'm really close (for testing I've commented out some
position offset and velocity vector code) but to me it's not yet 100%
right, as if I'm missing something. I would really appreciate it if
someone who knows his way around this could take a look at
SGSoundManager::update_pos_and_orientation() in
SimGear/simgear/sound/soundmgr_openal.cxx
View related values are set in FlightGear/src/Main/viewmgr.cxx: both
recalcLookFrom() anf recalcLookAt()
Erik
Erik,
I'm not good at this stuff at all, but I just remembered that the mpmap
code recovers yaw, pitch and roll from the quaternion passed in the
multiplayer message... Is that what you need? Or is that where you
started from?
http://pigeond.net/git/?p=flightgear/fgmap.git;a=blob;f=src/fg_server_xml.cxx;hb=HEAD#l85
85 static void
86 euler_get(float lat, float lon, float ox, float oy, float oz,
87 float *heading, float *pitch, float *roll)
88 {
89 /* FGMultiplayMgr::ProcessPosMsg */
90
91 SGVec3f angleAxis;
92 angleAxis(0) = ox;
93 angleAxis(1) = oy;
94 angleAxis(2) = oz;
95
96 SGQuatf ecOrient;
97 ecOrient = SGQuatf::fromAngleAxis(angleAxis);
98
99 /* FGAIMultiplayer::update */
100
101 float lat_rad, lon_rad;
102 lat_rad = lat * SGD_DEGREES_TO_RADIANS;
103 lon_rad = lon * SGD_DEGREES_TO_RADIANS;
104
105 SGQuatf qEc2Hl = SGQuatf::fromLonLatRad(lon_rad, lat_rad);
106
107 SGQuatf hlOr = conj(qEc2Hl) * ecOrient;
108
109 float hDeg, pDeg, rDeg;
110 hlOr.getEulerDeg(hDeg, pDeg, rDeg);
111
112 if(heading)
113 *heading = hDeg;
114 if(pitch)
115 *pitch = pDeg;
116 if(roll)
117 *roll = rDeg;
118
119 }
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
Ron Jensen wrote: Erik, I'm not good at this stuff at all, but I just remembered that the mpmap code recovers yaw, pitch and roll from the quaternion passed in the multiplayer message... Is that what you need? Or is that where you started from? Not really, I need a (normalized) 3d vector that points towards the location the viewer is looking at. Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
On 11/01/2009 10:28 AM, Erik Hofman wrote:
At this time I've tried about everything to get the listener orientation
aligned properly. What's needed it converting the ViewOrientation matrix
(quaternation) and/or ViewOrientationOffset matrix (quaternation) to
align with OpenGL and get the look-at and look-up vector from it.
the look-at vector should match the OpenGL view vector and the up-vector
is the perpendicular vector pointing out of the top of the listeners head.
It looks like I'm really close (for testing I've commented out some
position offset and velocity vector code) but to me it's not yet 100%
right, as if I'm missing something. I would really appreciate it if
someone who knows his way around this could take a look at
SGSoundManager::update_pos_and_orientation() in
SimGear/simgear/sound/soundmgr_openal.cxx
View related values are set in FlightGear/src/Main/viewmgr.cxx: both
recalcLookFrom() anf recalcLookAt()
I know a fair bit about quaternions and rotations in general.
I don't know my way around the soundmgr code, but I will take
a look. At first glance this code looks much friendlier than
the corresponding viewmgr code, in the sense that its comments
are more numerous and much more meaningful.
Luckily I seem to get the best ideas when I'm frustrated since I now
found out that the up-vector of the listener was actually pointing down.
One small thing I can say about that: In aeronautical engineering,
the body x,y,z directions are conventionally defined as follows:
x = out the nose of the aircraft
y = out the starboard wingtip
z = out the bottom of the aircraft
This is diagrammed at http://www.av8n.com/how/htm/motion.html#fig-axes
If the aircraft is not in level flight, these axes are _not_
aligned with the earth-based notions of horizontal and vertical.
This convention may seem counterintuitive at first, but actually
it has several advantages:
-- It means that {x,y,z} is a right-handed basis set.
-- Rotation in the xy plane is /positive/ yaw,
i.e. clockwise as seen from above, looking in the +z direction.
-- Rotation in the yz plane is /positive/ roll,
i.e. clockwise as seen from behind, looking in the +x direction.
-- Rotation in the zx plane is /positive/ pitch
i.e. nose upward,
i.e. clockwise looking in the +y direction.
See e.g. http://www.av8n.com/how/htm/motion.html#fig-rotations
This has been the standard in the aeronautics community for 50
years that I know of, and probably longer than that.
On the other hand, nobody was born knowing this. Therefore,
in the spirit of open software, it would be nice if it were
conspicuously documented in the FG software. This would make
the software more maintainable and more extensible.
Contrast this with the OpenAL convention:
--) The bad news is that this OpenGL / OpenAL convention violates
the long-established aviation convention. This is a trap for the
unwary. It creates problems for anybody who wants to take code
from one part of FG and use it an another.
-- The good news is that simgear/sound/soundmgr_openal.cxx
contains the following comment, which IMHO is a quite
commendable example of how comments should be used:
/**
* Description: ORIENTATION is a pair of 3-tuples representing the
* 'at' direction vector and 'up' direction of the Object in
* Cartesian space. AL expects two vectors that are orthogonal to
* each other. These vectors are not expected to be normalized. If
* one or more vectors have zero length, implementation behavior
* is undefined. If the two vectors are linearly dependent,
* behavior is undefined.
* This is in the same coordinate system as OpenGL; y=up, z=back, x=right.
*/
It would be nice if viewmgr.cxx had correspondingly clear comments
about the semantics of its key variables, such as
-- ViewOrientation ... What is the standard orientation? I
am guessing that an aircraft at latitude zero and longitude zero,
in level flight, heading north, is in the standard orientation,
represented the identity quaternion (i.e. zero degrees of
rotation) ... but the code would be more open, more maintainable,
and more extensible if would-be contributors didn't have to guess
about such things.
-- ViewOrientationOffset. ... Offset? Offset of what relative to
what?
If somebody on the list knows the answers to such questions, perhaps
they could contribute an explanatory patch.
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
John Denker wrote: /** * Description: ORIENTATION is a pair of 3-tuples representing the * 'at' direction vector and 'up' direction of the Object in * Cartesian space. AL expects two vectors that are orthogonal to Hm that's an oversight, it should not be in Cartesian space but in OpenGL space (see the last line). Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
On 10/18/2009 02:04 AM, Erik Hofman wrote: I suspect there still is a positioning or orientation problem hiding somewhere that's causing it. My speed lessons in quaternations don't pay out just yet I guess. A possibly helpful discussion of rotations can be found at http://www.av8n.com/physics/rotations.htm It covers various ways of representing rotations, including product-of-vectors i.e. Clifford algebra i.e. quaternions, matrices, Rodrigues vectors, and Euler angles. It discusses how to compute with such things, and how to convert from one to another. If any of it seems unduly unclear, please let me know. PS You'll have more luck googling for information if you stick to the standard spelling of _quaternions_. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
On 11/01/2009 06:28 PM, Erik Hofman wrote: At this time I've tried about everything to get the listener orientation aligned properly. What's needed it converting the ViewOrientation matrix (quaternation) and/or ViewOrientationOffset matrix (quaternation) to align with OpenGL and get the look-at and look-up vector from it. the look-at vector should match the OpenGL view vector and the up-vector is the perpendicular vector pointing out of the top of the listeners head. It looks like I'm really close (for testing I've commented out some position offset and velocity vector code) but to me it's not yet 100% right, as if I'm missing something. I would really appreciate it if someone who knows his way around this could take a look at SGSoundManager::update_pos_and_orientation() in SimGear/simgear/sound/soundmgr_openal.cxx View related values are set in FlightGear/src/Main/viewmgr.cxx: both recalcLookFrom() anf recalcLookAt() I'm sorry I haven't looked in on this sooner. I've started to look at this and will have a (hopefully) coherent observation in the morning. Tim -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Call for Help (SoundSystem listener orientation)
On 11/01/2009 06:28 PM, Erik Hofman wrote: At this time I've tried about everything to get the listener orientation aligned properly. What's needed it converting the ViewOrientation matrix (quaternation) and/or ViewOrientationOffset matrix (quaternation) to align with OpenGL and get the look-at and look-up vector from it. the look-at vector should match the OpenGL view vector and the up-vector is the perpendicular vector pointing out of the top of the listeners head. It looks like I'm really close (for testing I've commented out some position offset and velocity vector code) but to me it's not yet 100% right, as if I'm missing something. I would really appreciate it if someone who knows his way around this could take a look at SGSoundManager::update_pos_and_orientation() in SimGear/simgear/sound/soundmgr_openal.cxx View related values are set in FlightGear/src/Main/viewmgr.cxx: both recalcLookFrom() anf recalcLookAt() Assuming you want the orientation and position of the listener, and the positions of the sources, to match those in the visual world, you should just use the absolute position and orientation in the corresponding FGViewer object i.e., what you get from FGViewer::getViewPosition() and FGViewer::getViewOrientation(). You don't need to worry about the local reference frame, view position and orientation offsets, or the rotation between OpenGL and aerospace coordinates; that is all included in those position and orientation values. Then the vectors you need for the OpenAL orientation are: SGVec3d lookAt = viewOrientation.back_transform(-SGVec3d::ec3); SGVec3d lookUp = viewOrientation.back_transform(SGVec3d::ec2); Now, there's a problem with using Cartesian coordinates directly: a single precision float doesn't have enough precision to represent positions near the earth's surface to better than a few meters. This is likely to be an issue for sound sources near the listener, like cockpit sounds and engine noises. So, the simplest coordinate system to use has its origin at the listener's position, but is oriented with the global Cartesian system. The position you set in OpenAL for the sound sources would just be the relative position of the source with respect to the listener i.e., sourcePos - listenerPos. While setting the listener position and orientation and source positions is simple, you will need to transform the velocities of the listener and sources from the local earth frame to the global Cartesian frame. Looking at src/Model/acmodel.cxx, you have a velocity in the local frame as (speed_north, speed_east, speed_down) in feet per second. To transform that to the global frame: SGQuatd hlOr = SGQuatd::fromLonLat(_position); SGVec3d globalVelocity = hlOr.back_transform(localVelocity*SG_FEET_TO_METER); If you can point me to the code where you calculate the positions of local sources from the model, I'll take a look at that too. Hope this helps, Tim -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
