the one issue I have when working with Niagara System is just the overwhelming amount of information that gets dumped onto user, making it very hard to navigate the systems as the complexity grows, and also creating huge room for error when working on both System and Emitter at the same time, as it’s often very easy to make changes on the wrong one (for example on System level instead of Emitter level) when shuffling around the open tabs.
I think Niagara is missing some optional abstraction, where instead of dumping every single module and its property onto the user in Niagara System view, we should be able to expose only specified input parameters like we can with Blueprint Variables.
An example would be creating a simple “Smoke Puff” Emitter to be used across multiple Systems. The only things artist should be interested in changing on this emitter are: Puff Size, Initial Velocity, Direction, Amount of Particles. So I’d like to be able to drop down abstract version of the Emitter which when clicked does not overwhelm me with every single module of the emitter with its parameters, offloading the frustrating task of digging through everything to find the right parameters, and gives me just the parameters I need.
Sure the ability to override absolutely everything is nice to have, but defaulting to that just makes using Niagara unnecessarily complicated and overwhelming IMHO.
While Niagara seems to be built with modularity in mind, I realized I still ended up creating completely unique Emitter for pretty much every single unique effect, simply because the UI/UX design of Niagara currently does not encourage modularity in any way. Compare that to Material system with Material instances, where user can easily, explicitly specify which aspects of the material are supposed to be instance parameters. If Material Instances UI simply dumped every single value found anywhere in the material onto the user, Material Instances surely would be much harder and more frustrating to work with.
It’s just that currently Niagara is presented, from the UI point in such a way that it not only doesn’t lead and encourage the user to utilize the modular aspect of relation between Emitters and System, but it actually obscures it in the fog overwhelming amount of information.