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.

In T66484#1044149, @Dalai Felinto (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 T66484#1044182, @Paul Kotelevets (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 T66484#1044276, @Germano Cavalcante (mano-wii) wrote:

In T66484#1044182, @Paul Kotelevets (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?

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 T66484#1471650, @Dalai Felinto (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?

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?

In T66484#1471650, @Dalai Felinto (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 T66484#1471650, @Dalai Felinto (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 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 B to confirm, holding 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 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.