Referenced Object Attributes

I am interested in retaining the Rhino Object Attributes when I reference geometry in a definition. There have been great definitions by Damien and others which custom bake applying attributes. Here is a reference to an thread on the old google group where David discusses a bit of the object referencing logic, and why attaining obj attributes was not possible:
http://groups.google.com/group/grasshopper3d/browse_thread/thread/5...

The SDK samples which grab the obj UUID, name, etc make sense to me, I I feel I understand a bit of what is needed, but as David said, this was a limitation of the GH release, and that in the next one, there would be the functionality to access this info. Has anyone given this a try with the latest version?

Replies to This Discussion

Permalink Reply by Damien Alomar on May 29, 2009 at 10:13am

I think we'll have to wait till David comes back for the definitive answer (unless Rajaa would know more), but I believe that this is a change that must be made to how the objects are passed to the scripting component. I guess at the moment, David has those GUIDs in the GH specific geometry classes that are used within standard components in the GH interface. He *could* have set up the scripting components to pass those GH classes, but instead opted for the standard OpenNurbs classes instead.

Therefore, the change that David has to make (I don't believe he's done it yet) is to switch the referenced objects over to the GH classes (so you would be passed a GHCurve instead of an OnCurve, or something like that). I'm not sure if this change is something that has to be done in place of the current data types or whether its in addition too, but I would imagine that its an "in place of" kind of change and that it would essentially make the scripts written in previous versions obsolete.

That's my interpretation from rereading David's post, so I guess at the moment there still aren't any options available for this. I would second the wish to get this in there though. Maybe a tag similar to the List tag could pass GH refs instead of OpenNurbs ones.

Permalink Reply by Luis Fraguada on May 29, 2009 at 10:17am

Ok, I did not know if "the next version" was the one we already had. Your suggestion for a tag on the input of the component would be a treat...though in this case, I wonder if its an easier said than done situation...
thx Damien

Permalink Reply by Damien Alomar on May 29, 2009 at 10:26am

Always a pleasure, Luis. I kinda had to scratch my head and reread that post a few times to get to what David was actually saying. I hope that it would be that easy to switch from a GH to a ON class, but for some reason I doubt it would be. I think that this begins to border on what's available as a scripting component and what is available as a custom developed component through a "GH SDK". Last I heard the intent to put out and SDK is there, its a matter of GH becoming less of a "moving target" and some documentation getting put together.

Permalink Reply by Giulio Piacentino on May 29, 2009 at 12:54pm

Hello Luis and Damien. Interesting topic here. Yes, knowing the attributes would be a good thing. There are a couple of occasions in which some objects are passed inheriting from the IEH_GeometricGoo interface. A quick test for exactely knowing what type of object one is dealing with is just filling a C# component with this line:

Print(x.GetType().ToString());

It will tell (in the "out" shoutbox) the underlying geometrical type. Mosty it is an On... object (no attributes), but sometimes, like for the twistedbox, it is already the famous EH_.. . I am sure the next version of GH will come with a lot of surprises (did you see the image sampler? Great), maybe also for the scripting components.

Permalink Reply by Damien Alomar on May 30, 2009 at 8:17am

I believe that David had to do this because there were not SDK counterparts to those objects. Therefore the only thing he could pass those as were their "original" EH classes.

Permalink Reply by Vicente Soler on May 29, 2009 at 1:31pm

Hi Fraguada,
While we wait for the object's uuid to be passed along with the geometry, one tacky solution is, just as we are using a custom script to bake components with attributes, we can use a custom script to reference geometry. This script will ask for polysurfaces to be referenced:

If x Then
Dim obj_list As New list(Of OnBrep)
Dim name_list As New List(Of String)

Dim go As New MRhinoGetObject()
go.SetCommandPrompt("Select Polysurfaces:")
go.SetGeometryFilter(IRhinoGetObject.GEOMETRY_TYPE_FILTER.polysrf_object)

Dim res As IRhinoGet.result = go.GetObjects(1, 0)
If (res = IRhinoGet.result.Object) Then
For i As Integer = 0 To go.ObjectCount() - 1
Dim objref As IRhinoObjRef = go.Object(i)
Dim brep As ionbrep = objref.brep
obj_list.Add(brep)
Dim obj As IRhinoObject = doc.LookupObject(objref.m_uuid)
name_list.Add(obj.Attributes().m_name)

Next
End If

a = obj_list
b = name_list
End If

It will output to 'a' the referenced polysurfaces and to 'b' the names of the polysurface objects. Input in 'x' a boolean switch. In this case the boolean switch has to be turned on all the time, and just toggle it off and on to select a new set of polysurfaces. The main down side of this method is that every time you rebuild the whole solution (press the play button) it will ask you to reference the breps (it won't ask you to reference the polysurfaces every time you modify a part of the definition), and everytime you modify the referenced polysurfaces, you have to reference them again... come to think of it, it's not a good solution at all...

Permalink Reply by Luis Fraguada on May 29, 2009 at 6:25pm

Buenas Vicente,
Yes, this is what I was looking to cook up from the SDK examples...I did not think through some of the downsides, but I very much appreciate you letting us know it works and how it works. I was trying to avoid that prompt, and I was thinking of other tacky things to go around the issue. Thanks for posting that, I'll give it a shot!

Permalink Reply by Vicente Soler on May 29, 2009 at 7:02pm

I can think of several ways to go around this problems but the solutions are even tackier than the method above.
For example, if you are referencing breps, lock down or hide the rest of breps in the document that you don't want to reference, then reference this breps to a brep component and input it to the script component, then change the script so that it selects all objects from the document and make the MRhinoGetObject to add the preselected breps and don't ask for any objects to be selected (similar to the code i posted in the old forum for running the _voronoi3d command).
Now every time you move one of the breps, the script will update and it will reference them again. I haven't tried it out but I'm guessing it will only update to geometric transformations (move, scale,etc.), i think if you change one of the attributes (name, color) it will not update.

Permalink Reply by Eric Anastas on May 29, 2009 at 6:52pm

I'm trying to do the same thing in one of my definitions. I thought there might be a way to take the ID from the OnObjects passed to my C# component and then find the MRhinoObjects in the document with the same ID. But when I run the code bellow "id" is always "00000000-0000-0000-0000-000000000000".

Rather then change the type of objects that are passed into the .NET GH components why not just make sure that the OnObject.ModelObjectID() method actually returns something. So if you need to work with the attributes or other complexities of the full MRhinoObject you can use the ID to find a corresponding MRhinoObject. But if you only need the geometry information you can work directly with the OnObject.

Eric

_________________________________

bool RunScript(System.Object Objects)
{
OnObject obj = (OnObject) Objects;
System.Guid id = obj.ModelObjectId();
MRhinoObject mRhinoObj = doc.LookupObject(id);

Print("id =" + id.ToString());

if(mRhinoObj == null)
{
Print("mRhinoObjB is Null");
}
}

Permalink Reply by Vicente Soler on May 29, 2009 at 7:16pm

Yes, that's exactly what we are waiting for. Here's a quote by David Rutten that you'll find in the thread linked at the opening post:

"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. "

But apparently this hasn't been added yet. In fact, if you right click on a brep component with a referenced polysurface and select 'manage brep collection', you'll see the object id right there, there's just no way of reading it from a .net component. Unless i'm missing something.

Permalink Reply by Eric Anastas on May 29, 2009 at 10:36pm

Humm, yeah that would be really useful. Guess we'll have to wait for the next version.

What if I set a custom UserString in an object in a Rhino. Will that UserString value be available in the OnObject passed to a .NET Component in Grasshopper?

Permalink Reply by Marc Syp on May 30, 2009 at 12:37pm

Really interesting discussion, much of which is over my head for now. I'm just curious... how do you imagine using the attribute information in a GH definition? For outputting component schedules for fabrication or something like that? Or something completely different?

Thanks,
Marc