I have some questions regarding how I’m spawning some particle systems in unreal and I was wondering if I was using good practices to do so. Also this question relates to persistent effects that turn off and on like some sort of aura or status effect.
The way I’m currently doing this is by spawning the emitter attached whenever the event fire and then destroying it once the effect is no longer required.
I was thinking it might be more efficient to have the emitters already spawned and then turning them on or off? I’m not sure exactly what the best practices are when it comes to these kinds of things.
In the vaguest, most general sense I would say that it’s better to spawn effects when you need them and then remove them, rather than keeping them around in an inactive state. I don’t work in Unreal professionally though, so I’m sure there’s lots of subtleties I’m not aware of.
The best thing to do will always be to test it yourself, since each game and use-case is different. Set up some test scenarios, do some profiling, and see for yourself what ends up being the most efficient
Ok that makes sense. For now I going to continue doing what I’m doing lol.
I gotta do some learning when it comes to the profiling tools in unreal.
Thank you for the insight!
if it’s just a 1 shot burst effect then there’s the option to Auto Destroy, which you’re currently using anyway. This will just remove the emitter once there’s no more particles being calculated.
You might find that when you destroy it you see a visual pop if there’s any particles still on screen so maybe deactivate first and then delay a few seconds and then destroy.
Personally, I think if it’s something that’s going to be turning on and off quite regularly then i’d just use a parameter for the spawn rate and scale that up and down instead of spawning and destroying it, but i’d have to do some tests to check the performance of the two systems - tbh it’s very unlikely that the psys overhead is big enough to worry about too much.
You could make you particle event a separate blueprint component, and within that component spawn your particle system. If it’s in its own component you can start on standard EventBeginPlay, and then add a deactivate, a delay to let your particles play out, and then a destroy actor at the end.
If it’s for player effects that will be turned on and off quickly and multiple times…it’s usually better to have things loaded. Think of it as moving to a new apartment because you want to move the couch. Would you rather move to a new apartment and move all the furniture in, or would you rather just rearrange furniture.
If the effects will go away for a fairly long period of time, then of course you want them to unload to make room for other streaming objects.
That’s my understanding, and I’m open to being corrected.
This is what I’m trying to do, but I’m currently having issues just spawning the systems at begin play. Because this is one of those FX that comes on and off quite often.
So an FX specific event manager? I’ve already got a separate component I handle all my FX management on, but when I try to spawn my emitters on begin play nothing seems to happen.
Ah I should have specified, the particle systems should have Auto Play on, that was as soon as it runs through the SpawnEmitterAttached it just plays. If I remember anything else, I’ll edit this and add it in.
If you have the system already called in your blueprint, you could just Activate/Deactivate it vs destroying the component so it stays loaded.
It will be in Bluprint. Under the Details panel, under Activation there should be a checkbox for Auto Activate, but this is only true if your particle system is either a component in your blueprint, or if you’ve promoted it to a variable. So the flow would be either > In your blueprint you attach your particle system component to whatever > activate > delay > deactivate
or
Your bluprint calls a custom event > event calls your bluprint component > your blueprint component attaches and fires particle system > blueprint component destroys actor (self).
I’m a bit tired so I may have forgotten a step or two but that’s the general gist of it.
You should not use delays too much, because delays ignore other blueprints from being called instead use: ‘Set Timer by Event’.
This in my experience makes the Tech Designers and Programmers much happier and also you’re not able to use delays in functions.
Here’s an example blueprint of how this would look like, in this example I needed an infinite looping particle that would dissapear after something would happen (Like a Damage/Heal overtime effect).
So does the event being plugged into the ‘Set Timer by Event’ get fired once the node is fired? After the allotted time?
I can probably find a youtube video about this node lol, but thank you for pointing this out.
Edit: Also, and this might be something completely different, but are Timelines an ok thing to use in
general?
So after the emitter is spawned we fire off the ‘Set Timer By Event’ node. Which basically sets a timer to 1 seconds, after that 1 second has passed it automatically fires off ‘Deactivate Particles’ whilst still firing off any other logic anywhere across the game. It can simultaneously fire off multiple events without stopping anything else.
as far as I’m timelines are okay to use, they can be a bit tricky if you want to fire them off multiple times. furthermore, you can’t use them inside functions, but you can however use curves. but then you’ll need to pass on increasing float value to set the curve value in your function.
Personally, I think if it’s something that’s going to be turning on and off quite regularly then i’d just use a parameter for the spawn rate and scale that up and down instead of spawning and destroying it
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.
If it’s for player effects that will be turned on and off quickly and multiple times…it’s usually better to have things loaded.
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.
This is what I’m trying to do, but I’m currently having issues just spawning the systems at begin play. Because this is one of those FX that comes on and off quite often.
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.
are Timelines an ok thing to use in general?
Timelines carry a heavy tick cost, if you’re implying to use a timeline simply as a delay, I’d avoid that.
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.
Hey Bill! Is there a more efficient way to control a material’s parameter than using a Timeline? I’ve been using them for things like boosting a character’s emissive value in its material instance, and controlling different parameters for decals like alpha erosion and emissive color over life.
There are different ways, all with their own tradeoff. I think the example of spawning dozens of decals on impact with a fast-firing weapon is a perfect example of timelines eating up too much cpu time. The alternative I’ve used is “time stamping” (generic and completely made up term). When the decal is spawned, we create and apply an MID for that decal. You’d then feed in the game time as a float parameter, which we’ll call the timestamp. In your material you’d then take ((time - timestamp) / scale) and saturate that value. This gives you a 0 to 1 animating value that happens entirely within the shader, so there’s no tick cost on the cpu.
But consider that this set of operations made your material a little bit more expensive. So it’s really a game of checks and balances that ultimately you have to decide. I use this technique pretty extensively on Fortnite FWIW.
Also consider that you can nativize blueprints now, which reduces CPU overhead (at the cost of a little more memory). On blueprints I create that need to tick, or rely heavily on timelines, I enable this setting on the blueprint actor (under class settings).
Thank you so much for all that awesome info! I’m getting a bit better at blueprint, but I’m always worried I’m doing something in a manner that’s not optimal or performant.
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.
but that’s the general gist of it.