Forum Discussion
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.
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
- 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.
- 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. - Any reason you aren't on the latest 0.4.4 SDK?
- 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 - 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 "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."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. :)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- 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;
///@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.
