In the Beta 8.0.23264.9003, 2023-09-21, there’s a bug with the User Text component or at least, its behaviour was changed compared to how it worked previously. If I reference an object from Rhino (e.g. a curve) and pass it through a curve param before feeding it into a User Text component, the User Text fails to recognise the curve’s key/ value pairs.
I am not sure whether there is more to this, because in the script that I built (which now malfunctions) passes content through for baking, but the baking component doesn’t update the curves, but instead puts them on a new Grasshopper layer (which it shouldn’t).
In fact, I what I suspected turns out to be true, User Text to User Text even drops values in a script of mine (can’t reproduce in a clean document as of now).
E: the curve/ point or surface passthrough issue is listed on Youtrack as enhancement, but it used to work this way for at least the past half year prior to the Beta. So in my eyes, it’s a regression.
So I understand, do you mean you could add User Text without a bake node being present? I’ve always needed a Bake Content node following the User Text node to have the User Text values of the objects actually get updated in Rhino. Otherwise the Key/Values live in the reference chain only.
EDIT: I just read your first post. Recently there were some casting errors like going from Model Point to Plane or Curve to Line not working.
It was corrected but perhaps what you are seeing is similar.
I almost exclusively pass all my input/outputs as “Data” so this issue with the Curves not carrying the User Text was unknown to me until you pointed it out.
I only use the geometry containers for curve/line/point/plane etc when I want to specifically cast/convert from my generic data to that new data type specifically.
Like if a component gets fussy and wants a vector I’ll cast a line to a vector first then plug it into the component. Or if I was just the point of a plane I’ll just throw it into point data container
I use the specific geometry params for in-and outputs of groups, that way, I can split a long script up into distinct modules. Each of these geometry containers is then labeled, so I know where my data resides if I need to reuse it elsewhere. I also colour code them for further clarity.
Point is, the User Text loses info on the geometry inside Grasshopper. And as a result, when I bake the geometry to modify User Text in Rhino, there are no key/value pairs and even the layer info is lost. As a result, I see a generic Grasshopper layer and I can’t filter its contents by User Text, nor operate on geometry any further.
This isn’t really a bug… It’s a feature I guess. Basically, you’re losing information because you’re casting a Rhino model object to a lower level geometry param. The Rhino model object contains all of the attributes and user text of that object. But the params like curve, point, etc. are just geometry representations and they know nothing of the actual attributes, etc. Does this make sense?
So, when you use the Query Model Objects component, you’re referencing actual Rhino objects into Grasshopper… as such, you retain all the attributes and user text at this step. However, when you pass the data into a surface parameter (for example) it’s extracting only the geometry and returns that…so you lose all of the other meta data. The reason why it looks like it’s working when you use a surface parameter as the starting point is because you’re referencing the surface directly from the model and so it’s still passing around the reference of the object… which still contains all the meta data.
You can kinda see what’s happening if you use the Model Object component to look at the Object output and the Geometry output. The data coming out of the Object output is the same as the input referenced surface and still contains all of the attributes/user text. However, the data coming out of the Geometry output is just the untrimmed surface and this doesn’t contain any metadata. This is what’s happening when you pass the model objects into the params… it’s only returning the base geometry.
For what it’s worth… this is how Grasshopper has always behaved. Core geometry params (like surface, curve, point, etc.) have never really stored any of the data beyond it’s geometry representation.
In re-reading this, I think I understand better now.
I do the same, breaking large definitions into “functions” and clusters.
I switched the input/outputs to always be a Model Object type inside the clusters as this will always let the meta data ride along. For any other geometry type such as just passing from one “function” to another I use the Data container as a labeled output on the first function and a labeled input (and wireless) on the second function.
So I great these data containers like parameters, setting them once in my script and then reusing them many times in other locations.
The exception is in the event that I don’t care about the meta data and only want a plane or something. Then I use the plane data type container and then the cluster input into that.
This allows you to “right click set” a plane or multiple planes directly on the cluster.
I use this method for all data types like booleans, inta, etc.
In the event I need the geometry of a model Object for “an older node” input I give it the G output of the MO component, then down stream pass the older nodes output into the G input of a new MO component with the O output of the original connecting to the O input of this new MO component.
This allows you to make geometrical modifications while passing the meta data along from the original MO prior to the modification.
Sorry, I think I haven’t been clear enough explaining myself.
I’ll try my best as I go over it based on your explanation. I’ve been using these components so much — and relied on this particular featureset that I ‘know’ this is how it worked, because my scripts don’t function at all anymore right now.
Yes, in which case, if I pass along the higher level “Content”, I always use the data param. This works as expected.
Yes, this does make sense, this is how I have been using them too actually.
The point is, that I used to be able to use the geometry params to get User Text attributes from the Rhino document. But that’s not possible now. The Keys from both User Text components used to be the same prior to the Beta in the example below:
Basically, when I filtered my geometry either through regular components or through the Filter content/ Group Content, I could pass them through a geometry param and then feed it into a User Text component to get the User Text associated with the geometries from the Rhino document.
Earlier the Meta data from Rhino was not lost if I passed through a geometry param as input for a User Text component is what I am saying.
See the example below, earlier both curve params would output Referenced Geometry. Now the Query Model Objects outputs the specific curve type and no longer a Referenced Curve type.
Hence why the User Text component does not pick up the geometry’s User Text metadata from Rhino anymore since the Beta.
I know this is the case, because I had to go about converting points using a Deconstruct Point > Construct point to get the actual point positions to bake as User Text, so I could monitor which points changed position after baking.
Exactly, when the geometry inside a geometry param was “Referenced [Geometry Type]”, it would preserve Rhino Metadata for User Text.
This is an important nuance that I had been heavily utilising in my scripts.
Yes, and I am not requesting that to change. I just hope that the old behaviour can be restored, because that was perfect the way it was — and also in-line with the way you now describe how it ought to work. So I am not actually requesting the feature that geometry params preserve Metadata, it’s actually nice to be able to filter geometry, add Keys/ Values in Grasshopper to aid filtering and to then get rid of it post-filtering with a geometry param prior to baking the result. For instance, for ‘looping’ scripts that read from Rhino > modify the Rhino geometry in Grasshopper > bake the result to Rhino > Read back in to Grasshopper, it was perfect the way it was.
We are going to clean the workflow up a bit to avoid confusion. The standard geometry param components behave differently depending on origination, for consistency we’ll need a Model Object Param and not mess with the original geometry params function.
Right, I could see that work. And that would make the workflow less context dependent. Looking forward to see the new components, so I can get back to my script.
:
