Blender Git Loki

Add required OpenXR defines to Ghost CMakeLists (used to be in root one)

Merge branch 'temp-openxr-directx' into temp-openxr-ghostxr

Merge branch 'temp-openxr-buildstuff' into temp-openxr-directx

Disable XR features (and the OpenXR SDK dependency) by default on Apple

Remove XR defines from top-level CMakeLists file, can be done locally

Remove now unnecessary OpenXR SDK patch for Win CRT linkage

Merge branch 'master' into temp-openxr-buildstuff

Merge branch 'temp-openxr-ghostxr' into temp-openxr-blenderside

Remove CMake include unneeded after recent build system changes

Merge branch 'temp-openxr-ghostxr' into temp-openxr-blenderside

Merge branch 'temp-openxr-directx' into temp-openxr-ghostxr

Merge branch 'temp-openxr-buildstuff' into temp-openxr-directx

Merge branch 'master' into temp-openxr-buildstuff

Core XR Support [part 1]: Add OpenXR-SDK dependency and WITH_OPENXR build option

Some points on the OpenXR-SDK dependency:
* The repository is located at https://github.com/KhronosGroup/OpenXR-SDK (Apache 2).
* We use the OpenXR loader lib from it, the headers, and some CMake utilities.
* It contains a bunch of generated files, for which the sources are in a separate repository.
* To use the injected OpenXR API-layers from the SDK (e.g. API validation layers), the SDK needs to be compiled from this other repository.
* We could use that other repo by default, but I'd rather go with the simpler solution and allow people to opt in if they want advanced dev features.
* For Windows a patch is needed to link the CRT in a compatible way.

All this is entirely untested on macOS.

Maniphest Tasks: T71365

Differential Revision: https://developer.blender.org/D6188

Core XR Support [part 4]: Blender-side changes (+ the remaining bits)

Changes for the higher level, more Blender specific side of the implementation.

Main additions:
* 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 initial management of VR session settings
* Utility batch & config file for using the Oculus runtime (Windows only)

Differential Revision: https://developer.blender.org/D6193

Core XR Support [part 3]: Ghost-XR API based on OpenXR

## Design Overview
* For code using this API, the most important object is a GHOST_XrContext handle. Through it, all API functions and internal state can be accessed/modified.
* Main responsibilities of the Ghost XR-context are to manage lifetimes of the OpenXR runtime connection (represented by XrInstance), the session and to delegate operations/data to the session.
* The OpenXR related graphics code, which is OS dependent, is managed through a `GHOST_IXrGraphicsBinding` interface, that can be implemented for the different graphics libraries supported (currently OpenGL and DirectX).
* Much of this code here has to follow the OpenXR specification and is based on the OpenXR [[https://github.com/KhronosGroup/OpenXR-SDK-Source/tree/master/src/tests/hello_xr | `hello_xr`]] implentation.
* In future we may want to take some code out of the context, e.g. extension and API layer management.
* There are runtime debugging and benchmarking options (exposed through --debug-xr and --debug-xr-time, but not as part of this patch).
* Error handling is described in a section below.

## Why have this in Ghost?

Early on, I decided to do the OpenXR level access through GHOST. Main reasons:
* OpenXR requires access to low level, OS dependent graphics lib data (e.g. see [[https://www.khronos.org/registry/OpenXR/specs/0.90/man/html/openxr.html#XrGraphicsBindingOpenGLXlibKHR| XrGraphicsBindingOpenGLXlibKHR]])
* Some C++ features appeared handy (`std::vector`, RAII + exception handling, cleaner code through object methods, etc.)
* General low level nature of the OpenXR API

After all I think much of the functionality is too high level to live in GHOST however. I would like to address this by having a separate `VAMR` (virtual + augmented + mixed reality) module, placed in `intern/`. The main issue is getting this to work well with Ghost data, especially how to get the mentioned low level data out of Ghost.
This is something I'd like to look into again before too long, but for now I think having this in Ghost is reasonable.

## Error Handling Strategy

The error handling strategy I chose uses C++ exceptions, a controversial feature. Let me explain why I think this is reasonable here.

The strategy requirements were:
* If an error occurs, cleanly exit the VR session (or destroy the entire context), causing no resource leaks or side effects to the rest of Blender.
* Show a *useful* error message to the user.
* Don't impair readability of code too much with error handling.

Here's why I chose an exception based strategy:
* Most alternatives require early exiting functions. This early exiting has to be 'bubbled up' the call stack to the point that performs error handling. For safe code, early exit checks have to be performed everywhere and code gets really impaired by error checking. Tried this first and wasn't happy at all. Even if error handling is wrapped into macros.
* All `GHOST_Xr` resources are managed via RAII. So stack unwinding will cause them to be released cleanly whenever an exception is thrown.
* `GHOST_Xr` has a clear boundary (the Ghost C-API) with only a handful of public functions. That is the only place we need to have try-catch blocks at. (Generally, try-catch blocks at kinda random places are a bad code smell IMHO. Module boundaries are a valid place to put them.)
* Exceptions allow us to pass multiple bits of error information through mulitple layers of the call stack. This information can also be made specific with a useful error message. As of now, they conain a user error message, the OpenXR error code (if any), as well as the exact source code location the error was caught at.

So the strategy I went with works as follows:
* If a VR related error occurs within `GHOST_Xr`, throw an exception (`GHOST_XrException` currently).
* OpenXR calls are wrapped into a macro throwing an exception if the return value indicates an error.
* Useful debugging information and user messages are stored in the exceptions.
* All resources must be managed through RAII, so throwing an exception will release 'dangling' ones cleanly.
* In the GHOST C-API wrappers, the exceptions are caught and contained error information is forwarded to a custom error handling callback.
* The error handling callback is set in `wm_xr.c`, prior to creating the XR-Context, and implements clean destruction of the context.

Differential Revision: https://developer.blender.org/D6192

Ghost DirectX compatibility from GSoC OpenXR branch

Needed for DirectX-only OpenXR runtimes (e.g. Windows Mixed Reality).

Adds a minimal DirectX 11 Ghost context, plus some shared DirectX-OpenGL resource interface using the NV_DX_interop2 WGL extension.
I know that the current implementation fails on some systems, which is something I'll have to fix at some point. Don't know if this is a showstopper though, I can fix that in master too. For now this isn't going to be used by many people anyway. Recently I also learned that OSVR uses the same extension, see https://github.com/sensics/OSVR-RenderManager/blob/master/osvr/RenderKit/RenderManagerD3DOpenGL.cpp. Their implementation may be useful to fix the issue, according to a OSVR dev, it works quite reliably for them.

Note: Didn't actually test just this patch on Windows yet.

Differential Revision: https://developer.blender.org/D6190

Add back accidentally removed CMake files

No clue how those ended up tagged as removed.

Core XR Support [part 1]: Add OpenXR-SDK dependency and WITH_XR build option

Some points on the OpenXR-SDK dependency:
* The repository is located at https://github.com/KhronosGroup/OpenXR-SDK (Apache 2).
* We use the OpenXR loader lib from it, the headers, and some CMake utilities.
* It contains a bunch of generated files, for which the sources are in a separate repository.
* To use the injected OpenXR API-layers from the SDK (e.g. API validation layers), the SDK needs to be compiled from this other repository.
* We could use that other repo by default, but I'd rather go with the simpler solution and allow people to opt in if they want advanced dev features.
* I copied `presentation.cmake` and `xr_platform_defines.cmake` from the SDK. They contain logic that is not needed for us and prints at CMake generation. We could change that but figured it would also be helpful to keep the files equal to the SDK ones.
* For Windows a patch is needed to link the CRT in a compatible way.
* @LazyDodo already pushed the precompiled binaries for Windows.

All this is entirely untested on macOS.

Differential Revision: https://developer.blender.org/D6188

Merge branch 'master' into soc-2019-openxr