More robust Named Selections

Hello,
Are Named Selections still actively developed?
Named Selections do not survive solid operations. If you compare them with how Breps with per face material or per face display color work, Named Selections seems to be much more fragile.

You can do all sort of booleans on Breps with per face display colors, and colors will stay where they sould stay, you can even split given face into two pieces, and color assigment will still be there.
Contrary, If you will add one face as a Named Selection and do some boolean union on Brep, then even if given face wasn’t affected in any way, you will lose this saved selection…

Use case:
Brep with some holes. You make a bunch of holes in a brep, and you add them to Named Selections, you make some more holes and you no longer have correctly working Named Selection you previously made.

1 Like

Hello - thanks, I see that on BooleanDifference and not on say RoundHole - I suspect this is because the Guid of the object changes in the first case and not in the second. @Trav - is that the case or am I making stuff up?

-Pascal

Yes, anything that causes the object to change its GUID will cause its named selection link to be lost.

Thanks,

I understand that there are some technical reasons.
For example Named Positions survive boolean operations, and GUID change doesn’t stop them from working.

I think Named Selections could offer much more functionality if they will survive GUID change. Is it something that can be implemented? Named Positions make me think that way.

Is this something I can realistically wish for?

I understand that it seems like it should be survivable more often than it is and hopefully we’ll be able to improve that survivability in the future.

2 Likes

@Trav
Some time has passed, is it something that we can expect in Rhino 8?
Would improvements in this area allow not breaking history with dimensions?
I think more robust dimensions history would save a lot of frustration.

No, the geometry core’s rules have not changed for v8.