Since [0], transform gizmos are no longer hidden during transform.
The same can be observed for rotation gizmos.
However, as a workaround for these rotation gizmos, there was already a
drawing utility running.
With the gizmo and the utility this drawing is now being done twice.
So remove the utility/workaround and update the gizmo accordingly.
[0] {648350e456490f8d6258e7de9bf94d3a6a34dbb2}
Differential Revision: https://developer.blender.org/D9542
The transformation snapping code contains a bunch of `#define`s, some ambiguously or incorrectly named attributes. This patch contains refactored code to improve this. This patch does (should) not change functionality of snapping.
Clarified ambiguously / incorrectly named attributes.
- "Target" is used to refer to the part of the source that is to be snapped (Active, Median, Center, Closest), but several other areas of Blender use the term "target" to refer to the thing being snapped to and "source" to refer to the thing getting snapped. Moreover, the implications of the previous terms do not match the descriptions. For example: `SCE_SNAP_TARGET_CENTER` does not snap the grabbed geometry to the center of the target, but instead "Snap transforamtion center onto target".
- "Select" refers to the condition for an object to be a possible target for snapping.
- `SCE_SNAP_MODE_FACE` is renamed to `SCE_SNAP_MODE_FACE_RAYCAST` to better describe its affect and to make way for other face snapping methods (ex: nearest).
Refactored related `#define` into `enum`s. In particular, constants relating to...
- `ToolSettings.snap_flag` are now in `enum eSnapFlag`
- `ToolSettings.snap_mode` are now in `enum eSnapMode`
- `ToolSettings.snap_source` (was `snap_target`) are now in `enum eSnapSourceSelect`
- `ToolSettings.snap_flag` (`SCE_SNAP_NO_SELF`) and `TransSnap.target_select` are now in `enum eSnapTargetSelect`
As the terms became more consistent and the constants were packed together into meaningful enumerations, some of the attribute names seemed ambiguous. For example, it is unclear whether `SnapObjectParams.snap_select` referred to the target or the source. This patch also adds a small amount of clarity.
This patch also swaps out generic types (ex: `char`, `short`, `ushort`) and unclear hard coded numbers (ex: `0`) used with snap-related enumerations with the actual `enum`s and values.
Note: I did leave myself some comments to follow-up with further refactoring. Specifically, using "target" and "source" consistently will mean the Python API will need to change (ex: `ToolSettings.snap_target` is not `ToolSettings.snap_source`). If the API is going to change, it would be good to make sure that the used terms are descriptive enough. For example, `bpy.ops.transform.translate` uses a `snap` argument to determine if snapping should be enabled while transforming. Perhaps `use_snap` might be an improvement that's more consistent with other conventions.
This patch is (mostly) a subset of D14591, as suggested by @mano-wii.
Task T69342 proposes to separate the `Absolute Grid Snap` option out from `Increment` snapping method into its own method. Also, there might be reason to create additional snapping methods or options. (Indeed, D14591 heads in this direction). This patch can work along with these suggestions, as this patch is trying to clarify the snapping code and to prompt more work in this area.
Reviewed By: mano-wii
Differential Revision: https://developer.blender.org/D15037
Unlike 3Dview snapping, UV snapping is always done to the UV closest to
the mouse cursor, no matter the distance.
From the user's point of view, this appears to be an inconsistency (See
{T93538}).
Therefore, set a minimum distance for snapping and, as in 3D View and
highlight the snap with a drawing of a circle.
Release Note: https://wiki.blender.org/wiki/Reference/Release_Notes/3.3/Modeling
Reviewed By: #uv_editing, campbellbarton
Maniphest Tasks: T93538
Differential Revision: https://developer.blender.org/D13873
The editing data of a `SURF`s is similar to that of Curves and should be supported for snapping.
But unlike Curve objects, for snapping, only support the nurb points if the object is in edit mode.
This matches the solution for Meshes and avoids having to create a kind
of "boundbox" for the SURF nurb points.
The solution supposedly listed all cases that `absolute grid snapping`
was supported. But it ignored some occasions like: Editing Surface
objects, Texture Space.
List now only the cases where this feature should not be supported.
This was a mistake in the conditional structure introduced in 4b35d6950d
This commit also adds a new type of snap exclusion: `SNAP_NOT_EDITED`.
Thanks to @Ethan1080 for pointing out the error.
`3DView`'s `use_snap` option has little or nothing to do with using
snapping in `UV`, `Nodes` or `Sequencer`.
So there are no real advantages to keeping these options in sync.
Therefore, individualize the option to use snap for each "spacetype".
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D13310
Using flags makes checking multiple modifiers at once more convenient
and avoids macros/functions such as IS_EVENT_MOD & WM_event_modifier_flag
which have been removed. It also simplifies checking if modifier keys
have changed.
This commit renames enums related the "Curve" object type and ID type
to add `_LEGACY` to the end. The idea is to make our aspirations clearer
in the code and to avoid ambiguities between `CURVE` and `CURVES`.
Ref T95355
To summarize for the record, the plans are:
- In the short/medium term, replace the `Curve` object data type with
`Curves`
- In the longer term (no immediate plans), use a proper data block for
3D text and surfaces.
Differential Revision: https://developer.blender.org/D14114
This is a regression partially introduced in rB0a6f428be7f0.
Bones being transformed into edit mode were snapping to themselves.
And the bones of the pose mode weren't even snapping.
(Curious that this was not reported).
Use a shorter/simpler license convention, stops the header taking so
much space.
Follow the SPDX license specification: https://spdx.org/licenses
- C/C++/objc/objc++
- Python
- Shell Scripts
- CMake, GNUmakefile
While most of the source tree has been included
- `./extern/` was left out.
- `./intern/cycles` & `./intern/atomic` are also excluded because they
use different header conventions.
doc/license/SPDX-license-identifiers.txt has been added to list SPDX all
used identifiers.
See P2788 for the script that automated these edits.
Reviewed By: brecht, mont29, sergey
Ref D14069
Regression introduced in rB098008f42d8127d9b60717c7059d3c55a3bfada7
Previously the selected geometry was ignored along with the hidden one.
The mentioned commit caused neither the hidden nor the selected one to be ignored.
But hidden geometry needs to be ignored.
Operator was erroneously starting edge_slide operation.
Revert part of the changes in rB3fab16fe8eb4 as obedit_type was being
confused with object_mode.
This patch implements part of what was stated in {T66484}, with respect to `Base Point`.
## Introduction
The snapping feature of the transform tools has a variety of applications:
- Organization of nodes.
- Positioning of frames in precise time units.
- Retopology with snap to face
- Creation of armatures with bone positioning through the snap to volume
- Precise positioning of 3D or 2D objects in the surrounding geometry (CAD modeling)
The goal of this document is to make it more powerful for precision modeling and still supporting the old use cases without extra complexity.
The main topic addressed here is the introduction of a **interactive mode for setting a snap source** (See terminology).
## Terminology
* **Snap Source**: 3d coordinate * we want to snap from. (Currently defined by the `Snap With` options: `Closest`, `Center`, `Median` and `Active`).
* **Snap Target**: 3d coordinate* we want to snap to. (Vertices, Edges, Faces, Grid...)
## Interactive Mode for Editing a Snap Source
Currently the fixed snap point can only be obtained through the `Snap With` options. So it's a little tricky for the user to define a snap source point having so much geometry on an object.
Because of this, the user needs to resort to impractical solutions to get a point in the geometry.
See example of an impractical use:
{F11714181, layout=left, width=960, alt="The user used the cursor (which can be snapped) to choose the snap origin point."}
The user used the cursor (which can be snapped) to choose the snap source point.
While it is possible to work around this current limitation, it is important to reduce the number of steps and allow the user to set a snap source point through an optional interactive mode during a transformation.
The proposed solution is to be able to move the current snap source point through a modal modifier activated with a key (eg. B).
The snap source point can thus "snap" to the elements in the scene (vertex, mid-edge, Lamp, …) during this mode.
{F9122814, layout=left, width=960, alt="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."}
## Implementation Details
- The feature will only be available in 3D View.
- The feature will only be available for `Move`, `Rotate` and `Scale` transform modes.
- The snap source editing will be enabled with a single click on the modifier key (B).
- Having a snap point indicated, the new snap origin point will be confirmed with the same buttons that confirms the transformation (but the transformation will not be concluded).
- The snap source editing can be canceled with the same key that activated it (B).
- If the transformation is done with "release_confirm" (common for gizmos), the new feature cannot be enabled.
- During the transformation, when enabling the feature, if the snap option is turned off in the scene, the snap will be forced on throughout the rest of the transformation (unless interactive mode is canceled).
- During a transformation, if no snap target is set for an element in the scene (Vertex, Grid...), the snap targets to geometry Vertex, Edge, Face, Center of Edge and Perpendicular of Edge will be set automatically.
- Snap cannot be turned off during the snap source editing.
- Constraint or similar modification features will not be available during the snap source editing.
- Text input will not be available during the snap source editing.
- When adding multiple snap points (A) the new prone snap source point will be indicated with an "X" drawing.
{F11817267}
Maniphest Tasks: T66484
Differential Revision: https://developer.blender.org/D9415
Move most of the gizmo snap and placement code to `view_cursor_snap.c`.
Simplify and extend the snap API.
Differential Revision: https://developer.blender.org/D12868
Regression introduced in {rBb0d9e6797fb8}.
Previously the Graphics Editor had a conflict with two different snap
types. Auto-Snap and Snap with Ctrl.
It is now clearer which snap should prevail.
Implements T89789, T89792, custom grid (described as dynamic grid in
T78389) and UV grid snapping (T78391)
Replaces the default UV editor grid with 2 new types of grid :
* Custom grid: Allows the user to create an NxN grid, where the value
of N is specified by the user.
* Subdividing grid: Subdivides the UV editor grid when the user
zooms in the viewport and vice versa when zooming out.
UV snapping improvements :
* Increment snapping: Increment values for snapping are calculated based
on which grid type is being used in the UV editor
(subdividing or custom). In general the increment value is equal to
the distance between 2 visible grid lines.
* Absolute grid snap: New toggle added to increment snapping option in
the UV editor, allows UV grid snapping during translation.
Reviewed By: campbellbarton
Ref D12684
Address initial feedback:
- Use checkboxes instead of radio buttons
- Hide snapping distance control from UI
- Tweak snapping line color - use selected strip color, 50% transparency. Similar to other editors
- Draw 2px thick line, since strip outline is also 2px thick
Reviewed By: HooglyBoogly
Differential Revision: https://developer.blender.org/D11759
Change snapping behavior to snap strip edges when they are close to snap point.
Default behavior is, that each transformed strip is snapped to any other strip.
Implement snapping controls in sequencer tool settings. These controls include:
- Snapping on/off
- Ability to snap to playhead and strip hold offset points
- Filter snap points by excluding sound or muted strips
- Control snapping distance
Snapping controls are placed in timeline header similar to 3D viewport
Reviewed By: mano-wii
Differential Revision: https://developer.blender.org/D11646
Use const arguments to simplify further optimizations.
Transforming elements shouldn't need to change their containers
data-structures.
ElementResize for grease pencil stroke thickness was
modifying TransInfo.num & TransInfo.values_final.
Now copies are operated on to preserve const correctness although
it's worth investigating if this can be avoided altogether.
