Blender Git Commits

Blender Git "temp-ghost_openxr" branch commits.

Page: 3 / 3

June 4, 2019, 16:27 (GMT)
Fix layer and extension count not stored as intended
June 4, 2019, 15:39 (GMT)
Print OpenXR runtime name once connected
June 4, 2019, 15:00 (GMT)
Merge branch 'master' into soc-2019-openxr
June 4, 2019, 14:42 (GMT)
Initial VR-session starting/ending

Adds operator to toggle a VR session, exposed in the Window top-bar
menu. It triggers the needed calls for session creation and destruction.
Setting up the XR-system (a configuration of related devices) is also
done now.

Calling WMR runtime functions fails currently. Not sure why. So while
this executes required routines, it doesn't really work.
June 2, 2019, 20:04 (GMT)
Fix GCC compile error, warnings and uninitialized use

extension_count could be used uninitialized if no valid OpenXR runtime
was run.
June 2, 2019, 13:24 (GMT)
Merge branch 'master' into soc-2019-openxr
June 2, 2019, 00:24 (GMT)
Correct previous commit

Intended to print out name, not address.
June 1, 2019, 15:16 (GMT)
Gather available OpenXR extensions and API-layers on OpenXR setup

We don't actually enable any extension or layer yet. We just put their
names into arrays and print them. The printing can be disabled via a
compiler define, later we should put them behind a proper
logging/debugging mechanism (CLOG).

Also fixes a Visual Studio compile error.
May 30, 2019, 14:22 (GMT)
Fix compiling with bundled OpenXR SDK sources

Also remove unused include.
May 30, 2019, 12:56 (GMT)
Corrections to previous commit

* Remove testing instance creation
* Rename function
May 30, 2019, 12:48 (GMT)
Proper creation & destruction of OpenXR instances

Adds wm_xr.c for an XR management API and creates/destroys the OpenXR
instance through this. This is as planned in my proposal, to lock the
OpenXR calls behind an abstraction.
XR data will be stored in a (non-public) wmXRContext struct within the
window-manager.

For now, creates the OpenXR instance on startup. I think it's better to
lazy setup this, as in, only creating the instance once the user starts
the first XR session. Just to avoid costs for something that may not be
used (the OpenXR loader we use will try loading and parsing the system's
OpenXR active_runtime.json on instance creation). That's for later when
I introduce session management though.

Also added a context getter for the xr-context, which is unused but may
be handy later.
May 29, 2019, 23:44 (GMT)
Support system installed OpenXR SDK

Adds OPENXR_USE_BUNDLED_SRC so that if disabled, CMake tries to find
the SDK headers and libraries in system paths or in specified root
directory.

I guess this is the way we'd want to do this in master. However for
people testing the branch the bundled sources are much more convenient
(should work out of the box, no need to compile the SDK manually).
May 29, 2019, 18:14 (GMT)
Merge branch 'master' into soc-2019-openxr
May 29, 2019, 13:17 (GMT)
Merge branch 'master' into soc-2019-openxr
May 28, 2019, 19:58 (GMT)
Linux: OpenXR Linking via OpenXR Loader

Calling OpenXR functions should now work on both Windows and Linux.

Also includes:
* Silence Linux only warnings
* Remove common_cmake_config.h and let CMake generate it when
configuring (contents vary on system it's compiled on)
* Remove JsonCpp CMake install target
* Remove unnecessary CMakeLists for JsonCpp includes
* Remove unnecessary CMake commands
* Style cleanup
May 27, 2019, 23:21 (GMT)
Windows: OpenXR Linking via OpenXR Loader

Adds needed headers for OpenXR, the loader from the OpenXR SDK and
JsonCpp into extern. Took a while to get this to compile/link, but on
Win10 it works fine now without patching #includes. Linux probably
needs more work.

Added a compile option WITH_OPENXR to toggle XR feature compiling.

Also does a dummy xrCreateInstance() call to test linking.
By: Miika HämäläinenLast update: Nov-07-2014 14:18MiikaHweb | 2003-2021