[Openal-devel] Extension proposal

[Chris Robinson]

On Tuesday 16 September 2008 06:13:41 am you wrote:
> Hi Chris,
>
> Based on our experience working with a variety of game engines (including
> Doom3) ... we've found a common solution is to set the AL Distance Model to
> AL_NONE and use alSourcef AL_GAIN to control attenuation over distance on a
> per Source basis.   This is completely flexible, and allows the game engine
> to use as many different types of roll-off curve as they like and allows
> them to be different per-Source (something which I think most developers
> would say is critical).

Hi Daniel.

That's what I ended up doing, actually. But to be honest, it doesn't feel like 
a proper solution. Since the distance attenuation has to work on the 
positions of the given source and listener, it means it has to be updated 
seperately from setting the source or listener positions. It ends up having 
to be another pass over the potentially active sources to calculate and set 
the new gains (after having already updated their 3d positions and velocities 
and other stuff), and having to track both the distance gain and normal 
source gain if you wanted to use both at the same time..  whereas ideally 
OpenAL would handle it automagically, like with the existing distance models.

Extending the distance model to have them per source was the next thing I was 
going to propose, if I needed it. For the software mixer it'd be easy enough 
(read ALSource->DistanceModel instead of ALContext->DistanceModel). Existing 
functions and tokens can handle the functionality.. you just need to define 
what an app needs to do and how it works.

For example, you could call:
alSourcei(sourceID, AL_DISTANCE_MODEL, AL_NONE);

to make that specific source use no attenuation, while all the others use the 
last specified. Calling alDistanceModel could change all allocated sources 
(and set what newly allocated sources will default to). So that way you keep 
the old behavior for programs that aren't aware of it, and have the new 
functionality. Plus, it'd work seemlessly with the attenuation table mode.

> An extension like this, IMHO, would be too restrictive.  At a minimum, I
> would recommend allowing each Source to have it's own attenuation table,
> and you would probably want to specify an interpolation method between
> attenuation levels to create a smooth, glitch free, output.

Allowing each source to have its own attenuation table was something I thought 
of, and left open for future possibilities. Instead of just 
AL_ATTENUATION_TABLE, you would have a series of them:
AL_ATTENUATION_TABLE0 (aliased from AL_ATTENUATION_TABLE)
AL_ATTENUATION_TABLE1
AL_ATTENUATION_TABLE2
AL_ATTENUATION_TABLEn
.. etc, hopefully keeping it true that:
AL_ATTENUATION_TABLE0+i = AL_ATTENUATION_TABLEi

And add an associated alGetInteger to get the number of supported tables (if 
you don't just want to have a flat number of them). I even added the <target> 
parameter to alAttenuationTable to account for this type of future ability. I 
suppose it could be added to this extension if it's that interesting, instead 
of waiting for a future extension.

And, still, this would work seemlessly with the aforementioned per-source 
distance models. Just set the source to whichever table you wanted it to use, 
assuming it's defined. Each table would keep a count of how many sources are 
using it, and not allow itself to be deleted if it's above 0.

For interpolation, I suppose it'd be a good time to bring in the alHint stuff 
that's been requested before. Can set a table to use AL_NICEST to have 
quality interpolation between the entries (preferably at least linear), eg:
alHint(AL_ATTENUATION_TABLE0+i, AL_NICEST);
and AL_FASTEST for nearest/fastest interpolation (and AL_DONT_CARE for 
whichever).