Change Details

Blender does not differentiate between tools for snapping, while this is elegant and reduces complexity on the user input - it also has a few drawbacks. Right now if the user wants to do angular snapping, one has to choose incremental snapping and rotate. Now as the modes do not differentiate between tools, incremental snapping is also set for translation as well. This is often not desired - as this activates gridsnapping on the move tool, where as the common use case would be vertex/face/edge snapping. Which is in turn a very rare use case for the rotation tool. Result is that one has to do that mode toggling all the time - or just ignore angular snapping and work with typing values directly. So we're stuck with a weird mix of grid snapping/angular snap/percent snap for all tools. To get some perspective on this topic I also did research the capabilities of 3ds max and maya as well, both don't support any snapping modes for rotate and scaling other than angular snap or step snapping. While I like the extended flexibility of blender here, it shouldnt get in the way of the most common use cases. -------------- This patch tries to improve this workflow without changing any existing behaviour. It introduces four new options for the incremental snapping section: {F5771853} //Disable Mode: Move | Rotate | Scale// These options allow to ignore the increment mode for these three tools. All the other tools like shrink/flatten etc. are not affected by this. //Override for Rotate & Scale// This option forces the snapping system to ignore all the other modes (except the incremental) on the rotate and scale tool For usage simplicity I merged these into one override. Now with these new options we can do the following: - Enable incremental & vertex snapping at the same time - Disable increment snapping on the move tool - Force incremental snapping on the rotate & scale tool We now have angular snapping which is not affected by vertex snapping, and vertex snapping which is not interruped by grid snapping. Open points from my side: - The implementation is rather simple, but I'm not entirely sure if its side effect free or catched every corner case. - Maybe naming of the options could also be improved. --------- Clever me searched rightclick-select pretty late and found this proposal: https://blender.community/c/rightclickselect/Vlcbbc/ This approach would separate move/rotaet/scale toolmodes per snapping mode - which would also solve the issue at hand, and doesnt interfere or change any existing behaviour. I think this would also work well - but Im not sure if it's necessary, as I think there aren't any widely used workflows which would benefit from this finer grained control? So, lets see what you guys think about this topic. Thanks for your time, and reading this.. lenghty description.

Blender does not differentiate between tools for snapping, while this is elegant and reduces complexity on the user input - it also has a few drawbacks. Right now if the user wants to do angular snapping, one has to choose incremental snapping and rotate. Now as the modes do not differentiate between tools, incremental snapping is also set for translation as well. This is often not desired - as this activates gridsnapping on the move tool, where as the common use case would be vertex/face/edge snapping. Which is in turn a very rare use case for the rotation tool. Result is that one has to do that mode toggling all the time - or just ignore angular snapping and work with typing values directly. So we're stuck with a weird mix of grid snapping/angular snap/percent snap for all tools. To get some perspective on this topic I also did research the capabilities of 3ds max and maya as well, both don't support any snapping modes for rotate and scaling other than angular snap or step snapping. While I like the extended flexibility of blender here, it shouldnt get in the way of the most common use cases. -------------- This patch tries to improve this workflow without changing any existing behaviour. It introduces four new options for the incremental snapping section: {F5771853} //Disable Mode: Move | Rotate | Scale// These options allow to ignore the increment mode for these three tools. All the other tools like shrink/flatten etc. are not affected by this. //Override for Rotate & Scale// This option forces the snapping system to ignore all the other modes (except the incremental) on the rotate and scale tool For usage simplicity I merged these into one override. Now with these new options we can do the following: - Enable incremental & vertex snapping at the same time - Disable increment snapping on the move tool - Force incremental snapping on the rotate & scale tool We now have angular snapping which is not affected by vertex snapping, and vertex snapping which is not interruped by grid snapping. Open points from my side: - The implementation is rather simple, but I'm not entirely sure if its side effect free or catched every corner case. - Maybe naming of the options could also be improved. --------- Clever me searched rightclick-select pretty late and found this proposal: https://blender.community/c/rightclickselect/Vlcbbc/ This approach would separate move/rotate/scale toolmodes per snapping mode - which would also solve the issue at hand, and doesnt interfere or change any existing behaviour. I think this would also work well - but Im not sure if it's necessary, as I think there aren't any widely used workflows which would benefit from this finer grained control? So, lets see what you guys think about this topic. Thanks for your time, and reading this.. lenghty description.

Blender does not differentiate between tools for snapping, while this is elegant and reduces complexity on the user input - it also has a few drawbacks. Right now if the user wants to do angular snapping, one has to choose incremental snapping and rotate. Now as the modes do not differentiate between tools, incremental snapping is also set for translation as well. This is often not desired - as this activates gridsnapping on the move tool, where as the common use case would be vertex/face/edge snapping. Which is in turn a very rare use case for the rotation tool. Result is that one has to do that mode toggling all the time - or just ignore angular snapping and work with typing values directly. So we're stuck with a weird mix of grid snapping/angular snap/percent snap for all tools. To get some perspective on this topic I also did research the capabilities of 3ds max and maya as well, both don't support any snapping modes for rotate and scaling other than angular snap or step snapping. While I like the extended flexibility of blender here, it shouldnt get in the way of the most common use cases. -------------- This patch tries to improve this workflow without changing any existing behaviour. It introduces four new options for the incremental snapping section: {F5771853} //Disable Mode: Move | Rotate | Scale// These options allow to ignore the increment mode for these three tools. All the other tools like shrink/flatten etc. are not affected by this. //Override for Rotate & Scale// This option forces the snapping system to ignore all the other modes (except the incremental) on the rotate and scale tool For usage simplicity I merged these into one override. Now with these new options we can do the following: - Enable incremental & vertex snapping at the same time - Disable increment snapping on the move tool - Force incremental snapping on the rotate & scale tool We now have angular snapping which is not affected by vertex snapping, and vertex snapping which is not interruped by grid snapping. Open points from my side: - The implementation is rather simple, but I'm not entirely sure if its side effect free or catched every corner case. - Maybe naming of the options could also be improved. --------- Clever me searched rightclick-select pretty late and found this proposal: https://blender.community/c/rightclickselect/Vlcbbc/ This approach would separate move/rotaette/scale toolmodes per snapping mode - which would also solve the issue at hand, and doesnt interfere or change any existing behaviour. I think this would also work well - but Im not sure if it's necessary, as I think there aren't any widely used workflows which would benefit from this finer grained control? So, lets see what you guys think about this topic. Thanks for your time, and reading this.. lenghty description.