Revision fca4826 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 16, 2019, 19:09 (GMT) |
Merge branch 'master' into soc-2019-openxr |
Revision b0845fc by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) 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 |
Revision 70cf8bd by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 12, 2019, 23:19 (GMT) |
Fix crash on OpenXR error before context is created fully |
Revision 3a2e459 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) 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. |
Revision 330f062 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) 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. |
Revision 09872df by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 11, 2019, 19:05 (GMT) |
Check runtime DirectX requirements for graphics binding too |
Revision 67d6399 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) 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. |
Revision c297249 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 11, 2019, 18:28 (GMT) |
Merge branch 'master' into soc-2019-openxr |
Revision 99560d9 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) 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. |
Revision b8a7b87 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) 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 |
Revision c9f6c1a by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 10, 2019, 22:51 (GMT) |
Fix wrong return value causing OpenXR initialization to fail |
Revision dd0fcb5 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 10, 2019, 22:50 (GMT) |
Fix compile errors on windows and with bundled OpenXR SDK sources |
Revision c1e9cf0 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) 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. |
Revision 84d609f by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 10, 2019, 13:08 (GMT) |
Use OpenXR extension for extra debug messages in debug mode 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.). |
Revision 8617854 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 10, 2019, 13:08 (GMT) |
Only try to enable OpenXR API validation layer in debug mode |
Revision d711540 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 10, 2019, 13:06 (GMT) |
Cleanup: Rename XR_DEBUG_BEGIN -> XR_DEBUG_ONLY_BEGIN Of course also renames XR_DEBUG_END accordingly. |
Revision 6e3158c by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 9, 2019, 15:49 (GMT) |
Only print info messages with --debug-xr enabled |
Revision b216690 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 9, 2019, 15:20 (GMT) |
Add --debug-xr commandline arg and pass on to GHOST XR contexts Doesn't do anything yet. |
Revision b98896d by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 9, 2019, 14:45 (GMT) |
Preparations to allow enabling OpenXR API validation layer 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. |
Revision a05104d by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 9, 2019, 09:28 (GMT) |
Fix warnings and compile error on GCC |
|