Snap Tools #66484

New Issue

Dalai Felinto · 2019-07-05T21:25:20+02:00

Dalai Felinto commented

2019-07-05 21:25:20 +02:00

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

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)
…?

## 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. ![image](/attachments/54ffebf0-9d99-427e-80f5-0029a81c1a67) ## 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) * …?

image.png

864 KiB

Campbell Barton commented

2019-07-08 13:27:46 +02:00

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.

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.

Germano Cavalcante commented

2019-07-08 14:02:22 +02:00

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.

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.

Dalai Felinto commented

2019-07-12 15:44:43 +02:00

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

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

Germano Cavalcante commented

2019-07-12 16:01:00 +02:00

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.

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.

Paul Kotelevets commented

2019-11-01 18:21:52 +01:00

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

``` 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". ![изображение.png](https://archive.blender.org/developer/F7892483/изображение.png)

Germano Cavalcante commented

2019-11-01 18:30:10 +01:00

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

Paul Kotelevets commented

2019-11-01 18:51:03 +01:00

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.

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.

Dalai Felinto commented

2020-10-29 11:49:11 +01:00

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

Paul Kotelevets commented

2020-10-29 12:39:37 +01:00

In #66484#1044149, @dfelinto wrote:
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

> In #66484#1044149, @dfelinto wrote: > 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

Germano Cavalcante commented

2020-10-29 14:57:17 +01:00

In #66484#1044182, @1D_Inc wrote:
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.

> In #66484#1044182, @1D_Inc wrote: > 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.

Paul Kotelevets commented

2020-10-29 15:15:29 +01:00

In #66484#1044276, @mano-wii wrote:

In #66484#1044182, @1D_Inc wrote:
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?

> In #66484#1044276, @mano-wii wrote: >> In #66484#1044182, @1D_Inc wrote: >> 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?

blender-admin commented

2021-11-17 15:02:54 +01:00

This issue was referenced by f19bd637e2

This issue was referenced by f19bd637e2c38b8b967944a88609a190b5179439

Dalai Felinto commented

2023-01-09 19:24:02 +01:00

Germano and I were going over a way to unify both the gizmo and the tool-less operators on how to confirm a base point.

We could press B to start picking the base point, and B again to confirm it. This prevent requiring pressing the mouse to confirm the base-point, which is not compatible with the gizmo mode.

Germano and I were going over a way to unify both the gizmo and the tool-less operators on how to confirm a base point. We could press B to start picking the base point, and B again to confirm it. This prevent requiring pressing the mouse to confirm the base-point, which is not compatible with the gizmo mode.

Paul Kotelevets commented

2023-01-10 05:55:03 +01:00

In #66484#1471650, @dfelinto wrote:
Germano and I were going over a way to unify both the gizmo and the tool-less operators on how to confirm a base point.

We could press B to start picking the base point, and B again to confirm it. This prevent requiring pressing the mouse to confirm the base-point, which is not compatible with the gizmo mode.

Yes, Gizmo mode is not supposed to be compatible with basepoint snapping in general, it is a known limitation of this system (it is single-handed, non-copying, release confirmed by default). If translate can be achieved somehow, gizmo-based rotating and scaling contradicts the behaviour that allow to reach the results which is supposed to be achieved with a base pointing.
When exactly pressing B is supposed to be performed in gizmos mode? Can you please describe steps - is it supposed to use B instead LMB to operate with basepoints during holding LMB in that case?

> In #66484#1471650, @dfelinto wrote: > Germano and I were going over a way to unify both the gizmo and the tool-less operators on how to confirm a base point. > > We could press B to start picking the base point, and B again to confirm it. This prevent requiring pressing the mouse to confirm the base-point, which is not compatible with the gizmo mode. Yes, Gizmo mode is not supposed to be compatible with basepoint snapping in general, it is a known limitation of this system (it is single-handed, non-copying, release confirmed by default). If translate can be achieved somehow, gizmo-based rotating and scaling contradicts the behaviour that allow to reach the results which is supposed to be achieved with a base pointing. When exactly pressing B is supposed to be performed in gizmos mode? Can you please describe steps - is it supposed to use B instead LMB to operate with basepoints during holding LMB in that case?

Paul Kotelevets commented

2023-01-10 07:09:33 +01:00

To clarify what I mean about rotating/scaling, here is a simple example of a Referenced transforms.
Referenced transforms is a type of transformations driven by exact value defined by existing geometry instead of a number.
RT is quite common CAD technique obtained by basepoint snapping, it allow to achieve precise resizing and specific form of a precise 2D alignment.
The only way I can see this applicable to gizmos is pressing B during transform - while holding LMB, since there are no other way to lock the desired transformation axis with gizmo.
Is it the proposed way?

Refrenced transform -v2.mp4

To clarify what I mean about rotating/scaling, here is a simple example of a Referenced transforms. **Referenced transforms** is a type of transformations driven by exact value defined by existing geometry instead of a number. RT is quite common CAD technique obtained by basepoint snapping, it allow to achieve precise resizing and specific form of a precise 2D alignment. The only way I can see this applicable to gizmos is pressing B during transform - while holding LMB, since there are no other way to lock the desired transformation axis with gizmo. Is it the proposed way? [Refrenced transform -v2.mp4](https://archive.blender.org/developer/F14136953/Refrenced_transform_-v2.mp4)

Duarte Farrajota Ramos commented

2023-01-10 11:02:30 +01:00

In #66484#1471650, @dfelinto wrote:
Germano and I were going over a way to unify both the gizmo and the tool-less operators on how to confirm a base point.

We could press B to start picking the base point, and B again to confirm it. This prevent requiring pressing the mouse to confirm the base-point, which is not compatible with the gizmo mode.
In #66484#1471650, @dfelinto wrote:
We could press B to start picking the base point, and B again to confirm it. This prevent requiring pressing the mouse to confirm the base-point, which is not compatible with the gizmo mode.

I'd definitely prefer the former behavior, of pressing {key B} then clicking to confirm base point for operators or non tool use, even at the expense of availability for tools and gizmos.

Would it be possible if instead of pressing {key B} to confirm, holding {key B} for both tools and operators would initiate some form of base point "modal definition mode", similar to how placing the 3D cursor currently works?

Holding the B key would interrupt current transform operation for operators and would initiate a mode similar to current Right-click drag behavior for placing the 3D cursor, where snapping to geometries would define the transform base point, or for tools would initiate snapping the gizmo to different base points. Releasing the {key B} key would return to regular operation.

One downside of this method is that it would not be easy to cancel base-point definition or reset to previous one without cancelling the operation. Upside is being consistent with other current behavior, not requiring any further key presses, and tentatively being compatible with both tools and operators.

Otherwise, if this is the only way forward, I'd consider it an acceptable compromise.

> In #66484#1471650, @dfelinto wrote: > Germano and I were going over a way to unify both the gizmo and the tool-less operators on how to confirm a base point. > > We could press B to start picking the base point, and B again to confirm it. This prevent requiring pressing the mouse to confirm the base-point, which is not compatible with the gizmo mode. > In #66484#1471650, @dfelinto wrote: > We could press B to start picking the base point, and B again to confirm it. This prevent requiring pressing the mouse to confirm the base-point, which is not compatible with the gizmo mode. I'd definitely prefer the former behavior, of pressing {key B} then clicking to confirm base point for operators or non tool use, even at the expense of availability for tools and gizmos. Would it be possible if instead of pressing {key B} to confirm, holding {key B} for both tools and operators would initiate some form of base point "modal definition mode", similar to how placing the 3D cursor currently works? Holding the B key would interrupt current transform operation for operators and would initiate a mode similar to current Right-click drag behavior for placing the 3D cursor, where snapping to geometries would define the transform base point, or for tools would initiate snapping the gizmo to different base points. Releasing the {key B} key would return to regular operation. One downside of this method is that it would not be easy to cancel base-point definition or reset to previous one without cancelling the operation. Upside is being consistent with other current behavior, not requiring any further key presses, and tentatively being compatible with both tools and operators. Otherwise, if this is the only way forward, I'd consider it an acceptable compromise.

Germano Cavalcante referenced this issue

2023-02-07 18:03:08 +01:00

Transform: add feature to edit the 'Snap Base' #104412

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Snap Tools #66484

Introduction

Terminology

Mockup

Base Point

Snap Filter