I currently have a Niagara system that spawns and ejects one bullet casing and plays a sound cue when doing it. I’m concerned about garbage collection. I guess poling is the answer and I understand Niagara has a pooling function already build in I have two questions. 1) Is pooling turned on by default? 2) The effect is triggered by an animation notify, by doing it this way am I spawning a new particle system each time or the system spawning the mesh that each it is called?
Hello there @Nitrox32!
Checking with my peers, and around the UE community, the answer to your first inquiry would be no, pooling is not enabled by default. When spawning your system, the Pooling Method is set to None, you need to choose between Auto Release and Manual Release.
With Auto Release, the component is taken from the Niagara pool, and when the system completes, is returned to said pool. This requires no manual cleanup, and it’s the best approach for quick effects that you need to re-use a lot (like your casing ejects).
On the other hand, Manual Release takes the component from the pool, and it will remain alive until manually released, it won’t auto-return. This is useful for when you need more control over the lifetime of your effects, or using them in different states.
For your scenario’s description, Auto Release is probably the best option. Another factor to consider, is how you set the pool size inside the emitter. Please make sure you have the proper amount loaded for your scene.
Now, for your second inquiry, the Anim Notify will trigger a system spawn, take one from the pool, and use it. When the next trigger happens, it will generate another system, according to your pool capacity, and eventually it will start re-using them. If you were to set a very short pool, the casings would be “teleported” and re-used, dissapearing mid air. As long as you adjust the pool values accordingly, you should be able to repeat the effect multiple times, with minimal impact in performance.
For further reading on this subject, please check the related community’s resources below:
Thanks for the detailed response. It was very helpful. It turns out I have everything set up correctly for my use case. The only difference is now I understand why. My project is still in the early stages, but I’d rather get ahead of any garbage collection problems before they get out of hand.
I’d do your pool manually and use actual meshes.
The benefits are endless. And you don’t have to deal with Niagara at all which is a blessing in itself.
Also the Notify will misfire. Constantly. If your game thread gets clobbered like it usually does for the engine during gameplay due to loading and whatever else.
Best approach is to design a weapon class where you have a function that triggers based on time after trigger pool.
Input call > delay node > function for eject.
This usually works well enough. Make the delay node a variable and when you generate new weapons from this base class you get to just set their value custom.
Then - don’t just spawn meshes. Keep count of how many are spawned and where they are.
You do this by spawning instances in a HISMC which can be linked to the weapon base class.
You manually manage removal of the oldest for the engine using basic MALLOC patterns for garbage collection. First in first out. Super basic.
The HISMC can keep the index and transform values in check.
Should you need complex simulation, consider spawning a regular mesh, having it stop simulating on a general (weapon linked) timer. At that point you convert from whatever (likely a skeletal mesh as you must be doing something complex to need this) to a mesh instance that’s locked in place at the final transform.
That’s all there is to it. I MIGHT make my custom system release in the marketplace. But honestly. If I never have to deal with the edjits that manage the now Fab stuff it’ll be too soon!