Page MenuHome

Snapping: additional Incremental Shortcut
Needs ReviewPublic

Authored by Benjamin Sauder (kioku) on Mon, Dec 3, 12:02 AM.

Details

Summary

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.
  • doesnt want vertex/face snapping interfere with rotation incremental snapping.

This is the second attempt on this topic - first see: https://developer.blender.org/D4013 .
Now it's more or less based on this: https://blender.community/c/rightclickselect/Vlcbbc/ which I think is much more userfriendly.

Notes:

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

Thanks for your time.

Diff Detail

Event Timeline

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

Benjamin Sauder (kioku) edited the summary of this revision. (Show Details)Mon, Dec 3, 2:37 PM

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

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:


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?

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.

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

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.

Benjamin Sauder (kioku) retitled this revision from Snapping: Allow for toolmode restrictions to Snapping: additional Incremental Shortcut.

I liked the Idea from @Brecht Van Lommel (brecht) very much, as its very simple, clean and non intrusive.

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

As always thanks for your time.

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.

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.

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.

@Brecht Van Lommel (brecht) ah yes you are correct - all good then.

I have updated the patch, this should implement the proposed behaviour.

From my testing this works out pretty nicely - very simple solution to this topic.

Notes:

  • I did not understand how the default value is handled correctly. Right now its correct if you add a new scene, but its incorrect when creating a new file. Maybe someone can enlighten me :)
  • Names got a bit lenghty

thanks for picking it up again.