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
