RenderingPipeline

from geometry to pixels

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.

Implementation

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:

  1. ovr_Initialize
  2. ovrHmd_Create
  3. glfwCreateWindow – will create a window and a OpenGL context
  4. ovrHmd_AttachToWindow
  5. ovrHmd_ConfigureRendering

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.

Final notes

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.

, , ,

3 thoughts on “OpenGL on Oculus Rift DK2
  • olstaad says:

    Hi,

    I applied the same pattern as you:
    ovr_Initialize
    ovrHmd_Create
    glfwCreateWindow – will create a window and a OpenGL context
    ovrHmd_AttachToWindow
    ovrHmd_ConfigureRendering

    But I have a crash and “OVRCreateDXGIFactory result 0x0” in the console.

    Do you have a code sample to show for help ?

    Thanks

    Awesome blog btw

    • Robert says:

      OVRCreateDXGIFactory sounds like a Direct3D related function, not OpenGL related. Maybe there is a problem with the OVR setup?

      • olstaad says:

        RESOLVED

        Yes indeed “OVRCreateDXGIFactory result 0x0″ is related to DirectX. After a long search I finally understood everything!

        SOLUTION: Select the Rift Display Mode” as “Extend Desktop to the HMD” before executing the program.

        EXPLANATION: The trace “OVRCreateDXGIFactory result 0x0” is generated by some functions in “OVR_Win32_ShimFunctions.cpp”. These functions intercept some function calls between the program and the OS. In direct HMD access from apps, OpenGl directives are not supported, so some calls were certainly trying to use DirectX stuff, and of course failing because DirectX was not initialized.

        In “Extend desktop to the HMD”, the OpenGL calls works, and the shim functions are not even bothered by the activities.

        Anyway, I’m quite happy the solution was found.

        Bye bye

Leave a Reply

Your email address will not be published. Required fields are marked *

*