Recently I am trying to work on a project. it has a lot of things needing to be referenced by grasshopper automatically. However each time something trigger the Geometry Pipeline component refreshing, all geometry referenced by this pipeline will be computed. And it’s waste of time because I just want the geometry which I made change recalculate.
I know geometry pipeline work well. but I want to know if there are some method or event in RhinoCommon or grasshopper API can reference geometry automatically on user condition?
I am a noob programmer. So i just try to use C# and Ghpython component in grasshopper to solve this problems.
Did I make myself clear? Any help and suggestion would be appreciated.
2020/08/02 frist edition
Sorry for the confusion . Since this project is still in the idea stage, I can’t provide any helpful documentation or code beyond a vague description.
But I can provide some examples. For example, I have a thousand points that I use to generate a model of a thousand houses. Every time I manipulate some of these points, the geometry pipeline component is refreshed. All the componets downstream will be recalculated.
I was wondering if there was any method or event trigger in the API that would help me implement the function of automatically picking up objects from Rhino. Every time I manipulate an object, I determine if the object meets some condition and then shunt them to a different output. In this attempt I can avoid unnecessary recalculation of downstream components.
Basically it can be described as implementing a more advanced geometry pipeline.
Is this clear enough? Or is the question too general? Or is there something fundamentally wrong with the idea?
This is a script based on the one posted by @efestwin
It find all geometries but you can add guid input to choose the geometry you want.
And it work slower than Geometry Pipeline, maybe someone will make it better.
Just a few thoughts for those interested in this topic:
The script is written in Python, which makes it already slower by default. Regular GH Components are compiled from VB .NET or C# code, which is much faster.
The script implements event handling. This is a complicated procedure in Python and the language is clearly not built for this, though it is still possible. As stated here before, this job should usually be performed by a “real” GH-PlugIn.
I wanted to see if I can get it to work anyway (because I’m a nerd) and at the time, I didn’t know much about C# let alone GH-PlugIn development in VS (ah yeah…times have changed since then *sigh*)
FWIW, I’ve recently had success subscribing to events using the __enter__ / __exit__ methods available in GHPython when running in SDK mode (i.e. that I picked up from Steve and Giulio over here). While there still are hiccups involved (e.g. this example recomputes on changes to layers other than the input Layer) it has been behaving as expected/intended for production. And is a quite terse/simple solution IMO:
Aaah Anders to the rescure with another gem Didn’t know about the __enter__ / __exit__ methods in the GhPython SDK until now, will definitely need to try that and update the components that are working with events.
Regardless of remaining hiccups, this seems like a much more straightforward solution. Thank you so much!
I use your script without change anything.
The script from the other topic to show rectangle in viewpor works without problem, also this example of @piac works but after some time it make the viewport blink and make the system very slow
I don’t recall, but just looked up answering the same question on our internal Teams:
I reviewed the Geometry Pipeline code (+1000 LOC) and think I’m gonna have to put a pin in the requirement to have this recompute on events occurring to objects on specific layers. It gets pretty wild as one has to write and assign custom eventhandlers (e.g. for layers LayerTableEventArgs) for each type of event, which ends up kinda defeating the purpose of this minimal code approach (i.e 40 LOC).
This might be incorrect information, was quite stressed. It would indeed be good to learn more on this topic.