I have a collectible item, which has a particle system attached to it. When collected, the item flies towards the player, and the particle system acts as a trail. For performance and a better look, I’m using GPU particles for this, but there is a problem. If I walk offscreen before the particles have fully disappeared, the particle system is culled. When I walk back in later, the particles that were left over from the trail are still there, and continue where they left off. This looks extremely odd, since the collectible item has respawned by that point. The way I would normally fix this is by emptying the particle system when it respawns, deleting all instanced particles. Is there a way I can do this, or prevent those particles from reappearing (short of killing them on disable, which would instantly delete the trail)?
Hmm… it seems “Kill on deactivate” doesn’t even work anyway…
Hey Hoeloe -
What is the lifetime setting on your trail effect and you have it sourced to your actor collectible item or just a child of the item in a blueprint?
Thank You
Eric Ketchum
It’s currently just a child in the blueprint which I’m activating and deactivating in the blueprint. The particle lifetime is a constant 1 second. I’m using a workaround at the moment which destroys the particle system and creates a new one when the item respawns.
Hey Hoeloe -
I am making the assumption that the particle system is only used as a trail here, but I would remove the emitter from the Components of the Blueprint and then spawn the emitter on the item’s movement, parenting the movement of the two items and destroy emitter on a few seconds (miliseconds) delay on the items destruction which should let the trails lifespan to dissipate.
Thank You
Eric Ketchum
Essentially, that’s now what I’m doing, except I’m destroying the one in the blueprint and copying the data to instantiate a new one.
Hey Hoeloe -
I am attempting to build a test of this issue, but I wanted to confirm how you are moving the collectible object in blueprints? Are you using a move component to or a VInterp Set Relative Location? As much information as you can would be helpful so we can solve this issue for you.
Thank You
Eric Ketchum
The objects are being moved using a vector lerp node fed into Set Absolute Location.
Hey Hoeloe -
After some testing, the best way to achieve what you are looking for is to deactivate the emitter in the Blueprint. The key to making it look nature and more like a fade out is to set up the Alpha fade of the particle to be set via a particle parameter which is controlled through a finterp in blueprints then deavtivate the particle. This will elimate the stray GPU particles and not look like a cut.
Thank You
Eric Ketchum
Thanks, but this isn’t the problem I was having. In fact, this is what I’m actually doing already. The problem is that GPU particles don’t receive a tick event if the emitter (that is, its bounding box) is offscreen. The issue with this is that when particles are present when the bounding box leaves the screen, they are no longer updated, and remain in their current state until the bounding box re-enters the screen. This means that particles that should have faded a long time ago have been essentially frozen in their previous state for all the time that they have been offscreen, making it appear as though they have reappeared.
Hi Hoeloe -
I am having a difficult time reproducing the exact scenario you are describing above, do you have a test map that you would not mind sharing for us to test that is experiencing this issue?
Thank You
Eric Ketchum
https://dl.dropboxusercontent.com/u/30847069/GPU_Particle_Error_Demo.zip
Here is a link to a MWE. You can click to disable the emitter, and right click to enable it. If you do this while the particles are on screen, any particles left over from when the emitter was previously enabled are immediately destroyed, however, if you disable the emitter, and re-enable it while the particle system is off screen, then the leftover particles are still present (and have not updated since the particle system stopped rendering) when the system is in view again.
Hey Hoeloe -
I am happy to report that your issue has been fixed in an internal build of the engine. The fix should be in a forthcoming release of the engine.
Thank you for you help and patience while we tracked this issue down.
Eric Ketchum