Skip to main content
rwblodgett
Inspiring
January 16, 2015

Trying direct hmd mode, but everything's stacked against me

Ok, that's a little too melodramatic of a title.

We've got a java application, using jogl, rendering multiple opengl contexts, incorporating libovr via jni, rendering with client distortion rendering (because all of our content is working in jogl), and we have the oculus rift dk1 and dk2 working in "extended desktop" mode with the exception that there is lots of Judder for the dk2.

Lots of Judder.

When I run the Oculus World Demo in extended desktop mode, there's lots of judder there too. However, when I run the Oculus World Demo in direct hmd mode, no judder.

So, I'm trying to get our client distortion rendered, opengl, java application working with the oculus in direct hmd mode. No dice. Should this be possible? When I call ovrHmd_AttachToWindow(hmd, hwnd, NULL, NULL) it returns true, but nothing ever appears inside the headset. I'm getting the hwnd for the window I'm creating over in Java Swing by calling the Windows API FindWindow function. You see, I've got to create the window, and opengl context, on the java side, because I'm doing all our rendering of content on the java side. Remember, this works in Extended Desktop mode. Before I actually create the java window, and opengl context though, I initialize the oculus library. Then I create the window, and opengl context. And then I try to attach.

Yes, I have "Direct HMD Access from Apps" selected in the Display Mode dialog. I'm using the 0.4.3 SDK as of now.

Any ideas?

I don't see any example in the SDK using client distortion rendering, opengl, direct hmd mode, all from within a dll. I have seen somebody post an opengl direct hmd example of the tiny room demo. This works for me, as a standalone exe, but again, not as an embedded dll.

I'm not sure if the problem lies with Java, Windows API, or Oculus's hmd direct driver. Is there a way I can rule out the latter, or view why it thinks it wouldn't be showing up in the headset?

thanks.

    13 replies

    Show previous replies
    jimbo00000
    Up and Coming
    January 23, 2015
    mrkaktus, Brad - thank you both for your input. I've cleaned the relevant code up a bit.

    "mrkaktus" wrote:
    It doesn't look like Client Rendering to me at all :


    int RiftAppSkeleton::ConfigureClientRendering()
    {
    ...


    I've extracted the common parts of initialization into a function ConfigureRendering:

    https://github.com/jimbo00000/RiftSkeleton/blob/master/src/AppSkeleton/RiftAppSkeleton.cpp#L216
    It's now called before both the SDK and Client init functions here:
    https://github.com/jimbo00000/RiftSkeleton/blob/master/src/AppSkeleton/RiftAppSkeleton.cpp#L126


    "jherico" wrote:

    Yes... you need to choose. If you plan to do client based rendering, you should not be calling ovrHmd_ConfigureRendering or ovrHmd_AttachToWindow on the target window.


    Following the ovrHmd_ConfigureRendering call into CAPI_HMDState.cpp's HMDState::ConfigureRendering I don't see anything that looks specifically like it would break if both the client and SDK paths are called. Although there is a rather unambiguous sentence in the Oculus Developer Guide:


    8.2.2 Configure rendering
    With the FOV determined, you can now initialize SDK rendering by calling ovrHmd_ConfigureRendering. This also generates the ovrEyeRenderDesc structure that describes all of the details needed when you come to perform stereo rendering. Note that in client-rendered mode the call ovrHmd_GetRenderDesc should be used instead.


    And for attaching the window pointer, is it benign if the SDK merely retains that pointer and doesn't act on it when not called?

    Calling both paths seems to work fine on my system (DK2, SDK0.4.4, Win7, 780Ti, nv driver 347.09) in Direct & extended modes, debug & release, core & compatibility context(and all 8 permutations), and each render type works with the others' init commented out.
    kojack
    kojack
    Honored Contributor
    January 23, 2015
    "jherico" wrote:

        ///@todo Do we need to choose here?
        ConfigureSDKRendering();
        ConfigureClientRendering();


    Yes... you need to choose. If you plan to do client based rendering, you should not be calling ovrHmd_ConfigureRendering or ovrHmd_AttachToWindow on the target window.

    Client rendering still uses ovrHmd_AttachToWindow, without it you are stuck with extended mode instead of direct mode.
    Author: Oculus Monitor , Auto Oculus Touch , Forum Dark Mode , Phantom Touch Remover , X-Plane Fixer Hardware: Threadripper 1950x, MSI Gaming Trio 2080TI, Asrock X399 Taich Headsets: Wrap 1200VR, DK1, DK2, CV1, Rift-S, GearVR, Go, Quest, Quest 2, Reverb G2, Quest 3
    jimbo00000
    Up and Coming
    February 1, 2015
    Here's a useful guide for anyone using GLFW with the OVR SDK:

    http://www.glfw.org/docs/latest/rift.html


    LibOVR needs to be initialized before GLFW. This means calling at least ovr_Initialize, ovrHmd_Create and ovrHmd_ConfigureTracking before glfwInit. Similarly, LibOVR must be shut down after GLFW. This means calling ovrHmd_Destroy and ovr_Shutdown after glfwTerminate.


    Previous to finding the guide I was initializing these in a different order, but it seemed to work fine on Win7.
    Terms & ConditionsAccessibility statement