Blender Git Statistics -> Branches -> soc-2019-openxr

"Soc-2019-openxr" branch

Total commits : 119
Total committers : 2
First Commit : May 27, 2019
Latest Commit : July 17, 2019


Commits by Month

DateNumber of Commits
July, 201935
June, 201976
May, 20198

Committers

AuthorNumber of Commits
Julian Eisel118
LazyDodo1

Popular Files

FilenameTotal Edits
wm_xr.c41
GHOST_XRSession.cpp35
GHOST_XR_intern.h25
wm_operators.c24
GHOST_XR.cpp24
GHOST_C-api.h22
wm.h15
wm_window.c14
GHOST_C-api.cpp12
CMakeLists.txt12

Latest commits Feed

July 17, 2019, 13:18 (GMT)
Fix DirectX context not freed on session exit

Also rename XrSurfaceData to wmXrSurfaceData
July 17, 2019, 12:51 (GMT)
Fix for previous commit, accidental call to xrDestroySwapchain
July 17, 2019, 12:05 (GMT)
Fix possible OpenXR swapchain leak by using new unique_oxr_ptr
July 17, 2019, 11:35 (GMT)
Add helper class to RAII manage OpenXR handles

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.
July 17, 2019, 09:29 (GMT)
Fix compile error with USE_FORCE_WINDOWED_SESSION enabled

At least get it to compile, this is still kinda broken though.
July 16, 2019, 22:41 (GMT)
Add helper batch file for testing on oculus rift.
July 16, 2019, 19:48 (GMT)
Temporarily let DirectX take priority over OpenGL

OpenGL doesn't work yet. Shouldn't be too difficult to get working, but
I don't have a working OpenXR runtime with OpenGL support to test here.
July 16, 2019, 19:09 (GMT)
Merge branch 'master' into soc-2019-openxr
July 13, 2019, 14:22 (GMT)
Fix some issues, improve error message

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
July 12, 2019, 23:19 (GMT)
Fix crash on OpenXR error before context is created fully
July 12, 2019, 17:51 (GMT)
Show useful error reports in case of errors.

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.
July 12, 2019, 12:40 (GMT)
Safe and informative GHOST_Xr error handling

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.
July 11, 2019, 19:05 (GMT)
Check runtime DirectX requirements for graphics binding too
July 11, 2019, 18:36 (GMT)
Check runtime OpenGL requirements prior to creating graphics binding

DirectX will need these checks too.
Also fix warnings due to wrong printf formatting.
July 11, 2019, 18:28 (GMT)
Merge branch 'master' into soc-2019-openxr
July 11, 2019, 14:44 (GMT)
Disable debug extension on Windows

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.
July 11, 2019, 14:36 (GMT)
General minor fixes and cleanup

* 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
July 10, 2019, 22:51 (GMT)
Fix wrong return value causing OpenXR initialization to fail
July 10, 2019, 22:50 (GMT)
Fix compile errors on windows and with bundled OpenXR SDK sources
July 10, 2019, 21:53 (GMT)
Refactor GHOST_XrContext into class + interface

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.

MiikaHweb - Blender Git Statistics v1.06
By: Miika HämäläinenLast update: Nov-07-2014 14:18 MiikaHweb | 2003-2019