[Openal-devel] AL_SOURCE_RELATIVE behavior

[Jason Daly]

On 03/11/2012 05:30 AM, Erik Hofman wrote:
> On Sat, 2012-03-10 at 15:02 -0800, Chris Robinson wrote:
>> Hey guys. I'm hoping to get some clarification on something.
>>
>> Up to now I had been working under the assumption that the AL_SOURCE_RELATIVE
>> source property made the source completely relative to the listener. That is,
>> a position of {0,0,0} would always be at the listener and {0,0,-1} would
>> always be in front in front of it, while a direction of {1,0,0} would always
>> face to the right of the listener, a velocity of {0,0,0} would always match
>> the listener's velocity, etc.
>>
>> Reading the 1.1 spec, it says this:
>>
>> "AL_SOURCE_RELATIVE set to AL_TRUE indicates that the position, velocity,
>> cone, and direction properties of a source are to be interpreted relative to
>> the listener position."
>>
>> Now, although it says it makes the source's position, velocity, cone, and
>> direction properties relative to the listener position, the source's velocity
>> and direction (and cone) are not affected by the listener position, just the
>> source's position in relation to the listener position. That, coupled with the
>> idea of what a relative source should be, can easily lead people to assume the
>> source properties are simply relative to the listener as a whole.
> My interpretation has always been that all sources are to be realigned
> such that the listener is located at { 0.0, 0.0, 0.0 } and (the listener
> is) facing { 0.0f, 0.0f, -1.0f,  0.0f, 1.0f, 0.0f }. Anything else would
> make it almost impossible to use matrix functions internally.
>
> So I would say all properties are relative to the listeners equivalent.


I have to believe that the more useful, less literal interpretation is 
what was originally intended.  The listener's local coordinate system 
essentially becomes the origin for all SOURCE_RELATIVE sources.  This 
would include velocities, so a SOURCE_RELATIVE velocity of (0, 0, 0) 
would match the listener's velocity exactly, as Chris pointed out.

As Erik says, anything else would make the use of matrix-based functions 
impossible.  It would also lead to undesired emergent properties (like 
Eric pointed out).

Perhaps instead of interpreting the specs "the listener's position" as 
the listener position and nothing but the position, it should be 
interpreted more broadly as "the listener's local coordinate system," 
which would be defined to include position, velocity, and orientation.

Obviously this should be clarified if we ever get to making a new spec!

--"J"