RE: suggestions on c++ game design with openAL most welcome

Clustering seems a damn good idea!
A question though - would the process of mixing many sources into one be pretty much as operation intensive as just playing the sources themselves?  Maybe not, given that I'll only have to mix them each time an object moves.  I'll have to experiment with this.

thanks,
Pingwah

---

Date: Tue, 2 Jun 2009 11:11:52 -0400
From: jdaly@...
To: pingwah_leronz@...
CC: openal@...
Subject: Re: [Openal] suggestions on c++ game design with openAL most welcome

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!

--"J"

 
 
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]
 
     //functions
     void AddCar(classCar* newCar, ALuint* newAudioSource);
     bool AssignBufferToSource(ALuint *intSource, ALbyte* filename);
     void UpdateAllPositionsAndVelocities();
     void UpdateCarsPositionAndVelocity(classCar* findCar);
     etc.
 
 
};
 
 
and also by a more object oriented
 
Method 2
----------------------------------
classCar
{
   //position, fuel, health etc.
   //....
   classAudioSource *soundSource[MAX_SOURCES];   //remember, each car can emit many simultaneous sounds
 
 
}
 
where classAudioSource is
{
   ALuint intSource
 
   //funcs
   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);
   
   etc.
 
}
 
 
 
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.
 
Thanks,
Pingwah
 
 
 
 
 

---

Find car news, reviews and more Looking to change your car this year?

---

Find your next place with Ninemsn property Looking for a place to rent, share or buy this winter?
_______________________________________________
Openal mailing list
Openal@...
http://opensource.creative.com/mailman/listinfo/openal