[2025.32280] Bypassed POPs bug

Bypassed POPs are holding a reference to previous node somehow. They continue cooking even when the viewer is not active.

Tested this behavior with a work-in-progress project using Probe. There is significant performance drop even though nothing is being rendering.

Steps to reproduce:

  1. Connect a POP to another POP
  2. Bypass 2nd POP
  3. Disconnect the input while it is bypassed. (holds previous memory reference)
  4. Reconnect and disconnect again while bypassed. (Now behaves as if it is still connected)

I’ve attached a file with example script thar reproduces the bug.

2025-32280_pop-bypass-bug.toe (8.2 KB)

Hello @defektu

Thanks for reporting the problem. I’m also seeing that keeping a reference to a previously connected POP while it’s bypassed can lead to other unintended effects. We’ll look into this.

1 Like

This will be resolved in the next build we release.

1 Like

Hello @Guillaume.L

Thanks for replying. The Particle POP render flow appears to keep cooking in the background even though it isn’t visible or being used anywhere. Do you know of any techniques for managing or consistently controlling its cooking?

I’m having hard time preparing for a performance next week, and this issue is making performance behavior difficult to predict.

I’d really appreciate any guidance you could share.

Normally, if none of the cooking nodes depend on the Particle POP and its viewer is not active, the Particle POP should not be cooking. Could you share a minimal example that reproduces the issue you’re seeing?

If this is related to the bypass issue, it might be possible in some situations to use a different POP as input through a Switch POP.