Hi, I will soon start working on a modular impact effect in Niagara (UE 5).
It will consist in several emitters that can be activated through Blueprint with booleans to match the weapon/skill characteristics (could be a slash attack with fire elements or a piercing exploding impact) all the different emitters will be there at the same time but inactive unless called in the script.
The question is : will the large number of emitters in this system affect the final result and the performance? Or is it only about the number of particles emitted and complexity of textures?
In case you were wondering why I’m not using many different systems, it is because of the high number of combinations of type, element, size and other variables. And the lead told me to investigate the possibility of making a dynamic effect that can cover all the possible combinations.
Thank you for your help!
My suggestion to you would be to look into profiling this yourself with Unreal’s Niagara profiling tools. Otherwise if your looking for a theoretical answer you would probably have to check with engineers that are familiar with how Niagara works.
That said, my guess is this would work but it might depend on exactly how many emitters and how you turn them on/off.
1 Like
Profiling aside, you should make good use of Niagara User Parameter to adjust the Niagara System behavior (e.g. particle/shape location scale, color, lifetime, etc.) and tell your programmer to modify the User Parameters instead of switching between multiple extremely similar emitters/systems. This way you can have fewer emitters/systems which will definitely relief you from data management.
AFAIC, the more emitters in one system, the slower the editor gets, although it also depends on the complexity of each emitter which you can tell how much it hurts by enabling the “Performance” tab in Niagara editor or use a separate Niagara Debugger.
P.S. I am a bit interested to learn how your programmer toggles emitter in a Niagara System from BP.
2 Likes
Thanks for your answers! The project is still very much into a pre-production phase and we’re deciding how to handle things.
For the activation / deactivation of the emitters I was thinking of making a system through Blueprint that can read tags from the target weapon (each weapon will have tags with the type of damage it deals), look for the equivalent tag name in the list of the bools available in the list of exposed parameters of the Niagara System (the spawn rate in each emitter will be dependent on a bool with the same name as the tags and set to 0 if false) and set those to True. Then every time that Niagara System is called from that weapon it will have those booleans true and all the others false.
To make it a bit clearer, the system will have for example 30 emitters, all with a spawn rate connected to a different boolean, and all set to false in the beginning, so no particles will be emitted. When the system is connected to a weapon, the Blueprint will look for the weapons tags. Let’s say the weapon has “electric” and “piercing” as tags. The BP will look for the bools named “electric” and “piercing” and set it to true. Then set all others to false. Now the emitters tied to those booleans will be emitting particles.
Ideally it will remember that setup until changes are made to the weapon (new projectile or weapon mods)
That’s mostly to allow the other developers to produce weapons and mods without having to build a special Blueprint for each of them, but just add tags with the damage type.
Of course I will try to avoid making very similar emitters, and instead change parameters like colors,sizes or textures based on the tags chosen.
As I said, we’re still very much discussing how to approach this, and for now it’s all an idea in my head, but if you have suggestions on a better approach, I’m all ears.
Thanks again 
1 Like
Thank for sharing your development details. I too use zero spawn rate to “switch off” an emitter, but not to the extreme of juggling with ~30 emitters in one single system.
The problem is that an emitter without emission isn’t completely “free” per se, for example the Emitter State module is still using up some CPU. Individually they are pretty harmless, but I suspect that could add up. Your weapon arsenal could keep expanding and requires more weapon effect emitters to fit inside your Niagara System. Personally my issue with having too many emitters in one single system is that it significantly slows down the Niagara editor which hurts my work efficiency and psychology.
AFAIC Niagara System isn’t built around to be an “effects manager”. Unless you are absolutely sure most (if not all) of the emitters will emit something within a short period of runtime, I wouldn’t endorse such approach.
2 Likes
I understand what you mean, and yeah a slow editor isn’t fun at all. I guess another option would be having different Niagara systems with very few emitters and each tag on the weapon would call a specific Niagara system or two. There would be a section where the BP branches out to all available systems to select the right ones for the tags on the weapon equipped, then change the parameters in the chosen systems. I guess as long as I keep the same variable names in all systems they should work together just fine. I think they did something of the sort for Borderlands 3 sounds where everything was modular allowing them to get randomly generated weapons with appropriate sounds. The Weapon Audio of Borderlands 3 - YouTube
That’s what I’m hoping to achieve with the vfx
1 Like
I tried building a system like this where ints would toggle the spawnrate of 25 or so emitters a while back. It’s hell. The performance will suffer if you have a bunch of these. If it’s just a couple, it’ll be fine.
However, working with it gets near impossible, real quick. The slowness already mentioned. Having to untick the autocompile to even be able to work with it is a good indicator that there is trouble ahead 
If this is to be more than a one off, get code to build you a system for handling this.
2 Likes
Considering the fact that I often also work from home and I get a bit of lag when I’m testing in the game environment, now and then, that would be nearly impossible. Btw thinking about reusing the same emitter for different kinds of effects. Does anyone know if it’s possible to change the sprite material for the particles in runtime? I’m assuming it isn’t because different materials might have different instructions and might cause errors. I’m right now writing some documents about my research on the matter and deciding the best course of action, so I don’t want to leave any stone unturned.
Thanks for the help everyone.
I don’t think it’s possible to change material in Niagara renderers during runtime. It is possible to have multiple renderers in the same emitter, change the visibility index and visibility binding attribute (int32) to switch between renderer (index 0 for renderer 0; index 1 for renderer 1, etc.), this should technically give you what you want. The only limitation is that Ribbon Renderer doesn’t support visibility index (yet).
2 Likes