Page MenuHome

Snapping: additional incremental options

Authored by Benjamin Sauder (kioku) on Fri, Nov 30, 10:20 PM.



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:

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:

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.

Diff Detail

Event Timeline

Looks interesting.

Can you explain the rationale for the 'Override for Rotate & Scale' feature? Why is this really necessary? I read your reasoning here multiple times and didn't understand what this is for.

@William Reynish (billreynish) basically I want to have vertex/increment snapping at the same time, but rotate should not snap to any vertices - as in denser models there is basically a vert everywhere and it shouldnt mess with the incremental snapping. It also kinda defeats the point of incremental snapping as it introduces 'uneven' values again. Im well aware that its a bit on 'one has to explain this' side...

thats also why I linked this other propsal, different take on the same topic.

Ah, I see. Yes, I'm afraid I think this solution is simply too difficult to understand I think. The one in the proposal on rightclickselect gives a clearer, direct visualization of what is enabled for what.

Benjamin Sauder (kioku) planned changes to this revision.Fri, Nov 30, 10:51 PM

@William Reynish (billreynish) I will change the implementation to follow the propsal then. thanks for your input.

Ah, I see. Yes, I'm afraid I think this solution is simply too difficult to understand I think. The one in the proposal on rightclickselect gives a clearer, direct visualization of what is enabled for what.

@William Reynish (billreynish) Unfortunately the other solution makes the whole snapping UI a lot more complex, and makes snapping something that's requires way too much mental energy to control. This is lesser evil I think.