Open JeroMiya opened 7 years ago
OpenVR handles this very nicely. Their Steam VR Compositor operates as a separate process, so there is no context issues to work around. It uses DirectX & handles interop for you, if your application is in OpenGL. It also takes care of Direct Mode. I went in expecting similar functionality from the OSVR Render Manager & have been struggling since. My advice would be to take OpenVR's lead & not try and integrate the rendering manager within the same application, which causes the whole context issue. I want my own "mirror" rendering window (for spectators) & the rendering manager should be a separate tool to manage displaying to the headset.
Another huge benefit to making the rendering manager a separate process: if the host application locks up or takes too long to submit frames, the rendering manager can continue to run & display an empty scene with tracking. This prevents motion sickness during loading times, for example.
We already have plans to implement a compositor similar to OpenVR, as a separate process. That is sort of a longer-term project. This issue is somewhat orthogonal in that, compositor or not, we should be able to make it easier to share OpenGL contexts and/or handle direct3D interop for you.
Our previous solution, the custom toolkit, enables this, but it's a big hammer where the application becomes responsible for creating the window on the HMD and creating the context and setting up resource sharing with any other context in the application (like a preview window).
For this issue I'd like to see the following two scenarios made easier: 1) Allow RenderManager to create an OpenGL context (using SDL2 currently) and window, and have it automatically setup resource sharing with the existing context, if any. This would be extended mode only for now. 2) Allow RenderManager to create a Direct Mode Direct3D context, configure OpenGL interop with an existing OpenGL context, and have everything just work.
I commited my jMonkeyVR OSVR "work in progress", the meat of which can be seen here:
https://github.com/phr00t/jMonkeyVR/blob/master/src/jmevr/input/OSVR.java
This could be used as a framework for improving Render Manager's behavior. 2) is where we want to be, but if that is too far out, I could work with 1) in the meantime.
Right now, jMonkeyVR has the Render Manager create a context first, since it seems to play the "most nice" with my LWJGL-created context later. I can see output to my primary window, but the Render Manager displays white & gives me GL_INVALID_OPERATION errors, as seen in this issue:
https://github.com/sensics/OSVR-RenderManager/issues/223
If I create the context first with LWJGL, then try to open a Render Manager window, my primary display is black.
Here is a built JAR of the OSVR "Work in progress":
https://drive.google.com/open?id=0Bza9ecEdICHGT0lRZy1DR0NWR1k
github wouldn't take it due to the 100MB limit. It was originally around ~21MB, adding OSVR brings it to 103MB ;)
So we added support for custom OpenGL toolkits, so that the application can take over creation of the window and OpenGL context, and RenderManager will tell the application where to put the window, what size to make it, etc...
That's good, but what if the user just wants to create their own context for the preview window, and let RenderManager create the window and context for the HMD window, and setup resource sharing between contexts automatically?
The feedback I'm getting from users is that setting up shared OpenGL contexts is too difficult. They can write their own toolkit, but all they really wanted was for RenderManager to create its own window and context and setup context sharing automatically. This is how the OpenGLSharedContext example currently works, for example. But that sample only appears to work when the application is also using SDL. Can we make it work for other toolkits using low-level OS-specific context calls like wglGetCurrentContext, and the Mac/Linux equivalents?
Above just making it easier for developers, this would make it possible to take advantage of RenderManager's ability to open up a direct mode context. We wouldn't necessarily expect applications to be able to create their own direct mode windows and contexts (through Direct3D/OpenGL interop or through extensions, if available).