I’m making a plugin for a customer that need to handle wood pieces.
Wood pieces will likely be simple breps, and the “meta data” to store will be something simple as material, id, order… but also some tricky information like the “orientation” of the wood grain, the wood fibers.
Let’s say we have a wood panel, the side panel of a forniture piece, xyz 2x20x100 cm.
The wood grain direction set by the client will be, for this case, aligned to the longest side, vertical, a vector 0,0,1.
Now, if the client/user rotate the panel and make it flat (xyz 100x20x2 cm), the fiber alignment would need to rotate too, to a final vector of 1,0,0.
How to achieve so?
Storing the vector as user data, or user attribute text is not good, as that information would not update if a rotation happens.
Would the inner sub-object structure of the brep be reliable enough?
Maybe using the UV directions of a surface inside the brep will do?
Would that information survive some solid operations applied to the brep? (like making a hole or filletting the panel)
I am aware of a similar problem in the textiles / garment industry where the “grain” of the material corresponds to the direction of the weave of the material.
In that industry the standard solution is to provide a short line within every part / garment which is called the grain line. This is placed in a separate layer - canonically a layer named “7”. The line runs parallel to the grain of the material.
Sure its not as neat as hiding the information within Rhino Objects but it is clear and clean and easily modified (and hidden by hiding the layer) and it allows interchange between different CAD programs and its worked for decades.
Yes, that would be a solution. We already thought about that. That or an hatch…
My customer currently does something similar, but it’s tricky to turn it on and off (because they doesn’t want to see additional lines in the layouts) sometime an hidden object is lost or not transformed properly… tricky.
That line should be grouped with the starting geometry…
Storing a Vector inside the Object relative to the ObjectFrame might be a good way to go, then rotations aren’t an issue. (Disclaimer : I haven’t used the ObjectFrame much myself)
There is some documentation about this ObjectFrame?
I made a quick test, and the objectframe plane would reset/change if the starting geometry is changed (like a small hole or a fillet/chamfer)…
How/when ObjectFrame can be used?
Might be interesting but seems unusable for my case…
Ah that’s a shame. You could of course store a Vector inside and subscribe the OnBeforeTransform event and update it. Undo is a bit trickier, but possible.
UserData is viable way to store this information. Assuming your plugin is in C# then your UserData class needs to override the UserData.Transform function. Then when that is called you simply transform your saved vector.
Thanks.
I’m used to code c# and debug it fast within grasshopper, very handy. (that’s why I really push c# components on GH).
I can’t test quickly UserData as it works only if the class is from a plugin.
Would be interesting if in future this can made be possible.
but if the document is opened in a installation of rhino, that does not have the plugin installed, this will mess up the Data.
Of course there is a workaround:
store some plugin-data in the file,
on each save / document close → transfer the breps to this plug-in data, on each file open read it out and populate it to the document again… a lot of work.
I am looking forward to custom objects being more powerful exposed to rhinocommon. (and maybe also serve as foundation for parametric blocks )
What happens if my cliean open and save a .3dm file in a Rhino installation that doesn’t have the plugin installed?
Does the event .Transform trigger?
Is the information at least kept or is the userdata actually lost altogether?