I figured out that there is something odd with the point selection by picking the control polygon between two control points. Sometimes, one of the two control points will not be selected, despite the mouse pointer being very close to it. That happens in situations where the control polygon is rendered behind the geometry of the surface. Selection via picking the control polygon works properly in Wireframe mode and Ghost mode, but fails to do so in any other viewport mode. Here is an example of that behaviour:
Also, you will notice in the video that the Status bar, if “Select object count” is shown, will not show the amount of selected control points. I think that it should give information about the selected sub-objects, as well to make it much more usable.
On a side note, another strange issue with selecting control points by clicking on the control polygon is that holding the Shift key to add more control points actually deselects already selected control points next to the picked control polygon line. That’s really annoying, because the Shift key is supposed to be used in relation to adding objects and sub-object to the selection, not removing from it. Here is an example:
Hi Bobi - I see by the hearts that others must be seeing this behavior as well - I set up what looks like your surface and do not, so far, see the behavior you describe… Does this happen if that surface is the only one in the scene? Is it at all consistent (i.e. different surfaces show this behavior) ?
Hi Pascal, that behaviour with inability to select two control points by clicking on the control polygon wire in-between also happens on many other untrimmed and trimmed curved surfaces, so it’s not an isolated case. I have experienced it since I use Rhino 7.
Hi Bobi - Isee - what I am wondering at the moment is whether there is any correlation to the complexity and extents of the scene - that is, does the same surface behave differently if it is the only one visible? It may be exactly the same, but if not there is a clue where to look and how to reproduce…
I tested it and several other surfaces in a separate scene and a few of them still produce that behaviour. Looks like the issue comes from the z-buffer since it only happens when a viewport with solid geometry is active. The selection via picking the control polygon works flawlessly only when Wireframe mode or Ghosted mode are active.
I’m uploading another 3d model where this particular bug results into a wrong selection. You will notice that the control point on the right side is being selected if clicking on the control polygon near the number 1 through the surface, despite that the left control point is much closer to the mouse pointer. Clicking on a control polygon should select both control points, but this is not the case here.
Despite that I use the latest Rhino 8.3 Evaluation, there are two bugs related to inability to select control points. I recorded a video to show them both:
Bug #1: Can’t pick two control points by clicking on their shared control polygon.
Bug #2: Can’t select control points or any object by window select while the mouse pointer is on top of a surface with shown control points. However, I can windows select if the mouse pointer is outside the surfaces with shown control points.
The so-called “safe selection” is done by holding down the Alt key before dragging by a window, which is a really inconvenient and counter-productive way to window select control points and objects. I propose to change that by allowing safe window selection without the need to preliminary hold the Alt key. This will also make the use if Rhino much easier for those who use a 3d mouse, because they will no longer be forced to reach to the keyboard each time they want to “safe select” control points. Could someone from “McNeel” explain to me why the safe selection by window dragging was made so bad and what’s the advantage of the current behaviour, which literally does nothing good and only adds inconvenience to the user? Not to mention that windows selection without holding the Alt key leads to extremely unwanted dragging of the object behind, that could cause damages to an important project and (if noticed too late) inability to return the moved object back to its original position.
I propose to eliminate the need to hold the Alt key and make the regular window selection safe by default.
Bug #3: There is also a third bug related to control point selection, which I reported a few years ago in another topic. It’s about the inability to chain select control points (after double-clicking on a control polygon) while there is another object behind, which obviously brings the Selection menu. Despite that the preview in the Selection menu detects the entire row of control points and marks those points with the preview colour, after choosing the control points from its list, the end result is that Rhino selects only those control points that are NOT adjacent to the picked control polygon. The original two points that share the control polygon where I click are NOT selected in this case. This behaviour is also counter-intuitive and forces the user to either switch to temporarily Wireframe display mode or first select one control point and run either the '_SelV or '_SelU commands (and trying to guess which is the proper directions meantime).
Actually, the issue is about the inability to select the control points via window selection, not the surface itself. Basic window selection works everywhere, except for when there is another surface near or behind the location of the mouse pointer. The latter either selects the object behind or evokes the Selection menu, making it impossible to do a windows selection. This is clearly a very intrusive bug which forces the user to (leave his or her 3d mouse and) hold the Alt key each time a point selection needs to be made, adding an unwanted layer of inconvenience. If you try this in other CAD programs or 3d mesh modeling programs, window selection works properly there. Only Rhino has that bug. Rhino must be smart enough to detect a dragging of the mouse pointer while the LMB is held, hence it should execute a window selection instead of picking an object with a single-click.
The desired behaviour is as follows:
a) Picking an object with the LMB immediately selects it; b) Pressing and holding the LMB and then dragging the mouse pointer immediately deselects the selected object behind and switches to window selection instead.
An alternative solution is to develop a Key toolbar, which is another proposal I added in the following topic. That way, users with 3d mouse will not be forced to reach to the keyboard for every control point selection or other commands that require pressing or holding the Tab, Ctrl, Alt ot Shift key.
I already attached the 3d model in my post above, under the “Bug #2” portion of the text.
