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?
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:
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.
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.
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.
@jeff@brian@pascal this just happened to me today, and testToggleControlPointsToFront did not help me because that apparently only works on surfaces:
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…
)
