Page MenuHome

Snap Tools
Confirmed, NormalPublicDESIGN

Assigned To
None
Authored By
Dalai Felinto (dfelinto)
Jul 5 2019, 9:25 PM
Tokens
"Love" token, awarded by Nominous."Love" token, awarded by gilberto_rodrigues."Love" token, awarded by ugosantana."Love" token, awarded by 1D_Inc."Love" token, awarded by amonpaike."Love" token, awarded by Okavango."Love" token, awarded by CMC."Love" token, awarded by dgriffin91."Love" token, awarded by symstract."Love" token, awarded by xrg."Love" token, awarded by duarteframos.

Description

Introduction

Snapping is used in Blender for the most diverse use cases:

  • Grid snapping (modelling, animation)
  • Vertex snapping (CAD modelling)
  • Volume snapping (retopology, assets placement)

The goal of this document is to make it more powerful for precision modelling, while still supporting the old use cases without extra complexity.
The main topic addressed here is the introduction of a "base point" concept (refactoring the current snap target setting), as well as a more clear "target points" system (the old snap elements setting).

Terminology

  • Base point: 3d coordinate * we want to snap from.
  • Target point: 3d coordinate* we want to snap to.
  • Filter: A snap filter is what we can snap to (end points, 3d cursors, grid, ...).

Note: These points don't need to be a vertex necessarily, nor the pivot of the operation, it can be the middle of an edge, ...

Mockup

An example of a user trying to move objects from a reference point to another using the grab operator.

Base Point Snap, example of transform operation via the shortcut (not the tool). After pressing g and the snap base change shortcut (e.g., shift + ctrl) the user set the base point. The base point is then visible until the end of the operation. The z axis constrains the final position.

Base Point

We only see the base point if snap is on and while the gizmo is manipulated. For tool-less operators (e.g., grab) we only see the base point while the operator is running.
Note that this is not the pivot. Although for translation the pivot can be used, for rotation most often they will differ.

Where the base point is initially, will depend on a "Default Base Point" setting:

  • Active (vertex, object center).
  • 3D Cursor.
  • Vertex closest to mouse (this only works for gizmo-less operators).

Users can change the base point with a key (e.g., alt), which can fix the base point to a new location. Like the target point, the base point can "snap" to elements of the scene (vertex, mid-edge, 3d cursor, …).

Alternative: For tools and transformation gizmos, we could show the base point all times, even when the gizmo is not manipulated.

Snap Filter

Snap filters allow users to select what we can snap to:

  • Vertices
  • Intersections
  • Edge midpoint
  • Edge perpendicular
  • Face center
  • Surface (volume)
  • 3D cursor
  • Grid (absolute grid)
  • Increment (relative increment)
  • …?

Event Timeline

Design for base-point is light on details, also skeptical about having tool & non-tool operation being different (would like to avoid if possible, logic for transform is already getting hard to manage and further splitting logic is something users need to be aware of... it needs to be documented and IMHO sets an awkward precedent, eg, changes to a keymap may conflict when accessed from a tool but not the hotkey, if we add further differences, this becomes even more of a hassle to maintain).

If we add the base-point to the tool. Is this like a second 3D cursor when a tool is active? do we need to duplicate 3D cursor logic just to control base-point? (moving it, projecting it unto a surface, snapping to selection... etc).

Since transform is used very often, would like to see more detailed planning to how this interaction would work.

Alternatively, we could leave this an open topic. In that case would say less and note that design needs further work.

Another option would be not to implement this for tools initially and do it as a second step when we have a better feel for what it's like to adjust the base-point. Then the tool interaction can be reviewed separately.

I thought of Campbell's concern and in fact the logic of the tool & non-tool operation would change a bit.
The change would be that the user would have to choose the Base Point instead of relying on the Base Point calculated and appointed by the Snap Target.
Although it is a small change and would only appear if snap toogle was enabled, it would in fact bring strangeness to old users, so it would be nice to allow the user to choose the behavior of the transformation (with Manual or Automatic Base Point).

One way to resolve this would be to add an option to choose which default behavior.

It was not my intention to have a different logic for tool and non-tool. The way I see it they would work the exactly same way.

If we add the base-point to the tool. Is this like a second 3D cursor when a tool is active?

No, as stated there, only when operating the tool we get to see the base point.

Do we need to duplicate 3D cursor logic just to control base-point? (moving it, projecting it unto a surface, snapping to selection... etc).

No, the base point would use the same logic as the target point. But given that the 3D cursor would be a new filter option, nothing is preventing users from first using the 3D cursor to "e.g., snap to world origin" and then snapping the base point to the 3d cursor.

Since transform is used very often, would like to see more detailed planning to how this interaction would work.

Non-Tool Grab:

  • If snap is off: Press G, business as usual; hold ctrl for snap, you will see the base-point (based on the default base point option), and if you want to change the base point you hold alt (while holding ctrl) to re-position it.
  • If snap is on: Same as above but as if ctrl was pressed all the way (pressing ctrl then disable snapping just as we have now).

Note, not clear is whether we re-set the base-point at each transformation or not, I think we should.

Tool Grab:

  • If snap is off: Manipulate the gizmo as usual; hold ctrl for snap, you will see the base-point (based on the default base point option), and if you want to change the base point you hold alt (while holding ctrl) to re-position it.
  • If snap is on: Same as above but as if ctrl was pressed all the way (pressing ctrl then disable snapping just as we have now).

Note, not clear is whether we re-set the base-point at each transformation or not, in this case we can do every time a different object is selected or upon activating a tool.

(...) instead of relying on the Base Point calculated and appointed by the Snap Target.

Not really, it would use the "default base point" setting to determine the initial base point, but allowing users to change this with alt during transformation.

Alternatively, we could leave this an open topic. In that case would say less and note that design needs further work.

Honestly I would like to hear from @Germano Cavalcante (mano-wii) a proposal that address any raised issue we may have. This task is simply my proposal, and the most important is for the developer tackling this task to have a clear grasp of the design and to be able to communicate that before start coding.
As I said when we met, I was actually interested on @Germano Cavalcante (mano-wii) original proposal for handling the base-point, whatever that proposal is. It can work as a nice counter-point to this proposal here.

So, apparently Non-Tool Grab and Tool Grab should work the same way.
But it is good to specify if the paragraph is about moving with the Tool Grab or just activating the Tool Grab.
I believe it's about moving with the Tool Grab, since the original post mentions that we only see the base point if snap is on and while the gizmo is manipulated.

In general the idea is good. The Alt key needs and a bit more planning though.

Snap filters allow users to select what we can snap to:

  Vertices
  Intersections
  Edge midpoint
  Edge perpendicular
  Face center
  Surface (volume)
  3D cursor
  Grid (absolute grid)
  Increment (relative increment)
  …?
  • Origins of objects
  • regular edges (nearest)
  • and maybe extension of edges (if possible) can be useful.

Maybe, ability to pick an edge as direction (by specifying two nearest points on edge).
It is popular operation "move the object a certain distance towards some edge direction".

When the vert slide snapping is improved (T66426), the problem with edge extension snapping will be a good part resolved.

Currently we are using [Get Orientation] tool from 1D_Scripts, that creates rewritable transform orientation called 1DTEMP based on selection to perform such operations.
It solves an issue, but it's nice to know that there is development in the direction of transorient-free way.

Updated the design with an image to better illustrate the components in the viewport.

Updated the design with an image to better illustrate the components in the viewport.

Well, yes, but in this particular case default snap is better to use - just like is shown in the B.A.S.E. proposal, it is level set case

Basically, I am thinking of a scene, called Snap Chamber, to provide most relevant snap cases to satisfy, based on our experience, and provide possible solutions that we found, investing snap problem for a decade for a wide range of a workflows.
This can help generalize both problem and solution, excluding oversatisfying rare cases or leaving relevant cases unsolved.

Also
https://developer.blender.org/D7000#192452

Well, yes, but in this particular case default snap is better to use - just like is shown in the B.A.S.E. proposal, it is level set case

What do you mean "default snap is better to use"?
For me, the solution using shortcuts, is very similar to the B.A.S.E proposal.

Well, yes, but in this particular case default snap is better to use - just like is shown in the B.A.S.E. proposal, it is level set case

What do you mean "default snap is better to use"?

I mean the case with moving plate from the lower case to upper, depicted on a picture, is better to solve via default bounding box approach, so the case depicted on this picture can be solved by current default realization.
Cases are very important for proper snaps design, because it have to satisfy usability cases.

For me, the solution using shortcuts, is very similar to the B.A.S.E proposal.

Only for 1pt aligning. Or is it supposed to limit the base point snapping only to 1pt aligning?

Also, I would like to propose changes to the terminology section:

  • Base point snapping method: a method to perform snapping action, that allow set base points to transform objects from source to the target coordinates as a result of the transform action.
  • Source point: 3d coordinate we want to snap from.
  • Target (or destination) point: 3d coordinate we want to snap to.

How do you think?