In perspective mode the snap point direction needs to be taken into
account to define which side of the face is being looked at.
If there is no face under the mouse cursor, there is no direction
adjustment and the element normal will be used.
Walk mode implemented it's own grab which relied on WM_cursor_warp
to work (which isn't implemented for wayland).
Resolve this by using WM_cursor_grab_{enable/disable}.
Besides fixing Wayland this removes the need for workarounds:
- Ensure the event received were after the event generated from warping.
- Alternate logic that reset the "center" when using tablets.
- Checking the cursor location was scaled by native-pixels on macOS.
There is a minor change in behavior: on completion the cursor is left
at the location walk-mode began instead of the center of the region.
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
Add support for adding (inserting) new background images into an
override of a linked Camera ID.
Request from the Blender studio.
This ended up being more involved than expected as it uncovered some
latent issues with existing background images code. Noticiably, a new
`BKE_camera_background_image_copy` had to be added to handle copying
of background images in a proper, generic ID-management way.
Assuming that an ID pointer is NULL because another 'source type'
property has some specific value is utterly wrong and a gateway to
usercounting bugs.
Dropping would pass the name of the ID to drop to the properties of the
drop operator. This would then lookup the ID by name. With linking
and/or library overrides, multiple IDs of the same name and type may
exist, which is why the session UUID should be used instead. All
operators used for dropping support this now and the drop code passes
the session UUID instead of the name.
Also see 917c096be6 and 8f79fa9c67.
Some drop operators were already using the session UUIDs. This converts
the remaining ones. The "name" property is kept working as before, since
some scripts use this.
Side-effect: The "Name" property won't show up in the Adjust Last
Operation anymore, which was the case for some of these operators, and
its value won't be remembered over multiple executions of the operator.
Both were not at all useful from what I can tell, and I doubt this was
done intentionally.
8f79fa9c67 was an attempt to fix this already, but it didn't quite
work. Problem was that the tooltip was messing with the drop-box and
operator properties, setting the name property for its own internal
logic. This name property would then be used rather than the session
UUID to query the material, which gave the wrong material (linking can
result in multiple IDs of the same type with the same name). A followup
commit will further sanitize this.
917c096be6 applied to objects only, this also applies the same fix for
the general 3D View drop operations, e.g. used for dragging materials,
images, worlds, etc.
This is needed to fix T95706, but apparently something else is still
going on. Needs further investigation.
The operators to handle object drag and drop (from the asset browser,
outliner, etc.) used the object name to find the object to add and
place. This is problematic with linking and/or library overrides, since
this may lead to multiple objects with the same name. So the wrong
object would be used by the drop operators.
Partially fixes T97320. T95706 probably needs the same fix but for
materials.
As a side-effect, the "Name" button won't show up in the Adjust Last
Operation panel anymore. This isn't really useful, and I doubt this was
ever intentionally exposed in the UI.
The operators to handle object drag and drop (from the asset browser,
outliner, etc.) used the object name to find the object to add and
place. This is problematic with linking and/or library overrides, since
this may lead to multiple objects with the same name. So the wrong
object would be used by the drop operators.
Partially fixes T97320. T95706 probably needs the same fix but for
materials.
As a side-effect, the "Name" button won't show up in the Adjust Last
Operation panel anymore. This isn't really useful, and I doubt this was
ever intentionally exposed in the UI.
It wasn't possible to temporarily orbit the view, then set back to an
axis-aligned view.
Details:
- It was possible to change RegionView3D.view_rotation while the view
kept the axis alignment value (Top, Left, Front .. etc) which
displayed in the viewport overlay.
Now changing the view rotation directly or via "view_matrix" resets
the axis-alignment - clearing when the view is no longer axis-aligned
or assigning the newly aligned axis.
- RegionView3D.is_orthographic_side_view added in [0] could be assigned
but wasn't useful as it treated an enum as a boolean only setting the
RegionView3D.view to RV3D_VIEW_USER or RV3D_VIEW_FRONT.
Now enabling this aligns the viewport rotation to it's closest
axis-aligned orientation setting RegionView3D.view & view_axis_roll
accordingly. Note that the "orthographic" term is misleading as the
property only relates to axis-alignment, not to the
perspective/orthographic setting. We could consider deprecating the
current naming.
[0]: 63bae864f4
View roll checked if the resulting roll was close to a view axis
but didn't write the aligned quaternion back to the final result.
Add ED_view3d_quat_to_axis_view_and_reset_quat since most callers
to ED_view3d_quat_to_axis_view will reset the quaternion when a view
aligned axis is found.
Headers should only include other headers when absolutely necessary,
to avoid unnecessary dependencies and increasing compile times.
To make this change simpler, three DerivedMesh functions with a single
use were removed.
Recalc selection count at the end of the circle selection.
This was removed from circle selection as it became a performance
bottleneck, helas some operators rely on it.
This should have no functional changes.
This reduce the complexity of the shader by only supporting 2 colors.
We never use more than 2 color in practice and this makes usage not require
a UBO.
This allows object extras such as image-empties to be shown in the VR
viewport/headset display. Being able to see reference images in VR can
be useful for architectural walkthroughs and 3D modeling applications.
Since users may not want to see all object extras (lights, cameras,
etc.), per-object-type visibility settings are also added as session
options.
By slightly refactoring the definition of the 3D View object types
visibility panel (note: no functional changes), the VR Scene Inspection
add-on can show a similar panel without duplicating code. When VR
selection is possible in the future, the object type select options can
also be enabled.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D14220
Recent cleanups 9a8669ac81 and 1c790555a0
incorrectly interpereted the bitfield width syntax as a default
value. Also resolve two other compilation warnings.
If the measure gizmo is enabled, its snap state is used in the snap update.
As it does not require a plane, the orientation of the plane is not
calculated.
However, the calculation of the plane's orientation must prevail over
the states.
Split 'ED_view3d_cursor_snap_data_get' into 'update' and 'get' functions
Sometimes we just want to update and sometimes we just get the result.
Make it clear.
This patch adds the drag and drop strip previews in the VSE.
It also adds two new functions to the drag and drop API.
1. "draw_in_view" for callbacks that wants to draw elements in local viewport coordinates
2. "on_drag_start" that can be used for prefetching data only once at the start of the drag.
Reviewed By: Julian, Campbell
Differential Revision: http://developer.blender.org/D14560
View moves faster with two active directions.
This is probably because `dvec` is not normalized when moving in two directions.
Normalizing this direction vector will fix the problem.
Differential Revision: https://developer.blender.org/D14729
The "PROP" in the name reflects its generic status, and removing
"LOOP" makes sense because it is no longer associated with just
mesh face corners. In general the goal is to remove extra semantic
meaning from the custom data types.
Continuing the refactors described in T93602, this commit moves
the face dot tag set by the subdivision surface modifier out of
`MVert` to `MeshRuntime`. This clarifies its status as runtime data
and allows further refactoring of mesh positions in the future.
Before, `BKE_modifiers_uses_subsurf_facedots` was used to check
whether subsurf face dots should be drawn, but now we can just check
if the tags exist on the mesh. Modifiers that create new new geometry
or modify topology will already remove the array by clearing mesh
runtime data.
Differential Revision: https://developer.blender.org/D14680
Unlike regular selection cycling that is activated when clicking again
in the same location, object mode would cycle to another object
if the object that was selected happened to already be active.
This made it impossible to click-drag to tweak the active object
if there were other objects behind it as those would be activated first.
Resolves T96752.
Use Alt-Slash to remove objects from local-view (was M prior to [0]),
following the convention of using Alt to perform the reverse of an
action. Also remove the confirmation menu as this key as it can be
undone and it's not likely to be pressed by accident.
This can be useful to quickly subtract items from a complex selection
with items that only become visible when entering local-view.
The M key was originally used in 2.4x since moving between layers wasn't
possible. Now moving between collections is possible in local-view
the keys collided.
[0]: cf5d582b77
This patch adds color attributes to TexPaintSlot. This allows an easier selection
when painting color attributes.
Previously when selecting a paint tool the user had to start a stroke, before the
UI reflected the correct TexPaintSlot. Now when switching the slot the active
tool is checked and immediate the UI is drawn correctly.
In the future the canvas selector will also be used to select an image or image texture node
to paint on. Basic implementation has already been done inside this patch.
A limitation of this patch is that is isn't possible anymore to rename images directly from
the selection panel. This is currently allowed in master. But as CustomDataLayers
aren't ID fields and not owned by the material supporting this wouldn't be easy.
{F12953989}
In the future we should update the create slot operator to also include color attributes.
Sources could also be extended to use other areas of the object that use image textures
(particles, geom nodes, etc... ).
Reviewed By: brecht
Maniphest Tasks: T96709
Differential Revision: https://developer.blender.org/D14455
The internal camera used to render the thumbnails also has to consider
`clip_start` and `clip_end`.
Reviewed By: Severin
Maniphest Tasks: T95678
Differential Revision: https://developer.blender.org/D14138
Replace 5 arguments with a single struct as the same arguments
are used in many places.
This didn't read well and was confusing with both arguments named
`val` & `value` in the case of WM_modalkeymap_add_item.
