FX spawning practices

unreal
particles

#21

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.

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.

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?

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.

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!


#22

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.


#23

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


#24

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


#25

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


#26

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:


#27

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


#28

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?

Agreed!


#29

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


#30

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


#31

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.