Snap priority

[Anonymous]

When one snap is essentially a specific element of another, the more specific should take precedence.

For example, when both endpoint and edge snaps are turned on, endpoint should take precedence over edge when hovering near an endpoint.

Since an endpoint is essentially a specific part of an edge, wherever there is an end, there is an edge that max tries to snap to, and since the edge is infinitely larger, you're lucky to find the endpoint. You can hover off, but close to, the object so the very end is closest to the mouse and is found, but then since you're not hovering on the object the move tool doesn't even work, which is half of the reason for using snaps in the first place.

Every time I want to snap to an end, I have to turn off my edge snap so it won't interfere, which gets frustrating very quickly. No other 3d software I've used has this problem.

A fix would be easy and save so much frustration.

[michael_spaw]

Good Idea.

[MartinBeh]

I'd like to propose an alternative solution to the underlying problem of conflicting snaps: The ability to specify start and end snap type independently. Right now, we have to have to turn on all possible snaps, then start our operation and use the Alt-S snap override command to cycle between those (while keeping the Snap dialog open to see what cycle we're in), while holding down the mouse button. Very clunky. My suggestion: Make better use of the Working Pivot. (WP) We need a hotkey to quickly enter WP Edit mode, then we snap the WP to our source point, turn of WP Edit mode and use a different snap type to define the snap target.