David, Damien - This is very interesting and way too in-depth for my knowledge. I guess to put it in laymans terms :
the components that extracts object(s) attributes would be very helpful: - name - color - material - layer name and another one to extract object data: - one for list of sections - one that will get section name and output 2 lists: entries and values thanks, Jarek On Feb 8, 10:54 pm, damien_alomar <[email protected]> wrote: > 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- Hide quoted text - > > - Show quoted text -
