[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