(Wish) Highlight CVs / control Polygon

Serengeti (Rhino WIP)
1

Screenshot 2025-06-11 at 14.18.16
Screenshot 2025-06-11 at 14.18.16530×584 61.8 KB

let s say i have a few curves on top of each other, that have different CV-structure,
it would be nice to have not only the curve be highlighted in the selection-menu, but also the CVs - to pick the correct crv.

@Rhino_Bulgaria and @davidcockey will for sure love this feature also ? right ?

in the sample the curves are named.
but in 99% this is not the case.
(and it is a pity, that commands do not add there parenthood to the name as an option:
MyNiceCurve → _rebuild → MyNiceCurve_rebuild )

thanks - kind regards -tom

5 Likes
2

I assume the request if for the control points and net to be highlighted as well as the curve when a curve is selected; but only if the control points and net are displayed.

I would also apply this to surfaces.

2 Likes
3

There is another issue in the selection menu. Let’s say I have 3 surfaces on top of each other (surface A, surface B and surface C). When I click on them, the pop-up selection menu lists them one above another and I pick the first one from the list. It’s surface B. However, I needed surface A, so I click again. This time, I pick the 2nd surface from the list. It’s surface B again. Then I repeat that and this time select the 3rd surface in the list. Damn, it’s surface B again! :smiley: Happened so many times… The selection menu is not consistent in the way it lists the objects that appear to share the same coordinates.

3 Likes
4

my workaround for this:
select the first surface - name it (properties)
select the next surface - name it if it is not the one i expect …
and so one…

but i see your point.
the selection menu could be sorted by the Guid of the Objects and the component index - this would allow a consistent sorting.

5

Yeah, at some point I ended up naming my surfaces or assigning a unique colour to them, but the issue is still valid, because the object arrangement in the list is random every time. :slight_smile:

For this reason, years ago I proposed implementing of “Time of last modification” property to every type of object, so that the user could get a better idea which object is newer and which is older. This could be especially useful in case that there are nearly duplicate surfaces with minor improvements on each iteration.

2 Likes
6

there is RuntimeSerialNumber
(as far is i understand it is per session, not stored in the document)
https://developer.rhino3d.com/api/rhinocommon/rhino.docobjects.rhinoobject/runtimeserialnumber

7

The idea is to get it as an universal value which is stored across different sessions and never disappears/changes unless the object is being modified.

8

Nice ideas here.
Up!

1 Like
9

Terribly tedious tinkering ; )

Alias names each object for what it is, appending a hash and incremental number. That not only facilitates the selection of congruent objects, but it also reminds you and potential co-workers what type of object it is they have selected (extrude#123, loft#456, edgesurface#789, line#012, blendcurve#345, etc.). Should be simple to implement in Rhino.

1 Like
10

there are cases where it would be nicer to have the last used / modification command of the objects.

curve#123#pulled
curve#124#projected
curve#125#rebuild

Rhino allows Multiple objects to have the same name - this can be quite a hassle.
so maybe we need a discussion about unique names first ?
or its an additional “human readable basic information unique id”

?

cheers - tom

11

Sure, but above all, Rhino should name objects by type and UID, like other software does since decades; then the devs may tackle adding snazzy options.

12

As I proposed multiple times before, a much needed feature would be to add time of last modification to each object, which will be handy to distinguish duplicate objects from each other. Or a copied object that was slightly modified and the user can’t tell which is the better version of the two.

1 Like