What can trigger Geometry Pipeline component refreshing?

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. :stuck_out_tongue_winking_eye: 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. :heartbeat:

2020/08/02 frist edition

Sorry for the confusion :frowning_face:. 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?

1 Like

Welcome @1071969980
Start here

1 Like

Thanks for the guidance. I tried to re-describe the problem. But I’m sorry I wasn’t able to provide any documentation or pictures.

1 Like

I think you are being a snob here.
I perfectly understand the problem as it is clearly stated.
As a matter of fact, I have the same problem : I’d like a geometry pipeline with a trigger.

It’s not so hard to understand.

1 Like

I think it’s a very interesting idea if I understood it correctly. It should not be too much of a problem doing it with Visual Studio in C# as a “real” component.

If you’re working with python however, you need a lot of black magic to do it - the reason being that you most probably need to track event states etc.

It’s not exactly the thing you want to do, but I think it could help you understanding what needs to be done if you look at this python component (shameless self-promotion incoming):

Maybe you can adapt the component/code to do exactly what you want :slight_smile:

1 Like

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.

geos pipeline.gh (5.3 KB)

1 Like

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*)

Hope this helps anyone interested.

1 Like

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:

211028_RecomputeOnRhinoEvents_00 (1).gh (4.1 KB)


Aaah Anders to the rescure with another gem :smiley: 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!

1 Like

Thanks @AndersDeleuran , it work fine at first but than the same problem as the script of @efestwin
Nothing changed until i hit recompute

Can you share an example/elaborate upon what causes this occur? Would be good to know of cases that break the event listening/update methods.

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

1 Like

Nice, what would need to be changed so this component only recomputes on changes to the input layer?

I’ve been playing around with it but couldn’t figure out how to use a filter in this SDK mode.

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.

Hi Anders, thanks for your reply.

Not sure if you follow my other topics:

The goal is to reference Rhino content but without the component recompute on every change to the specified layer.

1 Like