Automate Sliders From Python WITHOUT Needing Full Recalculation

There are forum threads affording ways to move Grasshopper sliders from custom script components but they all seem to require a full recalculation be triggered for the entire Grasshopper script to have any affect, but that's way too slow if 90% of the GH program is initialization and creation of source geometry to then simply alter a bit or array here and there. When I use Python directly to change output values that I plug into former slider inputs, again no new solution is triggered at all so I'd have to recalculate the entire Grasshopper program which is simply not how Grasshopper normally works. How do I actually emulate a human changing a slider value one slider at a time in a way that makes Grasshopper behave normally so that only downstream flow is affected in an efficient way?

An related example would be if you have several separate programs in a Grasshopper page and you wanted to only change one of them without triggering full recalculation of them all.

At this point it's almost like a Windows mouse scripting utility is needed but if I need to do combinatorial combinations of all possible slider values, that seems quite thorny too unless I set up a pre-arranged array of values that could then simply be incremented "manually" followed by a right click to bake and then typing commands into Rhino to save to a file. UGH. That would be quite difficult to pull off since I need to control file names, but it's what I seem to need.

I'm using Python since it avoids thorny Grasshopper schemes and it allows me to access Rhino to save baked objects files.

Replies to This Discussion

Permalink Reply by Anders Holden Deleuran on April 29, 2015 at 4:38am

Attached an approach which is based on named sliders, but you should be able to use GUIDs if you prefer as well. Hope that helps..

Attachments:

150429_SetNamedSliders_GHPython.gh, 4 KB

Permalink Reply by James Ramsden on April 29, 2015 at 5:07am

Very succinct solution! Nice!

Permalink Reply by Nik Willmore on April 29, 2015 at 9:20am

Rather exciting that it actually initiates a real slider movement rather than just the mere value changes minus any visual movement that I've seen before. That other method requires a refresh of the whole Grasshopper program, whereas your version changes a test sphere mesh geometry diameter as soon as it moves the slider.

There's no manual for this kind of stuff yet, thanks.

Permalink Reply by Nik Willmore on April 29, 2015 at 10:15am

Uh oh...looking at your short solution, it looks like it does force update of the entire Grasshopper solution:

obj.ExpireSolution

Good enough for most work. Awful for black box Grasshopper programs that involve a lot of preliminary processor time to set up a scene to merely modify, which works fast with manually moving sliders but is again slow upon full recalculation. Unfortunately for me the solution below is in C# which is hard to translate into Python for me.

Permalink Reply by Anders Holden Deleuran on April 29, 2015 at 10:40am

That is not the case on my system (see attached file). Only sliders with a nickname which is in the "Sliders" input list are updated. However this update will of course trigger any downstream connections from the sliders to update. This is how dataflow programming fundamentally works. Could be that your specific task is better suited for pure imperative programming in C# or Python. Edit: There's also the datadam, which allows you to only propagate data at your choosing.

Attachments:

150429_SetNamedSliders_GHPython_01.gh, 9 KB

Permalink Reply by James Ramsden on April 29, 2015 at 10:54am

The ExpireSolution() method acts on Grasshopper objects (i.e. individual components). In the background, each component has its own 'solution'. It expires the components it's called upon and everything downstream of that component (i.e. the same action as what happens when a user changes a component, such as moving a slider).

Despite its confusing name, it does not expire the entire document.

Permalink Reply by Nik Willmore on April 29, 2015 at 11:58am

Heaven, I'm in Heaven
And my heart beats so that I can hardly speak
And I seem to find the happiness I seek

Permalink Reply by James Ramsden on April 29, 2015 at 11:23am

Just tested the BatchComponent to be completely sure...

I've just loaded up a quick demo:

The 'bucket' contains a list which collects every item that's fed into x. The BatchRun component is based upon Rutten's, and uses the ExpireSolution to trigger new events.

If ExpireSolution did expire the entire document, what we would find by running the batchrun is that the top-most bucket would amass a list containing repeated values of 4.

But I've just confirmed that the topmost list contains only one item even when BatchRun is run.

The bottom bucket, as expected, runs 121 times, producing a list of the 0-10 times tables.

If you are still having problems with the entire canvas recalculating, might be worth sharing your GH file.

Attachments:

slider demo.gh, 10 KB

Permalink Reply by Nik Willmore on April 30, 2015 at 6:26am

New Python confusion: your short script pasted into the latest Python module in Grasshopper fails. Your Python component has an "adh" icon and is permanently titled "Reset (R): Reset named sliders" whereas a normal Python module can be renamed. I have used the same type hints on the inputs, of default, float, and default. The list of two numbers, Values, is refusing to be treated as a list I guess.

Attachments:

SetNamedSliders_GHPython_NEW_PYTHON_VERSION_FAILS.gh, 8 KB

Permalink Reply by Anders Holden Deleuran on April 30, 2015 at 6:32am

Since we are inputting "Sliders" and "Values" as lists, you also need to set their parameter data access from "Item Access" to "List Access"..

Permalink Reply by Nik Willmore on April 30, 2015 at 6:54am

More "hidden variables" than a string theory crackpot might even imagine. That worked, and I just learned more about Grasshopper, er, I guess mostly just the scripting modules. I'm under some pressure and impatience was making me blind to just casually looking at where other settings are. Thanks.

Permalink Reply by Nik Willmore on May 1, 2015 at 9:35pm

Not just "hidden variables" but now lonely ghosts! Why does this slider-changing remote control strategy cause my Python script to continuously loop just because I try to bake and save the result?

"Where's the loop?!" I try a simple bake/save test but it then churns forever, saving the same OBJ file over the last one. Yet happily the Enable button can be double clicked to stop looping, unlike my former entry into the Grasshopper Python jungle that required Ctrl-Alt-Del.

So some state is changing somewhere that retriggers something? I added print statements in the script but they *don't* evidently themselves repeat as the bake/save statement indeed does.

How do I better learn to think like a programmer here? There is something of a human element to most all programing though, little details of how things are really connected. I did chemistry. Synthesis. There was no human element. Just myself against constant Nature. If we discovered such a loop, we would have real cold fusion.

Attachments: