Week 1 (May 27 - June 1):
To use OpenXR, mechanisms to dynamically link to the OpenXR runtime need to be set up. The best way to do this is via an OpenXR loader. Focus for this week was to get OpenXR up and running via the loader provided by the OpenXR SDK.
- Added required parts of the OpenXR SDK to the Blender source so that the branch can be built without setting up any additional dependencies. This was a bit of a fight, but gave me a nice introduction to the loader’s design. Works on both Windows & Linux (06d52afcda, e65ba62c37)
- Based on this experience, I don’t recommend using this approach for a master integration. It smells like a maintenance nightmare. So I added an alternative version to compile with the OpenXR loader, which attempts to use a system installed SDK. It can be enabled with a CMake flag. (864abbd425)
I checked on this with other developers here: GSoC 2019: Core Support of Virtual Reality Headsets through OpenXR. - Started working on the window-manager XR-API. It currently attempts to create, store and destroy an OpenXR instance (41e2f2e75f). Such an instance is used to manage the lifetime of the OpenXR runtime connection. On Windows 10, I can succesfully connect to the Windows Mixed Reality OpenXR Runtime (development preview) by now.
- Added basic functionality to query OpenXR extensions and additional API layers. We don’t use that yet, but will soon, as extensions are used to manage graphics library support. (5d5ad5d6dd)
- Tried to compile the Monado runtime on Linux but had to update my distro to a not yet released version (Debian Buster) - Monado requires this unfortunately. Still had errors compiling Monado, but didn’t really look into them yet.
Also, spending a few great days at the Libre Graphics Meeting. Bit of an eye opening experience: They all seem to look up to Blender. Very motivating 