[Openal] suggestions on c++ game design with openAL most welcome
jdaly at ist.ucf.edu
Tue Jun 2 08:11:52 PDT 2009
Pingwah Leronz wrote:
> and Cars are to be able to emit several sounds at once , an ambient
> engine roar, horn beeps, drivers yelling etc.
> /Also there's to be literally _millions_ of cars /(OK, in the project
> itself , they're not cars :) ), so a method of culling sound emitters
> from the set needs to be there.
> Criteria for adding and removing Cars from the audio set is simply
> proximity to a viewing position, and the cars themselves are stored in
> something like
Wow. _/Millions/_ is a lot of cars (or whatever :-) ).
You're obviously not going to be able to mix and play that many sounds
in real time, so there will be some culling done. You've got the right
approach in either case, in that you're allocating buffers and
dynamically assigning them to sources. Either way would work, but the
second method is probably closer to the "better" way. I've referred to
this as "virtualized sources", because you effectively are representing
lots of logical sources and then assigning real sources to them dynamically.
Listener proximity is often an adequate metric for determining which
sounds should be auralized. In my case, each update cycle I actually
compute the effective gain (using the attenuation formula from the spec)
for each virtual source, and then sort them by effective gain. I also
throw in a user-defined "priority" metric (picked from LOW, NORMAL,
HIGH, and ALWAYS_ON). The sounds with ALWAYS_ON priority are guaranteed
sources, regardless of effective gain (obviously, you can't have too
many of these). First, each virtual source is checked to see if it is in
a playing state (it is removed from further processing if not). Next,
the sounds are sorted by priority, then by effective gain. Finally,
real sources are assigned to the sounds at the top of the list.
This method is probably a bit too expensive for you if you really have
to deal with millions of virtual sources. You might need to add in an
extra layer of cheap, coarse level processing to deal with culling out
most of the sources before you get to a method as fine-grained as this.
This might involve some kind of spatial subdivision, where you ignore
sounds that lie outside of some radius, or something like that.
You might also consider a form of clustering. This technique pre-mixes
sounds that lie some distance away, but are roughly in the same
direction. Say you have three sources to the northeast, two to the
west and five to the south. You could effectively auralize all of these
virtual sources using only three real sources. You simply pre-mix the
sound from the first three into one buffer, the next two into a second
buffer, and the last five into a third buffer, and then play those three
buffers on three real sources.
In your case, I'm thinking you might not get enough of a soundfield by
just picking, say, the sixteen closest sources. You might try
pre-mixing some number of sources that are moderately distant into a
single, non-directional "ambient" buffer. This might better represent
the soundfield you'd really hear in that kind of situation. An easy way
to make a non-directional buffer is to mix the sounds into a stereo
buffer, with the same data in both left and right channels.
That's all I can think of right now. Hope this helps!
> multimap <classCoord*, classCar*> mapCars;
> (again, they're not cars- let's say the track consists of
> many discrete positions, each of which can contain many cars).
> I've been experimenting with two methods of handling this - the first
> with a global controller:
> *Method 1*
> class classAudioController()
> int MAX_SOUNDS = 150;
> multimap <classCar*, ALuint> mapSounds; //where ALuint here
> is a ref to the standard openal source[MAX_SOURCES]
> void AddCar(classCar* newCar, ALuint* newAudioSource);
> bool AssignBufferToSource(ALuint *intSource, ALbyte* filename);
> void UpdateAllPositionsAndVelocities();
> void UpdateCarsPositionAndVelocity(classCar* findCar);
> and also by a more object oriented
> *Method 2*
> //position, fuel, health etc.
> classAudioSource *soundSource[MAX_SOURCES]; //remember, each car
> can emit many simultaneous sounds
> where classAudioSource is
> ALuint intSource
> bool AssignBufferToThis(ALbyte *filename);
> void UpdatePosition(float x, float y, float z);
> void Play();
> void Stop();
> void PitchMod(float fltMod);
> void GainMod(float fltMod);
> void SetLooping(bool boolLooping);
> With Method 1, Cars are added and removed from the emitters map on
> movement events, In method 2 classAudioSources are triggered to
> Play/Stop based on listener proximity , again on movement events.
> I'm running into problems with both, mainly from unfamiliarity.
> If anyone here has input into handling large sets of sound sources in
> a good OO-heavy way, or can point me to any reading that does I'd be
> massively grateful.
> Find car news, reviews and more Looking to change your car this year?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openal