Grasshopper

algorithmic modeling for Rhino

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?

Views: 3666

Replies to This Discussion

Personally, I see the benefit coming from being able to match properties from the input reference object to any object one would bake manually so that any geometry made in GH can get put back into the Rhino file in a more seamless and integrated way. Also, if there was something about the object that you wanted to work with (its name, its plot width, its line style, etc) in GH you could. At the moment, you're kinda in the dark with some of those things. I'd be very interested in what other people were intending to use this.
Along the same lines as Damien...many times I am doing some analysis through scripting or another program...many times objects will have attribute data, from color gradiation to custom set attributes. It would allow me to use this info without going into an excel sheet (which is how I sort it out now).
Hi Luis, the findID component on this page should help finding the ID and the object ref inside Rhino. It goes through the document and compares object types. If types are the same, objects are compared by their CRC. At this point the guid/ref is returned. Being this method based on CRC, objects that are exactly the same and exactly at the same position, orientation and scale will be surely considered the same. This is similar to the selDup command in Rhino. In this case, the component will return the first object that the enumerator will supply (from short testing, this should be the last object added to the document).

Horster

Another workaround may be selecting objects in Rhino and then getting them from GH:

            List<Rhino.DocObjects.RhinoObject> oblist =
                new List<Rhino.DocObjects.RhinoObject>(
                  RhinoDoc.ActiveDoc.Objects.GetSelectedObjects(false, false));

... and then possibly deselect them :

            if (desel) RhinoDoc.ActiveDoc.Objects.UnselectAll();

BTW, glad to hear that this limitation is going to go away in GH 2 ...  :)

Hmm, I'm not sure GH2 will have space for attributes along with geometry. There are several big logical problems with this. I'll probably provide better tools to find this data, but keeping attributes associated with geometry throughout a GH file requires every single component which operates on geometry to retain attributes. That is a responsibility I do not want to inflict on component developers.

--

David Rutten

david@mcneel.com

Tirol, Austria

Hi David,

will there be in GH2 a way to easily pick objects and get their ID's ?

Workarounds like Giulio's findID components will then no more be needed.

emilio

Probably. It's easy enough to extract all kinds of data if you have a referenced piece of geometry. You can already do this for IDs now by plugging the geometry into a GUID parameter.

--

David Rutten

david@mcneel.com

Tirol, Austria

Perfect !

The GUID parameter works like a charm.   :)

No need to change anything for GH2.

Thanks !

emilio

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service