Model Object looses properties after Move?

[ShynnSup]

Seems like performing a move on model objects makes them loose their properties. Is there a way to avoid this while still performing GH operations on them? Thank you.

[wim (Wim Dekeyser)]

Hi Shynn -

@ShynnSup

Seems like performing a move on model objects makes them loose their properties.

You are not moving a model object. You are moving (creating a copy) the geometry of a model object. Geometry doesn’t hold attributes, and you will need to reconnect the attributes from the original object.

-wim

[ShynnSup]

@wim

You are not moving a model object. You are moving (creating a copy) the geometry of a model object. Geometry doesn’t hold attributes, and you will need to reconnect the attributes from the original object.

Thanks Wim! Will do it like this next time.

I actually used the Model Object output… specifically to not use Geometry… Seems like connecting a model object to Move component converts it to geometry alone? Pretty obfuscated way to design things but at least it works, that’s good.

[Kyuubimode]

I’d agree it does feel a bit unintuitive. I would expect the model object to be transformed and not the geometry if I am connecting the object itself. Is there a reason behind this behaviour @wim ? Is it a limitation in Grasshopper or was this a conscious design decision?

[Japhy]

@Kyuubimode

Is it a limitation in Grasshopper or was this a conscious design decision?

Here is one of the WIP threads that discusses such things.

Rhino 8 Feature: GH1 Is Now More Than Just Geometry!

New Data Types Available in GH1 Have you ever been frustrated that you couldn’t bake geometry with custom attributes? What about display materials? Have you ever wanted to be able to use native Rhino materials in the Grasshopper display pipeline? How about importing files into Grasshopper - have you ever become discouraged when you try to import a CAD file and lose all of the basic metadata that is included with the geometry? The latest Rhino 8 WIP now has new data types and components which e…

[AndyPayne]

@ShynnSup

Seems like connecting a model object to Move component converts it to geometry alone

The reason for this happens because of the Move component, not the Model Object component. Notice that the input of the Move component is the G parameter (for geometry). This component was made very early on in the development of Grasshopper when we only had data types that represent the raw geometry (there were no model objects back then). So, when you connect the Model Object component (or it’s output) to the geometry input, it will extract the geometry from the model object and create a copy of that.

We could create a new Move component which would work for Model Objects, but if you used that component, then your definitions would no longer be backwards compatible. Plus, then you have two components for Move, Scale, Rotate, etc. Typically we avoid this by making the older version “obsolete” (and hidden) and only expose the newer one. But, again this would break any backwards compatibility.

[Kyuubimode]

I thought this was the case as well since the input output is geometry and not model object.
Regarding backwards compatibility though, how would it break older scripts if model objects are a new addition anyways? Shouldn’t the transform components just understand that when a model object is connected it should perform transformations on the geometry, and then re attach the attributes back to it? A few instances I can think of is-

1- The multiply component can be used for normal multiplication but it can also be used to multiple the amplitude of a vector. It realizes that when I attach a vector it has to take the amplitude, perform a multiplication and set the new amplitude to the vector.
2- The sift component and stream gate/filter seems to be designed for numerical inputs but also works with boolean inputs as it converts false to 0 and true to 1. This is very helpful when I dont want to use cull pattern and lose the tree branch structure.

Essentially just update the transform components to see what if its just raw geometry or model object attached geometry thats being fed in and give the appropriate output.

Ofcourse this is just theoretical, I am not a software engineer and I wouldn’t know if this is something extremely difficult to do/ will increase performance overhead of the transform components. The solution to re-attach the attributes manually is not a deal breaker, its something I can deal with for now.

[ShynnSup]

Agree with everything you said and I share the same thought process.

Also for Rhino 8 multiple standard components such as Area and Multiplication stopped being backward compatible so it’s kinda ironic to try to use that flag now and be so puristic about it.

[AndyPayne]

The Area component did change in Rhino 8, but we then backported that change to Rhino 7 so that it would be backwards compatible with that version. To my knowledge, nothing has changed with the Multiplication component.