Thanks for the great explanation. I guess to put it in laymans terms just to make sure I understand it, it boils down to the difference between the geometry living within Grasshopper and not having any specific connection to the Rhino document. Your explanation also explains why just based on the references I was looking at the code should have worked, but once I tried to access that MRhinoObject I got an "Reference not set to an instance of an object" error which probably relates back to that MRhinoObject never being created. Anyway...
If you think through it, its entirely logical that GH geometry doesn't have attributes, as they don't really have any need for them or way to specify/modify them. Now setting up the attributes of a baked object is something a little different, but thats also after the object is actually added to Rhino. Also, from your answer it seams as though there are could potentially be access to elements of the GH kernel through the scripting components. Am I reading to much into that or is it a possibility? If it is a possibility what would be there potential added functionality that would be made possible through the accessible parts of the GH kernel. Best, Damien On Feb 8, 2:24 pm, David Rutten <[email protected]> wrote: > Hi Damien, > > it's impossible to go from OnBrep to MRhinoBrepObject. An > MRhino****Object instance refers to a unique object inside a Rhino > document (ok, it *is* possible to have such an object all by itself, > but it's rare). An OnBrep on the other hand (or On3dPoint, OnPolyline, > OnNurbsCurve...) is just geometry. It has no conception of a 3dm file, > of the Rhino application or anything much else. > > When you pick an object in Rhino, you get a pointer to (or a proxy > for) an MRhino****Object. This proxy (usually in the form of an > MRhinoObjRef instance) contains both the geometry *and* the attributes > *and* often the circumstances of selection (was it window-selected, > auto-selected, point picked etc.). Grasshopper cares not for > attributes and removes them promptly, retaining only the geometry. It > is a logical impossibility to regain the ID of an object if all you > have is the shape. You'd have to run through all the objects in the > current file to find one that looks similar and then hope it's not > duplicate. This would obviously take a lot of processor cycles and > code. > > Now, although grasshopper does not store attributes, it does keep a > place for object GUIDs, because once you have the ID, you can always > dive into Rhino, find the object with the matching GUID and retrieve > all data at leisure. In order to get to this ID, you'll need an > instance of a Grasshopper class that derives from the IEH_GeometricGoo > interface. Unfortunately -in light of the current discussion- I > replace all IEH_GeometricGoo instances with their OpenNURBS > counterparts prior to feeding them into a VB or C# scripting > component. I did this to make it easier for scripters to get down to > business with the geometry, without being confronted with all the > grasshopper wrappers that are involved. I probably should have allowed > for a way to get data into a Script component that circumvents all > casts, but there you have it... > > I'll have to write additional components that take in geometry and > extract (if they exist) GUIDs. This is not difficult in the slightest, > but it will have to wait until the next version. > > If you've been able to read all the way down to here, you've earned a > stiff drink. > > -- > David Rutten > [email protected] > Robert McNeel & Associates > > On Feb 8, 12:49 am, damien_alomar <[email protected]> wrote: > > > David, > > > I tried taking a look at this today and wound up suprisingly getting > > no where with it. I was specifically trying it with Breps though, but > > I'm not sure if the object attributes get retained when loaded into > > grasshopper. I'm not sure if it was my approach or not, but I had a > > hard time generating an MRhinoObject (or a MRhinoBrepObject) from the > > input values. I tried both as a generic object and a bRep, and > > neither one seamed to work. I'm wondering if there were any tricks to > > this that I was unaware of. It seams to me that the only way to get > > to object attributes is through MRhinoObject (or an class that > > inherits MRhinoObject), so how would you go about getting there from a > > OnBrep or something like that. > > > Also, would it be possible to have an OnObject option on the type > > list. It would be useful as a "catch all" hint for generic geometry. > > It seams to me that the Object option seams a little restrictive since > > it could be anything (i guess). Or could this be circumvented by just > > casting object to specific data types and seeing if the cast "sticks". > > > Thanks, > > Damien > > > On Feb 7, 3:05 pm, David Rutten <[email protected]> wrote: > > > > Jarek, > > > > due to current behaviour, if you import a Grasshopper point into a VB > > > component, only the actual coordinate is maintained. Any reference > > > data (i.e. the ID of the point object, or the ID of the curve object > > > and the parameter along the curve length etc. etc.) is stripped. > > > > The only way to get an ID is to actually type it into a String > > > parameter. In the attached network, I copy-pasted the entire _What > > > content into the String parameter 'Manage Collection' dialog and then > > > removed all the bogus lines. > > > >http://groups.google.com/group/grasshopper3d/web/retrieve_object_name... > > > > The current conversion logic does not automatically create IDs from > > > referenced geometry, nor does it create Geometry from IDs. This will > > > only be available in the next version. > > > > -- > > > David Rutten > > > [email protected] > > > Robert McNeel & Associates > > > > On Feb 7, 4:04 pm, Jarek <[email protected]> wrote: > > > > > Can anyone help me to make VB.NET component that would take a set of > > > > objects and output a set of strings that are the object names ? > > > > I am particulary looking for inputing set of Point Objects. > > > > ( I guess that is a WISH for ObjectName component at some point in > > > > future releases of GH...) > > > > > thanks
