Re: Distance units

> > There seems to be a misconception here that different rendering algorithms
> > would somehow want to use different distance units.  I can't think of any
> > reason why that should be necessary.  All I am arguing for is that distance
> > units are in the core API and available to every renderer implementation
> > and every extension.  I can think of no good reason why any one extension
> > would want to deal with different distance units from either the core API
> > or other extensions.  So the whole notion of "OpenAL units" or "EAX units"
> > (as mentioned in a previous post) just doesn't make sense to me.
>  If you have a copy of the AL 1.1 spec read section 3.3, that explains the lack 
> of units in the
> AL.
>
> The argument Alexandre is making is that you can still keep true to the AL 
> unit-neutral idea and
> still be able to support EAX throguh a value you can set that scales the 
> user-defined AL units
> into meters for use with EAX.
This doesn't just have to be about EAX though. In fact the Sensaura problem 
example isn't, they're
different companies (or were...) Distance parameters such as the size of the 
head being modelled can
impact not just some optional extension, but core rendering.

I still disagree with that being done through magic numbers though. My earlier 
example of the
elephant head was perhaps unrealistic, but I think the point still stands that 
the implementation
shouldn't be tied to any units. After all the basic implementations do no such 
advanced modelling.
The DS3D implementation strikes me as interesting; if the basic audio rendering 
of that API cannot
operate without a defined distance unit, then how can it be wrapped by OpenAL 
which certainly up to
this point doesn't require one and provides no way for the programmer to 
specify one?

Andrew