Rhino 8 control point and control net selection

Hi all.

@stevebaer , I’m tagging you. :see_no_evil:

Very often while adjusting control points I work with short camera lens, literally inside my geometries…


Control point (grips) selection in Rhino 7 was not really good.
Sometime grips are slightly beneath the rendermesh and you are unable to select them!
You have to find tricks when you are going to adjust grips for 8 hours at time…

So, I often do this trick:

  • select a control net dashed line that is connected to the grip I want, this result in selecting 2 grips
  • deselect the extra grip

Sometime it is even useful to “walk” over the control net by selecting something else!
Imagine A-B-C grips:
I want to select grip A. But it is not visible or Rhino won’t let me pick it.
Not even any control net line from A is visible! Then…
I select control net BC , now any control net line from B is visible!
I select AB control line > A is selected!
Deselect B and C.

If some grip is selected, its neighbor control net lines and grips are more selectable!
Also I can snap on selected grips, even if behind many other geometries. (tricky! strange!.. but useful to workaround Rhino shortcomings… hope to not lose this “feature” until everything else is much more mature…)

Many sort of similar tricks ^ are needed.
Control point and control polygon selection and handling is a mess!
I can work not-too-slow , but it require doing backflips and many clicks!
On Rhino 7.


Often it happens that:

  • I can’t select a clearly visible object
  • I un-wantedly select an object that is completely behind something else

Please. Selection should follow 1:1 what we see on screen. Anything different will always be wrong.


Rhino 8:
everything feels a bit worse! :cold_sweat:

(I cannot share this model, but I’m 100% sure it is not related to a specific geometry, happens anytime and easily.)

Se how everything… is cumbersome.
After turning on curvature analysis, i can see where completely hidden and far control net lines are, but I can select some, and other not. Totally arbitrary, random.
The problem is there even without analysis active.

I tend to use “vanilla” setup in my Rhino workplaces, few customizations. My Rhino 7 have almost none.
Rhino 8 is behaving differently. “Problematicly” different!
Selecting grips and/or control polygon is harder than in 7. And even 7 wasn’t good.
What’s going on?
There is some default setting active different from 7 about this?
Which setting could I play with to try to make the situation better?


I hope someone at McNeel can understand my situation.
Me going 3d mouse, going inside complex subds, etc … I can’t imagine alternative workflows…


PS Note that, there is still that extremely bothering problem of having the whole control net and grips 100% visible and in front of everything if an analysis mode is active… please fix it :sob:

PS2 There is a toggle to turn off the automatic disabled selection filter when someone “miss” a selection some time in a row? I hate that feature!

PS3 3dconnexion jump to the last camera position randomly… I didn’t manage to recreate the problem but occurs every … OFTEN… OMG (8 “feature” …not in 7)

PS4 would It help to recreate a specific file with saved views, to “point” at specific mis-behaviour about this selecting thing? Or it is system-dependent? Maybe any difference in viewport size change results… i don’t know…

1 Like

Hi Riccardo - if you can take the time to do this it would be very helpful.

-Pascal

1 Like

Ok then.
2 simple cases here:
control net grips selection bugs.3dm (864.2 KB)

  • Open file
  • perspective maximized
  • shaded
  • SubD visualization flat/smooth set to Smooth
  • Named Views, make active the one saved
  • turn on control points of the SubD object
  • disable SubD from selection filtering

Now, get ready with a swap Hidden/Visible command.
There are 2 spheres hidden.

Try to click/select the SubD control net by clicking where the spheres are.

Spheres are named with the problem in that location.

(please tell me if it make sense)

If you can replicate those 2 cases then I might make a more complex file with more cases…

Hi Riccardo - - thank you. So this control polygon cannot be selected by clicking:
image

Correct? I see that.
If I delete most of the SubD
image

selection from that view works. Which suggests its a depth-testing thing, possibly.

The second sphere’s control polygon is definitely occluded by the subD however - that seems correct behavior, not to select it…?

(Unfortunately, testToggleControlPointsToFront does not work on SubD…)

-Pascal

1 Like

If i click in the center of that sphere, i CAN select the occluded control polygon.

Make sense, since I work inside an object, half of the object is in front of me, half is behind me.

To micro-manage grips, setting fisheye camera and going inside (easy with 3d mouse) is a perfect solution… IF stuff works.

Working from outside? No idea how.

I’m an ant sculpting an anthill.

I’ll get this on the pile so a larger brain can have a look. Thanks.
RH-80725 Selection - control polygon visibility
I also see that if the named view widget is displayed, osnaps fail in that view…

-Pascal

3 Likes

By the way, just now:

It happens I can’t select a control net dashed line (that is fully visible) even when I’m working with the camera from outside the object…

Edit:
@pascal see attached again:
control net grips selection bugs.3dm (751.9 KB)
new named view “New unselectable”
Use the hidden red sphere as location, I can’t select that control net dashed line, even tough I’m definitively outside from the object (mostly) and the line is fully visible.


Can’t select this ^


Each grip and control net lines are like “flickering” … any different camera position might “flip” the selectable/unselectable state, regardless of if it being visible or not (i’m exaggerating here) … 1 in 10 selection attempt fails or select something completely unrelated, hidden, far away.
I’m inside a 500x500x500mm subd, trying to pick a grip, and with my click I end up selecting a completely hidden mesh/brep/curve that is 2000mm away…

Hi Riccardo - I see this as well - same problem, no doubt, I’ll add this example. Interesting that a double-click does select the ring though. So the first click is not completely lost. That is also true in the first example file.

-Pascal

1 Like

Interesting indeed. There is hope! :sweat_smile:


What about:

Already reported stuff.
But I cannot “afford” to stop hammering those. Rhino “number” goes up but some stuff stay there…


I know each and every bug should have its own thread.
I can’t easily find where those were already reported, sorry.
Today is the n-th time I tried Rhino 8 and decided to report anything I’ve found.
5 minutes in Rhino 8 > some hours making reports, example files, etc…
Should i charge my boss those hours as normal work because they count as “future investment”?
I want to think that way. Time spent now is a more smooth workflow tomorrow.
But tomorrow is called “8”? “9”? “10”?

:upside_down_face:


Thanks for the support.

1 Like

RH-80725 is fixed in Rhino 8 Service Release 5

1 Like

Thank you!
I can confirm, current service release candidate have control net selection much more reliable on what we can see.


Let’s strike while the iron is hot.

… then, there is the opposite problem: the positive selection of what is not visible or occluded.
Mikko on youtrack says “there’s no occlusion culling”.
Ok. I’m not sure it is better to have selection prevented, culled, for not visible control net elements.
For sure I’d like to try it.
Most of the times I select an occluded object is by mistake!
How could I possibly volontaurly select something I cannot see?
(apart from selecting/snapping to something already selected, I can “chain” up using the yellowed control net lines, that is useful…)

But

this is wrong:
control net selection bug
double click to select a loop of grips can result in the selection of a different, occluded, loop, if the click point is “unlucky” and near the visual intersection of 2 unrelated control net lines…
It’s tricky because the first click correctly select the visible control net line, but the second click loop-select a totally different loop.

(I’m clicking near the same control net line of my last shared file + named view, red sphere)

btw this is easily repeatable:

  • select all control net grips
  • visually rotate the camera until 2 unrelated loops intersect on screen (first loop visible near intersection, the second not)
  • deselect all
  • try to double-click select the visible loop near the on-screen intersection
  • with few attempts you can loop-select the not-visible loop (toghether with a single line of the visible one)

At first attempt:
control net selection bug 2
Imagine this ^ but that happens un-wantedly!
Imagine this ^ but on heavy complex SubDs: you fail selection most of the times.
… that’s why I work with camera from inside the objects…

… culling selection of occluded stuff would be cool.

2 Likes

Another situation:
situations like this also happens:
control net grips selection bug 2.3dm (126.3 KB)
Grip apparently visible: (making me go crazy)


While actually is not visible:

Once again because of this bug:

We can’t select or snap-to something that is displayed on screen.


This. but also the last bug on my previous post occurs often and breaks the workflow.


Raw idea I talked before, but with pictures now:

Let users see and snap-to only to control-net grips when their analogue “surface point” is visible.

Example:
Camera and visibility, blue.
Grips, red. With circle around = visible, selectable, snap-able
Surface points, black.



see how in this second case we would let users properly interact and work with grips of a concave zone, without the need to either go inside with the camera or costantly switch in-out smooth mode.
(But this apply to surfaces too, where there is no smooth mode…)

(PS the “trick” about the, IF control net dashed-lines are “yellowed”, clicking on them is always possible. This is always useful. As like as having selected grips visible also when occluded. It’s useful)


I hope there is someone in McNeel that is using SubD intensively that can understand my situation :face_with_head_bandage:

2 Likes

Did anyone read my past posts? ^

Is it useful if I report this extremely common situation being SO bad… ?
Is the problem known/understood? Is someone working on it?
Are posts like this meaningful? Do I have to continue reporting?
(aka “do someone care?” :cry: )


None of those circled grips can be selected:


selection grip bug.3dm (681.0 KB)


This is a clash of many “minor” problems summed up into a BIG bothering problem, that last 8 hours straight , each day, all month. :face_with_symbols_over_mouth:

Usually…
Shaded:

  • grips are correctly visible/selectable (sort of)
  • control net dashed lines are selectable even while not visible! Double-click control net might result in random hidden loop selecting after first click on visible line (reported ^ )

Analysis mode:

  • Grips are visible when they shouldn’t , but still unselectable!!!
  • control net dashed lines are visible when they shouldn’t, but still selectable (wtf?) (and this is sort of handy, while this problem persist)

Is anyone working on this?

micro-managing grips (or “Surfacing” or whatever we can call it if with SubDs)
+
some analysis tool like curvature/draft/zebra

=

total mess!

Please!

A solution.

2 Likes