ribbons steal particle capacity from the system that trigger them

Unity Engine
,
1

I’m chasing my tail.
I thought line distribution was the problem but it seems to be life cycle of particles that i’m not understanding.
The graph is this

9814959--1410126--upload_2024-5-4_21-4-47.png
9814959--1410126--upload_2024-5-4_21-4-47.png793×2417 144 KB

in my mind delay of 1 in the periodic burst should sync with the lifetime of 1
but instead it blinks on and one with a period of 2 seconds.

even weirder, if i turn back on the GPU event trigger now the period is 2 seconds + lifetime of the ribbons
as if blocks below had an effect on periodicity or maybe capacity.
So I jacked up capacity of the PARENT particle system to 10k and bingo no more blinking.
So it looks like ribbons steal particle capacity from the system that triggers them, even though they have their own capacity bucket
bug? by design? if by design it doesn’t seem right to create a upward dependency in a branch but I can live with it now that I know. actually in usage, even knowing, it’s cumbersome workflow as i need to up the capacity when i change ribbon settings.
really it should be handled automatically by this:
9814959--1410135--upload_2024-5-4_21-9-48.png

also what’s the lifecycle of things? ribbons survive particles after trigger particle death, which is cool as it avoids ribbon suddenly disappearing and instead whisping away.

2

It seems that a bug is present with GPUEvent and Child Strip’s system. I’ve created a Bug that you can find here.

3

doesn’t seem new to u6 though

4

Hi!
I’m afraid this is a limitation by design (not sure if it is documented, probably not).
When using strips with GPU events, the strip index is taken from the particle ID. This means that, if a particle died and a new one was generated with the same particle ID, they would use the same strip, with unexpected results.
For this reason, particles in the parent system are forced to be kept alive until their attached strip is empty. This has 2 main consequences:

  • What you are seeing, that child system prevents the parent from spawning particles over the number of active strips.
  • If you had more than one strip child system, the parent system only checks for the strips in the first child, potentially allowing the issues that we are trying to prevent.
    This will be reworked in the future.
    Hope that helps understanding this unexpected behavior!
1 Like
5

good, because it’s awful that we have to go low level to get the most common fx, trail.
all this allocation stuff needs to be automatic with option to go under the hood

in the meantime you need to add a message “child #1 requires ### particles” below the counter field