Operators like smooth weights, or transfer weights are exposed in
weight mode. Their definition has `OBJECT_OT_*` prefix, this appends
shortcuts key on those operators to "object mode" keymap. Use
`WM_keymap_guess_from_context` instead. This will allow new shortcut
keys to relevant keymap when object operator is exposed in 3d view.
Pull Request: https://projects.blender.org/blender/blender/pulls/137519
Pen tilt values come into Blender through ghost platforms and device
drivers with inconsistent and ambiguous directions. This PR codifies
that we consider tilt-x positive values to be rightward, negative
values as leftward. Similarly tilt-y positive is away from the user,
negative is toward the user. Comments are updated to make this clear.
This fixes Windows Ink (currently always returning left and away). This
also reverses the Wayland tily-y values to match. We might still have
to consider a user preference to swap directions if we find differences
within a platform.
Pull Request: https://projects.blender.org/blender/blender/pulls/137501
Shortcut is actually assigned to the operator but inside wrong keymap
("Animation"). When "add shortcut" is invoked for a property within
side panel or properties tab, add the new keyitem to "User Interface"
keymap.
Pull Request: https://projects.blender.org/blender/blender/pulls/137080
We have separate drag movement thresholds, and one is specifically for
tablet pen movement. A movement is not considered a drag (when using
left click select) until this amount is detected. This PR decreases
that amount with pen pressure. This results in more immediate and
responsive behavior that feels quite natural. Whether using RCS or
LCS this also similarly reduces the lag when dragging on numerical
inputs and sliders.
Pull Request: https://projects.blender.org/blender/blender/pulls/136685
This patch makes it so that the theme color is used for the
initial/loading Blender window background color. Unlike what
it may look like, theme settings are well loaded at this point
in the initialization process, which lets us directly use them
for coloring the window background instead of relying on a
default grey color.
This also makes the colored titlebar window decorations (introduced in
#123982 for macOS, #134054 for Windows 11), always blend with the window
instead of looking somewhat broken during window initialization. On the
technical side, this uses the top-bar header background theme color to
ensure this always matches with the color used by the colored titlebar.
Pull Request: https://projects.blender.org/blender/blender/pulls/137425
So far it was only possible to relocate a whole library, now one can
also relocate a single linked ID (pulling in all of its dependencies).
This is essentially linking the new data, remapping local usages of the
old linked data to the new one, removing no more used IDs, and updating
liboverrides if needed.
This patch adds initial cursor support for the blade tool, with bitmaps
for 16x16, 24x24, and 32x32 cursors.
Additional Changes:
- Locked strips now show a "stop" icon when hovered over.
- Previously, the frame to split was truncated when clicking in between frames.
Now, round to the closest frame.
- Previously, the blade operator was able to select padded strip handles
outside of strip bounds. This bug has been resolved, so that selection with
the blade tool can only happen via box-select passthrough.
Pull Request: https://projects.blender.org/blender/blender/pulls/136749
Regression in [0] which incorrectly swapped the check for the
`use_scripts` property being set with the value it was set to.
Resolve this error as well as the "Recover Last" operator
which never worked.
[0]: 8c688a052c
Regression in [0], buffer overflow reading a short array as floats.
Support short array and fix glitch where the mouse cursor wasn't
included in the poly-line.
[0]: 9d4d1aea98
Gizmos that contain 3D parts, like the rounded lines of the "Rotate"
gizmo, have a fairly small hit size that make it hard to grab with a
tablet pen. This PR just increases the radius around the pointer
position while using a pen.
Pull Request: https://projects.blender.org/blender/blender/pulls/136847
Some OpenXR platforms do not support OpenGL or Vulkan. To support these
platforms we use a bridge. Blender still renders in OpenGL/Vulkan, but
will copy the render result into a D3D11 swapchain.
OpenGL doesn this by importing the D3D11 swapchain into the OpenGL
context and perfor OpenGL calls to update the swapchain. However for
vulkan that could lead to construct 3 context for OpenXR
- Blender GPU Context
- OpenXR D3D Context
- New context that imports the Blender render result and the OpenXR
Swapchain image and copies them.
Due to Direct3D limitations importing into a vulkan context has known
issues (driver + extensions). Secondly we are not sure if we are running
on the same device as the OpenXR swapchain. The solution provided with
this PR is to only support CPU data transfers.
**SteamVR using d3d bridge**
SteamVR normally would use the Vulkan binding. But by changing the binding
priority in code you can make it select the D3D bridge.
<img width="1518" alt="Screenshot 2025-04-10 114534.png" src="attachments/f856bb2b-9ad5-4bb2-9cfd-a1412da9edd1">
It has been tested and validated to work using Mixed reality portal as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/137264
Part of #82877
When drawing specialized cursors for the different paint modes via the
`wmPaintCursor` draw callback, tablet tilt direction is unavailable to
use to customize the drawing for the user.
To enable this functionality, this commit adds the `x_tilt` and `y_tilt`
data read while processing MOUSEMOVE events to the `eventstate` variable
so it can be used by consuming functions.
Pull Request: https://projects.blender.org/blender/blender/pulls/137189
Even though the default startup already has `Trusted Source` and
`Auto Run Python Scripts` off by default, when resetting their values
to default (right click, Reset to Default) they would be turned on.
It was simply missing explicitly setting this off by default.
Pull Request: https://projects.blender.org/blender/blender/pulls/137205
Failure to refresh the highlighted gizmo meant that clicking
on a highlighted gizmo would attempt to activate it even though
it's poll function failed - which crashed in this case.
Resolve the common-case by ensuring a call to refresh the gizmo-map
causes the event system to re-evaluate the highlighted gizmo,
even if the cursor doesn't move.
Since it's still possible the call to "refresh" the gizmo is missed,
gizmo_tweak_invoke now checks the gizmo-groups poll succeeds with an
assert and early return if it doesn't. This would have prevented the
crash although the highlighted-gizmo still won't be reset - causing
the cursor to display as if it's over a gizmo until it's moved.
`radial_control_modal` would only actually update the target property
(via `RNA_property_update`) for the "standard" ways of confirming
(`LEFTMOUSE`, `EVT_PADENTER`, `EVT_RETKEY`).
When using "release_confirm" however, that was skipped, so added the
`RNA_property_update` now.
Pull Request: https://projects.blender.org/blender/blender/pulls/136884
Current implementation uses a CPU roundtrip to transfer render result
to the Xr Swapchain. This PR adds support for sharing the render result
on Linux systems by using file descriptors.
To extend this solution to win32 or dx handles can be done by extending
the data transfer modes, register the correct extensions. When not
using the same GPU between Blender and OpenXR the CPU roundtrip
will still be used.
Solution has been validated with monado simulator and seems to be as
fast as OpenGL.
Performance can be improved by using GPU based synchronization.
Current API is limited as we cannot chain the different renders and
swapchains.
Pull Request: https://projects.blender.org/blender/blender/pulls/136933
GPU_DEPTH_NONE leads to issues with Intel GPU drivers on Windows
where camera gizmos cannot be shifted. glGetQueryObjectuiv for
GL_SAMPLES_PASSED seems to return zero in all cases.
This might be due to undefined behavior of OpenGL when the depth
test is disabled and rendering to a depth render target-only
framebuffer. Using GPU_DEPTH_ALWAYS fixes the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/136607
`win->ime_data` could be non-null when it's read from a file, and
subsequent dependence of this value would crash on interface handlers.
Now always clear it when ghost window is ensured after reading the file.
The actual reset is put in `wm_window_ensure_eventstate`, since it's
also conceptually a part of "event state".
Pull Request: https://projects.blender.org/blender/blender/pulls/136833
Use enum types for event modifier and types,
`wmEventModifierFlag` & `wmEventType` respectively.
This helps with readability and avoids unintended mixing with other
types. To quiet GCC's `-Wswitch` warnings many `default` cases needed
to be added to switch statements on event types.
Ref !136759
MacOS generally uses mouse cursors we specifically made for that
platform. But in some cases, like WM_CURSOR_WAIT, the OS does not have
an equivalent and we don't have a platform-specific one. So it then
uses of of our base custom cursors. This type of cursor is always
enlarged on Mac high-DPI displays like Retina. So no need to ever
supply larger versions of this type of cursor as it will just get
huge.
Pull Request: https://projects.blender.org/blender/blender/pulls/136005
Part of incoming refactors in interface layout c++ code, this enables
forward declaring this enum type. Enum is renamed as `EmbossType` and
moved to `blender::ui` namespace. No user visible changes expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/136725
The Blender config.ocio does not have any rules, but custom ones can.
The default file rule is ignored if default_byte or default_float roles
exist. These roles are Blender specific, so would not be found in a typical
OCIO config. But when they are set appropriately, they help provide better
default guesses than what is possible with standard OCIO rules.
Pull Request: https://projects.blender.org/blender/blender/pulls/136516
The Blender's VkInstance cannot be shared with OpenXR VkInstance. The
reason is a chicken and egg problem where OpenXR needs to be started
before Vulkan. OpenXR can add special vulkan specific requirements
(instance&device) that are only available when the user starts an OpenXR
session.
The goal implementation is to share memory between both instances using
[VK_KHR_external_memory](https://registry.khronos.org/vulkan/specs/latest/man/html/VK_KHR_external_memory.html) and related extensions. However this seems
to be a bridge to far as a initial step. Reason: There are not that many
samples/ guides and documentation to be found to handle the workflow that
we require. We want to do a smaller step by step approach to gain the needed
knowledge.
For that reason this PR does the most stupidest thing that can be done to
share memory between instances. Download the render result to CPU RAM share
the host pointer with the OpenXR instance which copies it to the swap chain.
Also the synchronization is done using wait idle commands.
<video src="attachments/32a0d69b-c3fa-4272-aea0-d207609afaaf" title="Screencast From 2025-03-18 11-16-17.webm" controls></video>
**Gaining knowledge**
- Experiment with `VK_KHR_external_memory_host` extension for uploading vertex buffers (not related to OpenXR).
- Import host pointer with `VK_KHR_external_memory_host`. This reduces the additional
memcpy on OpenXR side.
- Export host pointer from Blender side from a mappable buffer.
- Replace host pointers with fd/dmabuf/winhandle
- Remove mappable buffer.
Ref #133718
Pull Request: https://projects.blender.org/blender/blender/pulls/133824
Even though the doc-string notes that they're only used for
function parameters, it looks as if they might be used for
`wmEvent::modifier` and are exposed in a prominent location.
Remove the flags & replace them with a macro that bit-shifts the
existing modifier values which is more clearly intended to be used
with `KeyMapItem_Params`.
Ref !136539
Add support for a 5th modifier key called "hyper",
this is a modifier supported on Wayland & X11 although
other platforms could support an additional modifier too.
Both GNOME and KDE can map CapsLock to Hyper.
Other compositors can use the XKB_DEFAULT_OPTIONS environment variable.
This allows users to have an additional modifier for their own use
that doesn't conflict with other keys.
Ref !136340
Rename to be more consistent with other Blender keymaps, as well as the
naming convention used in "View Type."
- "SequencerCommon" -> "Video Sequence Editor"
- "SequencerPreview" -> "Preview"
- "Sequencer Timeline Tool" -> "Sequencer Tool"
- "Sequencer Preview Tool" -> "Preview Tool"
There is versioning in place to make sure custom keyconfigs keep working.
Once #131102 goes through, if we would like to rename the "Sequencer"
view type to "Timeline" or "Sequencer Timeline," then we can make the
necessary changes here too.
Pull Request: https://projects.blender.org/blender/blender/pulls/136217
Some of the existing logic checked that modifiers were KM_MOD_HELD,
other logic checked the value wasn't KM_NOTHING or KM_ANY.
Simplify checks by comparing against KM_MOD_HELD in all cases
as this won't be set to other values.
- Document values to use for modifiers in code-comments.
- Only compare modifier values with KM_ANY/NOTHING/MOD_HELD.
- Use smaller integer sizes where possible.
