Interactive, real-time geometry referencing...

Hi everyone,

My quick question on grasshopper today is: can I have grasshopper reference geometry from the scene on the fly?
In other words, is it possible as a user to place points on a rhino plane and have grasshopper pick them up in real time and process them in a definition? (essentially outmoding 'set multiple points' in this scenario)

Thanks..

Replies to This Discussion

Permalink Reply by David Rutten on March 29, 2011 at 11:02am

Hi DumDaDaDum (if that is your real name),

this is not possibly natively. Though it should be possible to write a VB/C# script for this. It's quite tricky though, as the object-added/deleted/replaced events from Rhino get fired for every individual object. So if you were to drag 500 points around, you'd get 500 unique events. It would be a bad idea to recompute Grasshopper after every individual event. To collect all event information and respond at the appropriate time is quite involved.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by DumDaDaDum on March 29, 2011 at 2:05pm

Hi David, my real name is Radu,

and yes, I see how that may not be computationally intuitive. But! What about if you build the architecture of the script so that grasshopper does not sample the geometry except on a 'create' event?

I know that grasshopper already iterates through the definition if I move or change the original referenced geometry, in our case 'points' on the construction plane, with more than acceptable response times. Therefore, it should only source newly created objects - rhino already has a function for selecting last created objects, so possibly it has an internal tagging mechanism for this. Unless what you're really saying is that in a scene with 500 points, if I drag one around, rhino would still issue 500 unique events...

Permalink Reply by David Rutten on March 29, 2011 at 2:42pm

I can probably extend the functionality I have now. The way it works is:

1) an object changed/added/deleted event comes in from Rhino

2) if I don't have an ID-Hash table for the current ghx file I build it

3) I test the ID of the rhino object in question against the hash table

4) if the ID isn't referenced, I ignore the event.

5) if the ID is referenced, I store all components that are associated with that ID in a list.

6) at some point the changed/added/deleted events stop flowing in and I get an undo event instead. This signals to me that it would now be a good time to expire all the objects on the canvas and recompute.

The beauty of this system is that I can trivially reject the bulk of uninteresting events close to O(1) runtime. The last thing you want is for Grasshopper to slow down regular Rhino use. If I have to start digging through object attributes to find out if they're on a layer I care about, it all gets a lot slower.

But I can definitely see the point of all this. I'll see if I can come up with something quick, otherwise it will have to go on the long-term pile.

David Rutten

david@mcneel.com

Poprad, Slovakia

RSS