Details

This patch introduces control over which tools each snapping mode should affect. So one can freely pick which snapping mode gets used by move/rotate/scale. Other modes like shrink/flatten are not affected by this at all.

It should not change any existing behaviour, merely give the user some more freedom on setting up snapping.

This adresses common issues like:

wanting incremental snapping for rotation, but not in move. As grid snapping & angular snapping are very different usecases.

the current icon set does not contain corresponding images to the toolbar icons. I picked some which remotely fit - but this should be improved

the flag boolean rna properties are really lengthy. Reasoning here is that I wanted these to be separate toggles and not like the bitflag property only work with shift. Im sure I missed something, but I could not find anything which worked like this in the current code.

not entirely sure if the early exits in the snapping calls are sufficient. My local testing here was fine - but someone more knowledgeable should have a look at it..

the scaling in the rows to align to the snapping modes - maybe theres a better way to do this?

I'm not that familiar with the typical workflows here, but this seems overkill to me. Do we really need control this fine, or would a single option to restrict rotation/scale snapping to increments be enough?

I can imagine users mostly working with increment-only snapping for rotation and scale, and then occasionally want to use more advanced snapping. In that case it's quicker if it's just a single option to toggle, perhaps in a pie menu or under a shortcut, rather than tweaking a bunch of checkboxes.

The popover is supposed to function as quick as an enum button also, where you can click and drag down to pick an option. If there's a bunch of checkboxes to the side it slow down that basic operation, while you wouldn't toggle all those settings often.

I already feared to have missed the window of opportunity, but with the release on the horizon it's also very understandable.

Nevertheless a few words on this topic:

@Brecht Van Lommel (brecht) I think these toggles wouldn't need to change all that often - one would simply set it to general liking and then run with it. But still it is kinda overwhelming..

I really think a change is necessary, as all the 'exotic' snapping combinations make a very basic and common use case practically unusable. The mix of grid snap with angular snap just wasn't a good idea either.

This might need a new design approach, but the way snapping is setup currently makes it tricky to come up with something simple tho...

This is similar kind of giant time waster as the transform tools not respecting user orientation. I can't see any reason why this should wait so long. Absence of correct snapping behavior has been agonizing for way too long now. This would also not break anyone's existing workflow. If it's too much UI change at once, maybe we could start with simplified version, such as this:

Aside from mockup above, I also propose that by default, all 3 buttons (Move/Rotate/Scale) are enabled, so that it defaults to exactly the same behavior as it is now.

If default behavior would be absolutely identical to current state, and only option introduced would be one joined trio of buttons, which would only appear if increment mode is active, would that not qualify as a "straightforward improvement" given the huge benefit in terms of usability it'd bring to increment snap feature?

@Germano Cavalcante (mano-wii) this does not work, as other tools also use these snap flags. Now you can only control these for move/rotate/scale - but you can't control the snapping in other modes like shrink wrap anymore.

Maybe it would make sense to 'hide' the fine grained controls:

So its not this huge toggle list popping up.

Or what about something like this:

Basically separates the increment flag into three different modes.

Step: works the same as current increment, except it does nothing for move & rotate
Grid: enable increment snapping for the move tool
Angle: enable increment snapping on the rotate tool

So far this would solve the annoying mixup of grid snapping and angular snap.

There would still be the issue that one often only wants angular snap on the rotation tool but different modes on the move tool.
This could be solved with an extra option for the angular tool, something like "Force angle snapping for Rotate".
Same could be brought up for scale tool too.

The necessity to add these options lowers the general appeal of this approach.

Perhaps it is increment snapping that should be decoupled from the rest of the snapping enum, rather than making a distinction between move/rotate/scale? If we bind increment snapping to its own key it could be available for any transform operator.

I've always found it a bit weird that increment was part of the snapping system. It is mutually exclusive, but still feels like quite a different feature.

If we don't want to break anything it can be done in a conservative way, just adding a new shortcut for increment snapping.

Perhaps it is increment snapping that should be decoupled from the rest of the snapping enum, rather than making a distinction between move/rotate/scale? If we bind increment snapping to its own key it could be available for any transform operator.

I've always found it a bit weird that increment was part of the snapping system. It is mutually exclusive, but still feels like quite a different feature.

If we don't want to break anything it can be done in a conservative way, just adding a new shortcut for increment snapping.

I am happy with pretty much any solution that allows me to use rotation angle increment snap alongside vertex snap without snapping to grid interfering with vertex snap when translating objects or mesh elements.

Right now, that is not possible. Therefore one has to make choice between using vertex snap or being able to snap to angular increments when rotating. (Or keep constantly toggling between the two)

This changes the whole approach to not fiddle with the existing UI at all, and only introduces a separate increment shortcut for any of the transform modal operations. It basically works like the Ctrl for snapping, but results in having only increment snapping.

I know this is probably not high on any list, but as I have it in a working state I thought I could just do an update here as well. Not sure if this is the appropriate way to implement such a change - I was merely following allong what the existing code was doing and extended a few if blocks.

I have used the Alt key for this, but I don't know how the workflow is for changing default keymaps - so you'd have to set this yourself right now.
As a last thing - it does not show up in the status bar, but as I found no code which did anything explictit for this I ended up being a bit clueless :)

We went over this in the UI meeting today. We found the issue with using Alt is that it interferes with some other shortcuts in transform, and doesn't work with MMB emulation.

Apologies for the changing ideas all the time, but we now agreed on the following:

At the bottom of the snapping panel, add 3 toggles like this:

Affects
Move | Rotate | Scale

This is hidden when only the Increment snapping type is selected, to make clear that it does not affect that case.

This setting is shared for all snapping types.

By default, Move is on and Rotate and Scale are off.

When an option is off, then for that transform type it works as if snapping is off and the snapping type is set to increment. That is you press ctrl and it will snap to increments, otherwise it does not snap.

@Brecht Van Lommel (brecht) good to hear back from you. dont worry about changeing stuff around - I think the actual implementation is pretty simple, its the design which isnt so straight forward.

Alt was just a suggestion - but I see why that can be troublesome. I know there is no nice abbreviated key availiable like "S", and "I" is too far away. But really A/D/V/Q/E/^ would also be ergonomic choices. Maybe Tab would also work.
Ok lets not get into this further as you have apperantly ditched this approach already.

Anyhow if I understand correctly, the proposed way would do the following:

Select Increment & vertex snapping modes

enable move operator

now hit CTRL -> it now snaps to increment & vertices

So its not possible to only have incremental snapping on the rotate&scale tool and not on move tool (and the others).

I feel this approach is definately better than the current state, but Im not sure if the continued mixup with grid + any other snapping will still be annoying.

This is hidden when only the Increment snapping type is selected, to make clear that it does not affect that case.

This setting is shared for all snapping types.

By default, Move is on and Rotate and Scale are off.

When an option is off, then for that transform type it works as if snapping is off and the snapping type is set to increment. That is you press ctrl and it will snap to increments, otherwise it does not snap.

is this patch already included in the latest master? I can't see anything being changed about the behavior. When having both incremental move and rotate snaps enabled, I am still unable to disable incremental moving snap to grid so that it doesn't interfere with vertex snapping. I can see three new options for Vertex snap, but they are completely unrelated to this request. I am very worried you have completely misunderstood point of this request.

you dont need to activate incremental snap - just use vertex snap and disable affect for rotate&scale. if affect is turn off these modes will always fall back to incremental snapping.

Ohhhh.... so it's just very confusing implementation :|

I can already guarantee that people will have problem with understanding it. It's very "Blender" way to go about it. I still think that "Move, Rotate and Scale checkboxes should be sub option of the "Incremental" snap mode, not all the other modes. This introduces very weird and confusing concept of using a snap mode that is not explicitly activated. Since Blender 2.8 is in the spirit of removing all the UI weirdness, we should not be adding more of it.

Let's just put the three checkboxes under "Incremental" snap mode, and make them toggle which of the 3 transform tools are affected by incremental snap. So you'd just Shift+Click to activate both Incremental and Vertex modes, and then you would uncheck "Move" in Incremental suboptions to prevent Move increment snap interfering with vertex snap. And you could also uncheck Rotate, if you wanted, to prevent rotation incremental snap from interfering with your rotation to vertex snap.

It would be identical functionality, but would not confuse the hell out of users.

When an option is off, then for that transform type it works as if snapping is off and the snapping type is set to increment. That is you press ctrl and it will snap to increments, otherwise it does not snap.

The idea is that if you disable Rotate and Scale, the snapping settings do not affect them at all. Instead you get the basic type of snapping like you do when using e.g. Ctrl when dragging number buttons, which happens to be the same as incrementing mode. But communicating this as "forcing increment mode" is wrong.

When an option is off, then for that transform type it works as if snapping is off and the snapping type is set to increment. That is you press ctrl and it will snap to increments, otherwise it does not snap.

The idea is that if you disable Rotate and Scale, the snapping settings do not affect them at all. Instead you get the basic type of snapping like you do when using e.g. Ctrl when dragging number buttons, which happens to be the same as incrementing mode. But communicating this as "forcing increment mode" is wrong.

I do think this works pretty well and is simple and easy to use. happy its solved now.

No, sorry, but I am still even more confused now. I just tried latest patch @Brecht Van Lommel (brecht) , and now I am completely unable to figure out which combination of snapping modes and move/rotate/scale buttons I need to use to make vertex snap work alongside rotation incremental snap.

I am perplexed by how such trivial thing can be implemented in such an overcomplicated way. Why isn't it possible to have those move/rotate/scale buttons be sub options of "Increment" mode specifically, and define which of the transform tools does increment mode specifically affect?

By default, the snapping settings don't affect rotate/scale at all. Just press Ctrl during rotation to snap to increments there.

Why isn't it possible to have those move/rotate/scale buttons be sub options of "Increment" mode specifically, and define which of the transform tools does increment mode specifically affect?

Because this means that when you're changing snapping modes for move, you have to be careful to always keep increment active for rotate. It means you have to do 3 clicks each time you want to change snapping mode for move while leaving rotate unchanged, instead of just one click and drag. If someone controls snapping modes with a pie menu, that would break as well.

By default, the snapping settings don't affect rotate/scale at all. Just press Ctrl during rotation to snap to increments there.

Why isn't it possible to have those move/rotate/scale buttons be sub options of "Increment" mode specifically, and define which of the transform tools does increment mode specifically affect?

Because this means that when you're changing snapping modes for move, you have to be careful to always keep increment active for rotate. It means you have to do 3 clicks each time you want to change snapping mode for move while leaving rotate unchanged, instead of just one click and drag. If someone controls snapping modes with a pie menu, that would break as well.

Ah, it's confusing, but I can live with it. I am just worried other people will be confused to the point where they won't know how to use it.

Sure, if someone switches snapping modes with pie menu, then that won't work. But the whole concept of being able to select multiple snapping modes then won't work either, yet that did not stop you from implementing it.

I am sorry but this really should not be left the way it is now. It's really beyond confusing. Imagine yourself being a new user and seeing this:

1, Tooltip says the button toggles if Move is affected by snapping settings
2, Currently active snapping setting is increment
3, Move button is disabled
4, YET when moving the objects with current snap settings configuration, it snaps to increments.

What happens in Blender is not what the UI says at all.

Now, imagine yourself once again being a new user, and seeing this:

1, Tooltip says the button toggles if Rotate is affected by the snapping settings.
2, Rotate is disabled, therefore it should not be affected by snapping settings.
3, Increment snapping setting is disabled
4, YET if you rotate object with current snap settings, it snaps to increments.

Again, what UI says is not what's happening in the scene.

You are claiming that the buttons toggle which transform tools are being affected by snapping settings, yet if you turn them off, you fallback to increment. You don't mention that "Increment" mode is not part of those "affected by" snapping settings anywhere in the UI, neither do you communicate that increment is now a special kind of fallback setting.

I think youre making it a bigger issue than it is. Yes the tooltip could be improved to mention the increment fallback - but how about making a concrete suggestion what it should say?
In my original tooltip there was somethign about it, maybe it was too lengthy or because of the changes it made no sense anymore - anyways its just a tooltip/wording issue, the usage of this is straight forward.

I think youre making it a bigger issue than it is. Yes the tooltip could be improved to mention the increment fallback - but how about making a concrete suggestion what it should say?
In my original tooltip there was somethign about it, maybe it was too lengthy or because of the changes it made no sense anymore - anyways its just a tooltip/wording issue, the usage of this is straight forward.

Well in that case, to properly describe the functionality of those buttons, it'd need to be long. If it's long, it means it's not a straightforward thing to learn. I still fail to see a reason why does it have to be so complicated. If the three switches were only related to increment mode, it'd be immediately obvious what's going in. Brecht argued that it'd then not be possible to use if snapping modes are switches through pie menu, but if one uses pie menu, then such user can't even enabled multiple snapping modes at once in the first place.

I think it's quite a big issue, simply because snapping isn't something that needs to be complicated, in any software.

The solution I am proposing will give users exactly same flexibility the current one does, but at the same time, it will be a lot easier to understand. But at any point of time, for example for rotate tool, you will be able to choose if rotate snaps to increment, mesh/scene elements, both, or neither of them. It's the exact same set of possibilities, it'd be just presented in a more straightforward way inside UI.

Here is for example how we currently let user know he is using Vertex snap for move, and Increment snap for rotate and scale:

You can not with honesty say that is self-explanatory. There's nothing on that picture that would imply increment snap is being used for anything.

Here's my proposal where Move/Rotate/Scale buttons would be exclusive sub-option of Increment mode, and we are letting the user know that exactly same behavior as above is happening:

Now the users clearly knows that Increment is being used for rotate and scale, and if he finds that rotation increment interferes with his ability to use rotate snap to vertex, it's very clear how to solve that (uncheck rotate in increment affects).

Now for Brecht's argument that it would not work for user who switches snapping modes using pie. That is true. But if you set up more advanced, combined snapping behavior, does it really make sense to switch them then using a pie menu? In such case, one would most likely just use hotkey to turn snap on and off, but the whole point of having ability to use multiple combined snapping behavior is that you don't have to switch between them.

Because this means that when you're changing snapping modes for move, you have to be careful to always keep increment active for rotate. It means you have to do 3 clicks each time you want to change snapping mode for move while leaving rotate unchanged, instead of just one click and drag.

In that mockup, it seems you are proposing quite different behavior, not just UI. Rather than disabling vertex snap for rotate / scale, you are making it so you can disable increment snap for move while presumably still keeping vertex snap active for rotate / scale.

Personally I don't think that is easier to understand. And as a mental model to me it seems harder for a user to keep track of having multiple snapping modes active to get the typical desired behavior for the various transform modes. As far as I know, in practice you almost always want increment mode to be available for rotation and scale. And the user having to keep that in mind while changing snapping settings for move seems annoying and slows down the workflow.

Further, it requires users to understand combined snapping modes to understand how to get increment for rotate and something else for move. I don't think that is something many users will discover by themselves, without reading documentation.

Because this means that when you're changing snapping modes for move, you have to be careful to always keep increment active for rotate. It means you have to do 3 clicks each time you want to change snapping mode for move while leaving rotate unchanged, instead of just one click and drag.

In that mockup, it seems you are proposing quite different behavior, not just UI. Rather than disabling vertex snap for rotate / scale, you are making it so you can disable increment snap for move while presumably still keeping vertex snap active for rotate / scale.

Personally I don't think that is easier to understand. And as a mental model to me it seems harder for a user to keep track of having multiple snapping modes active to get the typical desired behavior for the various transform modes. As far as I know, in practice you almost always want increment mode to be available for rotation and scale. And the user having to keep that in mind while changing snapping settings for move seems annoying and slows down the workflow.

Further, it requires users to understand combined snapping modes to understand how to get increment for rotate and something else for move. I don't think that is something many users will discover by themselves, without reading documentation.

I don't think current behavior is lesser evil. It's either users will be confused by what the UI looks like, or users will be confused by losing ability to rotate-snap to increments when switching the snap modes. I have two proposals to solve this:

A: Why don't we just make the snapping mode buttons into toggles, instead of multi-switch it's now? Right now, if you click vertex, it will automatically turn off increment to enable vertex. You need to hold down Shift key to select multiple of them. Move/Rotate/Scale buttons are exactly the same type of UI buttons, but they behave as toggles instead. If you click Rotate, it won't automatically disable move. So how about we do the same for the actual snapping modes? By default, incremental is enabled. Clicking Vertex without need to hold down shift would toggle Vertex mode on, but would not turn increment mode off. This would also allow it to be used with pie menus, with only difference that activating pie menu option would mean toggle, instead of set.

or
B: Simply remove incremental mode from the list, and improve description of the Move/Rotate/Scale to imply that they are overrides, which override default incremental snap mode to selected snap mode. But the actual toggle for incremental snap doesn't make much sense in current state.