FX spawning practices

[MGDubois]

@imbueFX

I’d be careful with this. Cascade is horribly inefficient on the CPU, so running a particle system active without spawning any particles is bad for perf. Maybe not a dealbreaker if you’re having fun at home, but it would add up quickly in a production environment.

Do you have any idea if Niagara systems are the same? Because I’m currently running a few systems in this way. I try to keep this practice to a minimum though.
Also I’m not entirely sure what the perf is.

@imbueFX

If you have a reference to any asset in a blueprint, it gets loaded alongside the blueprint. Only soft references need to do an async load, which is good for memory but can cause hitches.

To be honest I’m not 100% sure what you mean here. What is a soft reference and what is async loading? And is there any documentation where I can learn more about these things.

@imbueFX

It sounds like you just want the particle system to be a component of your blueprint, and you should use activate / deactivate functions as you want particles to turn on and off. There is a construction cost to spawning any actor in unreal, so consider that as well. Same with calling destroy.

So I currently have a BP that is separate from my character BP and I do all of my system spawning logic there. Should I instead be making all my systems components for my character BP? And then turn them off and on from there?
Is there a big difference between deactivating a system and just changing the spawn rate?

@imbueFX

Timelines carry a heavy tick cost, if you’re implying to use a timeline simply as a delay, I’d avoid that.

No, thankfully I’m just using it to drive parameters in a material instance. But I see you went over some ulterior techniques on how to do this more differently, which I will look at, exactly now.

@imbueFX

Sorry if any of this is coming in abruptly. If anything I said needs clarification, just ask! I have too many years of knowledge accumulated on this stuff.

Don’t be sorry, this is incredibly useful to me. I have tons and tons of questions so thank you for the help and wisdom!

[imbueFX]

@MGDubois

Do you have any idea if Niagara systems are the same?

I don’t because we have yet to use Niagara in Fortnite. Wyeth or Shaun Would have better info.

To be honest I’m not 100% sure what you mean here.

Async (asynchronous) loading in simplest terms means you load the asset separately from your blueprint and over time (latent). It does it along other async tasks on the game thread. So you can say " async load asset", and it might take a few frames to complete the task so it doesn’t hitch the game. Once the asset is loaded, you get an event to continue your execution path.

This is the blueprint node for reference. Notice the asset input I’m hovering over is a soft object reference. This is literally just a string pointing to content. Once the load is complete, it fires the completed execution path. The function outputs only an object reference, so you have to cast to the class you’re loading afterwards. For example of loading a particle system:

I am loading an asset. When it’s done, I cast to particlesystem to make sure I have the right class. I then change my particle system component in my blueprint by setting its template. Then I activate it.

Should I instead be making all my systems components for my character BP

While there’s never a “right” answer, typically no we don’t want to do that. You’d want to probably keep it a separate BP with a particle system component.

Is there a big difference between deactivating a system and just changing the spawn rate?

Yes, see my comment above about cascase being inefficient on the cpu and why activate/deactivate is better.

[Travis]

Do you know of any video examples, or documentation on this in the Unreal docs, so I’m not spamming you with replies?

[imbueFX]

Sorry, not that I can think of. This is just tribal knowledge I’ve picked up over the years working with programmers.

[Travis]

The dreaded followup question then, how would I go about implementing your aforementioned solution with the vertex shader?

@imbueFX

My pleasure. And to follow up on my comment of doing the work in the material: Consider also that you can perform this through a vertex interpolator, which will dramatically reduce the cost by offloading the calculations to the vertex shader instead of the pixel shader.

[imbueFX]

It’s actually very easy now, there’s a new node the rendering team created that makes the process much easier

And then you can count how many interpolators you’re using (important primarily on mobile) in the stats tab:

[Travis]

Thank you so much! I really appreciate you sharing this with us

[MGDubois]

@imbueFX

I am loading an asset. When it’s done, I cast to particlesystem to make sure I have the right class. I then change my particle system component in my blueprint by setting its template. Then I activate it.

Ok so basically you are using this to load various different systems at different times?
Or is this just loading the asset at the start so that it’s already there for future activation/deactivation?

@Travis

Thank you so much! I really appreciate you sharing this with us

Agreed!

[imbueFX]

@MGDubois

Ok so basically you are using this to load various different systems at different times?

Yes. And this isn’t exclusive to particle systems, this can be used from most any time of asset in the engine.

[Chris]

That’s really interesting! I’ve actually never worked on a game where effects assets (i.e. textures) were streamed. Have you worked on games that do that? I’m really curious to know how it works.

Whenever I’ve done weapon effects, muzzle flashes for example, the effects systems I’ve worked with have generally always spawned and then, a frame or two later, despawned the entire object. And then you just do that for as long as the player is shooting haha. It sounds inefficient, but from what I’ve understood, in those cases it’s still more efficient to Allocate -> Update -> Deallocate than having an object Allocate -> Update -> Update -> Update... etc, even if it’s not actively doing anything. This is of course assuming that textures and meshes are constantly loaded and available in a shared pool

[William_Mauritzen]

@Chris

…muzzle flashes for example, the effects systems I’ve worked with have generally always spawned …

We had a particle pooling system that would throttle performance by stopping the oldest systems because there were just too many. We had mobs that were on fire. So every once in a while some of them would noticably die out if you weren’t killing them fast enough.

I vaguely remember a system where we would pause the update off screen.

I remember a programmer griping that Cascade systems were made mostly out of the base emitter and that everything that made systems different took up very very small amounts of memory. But my response was, “I can’t imagine a system where that isn’t true.” The oddity being that I may actually be working with one right now because we’re up on the gpu.

[update]
I just checked with our architect. The framework to run our particle systems is almost nothing now and the memory for our systems can be thought of in terms of very small textures for the instructions.