pclare@xxxxxxxxxxxxxxxxxxxxx wrote:
Alexandre Mah <Alexandre@xxxxxxxxxxxxxx> wrote on 18/03/2005 22:50:17:
If HRTF did make it into the core (which would probably be a nice thing
at some point), I imagine it would work in a way similar to textures in
OpenGL. The programmer would provide and load the HRTF data into
OpenAL and determine how it would be mapped to OpenAL's 3D space (just
like an OpenGL programmer provides the textures to OpenGL and
determines how it gets mapped to a polygon).
<snip>
What you describe is fine for a *very* low level API that sits just above
the hardware. Whilst OpenAL can be classed as low level, I don't think
that it is intended to be *that* low level. If OpenAL is to be of use to
put 3D audio support into a game then I think you need a more abstract
interface than simply loading filter coefficients. I just don't think that
the majority of game audio programmers want to go that low.
I agree in that you don't want to put unnecessary low-level code in. To
me the threshold would be any low-level code that breaks the ability of
the AL for cross-platform development. Anything above that level can be
debatable, but yes, generally speaking we should keep the lines of code
required to do a certain task to a minimum.
The AL could still support presets while at the same time exposing model
parameters through an alGet/alSet mechanism for the brave of heart.
That would keep the *required* code to a minimum, but at the same time
making the model tweakers happy.
We currently have a sensible abstraction (i.e. specifying cartesian
coordinates) in OpenAL. It should then be up to different renderer
algorithms to do the best job they can from this information. All I am
saying wrt distance units is that if the renderer has that information too
then it can do a better job than if it doesn't.
Also, if we did have such a low level HRTF coefficient type API in OpenAL
then it starts to force every implementor to implement 3D audio rendering
in exactly the same way, using the same type and length of filters, etc.
etc. This is not a good thing and will stifle innovation.
It would be best to leave HRTF as an extension, the vendor can expose
whatever interface they desire to the AL including the developer to
specify what units they are using. There are no restrictions this way
from the vendor's point of view.
The discussion has been on what to do with distance since historically
the AL has ignored them. There have been several good examples on
features that would require such a definition. The prudent thing to do
would be to add distance into AL when there is a feature that requires
it, otherwise there's no point obviously.
In regards to the 1.1 spec the only feature I see that has a distance
requirement is the Doppler equation, but this would break backwards
compatibility with 1.0, which is why I am concerned. There also seems
to reason for it to be there, the 1.0 way works well with the rest of
the AL, being unit-neutral.
=====================================================================
Peter Clare |
Sensaura | Telephone: +44 1784 476755
Meadlake Place | Facsimile: +44 1784 476770
Thorpe Lea Road, Egham | Email: pclare@xxxxxxxxxxxxxxxxxxxxx
Surrey TW20 8HE | WWW: http://www.sensaura.com/
UNITED KINGDOM | http://www.gamecoda.com/
=====================================================================
_______________________________________________
openal-devel mailing list
openal-devel@xxxxxxxxxxxxxxxxxxxxxxx
http://opensource.creative.com/mailman/listinfo/openal-devel
--
James Tomaschke
Snr. Software Engineer
InfoSemiconductor, Inc.
|
| 
