Hello,
I have a pretty complex GHPython script and I believe is the cause of the severe lag time that I have been experiencing while the grasshopper file is open in Rhino. Does the GHPython script continuously run in the background while grasshopper is open? Is it possible to only have the script run once upon changing a number slider while keeping all the geometry that it creates visible?
Thanks!
Unless it gets prompted externally by something like a Trigger or connected, upstream components to refresh, or internal logic that recomputes the canvas non-stop, no, it normally doesn’t continuously run.
Yes, but I don’t understand what you mean by “keeping all the geometry visible”.
I thought if it wasn’t running the geometry would disappear. However, I clearly have the wrong idea in mind. My script is in fact connected to upstream switch field components that it later alters when a particular event occurs. So maybe it could potentially be continuously running. How would I go about running the GHPython Component upon the change of a number slider?
I don’t think so.
Oh, so it must have some internal logic that recomputes the canvas in regular intervals to be able to check for changes in that “switch field”, right? Does it behave somewhat like a daemon?
As long as the component is connected to the slider, it will re-run when a slider change occurs.
You can potentially use that to your advantage here.
To be a little more descriptive, upon the change of a number slider, my geometry (which is a structural frame) rotates about an axis. When it rotates, certain elements upstream in my script disappear/change because they were dependent upon certain points that no longer exist as a direct result of the rotation (change in number slider). The elements that altered are then brought back into my Python script which contains a bunch of classes that inside contain “if statements”. For example,
if curve == None:
a = 0
else:
a = 1
The variable “a” then gets directed from my python script component to a switch field component which will reparametrize a certain element in my frame when “curve == None”.
So I guess its a daemon in that sense. The slider is the only thing that the user needs to change and its not connected to the GHPython component. The GHPython component reacts to changes in geometry, not the number slider directly.
OK, it seems like your GHPython component should get recomputed each time that you change the slider value, since the latter changes the rotation of certain geometries, and the rotated geometries then prompt the scripting component to refresh?
As mentioned before, if the GHPython component detects that an input was passed a new value, it recomputes.
An indirect connection is one nonetheless. 
Yes, and the changes are provoked by the slider.
I think the issue here is that the slider outputs many interstitial values in between the old and new target value, while being moved. And at each increment the geometry is rotated and thus the GHPython component recomputes, which when having a heavy Grasshopper definition can be detrimental to a fluent workflow.
Here is my grasshopper component.
Is this exactly what you were envisioning when you made your last statement about having many interstitial values? I am a bit confused with that terminology and how it could cause inefficiencies in the script upstream.
Knowing this, what would you propose as a more efficient way of handling this?
