How to see control-points/polygons properly when surface modelling?

I have trouble to see what I am doing. this has been an issue for me since the introduction of GL shading in Rhino (3), and I am wondering if there is a cure for it by now:

can the control-points and the -polygon always be drawn in front of the surface they belong to?

I don’t seem to find a way…
I have this:


but I need this:

thnx,
Daniel

edit*

just to clarify:

when doing this kind of precise freestyle surfacing, it is essential to get solid, reliable, easy to read visual feedback from the application. All the lines of the control polygon and the points need to bee present, as they create an image that is the reference for deciding where to introduce further change:

yes I can work around it, by isolating and using x-ray or use transparent backfaces… but only if all other geometry is hidden in the scene, otherwise it becomes a mess again. I hope you can add to option to draw the control points/polygon in front of the surface it derives from!

excuse me, but I have to bump this once again, as I am again currently in a situation where i is very difficult to work with the current possibilities of control point display.

I wish you could add/restore the way they where displayed in Rhino V2, where control Points where simply visible trough shaded surfaces.

It is very straining to look for and select CPs in situations like this:

(I have asked for this 5 years ago already…

so I am a bit desperate by now :grimacing: )

thanks for listening,
Daniel

Hi Daniel - there is a bug report from ages and ages ago -

https://mcneel.myjetbrains.com/youtrack/issue/RH-26022

This, for some reason is marked ‘obsolete’ @jeff - is that correct, or a mistake, can you tell?

-Pascal

Hi Pascal,

thank you for digging this out. much appreciated!

just for the record once again, that is what I mean kind of “bring to front” for CPs and the CP polygon:

Hi Daniel - if you turn on say Zebra, in V6, and have points on, does that do what you want? Just checking the behavior here, not offering a solution. Jeff thinks he can add a toggle for global ‘points in front’ he just wants to be sure to get the right results.

related - https://mcneel.myjetbrains.com/youtrack/issue/RH-41407

-Pascal

yes, that is it.

1 Like

@dk2079

If you pick up the current 6.20 release candidate, you’ll be able to use the test command testToggleControlPointsToFront to toggle the behavior you want On and Off…

I would just stick it on a button somewhere, and/or make an alias for it.

Thanks,
-Jeff

3 Likes

@jeff
Not working in Version 6 SR20 (6.20.19295.13421, 10/22/2019) ?

Hi Fred - it is in our latest 6.20 here -

Build date = 10/25/2019 12:00:00 AM
Version = 6.20.19298.2331

Next week, I guess…

-Pascal

1 Like

Thanks Pascal.

Sorry, by “current” I really meant “THE latest build of 6.20” … As Pascal mentioned, this will be available next Tuesday… If you absolutely need it right now, I can provide a link to the installer.

-J

1 Like

@jeff
:beers:

thanks for the quick fix Jeff.
it will be very helpful!

I will give the build a try.

cheers
Daniel

RH-26022 is fixed in the latest Service Release Candidate

Any ETA for when this will become a proper Display Mode checkbox (and perhaps also per object override setting in the properties panel)?

@jeff @brian @pascal this just happened to me today, and testToggleControlPointsToFront did not help me because that apparently only works on surfaces:

controlpointsfront2

But besides that test command, this really isn’t very nice behavior from Rhino, imo… (especially since I had selection filter set to to only accept control points!)

Yes, I know I can switch to wireframe temporarily and move the points so they poke through, but again, there’s already so many wasted clicks in Rhino, so I’ll keep pointing out these issues.

EDIT: Ok… I’m going to be that guy again and post, a best of both worlds solution…

Hi. I agree here too. BringtoFront only goes so far.

That issue with the selection filter isn’t a nice one too. SO yeah, +1 from me.