Create and configure new Niagara Emitters from C++

Question

I’m trying to create a magic system that lets the player add spells and modifiers to a spell stack and combine them following a set of rules, creating new spells in the process (that maybe can be combined even further)

To do that with Niagara I need to be able to create new emitters from C++ using the merged settings of both emitters, then load the new emitter into a UNiagaraSystem. I’m guessing that I have to follow this path since I want to be able to merge multiple effects together and not just chain them (maybe one spell has a vortex modifier and the other burst meshes in an area, so the child could burst them in an area and the direction is altered by the parent vortex)

The compilation times for the UNiagaraSystem are fast enough to compile them on runtime (at least in my machine with test systems) so it doesn’t worry me a lot, and I see functions to ask the system to recompile from C++.

My main concern is being able to deduct the current properties and create a new UNiagaraScript to populate the different FNiagaraEmitterScriptProperties so I can create a new emitter into the new derived system (I’m guessing).

Is this even possible with current versions? The editor does it (although with scratchpad…), do I have to fondle with UnrealEditor code? Maybe using an empty system and adding lots of simulation stages? Are the provided modules even accessible from code?

As I am unable to find ANY working example creating emitters from c++, can you please post an example if you now how to?

I’m working with UE5 early access 2

Thanks a lot in advance to everyone!

Answer 1

It's probably possible; but not straightforward. You'd need to trace through what the editor does when you modify a Niagara script. Somewhere in there, it's parsing the script, turning it into HLSL, and shoving it into the render graph pipeline (assuming you're using GPU sims); but replicating that would require engine modifications to that entire path.

But... it seems like you could accomplish the same thing with User Parameters on your Niagara system. You can include emitters for all the various permutations of the effect, and enable/disable them at runtime.

That's the approach I'd take, anyway...

Answer 2

Don't force users to compile new systems at runtime - you don't have access to the shader compiler in a cooked build and adding that much overhead is unnecessary.

Either expose user variables that will get tweaked by gameplay interactions. If that does not give you enough control you can always write your own data interface that can be fed with data from the game thread and set the particle attributes directly.