Extends Ghost to include an abstraction for OpenXR, which I refer to as
Ghost-XR. Such an API is the base for the following commit, which introduces VR
support to Blender.
Main features:
* Simple and high-level interface for Blender specific code to call.
* Extensible for muliple graphics backends, currently OpenGL and a DirectX
compatibility layer are supported.
* Carefully designed error handling strategy allowing Blender to handle errors
gracefully and with useful error messages.
* OpenXR extension and API-layer management.
* OpenXR session management.
* Basic OpenXR event management.
* Debug utilities for Ghost-XR and OpenXR
For more information on this API, check
https://wiki.blender.org/wiki/Source/Interface/XR.
Reviewed by: Brecht Van Lommel
Differential Revision: https://developer.blender.org/D6188
There are still some issues left after the changes in master:
* Some optimizations need to be redone differently
* Color-space handling needs to be redone differently
* Upside-down drawing is broken
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
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
## 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
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
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
Just like the Windows Mixed Reality runtime, we have to apply a sRGB
OETF to get visually correct-ish looking colors.
We plan to further investigate if it's really WMR and Monado being wrong
here, or if it's Oculus (which doesn't need this additional transform),
but there are some details to check.
Reduces code duplication for the DirectX specific upside down drawing.
Didn't actually test the upside down drawing, since I need to do that on
Windows.
* Adds the needed bits to support VR session settings and access them in
the VR view drawing code.
* Added settings for: shading mode, grid floor, annotations, clipping.
More can easily be added.
* The Add-on adds a "VR" tab in the side bar, containing buttons for the
added settings
This fixes linking errors with the Monado runtime. The specification
says that extension functions have to be gotten through
`xrGetInstanceProcAddr()` which we did for some extensions, but not for
the graphics extensions. Worked fine earlier, but broke meanwhile.
Code now assumes that the view-draw callback left the OpenGL state for
ongoing use by Ghost-XR. So the state doesn't have to be set by the
swapchain image submission and thus it we don't need to pass the Ghost
OpenGL context to it in a hacky way.
Also, rename drawViewEnd (to submitToSwapchain) and remove
drawViewBegin.
These were previously used to blit from a offscreen (non-OpenGL)
context, into an onscreen one. We do this differently, and only within
GHOST_XrGraphicsBinding now, so this can be removed.
Rather than max. one shared resource per DirectX context, code can now
request a handle for a shared resource and ask the DirectX context to do
operations on that.
There were a few typos here and there, and the openxr_sdk does not respect the cflags we give it hence a patch was added to work around this undesirable behaviour.
Adds the SDK so that `make deps` works, on all platforms. On Windows,
the SDK headers and libraries are now assumed to be in the usual lib\
directory.
Also fixes a mistake in install_deps.sh
Note that none of this is tested as it requires an older Visual Studio
version than I have.
Removes the OPENXR_USE_BUNDLED_SRC option which allowed using the
OpenXR-SDK sources bundled in extern/. It would be too much hassle to
keept these updated.
Now these have to be provided on the system Blender is compiled on. I've
already added necessary bits to install_deps.sh and our Windows
maintainer is ready to provide builds with OpenXR-SDK linked.
Once this gets into master, platform maintainers will have to be
notified about the added dependency.
This also removes the JsonCpp dependency, it was only needed for the
OpenXR-SDK sources.
Discussed this in length with @sobotka, and it seems WMR has an utterly
broken pixel color pipeline. So we apply a SRGB OETF for this specific
runtime to compensate.
Only tested on Windows.
Updates loader sources from the OpenXR SDK to latest 1.0 SDK and updates
requiremed version to 1.0. The compile time generation of files is a
thing of the past now (although you can still force it).
1.0 got released yesterday. Only one line needed fixing in our OpenXR
code to get it to compile. Rendering is black though.
For now I tried to keep edits to CMakeList.txt files minimal. So now
there are OpenXR CMake options exposed (with bad names), CMake prints,
etc.
This way we avoid the big overhead of context switches. Makes frames
render about twice as fast here. For heavy Spring scenes I'm getting
around 20 FPS here, classroom scene is at 50 FPS.
This is great given that drawing itself still isn't optimized for dual
eye rendering.
Outputs frame render time in milliseconds and FPS this time would add up
to. We could average times so FPS is a bit more stable, but the
precision of un-averaged results may be helpful too.
I'm not really sure why the leak happened - draw manager kept allocating
certain buffers - but I figured I could avoid it by not recreating
GPU_offscreen/GPU_viewport on every redraw.
This should also improve performance a bit.
Adds generic unique_oxr_ptr to wrap xrCreate and xrDestroy functions of
OpenXR handles into a unique_ptr like RAII interface.
While for most cases, OpenXR resources can be freed by their owning
object, sometimes errors may occor before final ownership is established.
E.g. swapchain ownership is only transfered to the session object once
its swapchain-images are created - which may fail. With this RAII
wrapper, the swapchain would be freed on error (as this triggers stack
unwinding through an exception), no matter who holds ownership to it
currently.
There are other solutions to this problem, e.g. by establishing final
ownership right after/upon creation, or by explicit freeing in case an
error is spotted; it's too easy to make mistakes here though. Plus, we
may want to experiment with using this API for all OpenXR resources, to
entirely avoid the possibility of them leaking.
Fixes:
* Destruct surface when destroying session on error. Fixes null pointer
dereference when trying to draw the surface on next redraw.
* Fix trying to enable same extensions/API-layers multiple times due to
static array usage not being cleared after error.
* Null pointer dereference with OpenGL drawing
E.g. with an active OpenXR runtime installed, but no HMD plugged in,
Blender will now show: "Failed to get device information. Is a device
plugged in?".
In case of such errors, the VR-session will be cleanly exited, with
no side effects to the rest of Blender (at least if there are no bugs).
The GHOST_Xr API now allows setting a custom error handling callback
which may cleanly destroy all GHOST_Xr data.
This wraps all functions that could fail into some proper (although
unfinished) error handling.
These were the requirements for the error handling strategy:
* If an error occurs, cleanly exit the VR session (or the context if the
error happend during its set up), 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.
After some back and forth I decided Ghost internal exceptions are the
best way to go about this. I get exceptions are a controversial feature,
IMHO that's because most people use them 'wrong' however. Here's the
rationale:
* Most alternatives require early exiting functions. This early exiting
has to be 'bubbled up' the call stack to the point that performs error
handling. So the code gets really impaired by error checking. Tried
this first and wasn't happy with it 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 if an error is caught inside GHOST_Xr code, an exception is thrown
with specific and hopefully useful information in it. In the Ghost C-API,
these exceptions are caught and passed on to a custom error handling
callback. This callback will be defined by the Blender window-manager
and output the error information via a usual user report popup (not done
yet). It can also ensure the entire session is shut down.
Note that the majority of errors OpenXR can return are for invalid API
usage. Assuming the API usage is valid though, most error messages
should never reach users and can be left a bit more vague. Maybe we can
add something like "This is probably a bug and should be reported" to
those.
Unfortunately, enabling XR_EXT_debug_utils crashes instance creation
with the Windows Mixed Reality runtime. Maybe I'm doing something wrong,
for now, just disable it.
* Initialize all class member variables
* Add version to runtime name printing
* Separate functionality code from debug prints
* Improve code structure using Doxygen groups
* Make accessors const functions
* Add (Doxygen) comments
* Naming
* Reorder functions
Makes GHOST_Xr much more consistent with the rest of GHOST. Basically I
added a GHOST_IXrContext interface which can be called by the GHOST
C-API. The internal GHOST_XrContext class implements this.
Outside of GHOST only the opaque GHOST_XrContextHandle is accessible.
Kept GHOST_Xr_intern.h and GHOST_Xr.cpp for now. I'll probably remove
them soon. There's not much reason for both of them to be there.
Enables (or tries to) the XR_EXT_debug_utils extension which allows
setting a custom callback for additional debug prints. Note that I
haven't been able to test this really, as the Monado runtime appears to
not have this fully implemented (had to force sending a custom message
to find that out...). Will test with the Windows MR runtime in a bit. We
can also improve message quality then (it can print the exact function
name the message was sent from, print additional custom labels which
could indicate session state, etc.).
For this to work two environment variables have to be set:
XR_API_LAYER_PATH and LD_LIBRARY_PATH, both have to point to the API
layers built by the OpenXR SDK. It also requires you compile Blender
linked to your own SDK build (OPENXR_USE_BUNDLED_SRC disabled).
Further changes will make this set up unnecessary, so validation layers
can be enabled via some flag.
I was trying to set the camera pose as OpenXR reference pose. But then I
got really strange poses for drawing back from OpenXR. Couldn't figure
out a way to solve this.
Now we just apply OpenXR's draw pose to the Blender camera pose. If we
later want to support moving around in the scene (e.g. via teleporting),
that has to be changed.
Also uses flipped drawing for DirectX surface to correct DirectX upside
down drawing (compared to OpenGL).
Session code and data structures are now localized. But also, this
enables sessions to use deterministic destruction to end itself cleanly.
So whenever an error occurs, we can use stack unwinding which will cause
graceful ending of the session.
* Move GHOST_Xr types to GHOST_Types.h
* Add GHOST_XrPose. We'll have to pass around pose data at multiple
places.
* Don't require extra call to prepare session rendering, handle
everything through GHOST_XrSessionStart
* Naming
Finally: This makes it possible to render a viewport to an HMD via
OpenXR. Pure OpenGL rendering will need some more tweaks to work.
To my great delight, performance is quite good for reasonably sized
scenes.
Had to do some hacks and marked some TODOs. Nothing too bad though.
Here are a couple of notes:
* Current initial pose is pretty useless, think it just looks downwards
from world origin. Will change that soon.
* The rendered viewport has some issues: Too dark (bad lighting?), grid
doesn't show up even though I told it to, lighting seems to change with
view position/rotation, etc. Needs some polish.
* Ideally we'd just use the D3D11 Texture given to us via the OpenXR
swapchain and blit the OpenGL framebuffer into that. However the
NV_DX_interop extension fails doing this. Seems like this is a NVidia
Optimus only issue, but I'm missing the hardware to confirm.
So instead, we blit into the D3D11 back buffer first and then into the
Texture.
* The draw-manager uses its own offscreen context so we have to get the
render result from the draw-manager context to the VR session's
context first. Luckily I've already added code to support blitting from
one OpenGL context into another. But it requires blitting twice.
Blitting should be very cheap, but still...
Draw-manager could get a context to use passed instead.
Not visible yet, but it should draw in the offscreen. The way this is
now, we don't depend on the Window->Workspace->bScreen->... chain. We
simply draw an offscreen viewport in the draw callback of the XR session
surface.
The drawing also uses view and projection matrices from OpenXR (or
calculated from OpenXR data).
Uses the new wmSurface type (non-window drawable container) to manage
the OpenGL, DirectX and GPU module contexts. The draw callback of the XR
surface calls the GHOST_Xr session drawing routines.
What you should see when starting a VR session now (using the WMR
runtime): The Windows Mixed Reality Portal pops up, and a blue
background is drawn on the HMD. This is from the blue color clear call
we do in the drawing preparations of the GHOST_Xr session drawing.
Adds a wmSurface type which acts as a container for non-Window (offscreen)
draw surfaces. Ideally wmWindow would of course also just do C-style
inheritance from wmSurface, but I guess they can co-exist too.
For the VR session a surface is created on Linux and passed to the
graphics binding to use.
Note this is not used on Windows yet, it still opens a window there.
* Allow passing custom data to session draw function, passed to the
callback
* Actually call the callback
* Create and bind a WM level callback. Will later be used to draw the
viewport.
Also, check if session is actually visible before drawing.
Just a clear call for now, so all you see is a blue world. This blue
"world" is however drawn by Blender!
Also fixes use after destruction of compositor layer data.
Using a dummy identity pose at {0, 0, 0} to start with. This should
later use the current viewport position & orientation I guess.
Also adds function to set a draw callback. There's quite some OpenXR
related stuff to be done before and after drawing anyting, as well as
before and after drawing each view (eye). Quite some info would have to
be exposed to WM to let it manage drawing. So I think using a callback
called from GHOST_Xr to draw each eye instead is a good way to go.
VR session currently crashes after opening. Seems to be related to
blocking frame wait call. I'm not too worried about that though, might
disappear once OpenXR frame sync functions get proper timing info
passed.
Following the OpenXR SDK's example code very closely here. We have to do
some nasty converting of graphics binding specific image vectors to
generalized base ones. The SDK's approach seems like a good way to go
about this.
With this, the Windows Mixed Reality Portal finally pops up when
starting the session. That is how it's supposed to work. After it's
initialization phase all you see is black. That's expected too as we
don't send anything to the device yet.
Nothing special to say. Just calls needed OpenXR functions to create
swapchains. Swapchain images are not created yet.
Interestingly, the Windows Mixed Realtiy portal now pops up when closing
Blender after having created a VR session. So we're getting closer ;)
Monado now opens a window here when asking it to start a session. That
seems to be the case because it doesn't detect the HMD as direct mode
capable yet. But that shouldn't be an issue from our side.
Refactors function into a class, and make this class a friend of
GHOST_ContextGLX. That seems like a better way to access low level
graphics data for this specific case, rather than giving anyone access
via a getter.
Creating the context causes the OpenXR loader to try connect to a
runtime. That would involve reading the OS'es active_runtime.json and
dynamic linking based on that. So better avoid doing this on startup.
Also: don't pay for what you don't use!
DirectX is Y coordinates top to bottom, while OpenGL is the opposite.
For the final window manager on-screen drawing, draw to a texture first
and draw that upside down if needed.
Phew! That a fight. But this is also a pretty important feature as it
allows interfacing with Windows Mixed Reality OpenXR runtime and the
HMDs supported by it.
Important remaining issue: The rendered viewport is upside down :) That
is of course because DirectX has the opposite vertical direction than
OpenGL.
When creating a DirectX window, we also create an OpenGL offscreen
context to use for all drawing. Just before swapping framebuffers, the
DirectX window blits the framebuffer of the offscreen context into its
swapchain. This requires the WGL_NV_DX_interop and WGL_NV_DX_interop2
extensions.
For testing/dev purposes, also adds:
* Version of the offscreen to onscreen blitting that's OpenGL only. So
it blits the default framebuffer of the offscreen context into the one
of the onscreen context.
This is disabled by a #define.
* Code to draw a colored triangle using DirectX, also for testing.
Requires the D3DCompiler.lib to be available at compile time. This is
also disabled using a #define.
With this the VR window should open fine and get cleared in a red-ish
orange using Direct3D 11 calls (well, on Windows that is).
The window still draws a 3D view to an offscreen buffer. Where we
usually just swap the buffers, we now allow calling a GHOST function to
blit the offscreen OpenGL buffer to whatever type of graphics buffer the
window uses (DirectX here).
The nice thing about this approach is that all DirectX code stays in
GHOST_ContextD3D.cpp. And the entire compatibiliy code can go into a
single function higher level modules don't need to care about.
This also fixes a number of issues introduced in earlier commits.
The window doesn't show anything of course. However we draw (at least I
assume it does) as regular, just into a window offscreen context.
A valid 3D view is created in the window. It's not visible but you see
cursor changes as you move over the window. So handling works.
The window immediately crashes, hence keeping it disabled for now.
Not sure how much of this I'll leave in, for now this is mainly for
testing DirectX compatibility.
* Retrieve graphics context to bind through callbacks so the XR code can
manage their lifetime.
* Use static union to store system & chosen graphics lib specific
graphics binding data.
Makes some things a bit cleaner, too.
Adds support for creating a DirectX 11 Ghost context. It's not used yet
and more stuff besides creation is needed. Also, other versions than 11
should probably be supported.
We need a DirectX context to support the Windows Mixed Reality OpenXR
Runtime, a rather important one to support. Idea is to use an extension
for OpenGL-DirectX interoperability for drawing the OpenGL offscreen
viewport render using DirectX.
Similar to gizmo/ and message_bus/, there's now a xr/ directory
containing header files and a intern/ directory for source and internal
header files.
Guess this is reasonable to do. And better to do early on to avoid
loosing much git history.
OpenXR needs to interface with some graphics library (OpenGL, Vulkan,
DirectX, etc.). This is done through graphics binding extensions. The
OpenXR specification requires these to be properly set up before a
session is created.
Adds the following:
* Support priority list of multiple graphics binding extensions (e.g.
check OpenGL extension availability first, DirectX on Windows second,
etc.)
* Barebones for passing graphics library data to OpenXR session
creation. This is highly system dependent, e.g. it requires GLX data
for OpenGL on X11 systems (XrGraphicsBindingOpenGLXlibKHR). More work,
including additions to GHOST, will be needed once I get to the more
graphics related stuff.
* Create an own graphics context for the VR session. It's not doing
anything useful yet. This is just to fool the Monado OpenXR runtime
so that it actually attempts to create the OpenXR session.
* Had to add two CMake modules for platform dependent #define's required
by the OpenXR specification.
To correctly start a session, a graphics extension specific object needs
to be passed to the OpenXR runtime. E.g. for the Windows Mixed Reality
runtime, XrGraphicsBindingD3D11KHR needs to be passed with a valid
DirectX device. Since we don't have any DirectX compatibility working,
I can't test this on Windows yet.
So to test this I finally need to get Monado to work on Linux and
correctly setup the OpenGL extension there.
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.
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.
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.
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).
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
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.
2019-05-28 01:21:25 +02:00
1908 changed files with 10425 additions and 23587 deletions
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
