Snap Polishing #108669

Open
opened 2023-06-06 17:42:59 +02:00 by Dalai Felinto · 20 comments

After the recent Snap improvements (3010f1233b 33c13ae6e3) I believe we need to do some polishing, revise some decisions as well as take 4.0 as a chance to set new defaults:

  • (cf967f8e08) Revert the Transformed Snap Base (aka white aim gizmo) behavior to 3.6. Including not showing it for the new Snap Base functionality. Example of current (undesired) gizmo showing up:
    image
  • (cf967f8e08) Add an indicator of the Snap Base (i.e., X) when users manually set (click) a base.
  • Check with UI/modeling team:
    • Rename Snap With → Snap Base
    • Rename Snap To → Snap Target
    • If another icon (e.g., a circle) would be better for the Snap Base. Keep in mind that the same icon is used for the Edge Perpendicular since it also shows the Snap Base.
    • New default options for snap for 4.0. Suggestion:
      • Snap To: Vertex / Edge / Face Project / Edge Center / Edge Perpendicular
      • Affect: Move + Rotate + Scale (note that the Snap Base is ignoring this setting).
      • Snap With: Median
    • Navigate during Transform (as default and remove as an option)
    • Use the current snap options elsewhere (e.g., asset dragging and measurement tool).
  • Remove Snap With Closest.
  • Create a design proposal for when to show the Transformed Snap Base.
After the recent Snap improvements (3010f1233b29 33c13ae6e38f) I believe we need to do some polishing, revise some decisions as well as take 4.0 as a chance to set new defaults: - [X] (cf967f8e08) Revert the Transformed Snap Base (aka white aim gizmo) behavior to 3.6. Including not showing it for the new Snap Base functionality. Example of current (undesired) gizmo showing up: ![image](/attachments/de636391-cf24-4610-88a1-8b21daf03a6d) - [X] (cf967f8e08) Add an indicator of the Snap Base (i.e., X) when users manually set (click) a base. - [ ] Check with UI/modeling team: * Rename Snap With → Snap Base * Rename Snap To → Snap Target * If another icon (e.g., a circle) would be better for the Snap Base. Keep in mind that the same icon is used for the Edge Perpendicular since it also shows the Snap Base. * New default options for snap for 4.0. Suggestion: * Snap To: Vertex / Edge / Face Project / Edge Center / Edge Perpendicular * Affect: Move + Rotate + Scale (note that the Snap Base is ignoring this setting). * Snap With: Median * Navigate during Transform (as default and remove as an option) * Use the current snap options elsewhere (e.g., asset dragging and measurement tool). - [ ] Remove Snap With Closest. - [ ] Create a design proposal for when to show the Transformed Snap Base.
5.4 KiB
Dalai Felinto added this to the 4.0 milestone 2023-06-06 17:42:59 +02:00
Germano Cavalcante was assigned by Dalai Felinto 2023-06-06 17:43:00 +02:00
Dalai Felinto added this to the Modeling project 2023-06-06 17:43:01 +02:00
Member

Here are my thoughts:

Rename Snap With → Snap Base
Rename to Snap Base is fine with me. Good to keep naming consistent

Rename Snap To → Snap Target
Rename to Snap Target is fine with me.

If another icon (e.g., a circle) would be better for the Snap Base. Keep in mind that the same icon is used for the Edge Perpendicular since it also shows the Snap Base
The icon is fine. One thing that could be nice during setting snap base is to hide the 4-arrow grab icon and only show the orange ring until setting base is done. Currently it is a little hard to see the snap base ring because of the 4-arrow icon.

New default options for snap for 4.0. Suggestion:
Snap To: Vertex & Edge & Face Project (i.e. 3 snap targets active)
Affect: Move + Rotate + Scale
Snap With: Median
Project individual elements: True
Align rotation to target: False (This setting is False by default. Just want to emphasize that I think it is good as it is)

Navigate during Transform (as default and remove as an option)
I'm not sure I know what this feature is or where to activate it.

Use the current snap options elsewhere (e.g., asset dragging and measurement tool).
Yes please! Especially for asset dragging from the asset browser

Here are my thoughts: **Rename Snap With → Snap Base** Rename to Snap Base is fine with me. Good to keep naming consistent **Rename Snap To → Snap Target** Rename to Snap Target is fine with me. **If another icon (e.g., a circle) would be better for the Snap Base. Keep in mind that the same icon is used for the Edge Perpendicular since it also shows the Snap Base** The icon is fine. One thing that could be nice during setting snap base is to hide the 4-arrow grab icon and only show the orange ring until setting base is done. Currently it is a little hard to see the snap base ring because of the 4-arrow icon. **New default options for snap for 4.0. Suggestion:** Snap To: Vertex & Edge & Face Project (i.e. 3 snap targets active) Affect: Move + Rotate + Scale Snap With: Median Project individual elements: True Align rotation to target: False (This setting is False by default. Just want to emphasize that I think it is good as it is) **Navigate during Transform (as default and remove as an option)** I'm not sure I know what this feature is or where to activate it. **Use the current snap options elsewhere (e.g., asset dragging and measurement tool).** Yes please! Especially for asset dragging from the asset browser
Member

I agree with @DanielBystedt

One thing to add is that certain modes or workflows might require different snapping defaults.
But the main one that comes to mind is Retopology.
I'd suggest to look at this patch to improve the snapping behavior for modeling for retopogy tasks:
https://archive.blender.org/developer/D15406
The proposed defaults would not work well for retopology at all without this patch.

I agree with @DanielBystedt One thing to add is that certain modes or workflows might require different snapping defaults. But the main one that comes to mind is Retopology. I'd suggest to look at this patch to improve the snapping behavior for modeling for retopogy tasks: https://archive.blender.org/developer/D15406 The proposed defaults would not work well for retopology at all without this patch.

Note that these changes are proposed for Blender 4.0 and therefore decisions have to be made based on the latest daily build for 4.0.

In the 4.0 last daily build, the Project individual elements option was moved to a new list of modes and is now called Face Project (See #108555)

I don't think it's a good idea to mix the Snap To options with the Snap Individual Elements To options, as the snapping of individual elements often overlaps the "Snap Base" making it confusing to use.

Note also that Navigate during Transform was a feature implemented in 33c13ae6e3. You can find this feature in the Keymap options. It is in the keymap options because, along with the new feature, some key transform modifiers need to be adjusted to avoid conflict with the navigation shortcuts. A debatable modifier key that was changed is the Proportional Editing. With the option disabled the key for Proportional Editing is just the Mouse Scroll, with the option enabled it becomes Alt + Mouse Scroll. (See #106008 for the design)

(For "Use the current snap options elsewhere (e.g., asset dragging and measurement tool)" perhaps it would be good to consider the proposed change in #107854 as snap options can be used everywhere as long as the hidden tool_settings.snap_elements_tool option is 'DEFAULT').


I see that the best default options can differ according to the intended use: placement for architecture or vertex projection for retopology. The default option should benefit most uses.

The proposed change at https://archive.blender.org/developer/D15406 suggests adding an option to the Snapping Popover to hide most of the options and internally disable what is not desirable for retopology.
Hiding options according to other option doesn't seem like a good use of the UI. Disabling internally is hardcoded and doesn't seem to be a good practice either. If we want something for dedicated use, maybe we could think about Presets. Just like Format Presets:
image

(I don't know if Presets is supported in Popovers though)
(We also have a thread on devtalk where some of these issues were discussed: https://devtalk.blender.org/t/snapping-precision-modeling-improvements/28435/35)

Note that these changes are proposed for Blender 4.0 and therefore decisions have to be made based on the [latest daily build](https://builder.blender.org/download/daily/) for 4.0. In the 4.0 last daily build, the `Project individual elements` option was moved to a new list of modes and is now called `Face Project` (See #108555) I don't think it's a good idea to mix the `Snap To` options with the `Snap Individual Elements To` options, as the snapping of individual elements often overlaps the "Snap Base" making it confusing to use. Note also that `Navigate during Transform` was a feature implemented in 33c13ae6e3. You can find this feature in the Keymap options. It is in the keymap options because, along with the new feature, some key transform modifiers need to be adjusted to avoid conflict with the navigation shortcuts. A debatable modifier key that was changed is the Proportional Editing. With the option disabled the key for Proportional Editing is just the `Mouse Scroll`, with the option enabled it becomes `Alt` + `Mouse Scroll`. (See #106008 for the design) (For "**Use the current snap options elsewhere (e.g., asset dragging and measurement tool)**" perhaps it would be good to consider the proposed change in #107854 as snap options can be used everywhere as long as the hidden `tool_settings.snap_elements_tool` option is `'DEFAULT'`). --- I see that the best default options can differ according to the intended use: placement for architecture or vertex projection for retopology. The default option should benefit most uses. The proposed change at https://archive.blender.org/developer/D15406 suggests adding an option to the Snapping Popover to hide most of the options and internally disable what is not desirable for retopology. Hiding options according to other option doesn't seem like a good use of the UI. Disabling internally is hardcoded and doesn't seem to be a good practice either. If we want something for dedicated use, maybe we could think about Presets. Just like `Format Presets`: ![image](/attachments/8072eeeb-eed1-461d-bdd9-c5063f623e26) (I don't know if `Presets` is supported in Popovers though) (We also have a thread on devtalk where some of these issues were discussed: https://devtalk.blender.org/t/snapping-precision-modeling-improvements/28435/35)
Member

@mano-wii Presets might be good. We could also have each workspace use its own snapping settings instead of having it as a Scene settings.

Note that https://archive.blender.org/developer/D15406 also introduces this functionality:

  • Vertex, Edge, Edge Center, Edge Perpendicular snapping methods apply only to edited objects.
  • Face Raycast and Face Nearest snapping methods apply only to non- edited objects.

Using Vertex and Edge edge snapping methods is very undesireable for retopology because it also applies on the high res sculpt that is retopologized. So having these enabled by default is currently not good all the time.

@mano-wii Presets might be good. We could also have each workspace use its own snapping settings instead of having it as a Scene settings. Note that https://archive.blender.org/developer/D15406 also introduces this functionality: > - Vertex, Edge, Edge Center, Edge Perpendicular snapping methods **apply only to edited objects**. > - Face Raycast and Face Nearest snapping methods **apply only to non- edited objects**. Using Vertex and Edge edge snapping methods is very undesireable for retopology because it also applies on the high res sculpt that is retopologized. So having these enabled by default is currently not good all the time.
Author
Owner

I would suggest leaving the Preset discussion separately. They are probably overkill for the task (and add complexity to something that should be simple).

I like @DanielBystedt suggestions. I would go a step further on my initial post and propose to remove the "Closest" method altogether.


Small note, while we now have an indicator of when the snap base was selected (cf967f8e08) I think it should be adjusted.

Right now the X shows the moment you press "B":

image

However it should only be visible after you manually set it.
And after I press B (in case I want to set it again) I also dont think it should show the X since we will replace it anyways.

I would suggest leaving the Preset discussion separately. They are probably overkill for the task (and add complexity to something that should be simple). I like @DanielBystedt suggestions. I would go a step further on my initial post and propose to remove the "Closest" method altogether. ---- Small note, while we now have an indicator of when the snap base was selected (cf967f8e08) I think it should be adjusted. Right now the X shows the moment you press "B": ![image](/attachments/7f77e422-798c-43c3-8f7b-35df2079f9b1) However it should only be visible after you manually set it. And after I press B (in case I want to set it again) I also dont think it should show the X since we will replace it anyways.
Author
Owner

The icon is fine

The X conflicts with this patch: #107054 . In fact if we go with #107054, we could just use whatever icon was used for the Snap Base (e.g., the square if the Snap Base was a vertex).

> The icon is fine The X conflicts with this patch: #107054 . In fact if we go with #107054, we could just use whatever icon was used for the Snap Base (e.g., the square if the Snap Base was a vertex).

Right now the X shows the moment you press "B"

I can only confirm this if the Edge Perpendicular snap mode is enabled.

The current position of the Snap Base has some importance for the Edge Perpendicular as it guides the user to find the closest point on each edge.
GIF

Without it, in this case, the user may be disoriented.

> Right now the X shows the moment you press "B" I can only confirm this if the `Edge Perpendicular` snap mode is enabled. The current position of the `Snap Base` has some importance for the `Edge Perpendicular` as it guides the user to find the closest point on each edge. ![GIF](/attachments/6364e0fe-fb46-4849-961b-f5c52ae0b034) Without it, in this case, the user may be disoriented.
103 KiB
Author
Owner

I can only confirm this if the Edge Perpendicular snap mode is enabled.

Right, and I think we should disable (filter out) edge perpendicular (and probably face) when using the Snap Base.

Picking a Snap Base should ignore any previous defined base point (both the manually set, or the automatic ones). As such any snap option that works based on a the previous frame of reference (Snap Base) shouldn't be used to pick the Snap Base.

And after I press B (in case I want to set it again) I also dont think it should show the X since we will replace it anyways.

This happens with the other Snap types.

> I can only confirm this if the Edge Perpendicular snap mode is enabled. Right, and I think we should disable (filter out) edge perpendicular (and probably face) when using the Snap Base. Picking a Snap Base should ignore any previous defined base point (both the manually set, or the automatic ones). As such any snap option that works based on a the previous frame of reference (Snap Base) shouldn't be used to pick the Snap Base. > And after I press B (in case I want to set it again) I also dont think it should show the X since we will replace it anyways. This happens with the other Snap types.

I see the point. Snap Base is being set, so apparently it shouldn't have a use during the feature.
Currently, the Edge Perpendicular uses the last calculated/set Snap Base.
At first glance, it seems reasonable to ignore Edge Perpendicular, but are there any situations where this current behavior is desirable? (I don't have any in mind right now).

Benefits:

  • Edge Perpendicular can be inconvenient to set the Snap Base
  • Cleans up the drawing by removing the X icon and making its display consistent only on confirmation.

Disadvantages:

  • The user has set Edge Perpendicular and can expect it to work somewhat in Snap Base mode.
  • It can have some useful use?

If we don't think of a good use for it in the Snap Base setting feature, I believe we can ignore it in the feature.


For Face I already think it would be strange not to support it.
And I can think of utilities like working editing over an image on the face (where the user can choose to set the Snap Base at some point in the drawing).

I see the point. `Snap Base` is being set, so apparently it shouldn't have a use during the feature. Currently, the `Edge Perpendicular` uses the last calculated/set Snap Base. At first glance, it seems reasonable to ignore `Edge Perpendicular`, but are there any situations where this current behavior is desirable? (I don't have any in mind right now). **Benefits:** - `Edge Perpendicular` can be inconvenient to set the Snap Base - Cleans up the drawing by removing the `X` icon and making its display consistent only on confirmation. **Disadvantages:** - The user has set `Edge Perpendicular` and can expect it to work somewhat in `Snap Base` mode. - It can have some useful use? If we don't think of a good use for it in the `Snap Base` setting feature, I believe we can ignore it in the feature. --- For `Face` I already think it would be strange not to support it. And I can think of utilities like working editing over an image on the face (where the user can choose to set the Snap Base at some point in the drawing).

PR created:
#108776 (Transform: Remove current 'Snap Base' in 'Set Snap Base' mode)

PR created: #108776 (Transform: Remove current 'Snap Base' in 'Set Snap Base' mode)

Apologies for the hijacking the topic, this is not a recent regression, but seems adequate to bring over snapping improvements.

For the longest time, if you have 3D View snapping enabled (magnet icon turned on), when in camera view (Numpad 0) if you move the active camera while the viewport is in camera perspective, the camera object always snaps to Increment (grid) regardless of active snap mode.

If you move the same camera from other 3D View, or from the same 3D View while not in camera perspective it behaves correctly, it moves freely unless snapping to active snap target.

In the following capture from the latest 4.0 Alpha build, default factory setting, I switched to camera view on the left 3D View, turned on snapping to vertex, only and moved the camera by grabbing the visible camera frame. If you notice the camera moves in increments which is unexpected and undesirable behavior. Moving it on the 3D View on the right you can see it moving freely.

Is this considered a bug? Should I report it separately, or do you think this can be addressed in this task?

Apologies for the hijacking the topic, this is not a recent regression, but seems adequate to bring over snapping improvements. For the longest time, if you have 3D View snapping enabled (magnet icon turned on), when in camera view (<kbd>Numpad 0</kbd>) if you move the active camera while the viewport is in camera perspective, the camera object always snaps to _Increment_ (grid) regardless of active snap mode. If you move the same camera from other 3D View, or from the same 3D View while not in camera perspective it behaves correctly, it moves freely unless snapping to active snap target. In the following capture from the latest 4.0 Alpha build, default factory setting, I switched to camera view on the left 3D View, turned on snapping to vertex, only and moved the camera by grabbing the visible camera frame. If you notice the camera moves in increments which is unexpected and undesirable behavior. Moving it on the 3D View on the right you can see it moving freely. Is this considered a bug? Should I report it separately, or do you think this can be addressed in this task? <video src="/attachments/80bb86e6-688e-42cf-935f-b648628444d1" title="Blender_SnapCamera.mp4" controls></video>

@DuarteRamos, I appreciate the concern but this behavior is intentional. It's not a bug. And I don't see it as something that should be changed.

@DuarteRamos, I appreciate the concern but this behavior is intentional. It's not a bug. And I don't see it as something that should be changed.

Ah I see, thanks for the feedback.
If you don't mind me asking what is the use case or rationale for this behavior, are there situations where this is desirable?

Adjusting camera position from camera view is generally a precision task that requires fine grained control; as it stands it becomes too coarse to be usable without pressing the Ctrl key.

This seems to contradict the snap settings. If desired, snapping to increment could be intentionally turned on to obtain the current behavior

Ah I see, thanks for the feedback. If you don't mind me asking what is the use case or rationale for this behavior, are there situations where this is desirable? Adjusting camera position from camera view is generally a precision task that requires fine grained control; as it stands it becomes too coarse to be usable without pressing the <kbd>Ctrl</kbd> key. This seems to contradict the snap settings. If desired, snapping to increment could be intentionally turned on to obtain the current behavior

To make progress on this task, I've created a new build with the changes mentioned originally.

Although issues related to Retopology, Workspaces, mouse cursors are relevant to the discussion, the solutions to these issues can become radical and can slow down the process.

The PR with the new build is !109062

The idea for now is just to test and confirm if the change is convenient for 4.0.

In the PR there are details on how to test.

To make progress on this task, I've created a new build with the changes mentioned originally. Although issues related to Retopology, Workspaces, mouse cursors are relevant to the discussion, the solutions to these issues can become radical and can slow down the process. The PR with the new build is !109062 The idea for now is just to test and confirm if the change is convenient for 4.0. In the PR there are details on how to test.

Is that right: The "Set Snap base" option for objects is working for grab mode only in Blender 4 RC?
It's not working in rotate and scale modes?

Would be good to have a continuity and get this also in scale and rotation modes. Same for edit mode.

Is that right: The "Set Snap base" option for objects is working for grab mode only in Blender 4 RC? It's not working in rotate and scale modes? Would be good to have a continuity and get this also in scale and rotation modes. Same for edit mode.

Will be an option "Set Snap Base" and "Add Snap Point" into uv window this will make it much easier to work with uv's
I'm sorry if I'm writing in the wrong task

Will be an option "Set Snap Base" and "Add Snap Point" into uv window this will make it much easier to work with uv's I'm sorry if I'm writing in the wrong task

Will be an option "Set Snap Base" and "Add Snap Point" into uv window this will make it much easier to work with uv's
I'm sorry if I'm writing in the wrong task

Some GSoC participants want to handle this task

> Will be an option "Set Snap Base" and "Add Snap Point" into uv window this will make it much easier to work with uv's > I'm sorry if I'm writing in the wrong task Some GSoC participants want to handle this task
@lexabesed committed https://projects.blender.org/blender/blender/commit/a56a97576020766a178abc2708e51f1d93324bb2
Member

I did not find a build with this PR that I can test. Can you create a build with @blender-bot @mano-wii ?

If you can, I can do some testing from an artists POV and give feedback etc

I did not find a build with this PR that I can test. Can you create a build with @blender-bot @mano-wii ? If you can, I can do some testing from an artists POV and give feedback etc

@1D_Inc, I missed the suggestion for GSoC participants, "Add Snap Point" for UV is something that is still missing and can be implemented.

@DanielBystedt, most of the proposals here have already been implemented. Some need more discussion (new Defaults, remove Snap With Closest).
It seems interesting to divide it into multiple PRs, so I created !119723 "UI: rename 'Snap With' and 'Snap To' to 'Snap Base' and 'Snap Target'" for some testing and feedback.

@1D_Inc, I missed the suggestion for GSoC participants, "Add Snap Point" for UV is something that is still missing and can be implemented. @DanielBystedt, most of the proposals here have already been implemented. Some need more discussion (new Defaults, remove Snap With Closest). It seems interesting to divide it into multiple PRs, so I created !119723 "UI: rename 'Snap With' and 'Snap To' to 'Snap Base' and 'Snap Target'" for some testing and feedback.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset System
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Asset Browser Project
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
8 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#108669
No description provided.