Add null check for runtime data since it could already have been
freed via wm_xr_exit() (called on file read) prior to the session
exit callback.
Also, fix potential memory leak by freeing session data in
wm_xr_runtime_data_free() instead of session exit callback.
This addresses reduced visibility of scenes (as displayed in the VR
headset) that can result from the 8-bit color depth format currently
used for XR swapchain images.
By switching to a swapchain format with higher color depth (RGB10_A2,
RGBA16, RGBA16F) for supported runtimes, visibility in VR should be
noticeably improved.
However, current limitations are lack of support for these higher
color depth formats by some XR runtimes, especially for OpenGL.
Also important to note that GPU_offscreen_create() now explicitly
takes in the texture format (eGPUTextureFormat) instead of a
"high_bitdepth" boolean.
Reviewed By: Julian Eisel, Clément Foucault
Differential Revision: http://developer.blender.org/D9842
Provides two key improvements to runtime controller data.
1. Separates controller poses into two components, "grip" and "aim",
which are both required to accurately represent the controllers
without manual offsets.
Following their OpenXR definitions, the grip pose represents the
user's hand when holding the controller, and the aim pose represents
the controller's aiming source.
2. Runtime controller data is now stored as a dynamic array instead
of a fixed array. This makes the API/functionality more adaptable to
different systems.
Does not bring about any changes for users since only internal
runtime functionality is currently affected.
Reviewed By: Julian Eisel
Differential Revision: http://developer.blender.org/D12073
Addresses T76003. When using VR with Eevee and viewport denoising,
scene geometry could sometimes be occluded for one eye. Solution is
to use a separate GPUViewport/GPUOffscreen for each VR view instead
of reusing a single one for rendering.
Reviewed By: Julian Eisel, Clément Foucault
Differential Revision: http://developer.blender.org/D11858
Improves control over the XR reference space by using the stage ref
space (user-defined tracking bounds) instead of local ref space
(position at application launch), if available. Also adds an
"absolute tracking" session option to skip applying eye offsets that
are normally added for placing users exactly at landmarks.
By enabling absolute tracking, users can define the tracking origin
in a way that is not linked to the headset position. Instead, the
tracking values given by the XR runtime are left unadjusted and a
user can manually calibrate an "origin" landmark object to adjust to
their real world space.
Can be useful for applications that use external tracking systems
and those that primarily only need to use controllers and not the
headset (e.g. motion capture).
The absolute tracking option requires an update to the VR
Scene Inspection addon to be accessible by regular users.
Reviewed By: Julian Eisel
Differential Revision: http://developer.blender.org/D10946
Adds internal API for creating and managing OpenXR actions at the
GHOST and WM layers. Does not bring about any changes for users since
XR action functionality is not yet exposed in the Python API (will be
added in a subsequent patch).
OpenXR actions are a means to communicate with XR input devices and
can be used to retrieve button/pose states or apply haptic feedback.
Actions are bound to device inputs via a semantic path binding
(https://www.khronos.org/registry/OpenXR/specs/1.0/html/xrspec.html#semantic-path-interaction-profiles),
which serves as an XR version of keymaps.
Main features:
- Abstraction of OpenXR action management functions to GHOST-XR,
WM-XR APIs.
- New "xr_session_start_pre" callback for creating actions at
appropriate point in the XR session.
- Creation of name-identifiable action sets/actions.
- Binding of actions to controller inputs.
- Acquisition of controller button states.
- Acquisition of controller poses.
- Application of controller haptic feedback.
- Carefully designed error handling and useful error reporting
(e.g. action set/action name included in error message).
Reviewed By: Julian Eisel
Differential Revision: http://developer.blender.org/D10942
Split the depsgraph allocation into a separate function
`BKE_scene_ensure_depsgraph()`. Parameters are only passed to those
functions that actually need them. This removes the the "if that boolean
is `false` this pointer is allowed to be `NULL`" logic and more cleanly
decouples code.
No functional changes.
On VR session start with positional tracking disabled, the pose would
have an offset applied but it was supposed to start exactly at the
landmark position.
Issue is that we applied the offset to cancel out the position offset
reported by the OpenXR runtime incorrectly. We only want to do that if
positional tracking is enabled, because if not we don't even apply the
runtime's position offset. So we'd cancel something out that wasn't
there.
Proper handling of View Layers for the VR session was never implemented.
Now the View Layer of the VR session follows the window the session was
started in.
Note that if this window is closed, we fallback to another window. This
is done to avoid the overhead it would take to maintain a separate
depsgraph for the VR view. Instead we always share some already visible
View Layer (and hence the depsgraph).
We want the session to start exactly at the landmark position, with
no additional offset. Some runtimes (e.g. Windows Mixed Reality) may
give an initial non-[0,0,0] position at session start though.
Also add a comment explaining the purpose of the eye offset variable.
There would always be an unintended offset applied. Per design there
should not be any offset when changing VR Landmarks, the view should
just jump exactly to the Landmark.
Due to the recent changes, we don't have to add, but substract the eye
offset we apply to get the wanted behavior.
Mistake in 607d745a79.
We want the session to start exactly at the landmark position, with
no additional offset. Some runtimes (e.g. Windows Mixed Reality) may
give an initial non-[0,0,0] position at session start though.
Also add a comment explaining the purpose of the eye offset variable.
There would always be an unintended offset applied. Per design there
should not be any offset when changing VR Landmarks, the view should
just jump exactly to the Landmark.
Due to the recent changes, we don't have to add, but substract the eye
offset we apply to get the wanted behavior.
Mistake in 607d745a79.
This addresses warnings from Clang-Tidy's `readability-else-after-return`
rule in the `source/blender/blenlib` module. Not all warnings are
addressed in this commit.
No functional changes.
Once the base pose was changed (e.g. by changing the active landmark), we'd always run the logic to reset to the base pose. That would mess up the final viewer pose.
Think this only got exposed through 607d745a79.
* Changing to a landmark moves the view exactly to it, rather than
keeping the current position offset.
* Disabling positional tracking moves the viewer back to the landmark
position.
This is a more predictable and practical way to use landmarks. See
feedback in T71347.
On the code side, I did some cleanup so the logic flow is more clear.
Note: This is entirely untested. I currently don't have access to a
device. There might be issues, tomorrow I'll hopefully get feedback.
Draw-manager mutex has to be set before activating OpenGL/GPU context.
Otherwise, parallel jobs (like preview rendering) may try to activate
the context from another thread.
Also: Use WM wrappers for activating/releasing OpenGL context, which
have an additional assert check.
Suggest to backport this for 2.83.1.
The offsets are applied after toggling positional tracking off, so that
the view does not jump at that moment. But when changing the base pose,
keeping that offset doesn't make sense. Especially with landmarks, which
are supposed to give precise positions/rotations to jump to. For that
part the VR Scene Inspection Add-on will need a little adjustment
though.
Also exposes an explicit function to the Python API to reset the
offsets, to be used by the Add-on.
This is mostly untested since I don't have access to an HMD currently.
Splits up wm_xr.c into multiple files in their own folder:
source/blender/windowmanager/xr. So this matches how the message bus and
gizmo code have their own folder and files.
This allows better structuring and should make the code scale better.
I rather do this early on than to wait until we end up with a single,
huge file.
Also improves a bit how data is prepared and updated for drawing.
