Adds navigation transforms (pose, scale) to the XR session state that
will be applied to the viewer/controller poses. By manipulating these
values, a viewer can move through the VR viewport without the need to
physically walk through it.
Add-ons can access these transforms via Python
(XrSessionState.navigation_location/rotation/scale) to use with custom
operators.
Also adds 3 new VR navigation operators that will be exposed to users
as default actions in the VR Scene Inspection add-on. While all three
of these operators have custom properties that can greatly influence
their behaviors, for now these properties will not be accessible by
users from the UI. However, other add-ons can still set these custom
properties if they desire.
1). Raycast-based teleport
Moves the user to a location pointed at on a mesh object. The result
can optionally be constrained to specific axes, for example to achieve
"elevation snapping" behavior by constraining to the Z-axis. In
addition, one can specify an interpolation factor and offset.
Credit to KISKA for the elevation snapping concept.
2). "Grab" navigation
Moves the user through the viewport by pressing inputs on one or two
held controllers and applying deltas to the navigation matrix based on
the displacement of these controllers. When inputs on both controllers
are pressed at the same time (bimanual interaction), the user can scale
themselves relative to the scene based on the distance between the
controllers.
Also supports locks for location, rotation, and scale.
3). Fly navigation
Navigates the viewport by pressing a button and moving/turning relative to
navigation space or the VR viewer or controller. Via the operator's
properties, one can select from a variety of these modes as well as
specify the min/max speed and whether to lock elevation.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D11501
The drag and drop feature of objects in 3D View has been modified to include:
- Snap the object being dragged.
- Visual feedback through a box and the placement tool grid.
Maniphest Tasks: T90198
Differential Revision: https://developer.blender.org/D12912
No functional changes.
This commit adds 3 callbacks for `wmDropBox` which allow custom drawing
without affecting the internal dropbox API.
Differential Revision: https://developer.blender.org/D12948
Fixes a crash when blend thumbnails set to Camera View when there is
no camera, which resulted in use of a null region.
See D12748 for more details.
Differential Revision: https://developer.blender.org/D12748
Reviewed by Campbell Barton
When appending an asset from the asset browser, its asset data needs to
be cleared.
However, linking an asset (or regular append from the file browser)
should not clear such data. In linking case, it would be there again
after a blend file reload anyway.
So this commit introduces a new `BLO_LIBLINK_APPEND_ASSET_DATA_CLEAR`
option.
NOTE: in case the appended ID needs to be copied from its linked data
(instead of making the later directly local), asset data is lost anyway
since it is never copied with the ID currently.
Ref. {T91749} and D11768.
This change simplifies the parameter list for these functions
and reduces the chance of typos mixing up array indices.
Missed in rB69102786047dccdcbaee0df6307a8c3364d28fe0.
De-duplicates wm_append_loose_data_instantiate_object_base_instance_init
and object_base_instance_init.
Add BLO_object_instantiate_object_base_instance_init which also adds to
a collection since all callers did this.
Use arrays for wmEvent coordinates, this quiets warnings with GCC11.
- `x, y` -> `xy`.
- `prevx, prevy` -> `prev_xy`.
- `prevclickx, prevclicky` -> `prev_click_xy`.
There is still some cleanup such as using `copy_v2_v2_int()`,
this can be done separately.
Reviewed By: campbellbarton, Severin
Ref D12901
Make the snap system consistent with the placement tool and leak-safe.
**Changes:**
- Store `SnapCursorDataIntern` in a `static` variable;
- Initialize (lazily) `SnapCursorDataIntern` only once (for the keymap).
- Move setup members of `V3DSnapCursorData` to a new struct `V3DSnapCursorState`
- Merge `ED_view3d_cursor_snap_activate_point` and `ED_view3d_cursor_snap_activate_plane` into `state = ED_view3d_cursor_snap_active()`
- Merge `ED_view3d_cursor_snap_deactivate_point` and `ED_view3d_cursor_snap_deactivate_plane` into `ED_view3d_cursor_snap_deactive(state)`
- Be sure to free the snap context when closing via `ED_view3d_cursor_snap_exit`
- Use RNA properties callbacks to update the properties of the `"Add Primitive Object"` operator
No longer save asset catalogs on blendfile save. Instead:
- extend the confirmation prompt for unsaved changes to show unsaved
catalogs.
- In the confirmation prompt, make catalog saving explicit & optional,
just like we do it for external images. {F10881736}
- In the Asset Browser catalog tree, show an operator icon to save the
catalogs to disk. It's grayed out if there are no changes to save, or
if the .blend wasn't saved yet (required to know where to save the
catalog definitions to). {F10881743}
Much of the work was done by @Severin and reviewed by me, then we
swapped roles.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D12796
In 2.93 and before, when appending wityh 'localize all' off, all linked
IDs (including indirectly linked ones) from initial library would be
made local.
In 3.0, after refactor from rB3be5ce4aad5e, only directly linked IDs
(i.e. user-selected IDs) would be made local.
This change was not intentional (result of confusing code and naming in
previous implementation), and old behavior is used in some workflows to
control which data is kept linked and which data is made local.
This commit revert to 2.93 behavior.
NOTE: there is still an (extreme) corner case where behavior is
different between 2.93 and 3.0:
If you append (at the same time) object A from LibA.blend, and object B
from LibB.blend, and object B uses somehow a material from LibA.blend:
* In 2.93, that material would have been made local (because it belonged
to one of the 'initial' libraries, even though not the initial lib of
object B).
* In 3.0, this material will remain linked, since from object B
persective it comes from a different library.
There was a rare crash in WM_event_get_keymap_from_toolsystem_fallback
when wm->winactive was NULL.
This could happen when the event was handled
immediately after closing a window.
Keep track of the source library allowing other parts of the code to
to make better decisions. This is needed to localize external files.
In this case the file paths are updated when `making local`.
But we should decide based on the source library if we want to
copy the file relative to the new blend file. See D12423.
Reviewed By: mont29, Severin
Differential Revision: https://developer.blender.org/D12765
Addresses T77127 (Controller Drawing).
Adds VR controller visualization and custom drawing via draw
handlers. Add-ons can draw to the XR surface (headset display) and
mirror window by adding a View3D draw handler of region type 'XR' and
draw type 'POST_VIEW'. Controller drawing and custom overlays can be
toggled individually as XR session options, which will be added in a
future update to the VR Scene Inspection add-on.
For the actual drawing, the OpenXR XR_MSFT_controller_model extension
is used to load a glTF model provided by the XR runtime. The model's
vertex data is then used to create a GPUBatch in the XR session
state. Finally, this batch is drawn via the XR surface draw handler
mentioned above.
For runtimes that do not support the controller model extension, a
a simple fallback shape (sphere) is drawn instead.
Reviewed By: Severin, fclem
Differential Revision: https://developer.blender.org/D10948
Integrates XR input actions with the WM event system. With this commit,
all VR action functionality (operator execution, pose querying, haptic
application), with the exception of custom drawing, is enabled.
By itself, this does not bring about any changes for regular users,
however it is necessary for the upcoming VR add-on update that will
expose default controller actions to users.
For add-on developers, this updates the Python API with access to XR
event data (input states, controller poses, etc.), which can be
obtained via the "xr" property added to the bpy.types.Event struct.
For XR events, this property will be non-null and the event will have
the type XR_ACTION.
Further details:
XR-type window events are queued to the regular window queues after
updating and interpreting VR action states. An appropriate window is
found by either using the window the VR session was started in or a
fallback option.
When handling XR events, mouse-specific processing is skipped and
instead a dedicated XR offscreen area and region (see 08511b1c3d) is
used to execute XR event operators in the proper context.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D10944
Previously this was only happening when "Load UI" was enabled,
making it difficult for Python script authors to know when
re-registering subscribers was needed.
This caused problems calling screenshot from menu-search
which included the status text in the screenshot.
Now the status text is shown in the global status bar
for any operators called from a screen context.
This ended up being a copy of:
`toolsettings->workspace_tool_type == SCE_WORKSPACE_TOOL_FALLBACK`
requiring boiler plate assignment in gizmos refresh callbacks.
Remove this struct member and check `toolsettings->workspace_tool_type`
directly, since so far there has been no advantage in gizmo-groups
being able to control this themselves.
Resolve regression in c9d9bfa84a,
which added support for tools to be tagged as using a fallback too.
In these cases the "Active Tool" setting was ignored and the fallback
tool would be used (the spin tool would box select for example).
Liboverride references need a special handling during append, since
those pointers should never be made local, nor reampped to newly
localized data. And liboverride references should never be directly made
local either, to ensure their liboverride usages remain pointing to
linked data and not local one.
Issue was reported by the studio, and also probably as part of T91892.
This was simply never handled apparently.
Also fixes a regression from recent append refactor that prevented RB
objects to to properly handled too (since we instantiate loose objects
in append step now, we need to handle RigidBody ones after that
instantiation stage, otherwise nothing will happen since loose objects
won't be in any scene).
