Popular sound libraries

[spookyboo]

I want to add (optional) FMOD support to Particle Universe, so that synchronizing sounds and emission of particles becomes easier (and scriptable). I also look into other libraries (irrKlang), but I wonder what (besides FMOD) are the most used sound libraries? Anyone has an idea?

[jacmoe]

OpenAL, naturally.

There's a wrapper called cAudio, which looks really nice:
http://www.ogre3d.org/forums/viewtopic.php?f=1&t=55767

It's a FMOD-like library - I'd love to see some support for that.

[Wolfmanfx]

I recently switched from irrKlang to cAudio, the quality of the sourcecode from cAudio is really great.
I also vote for cAudio.

[Klaim]

cAudio is based on OpenAL, I think I'll try it to replace fmod on my game (to reduce dev costs...)

[KungFooMasta]

+1 for OpenAL. I've heard a lot of good things about cAudio, have to try it out.

[Jabberwocky]

In my opinion, this is going to be of limited use.

Almost always, a game will have a lot of code wrapping the sound library API, like some kind of SoundManager class. There's just no way you can anticipate what sort of SoundManager code an application using ParticleUniverse is going to use.

Perhaps the SoundManager needs to associate every 3D sound being played with a game object that is making the sound.
Perhaps the SoundManager needs to associate all playing sounds with a "category", so that when the game is paused, or the main menu is opened, we can pause all the sounds associated with the Scene.
Perhaps the SoundManager carefully tracks loaded sound samples, and the amount of memory used by sound samples.

Having ParticleUniverse interfacing directly with the sound library (FMOD, OpenAL, etc) will circumvent the game specific logic (SoundManager class) used to organize sounds, and this won't be usable in most practical situations.

I think a better approach would be to add an API to ParticleUniverse which provides the application with the information it would need to sync sounds with particles. Maybe like how Ogre3D allows you to register listener classes to receive events. Maybe there could be events like "emitter (de)activated" or "particle positions updated" or "observer triggered" or whatever. This API may end up being useful for lots of other things besides sounds. For example, if you had a periodic lava-eruption particle effect, this event API could be used to time the application of damage to characters near the lava-eruption.

I don't think ParticleUniverse should be making any calls to a sound library internally. Although it would always be nice to provide a sample integration of these ParticleUniverse events with a sound library.

This approach has the added bonus that you don't need to tie ParticleUniverse to any particular Sound Library or version of a Sound Library.

[spookyboo]

The idea is to add an abstract API in the plugin so it can also be scripted and used in the editor without a dependency with a specific sound library. A bridge class performs the communication with the sound library of your choice. I want to provide an example bridge for FMOD that can be used optionally, extended if needed and used as an example for other sound libraries.

To be able to define an API, which is abstract enough I have to look into the different sound libraries (unless someone can point me to an example of such an abstraction. I already took a peek at Yake).

There are already means in PU to acts on certain events and it is not difficult to add some event handler that takes care for playing sounds, but that must be all done programmatically. The idea is to use the event mechanism and implement event handler(s) that take care of that in a abstract way. I can hook them to the scripting system and add them to the editor.

[Jabberwocky]

Well, it's your project.

But the bridge concept doesn't change the fact that external middleware code (ParticleUniverse) would be communicating directly to another (external middleware) sound library, which in almost all cases is not what you want. In general, it's a bad idea for one piece of middleware to talk directly with a totally distinct type of middleware library. Instead, it should provide whatever API or "hooks" necessary for the application programmer to do this himself.

The existing PhysX bridge for ParticleUniverse suffers from this exact problem. In that code, the PhysX bridge directly manipulates NxActor::userData. Many projects which incorporate PhysX will be using NxActor::userData for it's own purposes (for example, to bind the NxActor to a game object). When ParticleUniverse changes NxActor::userData by itself, it is making (bad) assumptions about how the application will be interfacing with PhysX. So the ParticleUniverse-PhysX bridge code is unusable (without modification) in these projects.

Again, this is all a problem with ParticleUniverse trying to interface directly with another (totally distinct) middleware library, instead of just giving me an API that provides the data so I can handle the integration myself.

-----

This criticism aside, the core ParticleUniverse plugin and editor are fantastic middleware which I use in my game. I'm very appreciative. I just think you're taking the wrong direction here on this one aspect.

[Jabberwocky]

I thought I'd post some pseudo code of the ideal interface, from my perspective.

Lets say I'm making a military RTS game. My troop data might come from a database or XML.
For simplicity, lets say I'm using XML, like this:

Code: Select all

   <troop>
      <name>Space Mech</name>
      <combat_data>
         <damage>10</damage>
         <range>50</range>
      </combat_data>
      <movement_data>
         <move_speed>5</move_speed>
      </movement_data>
      <health_data>
         <max_health>100</max_health>
         <current_health>50</current_health>
         <armor>10</armor>
      </health_data>
      <explosion_data>
         <particle_script>pu_explosion</particle_script>
         <sound>space_marine_explosion.ogg</sound>
         <sound_volume>space_marine_explosion.ogg</sound_volume>
         <explosion_damage>10</explosion_damage>
         <explosion_damage_radius>20</explosion_damage_radius>
      </explosion_data>
   </troop>

So I've defined some "explosion_data" on my troop, which includes the particle script I should call, and the sound it should make, and the damage the explosion should do to anything within a specified range.

Now, I would use something like the following (simplified) code to handle troops exploding in my game:

Code: Select all

void Troop::explode()
{
   // Kick off the particles for the explosion.
   ParticleUniverse::ParticleSystem* pParticleSystem = ParticleUniverse::ParticleSystemManager::getSingleton().createParticleSystem( "whatever_name", getExplosionParticles(), getSceneManager() );

   getSceneNode()->attachObject( pParticleSystem );

   // This call will make us receive events about pParticleSystem.
   // The ParticleSystem will call handleParticleSystemEvent (see below) which will allow us to
   // sync sound and damage hooks to the particles.
   // This works just like Ogre3D listeners.
   pParticleSystem->addListener( this );
}

Now lets pretend that this is a "multi"-explosion, and there's 5 blasts that go off when this troop explodes.
Each time a blast goes off, this function would be called, because we registered as a listener above.

Code: Select all

void Troop::handleParticleSystemEvent( ParticleUniverse::ParticleSystem* i_pParticleSystem, ParticleUniverse::Event i_event )
{
   if ( i_event.type == EMITTER_ENABLED )
   {
      // A new explosion has began.

      // Hook up a sound using my game's specific SoundManager interface
      SoundManager::getSingleton().playSound( getExplosionSound(), getExplosionVolume(), i_event.getEmitter()->getPosition() );

      // Apply some damage to anyone in the area of the blast
      DamageSystem::getSingleton().applyExplosionDamage( getExplosionDamage(), getExplosionRadius(), i_event.getEmitter()->getPosition() );
   }
}

Now, ParticleUniverse has given me all the data I need to attach sounds (or other things) to particle events.
Advantages:

• I can use any sound library, or sound library version I want.
• I can use my game's SoundManager class for particle sounds, which manages all sounds in my game.
• ParticleUniverse isn't making any direct calls to the sound library, circumventing my SoundManager class.
• I don't need to recompile or alter any ParticleUniverse code, which could otherwise become a maintenance issue as future versions of ParticleUniverse are released.
• I can use these hooks for other things besides just sound, like hooking up damage
• ParticleUniverse code (core plugin or "bridges") isn't bound in any way to any specific sound library or version.
• The event API will remain the same, even as new sound library versions are released.
• e.g. FMOD 3.75 -> FMOD Ex was a total rewrite, and completely changed the interface. Do you really want to be in charge of keeping all these sound bridge classes up to date? It's also a version nightmare: What if a project wants the latest release of ParticleUniverse, but is using the old FMOD 3.75, and you've updated the bridge to FMOD Ex? (I'm sure you've already seen this problem just with Ogre, where someone wants PU 1.2 features, but is using Ogre 1.6)
• It's way less code work in the plugin, and more useful to the application programmer.
• You won't run into any issues with licensing. For example, you may not be able to use the free FMOD license in ParticleUniverse, then charge money for ParticleUniverse.

------------

Now maybe you'd like the ParticleUniverse editor to support adding sounds to particles. No problem - you could implement any sound library you like in the editor, since that code doesn't go into my game. Inside the editor, you could have a section in the particle_system script where you attach a sound to an event (maybe an observer or something). You could even export this data into the particle_script if you want.

But don't have the ParticleUniverse plugin code do anything at all with this data. Provide an event API, and leave it up to the application to play sounds by responding to ParticleSystem events.

------------

So anyway, that's ideally how I'd like it to work. If I've failed to convince you, no worries, I just thought I'd give it a try.

[spookyboo]

If there is a strong need to have a ParticleSystem listener, I can add it of course (there is already a ParticleSystemListener, but is it very basic).
Consider it a feature for the next release

[spookyboo]

I already started. This is the list of events that covers the most important situations. Is this sufficient?

Code: Select all

PU_EVT_TEMPLATE_PARSING,	// Submit event when a particle system template script is being parsed.
PU_EVT_TEMPLATE_PARSED,		// Submit event when a particle system template script is parsed.
PU_EVT_SYSTEM_ATTACHING,		// Submit event when the particle system is being attached or detached.
PU_EVT_SYSTEM_ATTACHED,		// Submit event when the particle system is attached or detached.
PU_EVT_SYSTEM_PREPARING,		// Submit event when the particle system is preparing.
PU_EVT_SYSTEM_PREPARED,		// Submit event when the particle system is prepared.
PU_EVT_SYSTEM_STARTING,		// Submit event when the particle system is starting.
PU_EVT_SYSTEM_STARTED,		// Submit event when the particle system is started.
PU_EVT_SYSTEM_STOPPING,		// Submit event when the particle system is stopping.
PU_EVT_SYSTEM_STOPPED,		// Submit event when the particle system is stopped.
PU_EVT_SYSTEM_PAUSING,		// Submit event when the particle system is pausing.
PU_EVT_SYSTEM_PAUSED,		// Submit event when the particle system is paused.
PU_EVT_SYSTEM_RESUMING,		// Submit event when the particle system is resuming (after a pause).
PU_EVT_SYSTEM_RESUMED,		// Submit event when the particle system is resumed (after a pause).
PU_EVT_LOD_TRANSITION,		// Submit event when the particle system switches to another technique when a LOD-level is exceeded.
PU_EVT_EMITTER_STARTED,		// Submit event when an emitter is started.
PU_EVT_EMITTER_STOPPED,		// Submit event when an emitter is stopped.
PU_EVT_NO_PARTICLES_LEFT,		// Submit event when all particles have been expired.

[Jabberwocky]

Awesome!

In a ParticleSystem with multiple emitters, is there any way you could identify which emitter has triggered the PU_EVT_EMITTER_STARTED or PU_EVT_EMITTER_STOPPED event? Maybe the emitter name could be passed along, or else a pointer to the ParticleEmitter itself? Whichever works. If it makes designing some kind of ParticleEvent class easier, it wouldn't bother me to have to do some pointer casting based on the type of EVT to get at this data.

[spookyboo]

Besides a pointer to the particle system, I also pass an event object, that contains some additional information. Currently this contains the event type, the type of component that triggered the event (emitter, ...), the component name and a pointer to that component. I still thinking about the casting stuff. Maybe I just pass the emitter pointer and set it to 0 if the component type is not of type ´emitter´.

[Jabberwocky]

That sounds perfect.
The extra memory for having one extra pointer around in the event class isn't a big deal at all. It's not like anybody is going to store a giant array of them.