Alexandre Mah wrote:
On 14/03/2005, at 3:00 AM, pclare@xxxxxxxxxxxxxxxxxxxxx wrote:
When rendering 3D audio, absolute distance measurements (where we
need to
know the units) are needed for at least the following:
1) Doppler (assuming we want to express this as a velocity rather
than just
the pitch shift multiplier which, deep down in the audio rendering,
is all
we actually end up with).
2) Near field effects (e.g. Sensaura's MacroFX). Since this relates to
actual human head sizes we have to know the units.
3) Air absorption. This could be expressed unit-free -- but then it
makes
it difficult to have standard reverb presets (assuming air absorption is
part of the preset).
4) Multi-speaker HRTF processing. Arguable whether this is
necessary, but
at Sensaura we chose to use absolute distance information in the
implementation of our MultiDrive algorithm.
I agree with 2 and 4. But I think 1 and 3 should remain unit-free.
It would be nice in the future for stuff like air absorption to make
it into the core (and the air absorption parameter would then be
expressed in whatever units you are using in your OpenAL world,
whether it be decibels per metre, decibels per foot, or decibels per
kilometre).
What do you think about this idea?
Define
alPreset(ALenum preset, ALfloat distance_factor);
where
ALenum preset specifies what useful set of presets for physical
constants to use.
ALfloat distance_factor is for associating OpenAL units to absolute
units.
Any extension could implement a new preset just by defining a new
token for "ALenum preset", and there could also be a set of "global"
tokens that would affect all extensions.
I like the idea of setting an AL state through a simple function call.
The AL state can be in 1.0 compatibility mode and the setting of a
distance unit could send the AL into a mode that handles some of the
features discussed.
OpenGL provides different rendering modes in a similar way.
glLightModel/glShadeModel specifies alternate code paths for the
internal engine on how it shades geometry.
For example, calling
// global preset for using the metric system for absotute distances
alPreset(AL_METRIC_EARTH, 1.0);
could set
1. AL_VELOCITY_SCALE (from core OpenAL 1.1, or whatever parameter ends
up being in core OpenAL 1.1) to 1/343.3
2. AL_EAX_METER_SIZE_CREATIVE (from the EAX extension) to 1.0
3. AL_MACROFX_METER_SIZE_SENSAURA (from the MacroFX extension) to 1.0
4. and any parameters from any other extension that need to be set
(like AL_AIR_ABSORPTION_COEFFICIENT).
You can of course still adjust AL_VELOCITY_SCALE,
AL_EAX_METER_SIZE_CREATIVE, and AL_MACROFX_METER_SIZE_SENSAURA
independently afterward if so desired.
I think the names could use rework, but the idea is there. Perhaps the
acoustic models can handle underwater as well as in air? Any name that
assumes a unit should have the unit in the name like you did with
AL_EAX_METER_SIZE_CREATIVE, so I would add that to AL_VELOCITY_SCALE.
If units are to be added, section 3.3 in the 1.1 draft spec needs a
complete rewrite.
I would like to suggest that AL's acoustic models not be sea-level/Earth
based. Perhaps the current equations used, assume certain physical
conditions to keep the model simple. But there are other exotics that
might interest the developer such as under water, and the AL shouldn't
lock them down. It would be proper to expose the acoustic model
parameters to the user through alGet/alSet* functions.
--
James Tomaschke
Snr. Software Engineer
InfoSemiconductor, Inc.
|
| 
