[Openal-devel] Extension proposal

Martijn Buijs buijs512 at planet.nl
Wed Sep 17 16:03:02 PDT 2008


Chris Robinson wrote:
> 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.

I agree with Chris.

I did customized attenuation the same way Daniel described, but it doesn't really make sense because 
the API already provides distance attenuation functionality. I would have agreed with Daniel if 
OpenAL did not do attenuation at all, but it does.

I was planning to propose a distance model that would guarantee gain falloff to zero at MAX_DISTANCE:

http://home.planet.nl/~buijs512/_temp/openal_distance_falloff.png

But it seem the 'table' distance model extension covers this, and is more flexible to boot. So I'm 
in favor of it.

> 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).

I like that, fits naturally into the API!


Cheers,
Martijn


More information about the Openal-devel mailing list