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.

Reading D4013: Snapping: additional incremental options I guess I'm going against @William Reynish (billreynish)'s advice here. But I can't see how a bunch of checkboxes like that is an efficient thing to change in the middle of modelling.

Straightforward improvements/fixes are one thing, but adding options needs careful considerations.

I'd rather postpone changes like this until after 2.80 release.

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...

The idea is good, but I did not like the layout.
I would prefer something like this (maybe even more compact):

In D4022#90974, @Campbell Barton (campbellbarton) wrote:

Straightforward improvements/fixes are one thing, but adding options needs careful considerations.

I'd rather postpone changes like this until after 2.80 release.

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:

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?

EDIT: Nevermind, actually: https://developer.blender.org/D4013

@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.

In D4022#91079, @Benjamin Sauder (kioku) wrote:

(...)
Or what about something like this:

That's perfect!

If it don't have space to add other flags, I think you could move the member to position any of the pads of type int.

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.

In D4022#91082, @Brecht Van Lommel (brecht) wrote:

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)

@Brecht Van Lommel (brecht) glad you also feel this way - I didn't dare to propose such a thing :)

guess the most obvious choice would be Alt key. So you can choose between snapping with Control, or Incremental with Alt - and Shift for precision would still apply for both modes.

@Brecht Van Lommel (brecht) @Campbell Barton (campbellbarton)
Any news on this? Is the latest revision feasible?

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.

I will update the patch in the next days using this approach.

In D4022#92077, @Benjamin Sauder (kioku) wrote:

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).

If you enable only Vertex snapping, and leave snapping to only affect Move, then it would work. For Rotate/Scale it would still do increment snapping when pressing Ctrl.

In D4022#92075, @Brecht Van Lommel (brecht) wrote:

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.

This is very good news. Can't wait to test it out.

In D4022#92739, @Campbell Barton (campbellbarton) wrote:

Thanks for the update.
Added version patch (so existing files have the flag initialized) and commited rB879c9665985b36c93f21a49663df033a010d2829

Hello,

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.

In D4022#92776, @Benjamin Sauder (kioku) wrote:

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.

The implementation does not follow this specification:

• 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.

In D4022#92799, @Brecht Van Lommel (brecht) wrote:

The implementation does not follow this specification:

• 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.

To be honest, now I am even more confused :(

@Ludvik Koutny (rawalanche)
builder.blender.org already has brechts iteration of this - just give a try?

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

In D4022#92830, @Benjamin Sauder (kioku) wrote:

@Ludvik Koutny (rawalanche)
builder.blender.org already has brechts iteration of this - just give a try?

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.

In D4022#92881, @Brecht Van Lommel (brecht) wrote:

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.

@Brecht Van Lommel (brecht) @William Reynish (billreynish)

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:

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

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

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.

This is really not on par with 2.8 UI standards.

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.

In D4022#92932, @Benjamin Sauder (kioku) wrote:

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's a more graphical explanation of what I propose:

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

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 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.

My main issue is not the pie menu, but this:

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.

In D4022#92939, @Brecht Van Lommel (brecht) wrote:

My main issue is not the pie menu, but this:

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.