Dynamic Geometry Pipeline prevents Human UI update

The very first time I want to give Human UI a go and immediately I have this weird bug. I am running a loop (using Anemone) and in each step it is baking geometry using Human. So far so good.

If I now use Human UI to trigger the start of the loop and want to say have a toggle and a loop counter in Human UI that works fine… UNTIL you add a Dynamic Geometry pipeline. It doesn’t have to do anything inside the loop. The sheer presence of it seems to give Human UI the heebie-cheebies in such a way that it freezes and doesn’t update again until the loop has finished. Delete the component and it works fine.

Any ideas why that might be happening? It means at the moment you can’t have Human UI update during a loop running with a dynamic pipeline present? That would be a shame. I was thinking to use Metahopper to disable it during the loop, but that doesn’t do it, the component has to be completely removed.

Thanks for any hints how to avoid this. Maybe/hopefully I am missing something…

In the attached file I have internalised everything. See the UI not updating while the loop is running, then delete that Dynamic Geometry Pipeline (simply disabling doesn’t help) and then it works.

human_ui_pipeline_bug.gh (90.2 KB)

You’ve got three players in this equation who all do non-standard things with a grasshopper solution (ie manipulate it programmatically): Anemone, Human UI’s Value Listener, and the Dynamic Pipeline. When you set the toggle to true:

  1. value listener fires with a “true” value
  2. loop start fires, triggering a bake operation
  3. dynamic pipeline is listening to changes to the rhino document and thus fires
  4. loop end fires, requesting a solution from loop start
  5. loop start fires, triggering a bake operation
  6. dynamic pipeline is listening to changes to the rhino document and thus fires
    … etc.

I can’t say why exactly the dynamic pipeline makes the difference here, but it’s worth noting that if you set the layer it’s listening to to something specific (not the default “*”) you can prevent it from expiring on each bake, and therefore cause it to behave the same as if the component were not there.

Cool, that’s good info. I am actually listening to the layer I am baking to in another part of the script, but I can switch it to listen to a different layer, like the default layer, while the loop is running. Probably best to not bake to and listen to a layer at the same time anyways.

Thanks, will give that a go!

I wish that there was an option to make the pipeline “not dynamic” and refresh when triggered.
When not triggered, it would be useful to have it retain the previously gathered data instead of outputting no data.

I’m trying to simulate such enhacements with Metahopper, but sometimes, that the new data fails to reach the dam before it is shut, so it’s not reliable.

1 Like

I’d love to have a sort-of “Trigger component” that has different connection wires, like Galapagos
and it listens to a bool: when the bool becomes True, it triggers a Recompute on the destination

1 Like

Well, that would be Metahopper components with wires :slight_smile:
Sometimes, it’s indeed hard to keep track of what components are affected by Metahopper.

I use “Jump” components to keep track :