RHINOCOMMON; Can we have a UserString Property for Grasshopper RhinoCommon Object Types?

I understand we have the option now in GH0.7 of a UserData property for a grasshopper objectype such as GH_Point. Is it possible that Grasshopper/Rhinocommon can expose the userstring property? The problem with userdata appears ti be that every time an object is instantiated a new GUID key will be needed for assigning values to the user data. Often, it is easier if a commmon key string is used to identify data attached to multiple objects.

Replies to This Discussion

Permalink Reply by David Rutten on August 26, 2010 at 7:07am

Hi Duck,

I wrote a complete UserData implementation a while ago for Grasshopper data, but it's currently hidden as I have no idea how it's supposed to be used from within components.

Imagine you have UserData attached to a Mesh, then you move the mesh. I think everyone would agree that it's reasonable the userdata is inherited as well. However, this would involve the Move component to be aware of UserData and responsible for duplicating it.

Now imagine you make a Pipe around a curve. Should the Brep inherit UserData from the base curve? Should it inherit from the Radius input? Both? Neither?

What about data attached to numbers when you multiply/add them. Which input number gets to pass on it's userdata, or do they both contribute?

Once these issues have been solved I can start adding components for getting/setting userdata. But at present I don't even have an inkling about how this can be solved.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Steve Lewis on August 27, 2010 at 1:45am

Yes it is a tricky one. Really what I was hoping for was something that already exists for persistent rhino objects - the option to add a user string to a volatile grasshopper object.

I would only expect a user string to be attached to an object explicitely by a user and to only stay with the object in cases where a replication transformation is not used to modify the object. i.e. scaling,translation are ok as you stated. I wouldnt expect the data to be inherited from one object to the next unless explicitely allowed for in a custom component - like you mentioned, may be a component which takes two grasshopepr geometry inputs A and B and then allows B to copy a specified user string value based on a specified key defined as a third input of the component. It just seems a shame that at the moment it is not possible to interrogate custom user data/user string values on a grasshopper object. I guess its up to the user what they do with the user data through the use of a custom component. I was only seeing the user string attached to geometric grasshopper objects and not numbers/boolean/string grasshopper object types etc.

RSS