DelegateRegion & Fuse with external values (best practice, performance)

Hello!
Following up on this topic Unstable Behavior of Fluid3D, I’d like to ask about best practice when dealing with values that, for example, come from a UI or from a Kairos Timeline via GlobalChannel, and are then fed into a DelegateRegion or other Fuse nodes.

1) In my DelegateRegion, I have two fuse noises that are added together. Let’s say I only ever need one noise active at a time. I control this via KairosTimeline with the respective scalar (one for Simplex and one for Worley). If I set the one scalar to 0 and have a Damper, once the damping time reaches “zero,” does that mean the corresponding noise is no longer being computed inside the DelegateRegion? Or are both noises still calculated simultaneously, even if one scalar is 0?
If I want to save performance and only need one noise at a time, what’s the correct approach? Is the solution with Switch and ZERO (as in the patch below) correct, or are there better alternatives?

2) I understood that as few IOBoxes and nodes as possible should be placed inside the DelegateRegion. But how should values like Amplitude and Frequency - if they change and are controlled externally - be placed correctly to save performance? Or does it not really matter? Is the GPUIn solution (on the right side of the patch) the recommended way?

Sorry for the long post - I hope these questions aren’t too trivial. Thanks a lot!


delegate noise.vl (40.7 KB)

I’ve been digging a bit around the way this regions work to use same approach in another library. The key point in there that regions wraps patch inside in to delegate, it is some sort of patch to delegate.

So basically what you see inside of region is not exactly the same in terms that u see a reflection, of actual stuff that is getting called from somewhere else.

About your performance concerns, everything inside delegate region would be computed, don’t think amount of ioboxes or evaluation of params would anyhow affect performance specially if thouse are not spreads, if thouse are larger spreads then it’s debatable.

In simpler words you won’t gain any performance by applying workarounds you proposed.

No

That works that way that to properly disable second noise you need to compile shader without it, technically you can place both noises each in If region, and switch If on and off, that would make sure noise is not evaluated

1 Like