I know you probably want examples illustrating this, but it is a little hectic right now so I will have to owe you, but I’m finding the more picky OSnaps a bit hard to deal with. What I am seeing most often is if I have extracted a isocurve, or placed a point on a surface, I often times can’t get a snap on that geometry unless I flip the camera around to the other side of the surface [1]. The other annoyance is that if I am in a display mode that uses render material, and I have an object with a material applied that is partially transparent, I can’t get OSnaps through that object, even though I can see the geometry behind it. If I can see it, I would like to be able to snap to it. This should also apply to objects and curves who’s highlighting is showing through objects. Even though that highlighted guy is behind other objects, because it is highlighted I can see it and often want to snap to it.
Thanks,
Sam
[1] - It appears this happens when I am trying to get an OSnap on on object that is on a surface when looking at the backside of that surface.
EDIT - I should say that I do very much like the idea that I am no longer OSnapping to a bunch of junk way off in the distance that I can’t see, so I am not at all saying please bring back the old system, but just a little more leeway for the new OSnap behavior would be nice.
Here is a file which I think illustrates what I’m seeing. There are three named views, each with an example, just be sure to be in a display mode that uses render material (for the issue where I can see the thing I want to snap to because the material is somewhat transparent). Let me know if you have any questions.
The one related to material transparency in a rendered viewport is now fixed.
Making the visibility testing pay attention to object being selected will be very hard, but I’ll try to get it done. Right now the low level snapping code has no knowledge of what is being snapped to, and if any part of it is highlighted.
The one about wire behind a coarse mesh can only be fine tuned, but I don’t think it will ever be perfect. Technically the wire is clearly behind the render mesh, as can be seen in the viewport too, so if I force this one case to work, you will then be able to snap to wires clearly behind the mesh in all other cases too. Using denser mesh settings like the default “Jagged & faster” should help.
Here is another example where I would not classify the wire as being unreasonably behind the display mesh but I can’t get a near snap on the majority of the curve. I would say if cases like these (or my first example) don’t work, where the wire is a result of an extract isocurve or intersect and therefore by at least the user’s standards not behind the surface, please include an option to use the old OSnap behavior.
This one should work better in the next build. I increased the amount the osnap location is offset towards the camera before testing, and it makes osnap snap to things that are just behind shaded areas.
There is no osnap visibility testing in ghosted or wireframe view, so there’s always a way to osnap to things you cannot see in opaque shaded views.
I am having some issues with clipping planes and the new OSnaps. In the attached, try and get a near or mid snap on the lower edge of the box which is being clipped. Over here, I can’t get an end snap on one side either. I haven’t been able to find a reason or pattern as to why some edges work and some don’t, but this example seems to reflect the failure rate of what I’ve been experiencing, where many times it works, but there are a few edges that prove problematic. Changing the detail to a non-rendered mode makes it possible, but it would be nice if it worked as is.
In the attached pictures, I have a box that is inside a pipe (cylinder with wall thickness).
The pipe is frozen but no part of the box can be snapped to (first picture) unless the view is such that that part of the box would be visible were the pipe not to be frozen.
The same thing happens when a clipping plane is active: even though you can see all of the box, you cannot snap to it unless it would have been visible also if there hadn’t been an active clipping plane.
I have to switch to wireframe all of the time to be able to get things to snap.
These should work better in near future WIP. I made osnap visibility testing pay attention to locked objects being drawn ghosted or behind normal objects, and see-through clipping planes.
I’ve now installed 2014-11-18 and see that the case where the pipe is frozen is sloved; the box can be snapped to.
But the problem remains when using a Clipping Plane. See attached file. box_in_pipe-snapping v6.3dm (328.8 KB)
Are you talking about a shaded view with “Show Fills” enabled for clipping planes? I hadn’t done anything to that yet, because the osnap code has absolutely no knowledge of where those fills are.
For the next build I’ll make the visibility testing always obey the clipping planes. That should make it possible to snap to the box inside the tube, but also makes it possible to snap to the parts that are behind the clipping plane fills.
Not sure I’m with you on this one.
Would that mean that you can snap to the corner that is on the back side of the box - represented by the point in the following image?
That would not be like normal (non-clipping) behavior and therefore counter-intuitive if you ask me.
First time in a while that I’ve had to make a drawing in V6, and I am still running into OSnap problems when in Layout space. I’ve uploaded a file which illustrates this to rhino3d.com/upload.
Hi Sam, I’m afraid I don’t see anything wrong in that file. Osnaps seem to be working just fine, in both layout and model space. Since nothing is shaded if there is a problem it’s not related to osnap visibility testing.
Which part are you trying to snap to with which osnap?
