| Age | Commit message (Collapse) | Author |
|---|
|
Differential Revision: https://developer.blender.org/D16259
|
|
This could happen when switching between custom action sets that both
had controller pose actions. Problem was that controller data is
cleared when changing action sets, and this clearing was done when
handling WM events, which always occurs after XR controller data is
updated from GHOST.
Now, instead of activating the action set immediately, delay activation
until just before the next XR actions sync.
|
|
The use-case is to allow an event handler (in C or a plugin) to
distinguish which hand produced the XR event.
The alternative is to register separate actions for each hand (e.g.
"trigger_left" and "trigger_right"), and duplicate the device bindings
(Oculus, HTC Vive, etc) for each action. Other than the problem of code
duplication, this isn't conceptually efficient since "trigger_left" and
"trigger_right" both represent the same event "trigger", and the
identity of the hand that produced that event is just a property of
that event.
Adds two string fields to the XrEventData called user_path and
user_path_other. The user_path_other field will be populated if the
event is a bimanual one (i.e. two-handed). This follows the pattern
used by the rest of the XrEventData struct for bimanual events (e.g.
state, state_other).
Reviewed By: muxed-reality
|
|
No functional changes.
|
|
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
|
|
|
|
Previously, the number of action map subactions was limited to two per
action (identified by user_path0, user_path1), however for devices with
more than two user paths (e.g. Vive Tracker) it will be useful to
support a variable amount instead.
For example, a single pose action could then be used to query the
positions of all connected trackers, with each tracker having its own
subaction tracking space.
NOTE: This introduces breaking changes for the XR Python API as follows:
- XrActionMapItem: The new `user_paths` collection property
replaces the `user_path0`/`user_path1` properties.
- XrActionMapBinding: The new `component_paths` collection property
replaces the `component_path0`/`component_path1` properties.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D13949
|
|
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
|
|
|
|
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
|
|
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 08511b1c3de0) is
used to execute XR event operators in the proper context.
Reviewed By: Severin
Differential Revision: https://developer.blender.org/D10944
|
|
This fixes a mistake in the XrActionMaps RNA struct declaration.
Originally, the XrActionMaps struct SDNA was set as wmXrData to get
access to wmXrRuntimeData. However, this doesn't give a valid pointer
and the XrSessionState RNA pointer needs to be passed instead.
Since XrSessionState itself does not have SDNA, it is necessary to
pass the XrSessionState pointer to the XrActionMaps struct functions
(new(), new_from_actionmap(), ...) instead of simply using
RNA_def_struct_sdna().
|
|
No functional changes.
|
|
- Rename functions to use RNA identifiers
- Use SET_FLAG_FROM_TEST macro
- Specify max string length for relevant function params
|
|
Was accidentally left out in rBe844e9e8f3bb.
|
|
|
|
|
|
Addresses the remaining portions of T77137 (Python API for Controller
Interaction), which was partially completed by D10942.
Adds an XR "action maps" system for loading XR action data from a
Python script. Action maps are accessible via the Python API, and are used
to pass default actions to the VR session during the
xr_session_start_pre() callback.
Since action maps are stored only as runtime data, they will be
cleaned up with the rest of the VR runtime data on file read or exit.
Reviewed By: Julian Eisel, Hans Goudey
Differential Revision: https://developer.blender.org/D10943
|
|
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
|
|
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.
|
|
The text and icon were supposed to change but didn't reliably, which was
a race condition I think. It depended on how fast the OpenXR runtime
would transition the session state.
This also makes sure the correct notifier is sent on session exit.
|
|
NOTE: While most of the milestone 1 goals are there, a few smaller features and
improvements are still to be done.
Big picture of this milestone: Initial, OpenXR-based virtual reality support
for users and foundation for advanced use cases.
Maniphest Task: https://developer.blender.org/T71347
The tasks contains more information about this milestone.
To be clear: This is not a feature rich VR implementation, it's focused on the
initial scene inspection use case. We intentionally focused on that, further
features like controller support are part of the next milestone.
- How to use?
Instructions on how to use this are here:
https://wiki.blender.org/wiki/User:Severin/GSoC-2019/How_to_Test
These will be updated and moved to a more official place (likely the manual) soon.
Currently Windows Mixed Reality and Oculus devices are usable. Valve/HTC
headsets don't support the OpenXR standard yet and hence, do not work with this
implementation.
---------------
This is the C-side implementation of the features added for initial VR
support as per milestone 1. A "VR Scene Inspection" Add-on will be
committed separately, to expose the VR functionality in the UI. It also
adds some further features for milestone 1, namely a landmarking system
(stored view locations in the VR space)
Main additions/features:
* Support for rendering viewports to an HMD, with good performance.
* Option to sync the VR view perspective with a fully interactive,
regular 3D View (VR-Mirror).
* Option to disable positional tracking. Keeps the current position (calculated
based on the VR eye center pose) when enabled while a VR session is running.
* Some regular viewport settings for the VR view
* RNA/Python-API to query and set VR session state information.
* WM-XR: Layer tying Ghost-XR to the Blender specific APIs/data
* wmSurface API: drawable, non-window container (manages Ghost-OpenGL and GPU
context)
* DNA/RNA for management of VR session settings
* `--debug-xr` and `--debug-xr-time` commandline options
* Utility batch & config file for using the Oculus runtime on Windows.
* Most VR data is runtime only. The exception is user settings which are saved
to files (`XrSessionSettings`).
* VR support can be disabled through the `WITH_XR_OPENXR` compiler flag.
For architecture and code documentation, see
https://wiki.blender.org/wiki/Source/Interface/XR.
---------------
A few thank you's:
* A huge shoutout to Ray Molenkamp for his help during the project - it would
have not been that successful without him!
* Sebastian Koenig and Simeon Conzendorf for testing and feedback!
* The reviewers, especially Brecht Van Lommel!
* Dalai Felinto for pushing and managing me to get this done ;)
* The OpenXR working group for providing an open standard. I think we're the
first bigger application to adopt OpenXR. Congratulations to them and
ourselves :)
This project started as a Google Summer of Code 2019 project - "Core Support of
Virtual Reality Headsets through OpenXR" (see
https://wiki.blender.org/wiki/User:Severin/GSoC-2019/).
Some further information, including ideas for further improvements can be found
in the final GSoC report:
https://wiki.blender.org/wiki/User:Severin/GSoC-2019/Final_Report
Differential Revisions: D6193, D7098
Reviewed by: Brecht Van Lommel, Jeroen Bakker
|
