"Transform" component strips object metadata

Hello,

passing model objects through “transform” component removes object metadata (i.e.) layer.

1 Like

Hi Vojtech -

I think that is to be expected. You are only transforming the geometry, not the object. The new object is no longer a Rhino object and has no attributes until you add them in Grasshopper.
-wim

I did some testing,

Move, Scale and ScaleNU behaves the same as transform.
Change units (imho also a scale operation) preserves object data.

Why should geometry lose layer and such? If I wanted to change it for modified geo, I would do it myself.
This forces me to extract object info from original and pass it onto the modified geo.
It becomes cumbersome for complex modifications with sorting. The object info has to be passed along and undergo the same sorting operations as the geometry.

Is it a performace issue, less data to pass around? If so, why does C-units behave differently?

Thank you in advance for explanation.

1 Like

When geometry is transformed in any way in Grasshopper, it is actually a copy of the original. This is true with any of the Move components or Scale components. This is how a functional language like Grasshopper has to work.

Only the Geometry itself that is copied in these transform components so it is geometry that is output. So, at this point the attributes do need to be reattached. Many times this would be done much later in the process, perhaps after multiple transformations or components, as then only the geometry needs to be passed around.

With the Get/Set components, re-attaching the attributes is not too bad. Just run the original object into the Model Object component and then also the geometry that needs those attributes. Looks like this:

That will produce a new object that contains all the same attributes.

Internally we are looking to perhaps have the transform components carry the attributes thru the copy process. Part of the discussion is trying to determine if this would break anything else. But the process above should help in the mean time.

To expand a little on Scott’s answer… the primary reason that transform components strip out the metadata, is because the Geometry input parameter in the transform component is a Geometry Parameter type (not a Model Object Parameter type). This difference means that when a model object is passed into a geometry parameter, it only takes the raw geometry from that object (but none of the metadata). The transform component then modifies/transforms the geometry and outputs the modified geometry (again, this is a Geometry parameter not a Model Object parameter). We could consider replacing the Geometry input/output parameters with a Model Object parameter, but this could effect existing definitions.

This confused me for some time but having the possibility to just re-assign attributes is actually perfectly fine.

I haven’t delved too deeply yet into the ‘Model Object’ aspects of R8 as I’m still waiting for the dust to settle and the bug reports to taper off… But just because there is a logical explanation for why metadata is lost doesn’t mean to me that this is “perfectly fine”. Sounds like @Vojtech_Liska has a valid point, that moving, scaling or transforming geometry is no reason to lose its attributes.

I haven’t thought it all through… and can see that in some cases retaining attributes maybe doesn’t make sense (and could be excessive overhead degrading performance?). But many times it makes a lot of sense to me that attributes should not be lost.

I’ll know more when I use these new features but am not concerned at all that new R8 GH code might be affected by changes to what is still a work in progress.

The reason I hesitate to make change changes to existing components is because if we did modify the transform component(s) to work with model objects, here’s how the process would look. First, we would have to make the existing component OBSOLETE. Definitions that used this existing component would still load and work just fine, but there would be an “old” icon which appears over the existing icon. Next, we would make a new transform component which uses the newer Model Object parameter. We would provide a mechanism to upgrade existing transform components to this newer version if a user wanted to upgrade these components. And every time you add a new transform component, the inputs and outputs would uses the Model Object parameter.
The issue is that this change would break backwards compatibility. If a definition was saved in Rhino 8 and used the newer version of the Transform component (and likely all transform components would need to be modified including the scale, rotate, translate, mirror, etc) then the definition would fail if someone tried to open this in Rhino 7 (for example). This is much like the condition that happened recently with the Area/Volume components where I believe you were somewhat frustrated that we broke backward compatibility. Ultimately, we did backport that feature back to Rhino 7… however, we can not backport the transform components because that would mean also backporting the Model Object parameter and it’s data type which is very complex and would require a significant amount of work. It’s possible that we could try to add some feature to Rhino 7 which would look for these new components and instead use the older version of those components instead… but again, we’re pretty much done adding any code to Rhino 7, so that probably wouldn’t work either. So, you see it’s not as easy as simply swapping things out and calling it a done.

Backporting to R7 was not the best fix. New functionality should get new names, in that case and this one.

So you would prefer to have double the amount of Transform components with one set only working with Geometry and one set working with Model Objects (and Geometry)? That seems confusing and redundant.

Yes. It preserves backward compatibility unless new features are used.

Ok. Well, I think we would like to try to keep the number of components as small as possible given that the native set of components is already well into the many hundreds. Doing this sort of change for any new modification would cause many duplicates of components with slight changes which (to me) would be very confusing to users as to which one they should use. We’ve already gone down the path of using the “Upgrade Components” method for upgrading components that become obsolete and have a newer version and it’s worked fairly well to this point. I only bring all of this up to show everyone that there are a lot of things to consider when making an “upgrade”. As a rule, we generally try very hard not to mess with any existing components for this very reason… especially ones that have been around for a very long time and are used extensively in many user’s existing definitions.

Like Area in R8?

Correct. We probably made a mistake there in breaking backwards compatibility. I’d like to think we’re trying to learn from our mistakes :slight_smile:

@Joseph_Oster I wasn’t a fan of model objects losing attributes on components like transform either but after getting into it more I actually prefer it now.

The area component is a big funny as that’s the one I would have guessed as the least likely to change haha.

Think of it like deconstructing and constructing points, vectors, and planes. You take an original point, and can do all sorts of complicated logic on just part of it, and then stitch it back together into a new point with some modified and some new attributes and you now have a modified point but with model objects this is better as you can do this with ANY piece of it’s meta data at any step in the process, geometry, material, layer info, user keys, etc.

But I guess it’s all subjective with each of our preferences of course.

TLDR, I didn’t like it, now I do and wouldn’t have it any other way.

2 Likes