Can anyone offer any insight into how Grasshopper manages it objects? I’m referring to how Grasshopper objects are “virtual”, unselectable objects in Rhino documents until they’re baked, and how Grasshopper programs respond to changes in Rhino objects that are inputs. Is there top-level support for that mechanism?
so I’m probably not the most qualified person to answer this but I’ll take a stab.
Grasshopper manages its own data structures of RhinoCommon geometry (Like Rhino.Geometry.Point3d or Rhino.Geometry.Brep), wrapped in special Grasshopper types (GH_Point, GH_Brep, etc). Each Grasshopper component that draws any “virtual” geometry to the rhino display implements a method that handles calls to the Rhino document’s display pipeline (Rhino.Display.DisplayPipeline).
As far as reacting to changes in the rhino document, it’s my understanding that the grasshopper document handles adding event listeners to Rhino that check for changes in the active document, undo/redo events, object additions/modifications/deletions etc. (events primarily attached to the active Rhino.RhinoDoc).
When a user triggers a bake operation, GH handles actually adding all the “virtual” RhinoCommon geometry to the active RhinoDoc’s Object Table (RhinoDoc.Objects) and assigning it appropriate objectattributes (the other “stuff” that Rhino needs but GH doesn’t pay attention to)
GH certainly does a lot of housekeeping under the hood but the basic functionality you’re talking about is pretty accessible via the SDK. Hope that’s helpful (and hopefully someone more knowledgeable than I can fill in the gaps!)
Thanks, Andrew. From your description, it sounds like it would take quite a bit of effort to duplicate that mechanism.
If the only functionality you’re trying to duplicate is “visible but virtual”, you could pretty much add geometry to the doc in the normal fashion but make it locked from the moment it’s added…No need to make a display conduit unless you need the stuff to be a different color other than grey.
There is indeed a lot of stuff going on and Andy is correct about how it works. However just displaying some geometry is not too much work. You can either handle your own dusplay pipeline events, or you can use the customdisplay class if you have geometry that is mostly static.