Blender Git Loki

Draw OpenGL framebuffer upside down in DirectX windows

DirectX is Y coordinates top to bottom, while OpenGL is the opposite.
For the final window manager on-screen drawing, draw to a texture first
and draw that upside down if needed.

Support drawing the VR view into a DirectX window!

Phew! That a fight. But this is also a pretty important feature as it
allows interfacing with Windows Mixed Reality OpenXR runtime and the
HMDs supported by it.

Important remaining issue: The rendered viewport is upside down :) That
is of course because DirectX has the opposite vertical direction than
OpenGL.

When creating a DirectX window, we also create an OpenGL offscreen
context to use for all drawing. Just before swapping framebuffers, the
DirectX window blits the framebuffer of the offscreen context into its
swapchain. This requires the WGL_NV_DX_interop and WGL_NV_DX_interop2
extensions.

For testing/dev purposes, also adds:
* Version of the offscreen to onscreen blitting that's OpenGL only. So
it blits the default framebuffer of the offscreen context into the one
of the onscreen context.
This is disabled by a #define.
* Code to draw a colored triangle using DirectX, also for testing.
Requires the D3DCompiler.lib to be available at compile time. This is
also disabled using a #define.

Merge branch 'master' into soc-2019-openxr

Set up DirectX window to support drawing

With this the VR window should open fine and get cleared in a red-ish
orange using Direct3D 11 calls (well, on Windows that is).

The window still draws a 3D view to an offscreen buffer. Where we
usually just swap the buffers, we now allow calling a GHOST function to
blit the offscreen OpenGL buffer to whatever type of graphics buffer the
window uses (DirectX here).
The nice thing about this approach is that all DirectX code stays in
GHOST_ContextD3D.cpp. And the entire compatibiliy code can go into a
single function higher level modules don't need to care about.

This also fixes a number of issues introduced in earlier commits.

Draw into OpenGL offscreen context in the DirectX window.

The window doesn't show anything of course. However we draw (at least I
assume it does) as regular, just into a window offscreen context.

A valid 3D view is created in the window. It's not visible but you see
cursor changes as you move over the window. So handling works.

(Disabled) code to open a DirectX window with the VR session

The window immediately crashes, hence keeping it disabled for now.

Not sure how much of this I'll leave in, for now this is mainly for
testing DirectX compatibility.

Fix compile errors with older MSVC/Win-SDK versions

Reported by @LazyDodo, thanks!

Fix mistake causing compiler error on Windows

Stupid one...

Merge branch 'master' into soc-2019-openxr

Refactor graphics context binding to avoid memory leaks

* Retrieve graphics context to bind through callbacks so the XR code can
manage their lifetime.
* Use static union to store system & chosen graphics lib specific
graphics binding data.

Makes some things a bit cleaner, too.

Fix compile error and warning on GCC

Support DirectX Ghost context creation

Adds support for creating a DirectX 11 Ghost context. It's not used yet
and more stuff besides creation is needed. Also, other versions than 11
should probably be supported.
We need a DirectX context to support the Windows Mixed Reality OpenXR
Runtime, a rather important one to support. Idea is to use an extension
for OpenGL-DirectX interoperability for drawing the OpenGL offscreen
viewport render using DirectX.

Split wm_xr.c into multiple files

Similar to gizmo/ and message_bus/, there's now a xr/ directory
containing header files and a intern/ directory for source and internal
header files.

Guess this is reasonable to do. And better to do early on to avoid
loosing much git history.

Fix compile errors and crashes on Windows

* Include needed Windows/DirectX headers
* Disable zero sized arraz (GCC extension)
* Add missing break causing failling assert
* Add missing semicolon in Win only code :)

Fix compile error with system OpenXR SDK

Graphics binding types were disabled by a compiler flag then.

Cleanup: Rename graphics-lib to graphics-binding

Merge branch 'master' into soc-2019-openxr

Proper management of OpenXR graphics bindings for session setup

OpenXR needs to interface with some graphics library (OpenGL, Vulkan,
DirectX, etc.). This is done through graphics binding extensions. The
OpenXR specification requires these to be properly set up before a
session is created.

Adds the following:
* Support priority list of multiple graphics binding extensions (e.g.
check OpenGL extension availability first, DirectX on Windows second,
etc.)
* Barebones for passing graphics library data to OpenXR session
creation. This is highly system dependent, e.g. it requires GLX data
for OpenGL on X11 systems (XrGraphicsBindingOpenGLXlibKHR). More work,
including additions to GHOST, will be needed once I get to the more
graphics related stuff.
* Create an own graphics context for the VR session. It's not doing
anything useful yet. This is just to fool the Monado OpenXR runtime
so that it actually attempts to create the OpenXR session.
* Had to add two CMake modules for platform dependent #define's required
by the OpenXR specification.

Cleanup: Move OpenXRData struct out of wmXRContext

Just to make access a bit more convenient.

Fix wrong enum-type used for switch

Why doesn't MSVC warn about this, grr...