Possibe to Attach User String to Volatle Grassshopper Point

Replies to This Discussion

Permalink Reply by David Rutten on July 25, 2010 at 6:59am

Hi RubberDuck,

this is not possible. The proxies are only used inside the "Manage XXXX collection" window where they populate a property grid with data fields.

Grasshopper data itself does not at present support any kind of user string.

I don't think it would be very difficult to add this though, as it would be the same for all data types. But how would you like to attach/retrieve this data and what kind of data are you looking to store?

The GH_IO dll will allow me to quite easily add hierarchical dictionary style user-data chunks as byte-arrays, thus minimizing the memory overhead of such a mechanism.

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

Permalink Reply by Steve Lewis on July 25, 2010 at 1:31pm

Hi David

thanks for the reply. Thats a shame.

I was lookign at being able to attach and retrieve data in the same manner as it is done in the rhino api. For example, define a tag say "My Tag"

rmaMRhinoObject.Attributes.SetUserString("MyTag", TagValue)

Then to retrievenames of tags

rmaMRhinoPointObject.Point.GetUserStringKeys(strKeys)

Steve

Permalink Reply by David Rutten on July 25, 2010 at 2:10pm

Hi Steve,

that is a fairly insecure way to handle user data. Sure, it's simple enough for a manual interface, but this kind of open data structure allows for a high degree of (unintentional) screwing up.

I realize "MyTag" is only an example, but it's not hard to imagine that different people will actually pick the same name, and when that happens you're up sh*t creek without a paddle.

I've just started coding on this about an hour ago, and I've picked a mechanism that is much more akin to OpenNurbs User Data:

- Every instance of IGH_Goo has a single readonly property called UserData. When you call this property you'll get an instance of GH_UserData which provides access to all the user data stored on the IGH_Goo instance.

- GH_UserData can tell you whether an entry with a specific ID has been defined. So instead of "MyTag", you'd use New Guid("{B257BC07-5FF3-42a3-BCE7-15DE42038E3E}") which has practically zero chance of collision. So other people won't unintentionally overwrite your precious user data, in fact they can't even do it intentionally unless you tell them what your ID is.

- GH_UserData can also retrieve or create any number of entries, each with a unique ID. Every entry is hierarchical dictionary similar to what I use for (de)serialization in all of Grasshopper. Thus, each entry has any number of fields (named and even indexed if needed), and also any number of sub-entries. Fields can store a variety of data, not just Strings. You could store points, planes, numbers, byte-arrays, or colours. Hell, even images).

Now, this code isn't working yet, but I imagine the result to work something like this:

Dim ud As GH_UserData = gooinstance.UserData
Dim entry As GH_Chunk = ud.CreateEntry(New Guid("{B257BC07-5FF3-42a3-BCE7-15DE42038E3E}"))
entry.SetString("first_tag", value0)
entry.SetString("second_tag", value1)
entry.SetDouble("first_num", num0)
entry.SetDouble("second_num", num1)

This basically ensures that your UserData entry exists and it assigns 4 values (2 strings, 2 doubles) to it.

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

Permalink Reply by Steve Lewis on July 25, 2010 at 4:34pm

Hi David, i was out and about and couldnt reply from my iphone. (May be the guy who runs Ning woudl like to check this?) I sent you a perosnal message that appeared to go through to you, but yes, I think what you reccommend is really good and more powerful than what i was expecing. Will it be possible to carry the userdata assigned to a volatile point through a series of components in a solution in your suggested approach?

Permalink Reply by Steve Lewis on July 25, 2010 at 5:47pm

Ok I found a long winded way of doing this with the current set up that works in 0.6, create a volatile grasshopper object, bake the object to get a rhino object, capture the uuid of the baked rhino object, assign userstrings to the baked object, create a new volatile grasshopper object from pointing to a reference to the uuid of the baked object. When the new volatile grasshopper object is interrogated alter on, if it is a reference type, point to the referenced baked object and retrieve the user strings. Hmmm, is there an easier way? Is there a problem in doing it this way?

Permalink Reply by David Rutten on July 26, 2010 at 2:43am

Well that's the tricky bit. User Data is assigned to a single instance of data, but when that data disappears into a Component, it's not obvious what happens to it. Obviously a Move operation should aim to maintain all user data (user data on the input geometry that is, not the translation vector), but in the case of a SumSurface, should data from one or both curves be copied onto the output surface? What if you attach userdata to a number and then use Addition?

Also, it is now up to the component to make sure that userdata is migrated from input to output. I don't know yet how to make this easy enough.

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

Permalink Reply by Steve Lewis on July 26, 2010 at 2:18pm

Yeah, i can see that this could potentially be a real head ache.

Yes I found my approch doesn't work 100%. If a grasshopper object such as a point is a "reference type" object - i.e. references a baked rhino object with a uuid - as soon as i take it into a component the point comes out as a non referenced type and the associaiton, UUID, is broken to the original baked rhino object. This happened for a simple translation action using the move component - i specified a vector and moved all referenced points, output points were no longer reference types

For addition, if you use your idea of a uuid for a user string will it matter if you use addition as the two curves will have differnet uuids for the user string. The user could iterate through the user string collection on the created object to decide on which one to use. I guess the order of the user strings on the additive object is imprtant i.e. if A + B = C, then theorder of the user strings on C should be A, B

Some thoughts about how to maintian this.

1. If a grasshopper object is a reference type - the porperty IsReference can be used - then a new instance of a grasshoper object derived from any geometry that is a reference object has the option of copying that user string.

2. May be you can specify a global option as to whether to maintain inputted reference geometry user strings in components? May be a local option when right clickign on a components inputs where you can specify maintain input reference user strings

3. Restrict copying of reference user strings to certain componens where teh order and number of input parameetrs is unaltered when outputting - as you said, this should be the case for translation, scaling operations.

Not sure what the answer is, Im sure if you dont know the answer then nobody will know!!

Steve

Permalink Reply by David Rutten on July 29, 2010 at 8:39am

Steve,

I don't know how to handle these cases yet. When geometry is referenced, it basically gets nuked and reloaded whenever I suspect it might have gone stale. Thus, it is not possible to move a geometry and have it retain it's reference, as the translation is liable to get undone at any moment.

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