OpenGL on Oculus Rift DK2
Oculus is sending out the first batch of the new development kit DK2 now and has released a new SDK (version 0.4.0) to support it. The display of the Rift (DK1 or DK2) can now be configured using the “Oculus Configuration Utility” in one of two modes (Tools->Rift Display Mode):
- Direct HMD Access from Apps
- Extended Desktop to the HMD
The Direct HMD mode is new in 0.4.0 and basically hides the screen from the OS (currently only Windows) but gives the Rift applications still a way to render to it. This way the user will never have to deal with 2D applications staring on the Rift screen or 3D applications staring on the main monitor.
Extended Desktop mode is the fallback in case the Direct HMD mode fails and will present the Rift as a normal PC monitor (1280*800@60Hz in case of DK1, 1080*1920@75Hz in case of DK2 – yes, the DK2 is rotated!). Using NVIDIA GPUs both modes work for me with the provided demos, but those are running in DirectX – OpenGL is currently a bit more problematic.
The first pitfall is the order of OculusSDK initialisation, HMD creation, window and OpenGL context generation. The best working order seems to be the following:
- glfwCreateWindow – will create a window and a OpenGL context
Note that the window & GL context (step 3) should not be done before the Oculus SDK initialisations and that ovrHmd_AttachToWindow only works for me if I perform this before the ovrHmd_ConfigureRendering call, even tho the order described in the SDK documentation is the other way around (see page 29).
Direct HMD Access from Apps
Using this order, I get correct rendering on Windows 7 with the DK2,
but (very strange) I don’t get any keyboard inputs in GLFW anymore (gamepad works). Keep in mind that I use NVIDIA cards and Direct HMD mode is not supported right now on AMD or Intel.
On Windows 8 however the application crashes. When a OpenGL context on windows gets created, one context gets created using wglCreateContext(). This is used to get some function pointers, e.g. wglCreateContextAttribsARB() and gets deleted after this. In the next step a new context gets created using wglCreateContextAttribsARB(). This second context creation fails on Windows 8 in Direct HMD mode, both in GLFW as well as in Oculus “OculusWorldDemo” (aka Tuscany) when switched to OpenGL rendering. Creating the second context with wglCreateContext() fails also btw. This happens both, for DK1 and DK2.
Extended Desktop to the HMD
The Extended Desktop mode works with DK1 but has some problems with DK2: Running the DK2 at 75Hz and rendering at 75FPS still produces judder and setting the DK2 to 60Hz doesn’t change that my application renders 75FPS (limited by the SDK, so I assume it syncs wrong) so I still get judder. (Note that this is not caused by dropped frames (as mentioned as one cause of troubles in the SDK readme), as the application is rendering at 200-300 FPS if not vsynced.) There are three options to get rid of this problem:
- Only attaching the Rift – if the Rift is the only screen it works fine, but this is often not the most user friendly way.
- Setting the other monitor to 75Hz as well – if you have one that supports it! I had to reactivate an ancient CRT to test this.
- Setting the DK2 as the primary monitor – this is probably the best work around, even tho many 2D windows will start on the Rift which makes working with Windows a pain.
This seems to work on Windows 7 and Windows 8.
But even here I get the problem with missing keyboard inputs from GLFW – not sure if these problems are related.
Keep in mind, that the SDK is still a beta and these problems should be solved in the next releases. I did most of my tests with GLFW, a few with SDL and bit of playing around with the OpenGL renderer of the OculusWorldDemo (wgl API), maybe other libraries do some magic that works better. If you find some better solutions, please let me know.
Update: The keyboard problem was indeed a bug on my side introduced when I had to reorder the initialisation code to work with DK2.