Persistent sub-object identifiers

Rhino Developer
, , ,
1

Hey everyone,

I would like to create the following setup for a box:

image
image1231×887 62.4 KB

In which a unique label or identifier can be tied to every face as such and have it persist through non-destructive transformations (rotation, translation or scaling).:
1 - Bottom; 2 - Top; 3->6 - Sides

A specific face could later be referenced and used through its identifiers in grasshopper or in a script.

In this case, face 3 will always be the “front” of the object, so a grasshopper script can move the box to the World Origin and align the “front” to the X axis, facing towards -Y. The steps of the operation could then be applied to other objects as well, maintaining their relative positions to the box.

Is such a thing possible in Rhino?

2

I’m looking for the same thing. My use case: I need to boolean several objects into one, and then do a remesh operation, with the resolution of the faces determined by the objects original ‘parent’ solids.

3

I think the most simpel but a bit brute force approach is to create a very rough mesh per face and use the inner vertices as sample points against the parents.
Note that also geometry can hold custom data / user strings but it is not clear / documented when this data survives or gets lost for example if you attach it to a surface that is part of a brep. @dale can you please clarify this / enlight us: will user data attached to a surface/ face of a breb survive boolean operations and / or transportations ?
Thanks

https://developer.rhino3d.com/api/rhinocommon/rhino.geometry.geometrybase/setuserstring#(string,string)

4

Thank you @Tom_P ! I did try setting userText (in gh) for brep faces, but that info is indeed lost as soon as you join them back into a solid.

I will have to stare at your mesh idea for a while longer before it sinks in :wink:

5

Did you try to attach it to the underlying surface?
https://developer.rhino3d.com/api/rhinocommon/rhino.geometry.brep/surfaces

EDIT:
@declan
i did a fast test and it looks like attaching user Data to the underlaying surfaces survives boolean operations and transformations.

6

Interesting. Are you accessing the srfs in Rhino or gh? Would you mind sharing your test?

Using vanilla gh:

image
image1583×715 68.5 KB

Using gh python to access Rhino.Geometry.Brep class:

image
image2032×956 133 KB

7

in a command in a rhinocommon / c# plugin - using above link / Rhinocommon function.

my guess - vanilla gh does not access user Strings attached to geometry (only to attributes).

8

Just doubling back here because I saw this Material workaround mentioned in another thread.