Revision 867007d by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 24, 2019, 14:44 (GMT) |
Set up OpenXR compositing layers for drawing That should be one of the last steps to prepare pushing pixels to HMDs. Fingers crossed! |
Revision e9ea814 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 24, 2019, 10:52 (GMT) |
Merge branch 'master' into soc-2019-openxr |
Revision 6b43c82 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 23, 2019, 16:27 (GMT) |
Set up OpenXR views and spaces for drawing 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. |
Revision afbb62f by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 23, 2019, 13:42 (GMT) |
Bring back wm_xr.c for higher level XR functions |
Revision 8a676e8 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 23, 2019, 11:47 (GMT) |
Execute necessary OpenXR frame timing calls |
Revision c52111e by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 23, 2019, 00:46 (GMT) |
Correctly destruct swapchain on shutdown |
Revision d749e8a by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 23, 2019, 00:12 (GMT) |
Create graphics binding specific swapchain images 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. |
Revision 8663aa8 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 22, 2019, 22:37 (GMT) |
Use abstract class/interface for generalized graphics binding operations Rather than having switch case blocks throughout the session code, give binding operations an own interface with dedicated implementations. |
Revision 88b3944 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 22, 2019, 20:08 (GMT) |
Fix error causing sessions to not start correctly 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. |
Revision 4cfc3ca by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 22, 2019, 19:25 (GMT) |
OpenXR swapchain creation 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 ;) |
Revision 28428b3 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 21, 2019, 20:31 (GMT) |
Merge branch 'master' into soc-2019-openxr |
Revision 2414656 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 21, 2019, 20:27 (GMT) |
Cleanup: Use CamelCase for XR functions/types Also silence warnings. |
Revision 2ee9c60 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 19, 2019, 19:11 (GMT) |
Finish OpenXR GLX binding initialization 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. |
Revision fb64675 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 19, 2019, 17:09 (GMT) |
Fix invalid delete operator use Again a thing MSVC should warn about but didn't... |
Revision 7638513 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 19, 2019, 16:30 (GMT) |
Use friend class to access graphics data on Windows too Also fix memory leak. |
Revision b18f5a6 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 19, 2019, 15:23 (GMT) |
Pass graphics context data to OpenXR graphics bindings on Linux too 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. |
Revision 9d29373 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 19, 2019, 10:20 (GMT) |
Init OpenXR graphics bindings with valid graphics context (Win only) Will do this for Linux in a separate commit. Also fixes a stupid mistake from previous commit on lazy-creation of XR context. |
Revision f2f1e4d by Julian Eisel (soc-2019-openxr, temp-ghost_openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 18, 2019, 23:00 (GMT) |
Remove CTX_wm_xr_context Not really useful, plus XR-Context is now GHOST data. |
Revision 0da0f29 by Julian Eisel (soc-2019-openxr, temp-ghost_openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 18, 2019, 22:57 (GMT) |
Rename of XR types (WM -> GHOST) |
Revision a8519db by Julian Eisel (soc-2019-openxr, temp-ghost_openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 18, 2019, 22:44 (GMT) |
Lazy-create XR-context 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! |
|