Besides the fact that the documentation is pretty strange (you never talk about user parameters, but show them through screenshots for instance) which made the initial use a bit weird… I finally succeeded to play sounds based on particle spawns and position.
But I’m immediately having a limitation: besides having some one shots or a loop based on the root of the system… it’s pretty pointless to use the particle position at the moment. For a simple reason: unless I’m missing something, there is no way to start a looping sound at the spawn of a particle with a persistent FMOD event and stop it on particle death.
Is there something planned for that or am I missing the big picture here and not thinking properly how I should handle the sound through Niagara system?
As an example, use cases:
A system shooting darts, darts having a flyby when moving close to the listener and a one shot on death/collision
A system firing balls in a straight line with a flyby
I found a workaround thanks to my fellow colleague specialized in VFXs.
We experimented with a specific parameter driving the playback of the loop.
With two “Update Persistent FMOD Player”, the first one updates the location, the second one updates a “Progress” parameter based on “NormalizedAge” from the particle domain.
The loop exits when the parameter reaches 1 and then finishes it’s playback.
This works nicely. But I’m pretty sure having a flag “stop on particle’s death” inside the base “Update Persistent FMOD Player” could be helpful.
That said, maybe due to performances, you’re not storing the instances, and you have no efficient way of knowing which event instance is linked to which particle… which would make a “stop” flag impossible I guess?
Now, I’m just wondering what is the cost of having that kind of setup inside Niagara? I suppose it’s not more than a standard burst of projectiles with a bunch of FMOD events tied to the projectiles?
