if parameter change then disable slow components temporarily

by Jonah Hawk

Apr 9, 2012

This is a simple example of a mechanism something like a callback to monitor user input... Sometimes, I would like to disable slow/time-consuming portions of my definition while tweaking parameters. I know this can be done manually. This small def shows one way of doing it somewhat automatically... at least for a graphmapper. I would love to see how others handle something like this.

http://www.jonahhawk.com/2012/04/grasshopper-parameter-change-test-...

  • up

    Hannes Löschke

    Just my 2ct:

    I personally hate "intelligent" programs. Most likely the intelligent behavior is disabling the exact component you want to observe.

    I prefer building the definition with light geometry to the very last moment. You'll have more fun adjusting parameters and probably will end up with an overall lighter definition.

    1

    Apr 10, 2012

    • up

      David Rutten

      Here's some ideas that might be interesting:

      1. Put locks on objects or wires. One click locks them (and everything downstream of them), another click unlocks them. Benefit is that it's quick to assign a state, drawback is that you have to remember to do it every time you start messing with the lightweight stuff. Locks could perhaps be limited to group objects only. It might also be interesting to control Preview On/Off via groups.
      2. Provide a data-dam object which collects data on the left but doesn't allow data to flow through it. Only when clicked will it seed its outputs. It could of course also have a mode where it always seeds data, in which case it would be like inserting a Generic parameter into an existing wire.
      3. Since most GH files are ordered left to right (sometimes they also have a strong top to bottom layout), I could add a draggable border. An infinite vertical line that can be dragged around at will, and everything to the right of this line is disabled. Benefit here is that it's easy to modify which objects are solved, drawback is that it's difficult to quickly solve all objects and then go back into locked state. You can think of this as a Clipping Plane sort of thing if you want.
      4. Have a mode that doesn't solve components which took more than X seconds to solve previously, until you specifically exit the mode via a mouseclick or keypress.

      I have to say I love your solution, very clever. But I can see how it's annoying if you have to add something like this to every definition you make.

      --

      David Rutten

      david@mcneel.com

      Poprad, Slovakia

      14

      Apr 10, 2012

      Load Previous Replies
      • up

        Andrew Heumann

        Jonah - this is really clever. Would be awesome to find a way to adapt it to work with any input object, rather than just the graph mapper. I tried myself but didn't get anywhere.

        David - I especially like #2 and #4. #1 doesn't seem to do a whole lot that simply disabling an upstream component wouldn't, and #3 would be a pain for sloppy users like me who aren't so careful about the left-to-right thing. 

        I like Hannes's suggestion of a timed lock, which only passes the data fed into it when it's not changing (within some specified time interval). This would allow precisely the kind of functionality Jonah's solution enables, but without the complexity or dependence on the graph mapper. 

        2

        Apr 10, 2012