Blender Git Commits

Fix objects not visible

Object.base_flag was not updated correctly so objects were hidden.

Fix race condition in state changes + related cleanup + add assert

Merge branch 'soc-2019-openxr' into temp-vr-draw-thread

Fix compile error after merge and warning

Merge branch 'master' into soc-2019-openxr

Fix error in OpenGL version check for OpenXR 1.0

Fix compile error on GCC

Add sources for OpenXR core API validation layer

Had to do quite some changes to CMakeLists.txt from the SDK this time.

Address changes in OpenXR 1.0 to get rendering to work again

Update OpenXR to version 1.0

Only tested on Windows.

Updates loader sources from the OpenXR SDK to latest 1.0 SDK and updates
requiremed version to 1.0. The compile time generation of files is a
thing of the past now (although you can still force it).
1.0 got released yesterday. Only one line needed fixing in our OpenXR
code to get it to compile. Rendering is black though.

For now I tried to keep edits to CMakeList.txt files minimal. So now
there are OpenXR CMake options exposed (with bad names), CMake prints,
etc.

Merge branch 'soc-2019-openxr' into temp-vr-draw-thread

Merge branch 'master' into soc-2019-openxr

Initial, mostly broken VR viewport drawing on own thread

Spawns a separate thread to do any VR session drawing on. There are
four reasons for this:
* VR session doesn't need the usual main loop procedure for drawing.
With the drawing on a separate thread, the session doesn't have the
overhead of the other parts of the main loop.
* OpenXR performs thread blocking operations to synchronize rendering
with the device refresh rate. This would conflict with the rest of
Blender, causing lags on event handling, drawing, etc.
* With an own thread, we can keep a single OpenGL context alive,
avoiding expensive context switches. This should improve performance
significantly.
* With a bit more work, viewports can draw entirely in parallel (at
least the CPU side of it), pushing performance even further.

Drawing the viewport on a separate thread shouldn't be much of an
issue. The draw-manager is already thread safe (mutex guarded). Not much
seems needed to get it entirely concurrent, allowing viewport drawing
from separate threads without any synchronization (i.e. only one at a
time).
I had to create an own depsgraph for the VR draw thread so the viewport
gets its own buffers for its own OpenGL context.

Right now this is utterly broken, but at least an empty viewport is
drawn for the VR session in a separate thread. Issues are:
* VR viewport doesn't draw any objects, just background + overlays
(apparently the VR session depsgraph isn't built correctly).
* OpenGL context of the main thread seems messed up when drawing the VR
view. Result is drawing glitches and eventually Blender crashes.
* Exiting the VR session causes failed assertions and memory leaks.

Use fixed lighting, don't make it rotate with view rotation

Fix broken VR viewport rotation and movement

Use draw manager offscreen context for the VR session

This way we avoid the big overhead of context switches. Makes frames
render about twice as fast here. For heavy Spring scenes I'm getting
around 20 FPS here, classroom scene is at 50 FPS.
This is great given that drawing itself still isn't optimized for dual
eye rendering.

Print 8 Frame average FPS for --debug-xr-time

Much more useful than a per frame FPS estimation. 8 frames are used for
the Blender viewport FPS stats too.
Refactored drawing data storage a bit.

Add --debug-xr-time command line option for VR frame time info prints

Outputs frame render time in milliseconds and FPS this time would add up
to. We could average times so FPS is a bit more stable, but the
precision of un-averaged results may be helpful too.

Merge branch 'master' into soc-2019-openxr

Silence GCC warning