Rhino Geometry versus Grasshopper Geometry

Can someone point me to a discussion or reference giving a general overview on why I would want to, or need to, use GH geometry inside a C# or Python component instead of Rhino geometry. Basically, is there an introduction to how Grasshopper handles geometry and why there is a need for a separate set of GH_Geometry classes? For example, when and why would I need to cast between the two?

I've been picking up bits and pieces from threads but its very frustrating to not have a clear explanation of what's happening. If one exists already, I would love to read it. If one does not, it should really be written sooner than later.

Thanks so much, David

Replies to This Discussion

Permalink Reply by David Rutten on August 1, 2016 at 1:08am

Grasshopper doesn't really have its own geometry, what it has are wrapper classes for all the data types it uses. So GH_Brep is not a different implementation of the notion of a boundary-representation, it just provides a bunch of additional methods and carries a regular Rhino Brep inside of it.

As a component developer there are a few cases in which you would deal with these IGH_Goo wrapper types directly:

If you wish to use any of the IGH_Goo functionality and you don't particularly care about the data itself. For example when transforming geometry. You want to be able to transform all kinds of geometry and you don't want to special case every single known type, let alone not handling types of geometry that are unknown to you at the time of writing. So you'd operate on IGH_GeometricGoo rather than the geometry data directly.
Other functionality available through IGH_Goo includes baking and converting data.
If you're dealing with GH_Structure<T> (ie. the data tree type used by grasshopper core). GH_Structure has a type constraint which states that T must be a type of IGH_Goo. So if you want to deal with a tree of breps, you have to use GH_Structure<GH_Brep>. However an alternative here is to use the DataTree<T> class which has no constraint on T and allows you to have a DataTree<Brep>.

Very few native components actually deal with these GH_XXXX types themselves, they are mostly just the way Grasshopper talks to itself.

Permalink Reply by David Birge on August 2, 2016 at 11:11am

Thanks so much for the prompt reply. Knowing these are wrapper classes is very helpful, and cuts short a ton of secondary questions. Is it right to assume Rhino DocObjects are wrapper classes as well, seeing they have a geometry and a set of attributes attached to that geometry? These are more intuitive to me.

The last issue I have then is knowing how to pull geometries from Rhino so that either:

(a) The reference is maintained and thus if the geometry in Rhino is changed, it will be changed in GH as well. It seems using the DocObject's GUID is the proper (only) way to do this? How do I maintain this if I'm passing geometry between components?

(b) The reference is severed immediately (either upon calling the geometry from RH into GH, or through a conversion) and thus the geometry becomes "naked" so to speak within GH? I would like to do this without having to manipulate the geometry, make a copy, etc., or pass it in and out of a component, which it seems sometimes does this for you. Instinctively I would imagine this is where i convert to a GH_Brep, or wrapper class, or, pull the geometry out of the DocObject wrapper class?

If it saves you time, David, feel free to point to other discussions. I searched, and didn't find anything with super clear answers however.

Lastly, I will try and write up a short explanation of all of this and add it to the common questions section. There doesn't appear to be anything there in this topic.

Permalink Reply by David Rutten on August 2, 2016 at 11:53am

Is it right to assume Rhino DocObjects are wrapper classes as well, seeing they have a geometry and a set of attributes attached to that geometry? These are more intuitive to me.

Yeah pretty much. The DocObjects add attributes and a bunch of drawing/picking caches to regular geometry without re-implementing said geometry.

You can use the GH_Convert class to perform almost all conversions between types known to Grasshopper. For example you can convert Rhino object ids to IGH_GeometricGoo instances using:

ObjRef objRef = new ObjRef(id);
A = GH_Convert.ObjRefToGeometry(objRef);

IGH_GeometricGoo goo = GH_Convert.ObjRefToGeometry(objRef);
if (!goo.IsGeometryLoaded)
goo.LoadGeometry(RhinoDocument);
goo.ReferenceID = Guid.Empty;
B = goo;

where A is a referenced GH_Brep and B has been dereferenced.

Permalink Reply by David Birge on August 3, 2016 at 3:03pm

Thanks so much.. these work great.

One last, last, last question (i hope)...

When I use DocObject.ObjRef.Geometry(objRef) , and then print the results I get something like:

<Rhino.Geometry.Brep object at 0x0000000000000031 [Rhino.Geometry.Brep]>

Is this now a reference to a Brep in memory? Or is it still referencing the RhinoDoc object? When I pass this geometry out of the Python component, it now says Closed Brep, so I assume the the former. Is there any reason not to use the DocOBject.ObjRef.Geometry function above, instead of the slightly longer code you wrote:

IGH_GeometricGoo goo = GH_Convert.ObjRefToGeometry(objRef);
if (!goo.IsGeometryLoaded)
goo.LoadGeometry(RhinoDocument);
goo.ReferenceID = Guid.Empty;
B = goo;

Thanks...

RSS