Week 4 (June 15 - June 21):
Exam phase started and hit me hard this week, so very stressful days here. I didn’t get as much done as I hoped to, but again enough to stay in schedule.
-
Main achievement: Finishing the DirectX compatibility layer (637b803b97, 71c7d61808). This is a Blender DirectX Window rendering to an offscreen OpenGL context, and then sharing the result with DirectX for presenting:
What this allows us is to target the Windows Mixed Reality platform, which includes one of the currently two available OpenXR runtimes - the much more advanced one. It is also the platform I use for most testing.The implementation uses shared resources and GPU side framebuffer blitting. That should be as fast as it can get. I expect virtually no performance overhead. It’s made possible with a WGL extension (
WGL_NV_DX_interop) which, although rarely used, should be available on most modern-ish hardware. -
Move OpenXR access API from WM to GHOST/C++ (f30fcd6c85, 4eeb7523e9, d15d07c4f6). Reasons outlined in previous report.
-
Pass low level graphics library data (GLX, WGL, D3D) to OpenXR graphics bindings (9d29373b06, b18f5a6a81, 2ee9c60c20)
-
Use lazy initialization/creation of OpenXR instances (a8519dbac2). Avoids costs of OS wide XR configuration reading and dynamic linking on startup. Also, don’t pay for what you don’t use!
Next Week
Continue working on rendering: Set up OpenXR swapchains, query and use spaces from OpenXR, frame timing, etc. Hopefully within one or two weeks I’ll see a viewport render in my HMD.
One question I didn’t think of earlier: When we do the entire VR view rendering offscreen, who owns the viewport region? Not tying this to the usual wmWindowManager->wmWindow->WorkSpace->bScreen chain would open a can of worms. Maybe introduce a virtual window type? Interesting to look into, but not a hard target for the week.
Exams/deadlines will keep me busy for two more weeks. I’m still trying/intending to get the expected 30h per week done though.