Inspiring

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

13 replies
4416 views

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.

C

cybereality

Inspiring

I'm not that familiar with OpenGL, but I recall that the Oculus SDK is sensitive to when you create your device context versus when your initialize the OVR library. So you may want to switch some of those function calls around and see if that helps.

R

rwblodgettAuthor

Inspiring

That's a good suggestion. I have tried several different orderings, but haven't found that magic permutation yet.

For example, I've tried:

create window
create opengl context
initialize ovr
create hmd device
attach

and

initialize ovr
create hmd device
create window
create opengl context
attach

and

initialize ovr
create hmd device
create window
attach
create opengl context

One other difference I've noticed between my application and the samples is that I've got a 64bit application, so, I'm using libovr64.lib vs them using the 32bit versions.

C

cybereality

Inspiring

Any reason you aren't on the latest 0.4.4 SDK?

kojack

Honored Contributor

I do:
- ovr_Initialize(); (this must be before opengl, since this sets up the code to intercept opengl with the oculus render shim)
- opengl (loaded as part of a dynamic renderer plugin)
- create window
- create hmd
- attach hmd to window
- configure tracking

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

J

jimbo00000

Up and Coming

Direct mode works for me in this project https://github.com/jimbo00000/RiftSkeleton on a GTX 780Ti, i7 920, SDK 0.4.4. I'm doing things in this order:

ovr_Initialize
ovrHmd_Create
glfwCreateWindow
ovrHmd_AttachToWindow
glewInit
ovrHmd_ConfigureTracking
ovrHmd_ConfigureRendering

R

rwblodgettAuthor

Inspiring

"cybereality" wrote:
Any reason you aren't on the latest 0.4.4 SDK?

I have now incorporated 0.4.4, but it still doesn't work. It was worth a try.

"kojack" wrote:
I do:
- ovr_Initialize(); (this must be before opengl, since this sets up the code to intercept opengl with the oculus render shim)
- opengl (loaded as part of a dynamic renderer plugin)
- create window
- create hmd
- attach hmd to window
- configure tracking

I believe I'm following roughly this same thing. However, how do you create an opengl context without supplying a window's device context? ie, I have to create the window first to get the device context.

"jimbo00000" wrote:
Direct mode works for me in this project https://github.com/jimbo00000/RiftSkeleton on a GTX 780Ti, i7 920, SDK 0.4.4. I'm doing things in this order:

ovr_Initialize
ovrHmd_Create
glfwCreateWindow
ovrHmd_AttachToWindow
glewInit
ovrHmd_ConfigureTracking
ovrHmd_ConfigureRendering

I'll have to look in to this project a little more. Basically, I'm doing this order, but through java, I'm not having success. You're using ovrHmd_ConfigureRendering, which implies you aren't doing client distortion rendering, but sdk distortion rendering. I'm trying to do client distortion rendering.

kojack

Honored Contributor

"rwblodgett" wrote:

I believe I'm following roughly this same thing. However, how do you create an opengl context without supplying a window's device context? ie, I have to create the window first to get the device context.

No idea. I let Ogre handle that stuff for me. :)

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

J

jimbo00000

Up and Coming

You're using ovrHmd_ConfigureRendering, which implies you aren't doing client distortion rendering, but sdk distortion rendering. I'm trying to do client distortion rendering.

It's doing both: initializing SDK and client rendering at startup and choosing dynamically between them(press the F4 key). The client path works fine, and is indistinguishable from SDK rendering(to my eyes at least).

Here's the init: https://github.com/jimbo00000/RiftSkeleton/blob/master/src/AppSkeleton/RiftAppSkeleton.cpp#L126
The display type switch is in glfw_main.cpp: https://github.com/jimbo00000/RiftSkeleton/blob/master/src/glfw_main.cpp#L619

M

MrKaktus

Up and Coming

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


int RiftAppSkeleton::ConfigureClientRendering()
{
    if (m_Hmd == NULL)
        return 1;
    ovrSizei l_TextureSizeLeft = ovrHmd_GetFovTextureSize(m_Hmd, ovrEye_Left, m_Hmd->DefaultEyeFov[0], 1.0f);
    ovrSizei l_TextureSizeRight = ovrHmd_GetFovTextureSize(m_Hmd, ovrEye_Right, m_Hmd->DefaultEyeFov[1], 1.0f);
    ovrSizei l_TextureSize;
    l_TextureSize.w = l_TextureSizeLeft.w + l_TextureSizeRight.w;
    l_TextureSize.h = std::max(l_TextureSizeLeft.h, l_TextureSizeRight.h);

    m_EyeTexture[0].OGL.Header.API = ovrRenderAPI_OpenGL;
    m_EyeTexture[0].OGL.Header.TextureSize.w = l_TextureSize.w;
    m_EyeTexture[0].OGL.Header.TextureSize.h = l_TextureSize.h;
    m_EyeTexture[0].OGL.Header.RenderViewport.Pos.x = 0;
    m_EyeTexture[0].OGL.Header.RenderViewport.Pos.y = 0;
    m_EyeTexture[0].OGL.Header.RenderViewport.Size.w = l_TextureSize.w/2;
    m_EyeTexture[0].OGL.Header.RenderViewport.Size.h = l_TextureSize.h;
    m_EyeTexture[0].OGL.TexId = m_renderBuffer.tex;

J

jherico

Inspiring


    ///@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.

Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action

Show more replies

Get Help

Sign up

Login with SSO

Login to the community

Login with SSO