in terms of performance, is using the node PlayEventAttached the preferred method to create multiple 3D Instances of sounds that need to overlap? Like for example firing multiple shots of an handgun.
By following the FMOD guide I had assumed that attaching an FMOD Component, with an event assigned, and using the Play node, would automatically create multiple instances of the sound, but it does not. Which leads to a few more questions:
Does every instance of an event needs its own FMODComponent?
Is there a way to create instances of an event from an FMODComponent attached to an actor?
If not using BP, might using code a better option?
I guess my main question is, what is the best practice to play a 3D event with some parameters that need to be changed in real time so that the sounds overlap? Think of a pistol with multiple firing modes.
Indeed, it seems to be impossible to stack several instances of an event contained in an FMOD Component, whereas in Unity (from what I understood), stacking instances is the default behavior when the event is detected as “oneshot”. That’s a bit weird.
As you said, you can spawn FMOD Components at runtime with the “Play Event Attached” node, but I don’t really see the benefit compared to “Play Event At Location”, except if you need component specific functions (like callbacks). Otherwise, I think “Play Event At Location” should be fine for almost every cases.
Here’s an example of how you could setup a repeating shot weapon, with a firing mode change in the middle of it. The “Select” node is optional, but it can be handy for setting an enum with firing modes in plain letters (instead of my “FiringMode” integer variable) .
In my experience it is preferred to use Play Event At Location for 3D Events that are fired once and forgotten about. Internally this will tell FMOD To create an Instance of the desired Event which will be removed once it has played.
Play Event Attached will internally create a FMODAudioComponent component and set it to play the Event assigned. Using the Play function in the FMODAudioComponent will just play the same EventInstance over and over again. The FMODAudioComponent is only holding a single EventInstance which corresponds to the EventDescription that is provided by the UFMODEvent Asset.
So I would say use Play Event At Location which will create multiple events that overlap anyway since there will be multiple Events for short lived sounds like Gunshots, Explosions etc. And Play Event Attached and FMODAudioComponents for sounds you expect to hang around for the entire lifetime of an Actor, think Engines of a car, music coming from speakers in the world. All of this can simply be done in BP but I recommend a short read through the FMODStudio Plugin code since it contains a lot of answers for questions like these.
Hello @Alcibiade and @Jok, thanks for the input and for taking the time to explain your process and showing some examples.
It seems really odd to me that there is no way to pool instances, creating and destroying them at run time, doesn’t seem efficient for something like footsteps, player character sounds and etc. Usually when working natively in a game engine, you want to instantiate objects at run time as little as possible, but if this is by design in FMOD, then the component must be really optimized to not create any performance issue.
I wonder if someone from the FMOD team will pitch in. The guides are so bare bone!
From what I’ve read in many posts from FMOD staff, create and destroy a new instance at each sound is one of the most common way of playing oneshot sounds in FMOD.
However, if you prefer you could manually program (even with blueprints) a pool of instances, check their playing state and reuse them. That’s what the dev of one of my projects does, with FMOD API, in another game engine.
Setting the frequent sound events persistent and recycling them seems to be a more effective solution, but only if there is a performance gain, otherwise why bother.
Thanks for the feedback, it would be nice to have this in the FMOD guide as best practice, I was totally fooled into thinking that the pooling of the events was managed by the FMODAudioComponent, like with the 2D events. One would thing that the engine implementation would provide something basic like this
Are you really sure 2D events behaves differently in that way than 3D events?
Like you, I don’t really get the purpose of FMODAudioComponent, except for callbacks, which by the way I don’t understand why they are not accessible elsewhere than in the component, as I pointed out in another post.
Anyway, I think I understand better now. You need to attach an FMODAudioComponent to and Actor, and then use the PlayEvent attached to pass the event you want to use, and also manage instances, like creating them, releasing them from memory and etc. Since this is such a common usage in game audio, it should really be in the guide as an example of best practice.
Maybe I’ll do some testing and make a post to help others too. I know FMOD studio from the inside out, I have been using it since version 1.0, but I don’t have a lot of experience on the engine side of things because fortunately (and unfortunately), the projects I have been working on so far were big enough to have a dedicated audio programmer that took care of code and blueprints.
Still think FMOD people should pitch in with a definite answer
There really isn’t a difference in how 2D and 3D events are played other than the spatialization involved. When using “Play Event Attached” the only difference is that the location of the event emitter matches the location of the object it’s attached to. It does not affect overlapping sounds or do any kind of “pooling”.
I’ve raised a task for the documentation to be updated with some more examples on how to use FMODAudioComponent for a future release, but everything already mentioned within this thread is correct.
