Revision 7fe1cc8 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 9, 2019, 08:56 (GMT) |
Enable grid floor in VR session Helps quite a bit orientating. |
Revision 70e84a2 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 8, 2019, 12:18 (GMT) |
Merge branch 'master' into soc-2019-openxr |
Revision 084a33c by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 8, 2019, 12:13 (GMT) |
Use base pose from Blender camera 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). |
Revision 37f619a by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 7, 2019, 11:07 (GMT) |
Don't recreate reference local space on each redraw Set this up on session start. |
Revision 6904ab1 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 7, 2019, 10:45 (GMT) |
Add GHOST_XrSession class for cleaner & safer session management 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. |
Revision 146ef0d by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 3, 2019, 19:01 (GMT) |
Properly end VR sessions fixing crash on next session start Previously, you had to restart Blender to start another session. |
Revision 5891e86 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 1, 2019, 17:04 (GMT) |
Cleanup GHOST_Xr types and functions * 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 |
Revision 2cedad9 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) July 1, 2019, 13:57 (GMT) |
Initial HMD viewport rendering (DirectX only first) 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. |
Revision 109be29 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 29, 2019, 00:30 (GMT) |
Draw offscreen viewport in XR session surface callback 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). |
Revision 13442da by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 28, 2019, 20:53 (GMT) |
Move WM level XR functions to wm_xr.c Operator is still in wm_operators.c, but only calls wm_xr.c functions. |
Revision 231dbd5 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 28, 2019, 14:24 (GMT) |
Support Window-less (offscreen) VR session on Windows 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. |
Revision d3e48fb by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 28, 2019, 12:09 (GMT) |
Merge branch 'master' into soc-2019-openxr |
Revision d544a0b by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 28, 2019, 11:56 (GMT) |
Avoid std::vector copy |
Revision cf4799e by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 28, 2019, 11:38 (GMT) |
Add wmSurface for non-Window offscreen VR 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. |
Revision 57d9f00 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 27, 2019, 17:55 (GMT) |
Fix compile/CMake errors and warnings on Linux |
Revision 62cde7a by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 27, 2019, 17:17 (GMT) |
Finish VR view drawing callback set up * 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. |
Revision e4fcf25 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 27, 2019, 16:56 (GMT) |
Don't use Microsoft::WRL::ComPtr<...> for COM types Makes things difficult if you're not familar with COM. |
Revision 215c919 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 26, 2019, 16:39 (GMT) |
Merge branch 'master' into soc-2019-openxr |
Revision da44a02 by Julian Eisel (soc-2019-openxr, temp-vr-draw-thread, vamr-openxr-module, vr_scene_inspection) June 24, 2019, 19:22 (GMT) |
The first pixels pushed to Windows Mixed Reality HMDs! 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. |
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! |
|