The Persistence of UserText

Replies to This Discussion

Permalink Reply by David Rutten on November 15, 2010 at 10:56pm

UserText should be copied when a piece of geometry is duplicated and it should remain unmolested when geometry is changed. Not all the types of geometry Grasshopper uses support usertext though (Lines, Circles, Point3d, Plane etc. don't)

I started writing a UserData mechanism for Grasshopper data (it's in there now actually, I'm just not using it yet), but ran into problems I don't know how to solve.

Imagine you use the Addition component on two numbers. Number A has usertext "Albert" while Number B has usertext "Bertrand". What usertext should the result of the addition have? "Albert", "Bertrand", "Albert;Bertrand", ""?

With transform components it's usually obvious enough how to copy the user data from left to right, but with most other components it's a problem.

Any ideas welcome.

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by Benjamin Golder on November 15, 2010 at 11:07pm

Wow. That's really interesting. Maybe I don't quite understand how it works, but I've been assuming that usertext refers to a list of key:value pairs that can be embedded into geometry. In the situation you're describing, are the two numbers from the usertext of something else (is each number a value stored under the keys of "Albert" and "Bertrand" respectively?), or are you saying that the numbers themselves have usertext key value pairs? Are "Albert" and "Bertrand" usertext keys or usertext values?

Permalink Reply by David Rutten on November 16, 2010 at 12:29am

I was simplifying. Yes, UserText is a key-value dictionary where both the key and the value are Strings. The UserData implementation I started writing for Grasshopper supported more data types and was stored as a hierarchical structure rather than a dictionary.

Of course if we actually look at key-value pairs, it becomes even more complex. Now we do not only have to decide which of the inputs seeds the output data, but what happens when the key-value pairs conflict.

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by Suryansh Chandra on November 16, 2010 at 5:21am

I'm still trying to think up possible uses of the UserString -- and the things that come to my mind are things like storing custom attributes (like flagging off stuff after a conditional check instead of making a separate boolean list), or maybe embedding layer information since Grasshopper discards it -- or any form of metadata that is outside the realms of describing the geometry.

So if one transforms/copies/rotates/moves the object, its easy to imagine what to do with the UserStrings. If one joins 2 curves/meshes/surfaces/breps into 1 -- it's still fairly intuitive if the userstrings just add up into a bigger list somewhat like the Merge function in GH. But it would be trickier if one object splits into many or say several curves with UserStrings are lofted to make a surface -- does the surface inherit any of the UserString stuff?

I'm just sounding off my thoughts on this stuff -- maybe I'm on a completely different tangent from what you guys are talking about.. But I do think it would be more logical if the addition of of UserTexts would lead to cocatenation in case of value types (points/vectors/numbers/colors) -- so addition would make "AlbertBertrand". But in the case of Geometries, the UserStrings just add up to the list, so it would be "Albert", "Bertrand". The logic would be similar to the fact that when you add 2 points, you get a new point and the original 2 points are completely lost. But if you join 2 curves, the new curve still has the 2 originals as its pieces.

Permalink Reply by Benjamin Golder on November 16, 2010 at 1:27pm

At the moment, having some rough way of maintaining limited forms of associated data would be really useful, especially for interoperability. I was imagining that having very little inheritance, and then allowing people to read, write, and edit key value pairs in some minimal way, would let me take attributes from GIS and maintain them all the way to Grasshopper outputs. That way Grasshopper could create geometry that could be later used to go back into GIS with that associated data.

With GIS operations, combining attribute tables is a task unto itself (for example when doing a spatial join), and appropriately there is a lot of functionality built into that process. The combination of two tables provides an opportunity to enter in custom calculations in order to arrive at the appropriate new values for each field, or even use calculations relating to specific spatial operations involving the two sets of geometry. A choice is offered concerning which fields should be used, and how those fields should be combined.

I see that there are tons of situations in which there would be no good default choice of how to deal with different interactions of UserData, but maybe there could be some clear distinction between operations that retain the data and operations that don't. If the UserData itself can be read, manipulated, and reattached, then the user can determine relationships on their own, possibly with a set of tools specific to editing UserData. This way the complicated questions about how sets of data should interact can be decided by users.

Permalink Reply by Steve Lewis on November 16, 2010 at 2:56pm

yes I have been desperately waiting for some means of inheriting usertext assigned to volatile objects but I think David Is stil very reluctant to give it the go ahead.............

Permalink Reply by to] on November 25, 2010 at 7:17am

Hi
to get on to this very interesting discussion
we have a components that write and read user string to/from meshes in our meshedit tools
we mainly use it for adding results from the ecotect values to the mesh (also which type of data it is).
But you can add also the centerpoints, vectors, etc. ....

Permalink Reply by Arend on May 25, 2011 at 3:12am

Is it very difficult to make it a key value system where the value can be any object? This paves to road for a lot of different implementations and types of metadata. The result for multiple objects perhaps can be a list.