cancel
Showing results for 
Search instead for 
Did you mean: 

Unable to get OpenGL working in Direct HMD mode

jherico
Adventurer
Neither my own applications nor the SDK examples appear to work in OpenGL mode if I enable DirectHMD with a DK1 (no DK2 to test with yet).

In my own example code, if I create a context with glfw and don't specify any special attributes (like the GL version or the profile) then the window is created on my primary monitor at the resolution of the Rift (in the upper left hand corner). If I attempt to specify the GL version and profile type, I get an error that the context could not be created.

In the OculusWorldDemo if I set the OpenGL renderer as the primary renderer, then the example crashes. This is because the wglCreateContextAttribsARB call in Render_GL_Win32_Device.cpp is returning NULL and the application isn't checking for that. The crash occurs a little later when glGetString(GL_VERSION) returns null (because there is no context active) and the SDK attempts to call strstr() with the null pointer.

I'm wondering if this is related to this thread and the behind the scenes voodoo that Oculus is using to render to a non-existent monitor surface.

If I set the Rift mode back to 'Extend Desktop', rendering in OpenGL works properly in both my application code and the Oculus SDK examples.
Brad Davis - Developer for High Fidelity Co-author of Oculus Rift in Action
47 REPLIES 47

sth
Honored Guest
"renderingpipeline" wrote:
Win7: window->OVR: DK1: <not tested>
Win7: window->OVR: DK2: black
Win7: OVR->window: DK1: ok
Win7: OVR->window: DK2: artefacts (GL3.3) - crash (highest GL (4.x))

(OVR->window means init the SDK first, then create a window) Everything on nvidia.

Tried all these configurations in my SDL2-based application and none of them works, not even the OVR->window variant.
The (D3D-based) Oculus demos work fine with direct mode, though.

Windows 7 64bit + nVidia GPU.

renderingpipeli
Honored Guest
"sth" wrote:

Tried all these configurations in my SDL2-based application and none of them works, not even the OVR->window variant.
The (D3D-based) Oculus demos work fine with direct mode, though.

Windows 7 64bit + nVidia GPU.


Thanks for testing, I assume, you are using the same window/SDK initialisation order (and methods) as in this example (viewtopic.php?f=20&t=11067) ?

sth
Honored Guest
"renderingpipeline" wrote:
"sth" wrote:

Tried all these configurations in my SDL2-based application and none of them works, not even the OVR->window variant.
The (D3D-based) Oculus demos work fine with direct mode, though.

Windows 7 64bit + nVidia GPU.


Thanks for testing, I assume, you are using the same window/SDK initialisation order (and methods) as in this example (viewtopic.php?f=20&t=11067) ?

Not the exact same code but it's pretty similar.
I tried ovr_Initialize() before SDL_Init(SDL_INIT_VIDEO) / SDL_CreateWindow() and afterwards; both with DK1 and DK2. The result is always an empty window frame on the desktop and no signal on the HMD, usually followed by a crash on shutdown.

2EyeGuy
Adventurer
"jherico" wrote:
"renderingpipeline" wrote:
It's triggered in ovrHmd_EndFrame 637 (hmds->pRenderer->EndFrame(true);) 284 (ReleaseDC(RParams.Window, dc);) and then it's dying in C:\Windows\System32\OVRDisplay64.dll (Unhandled exception at 0x000007FEF4418D08 (OVRDisplay64.dll) in sdl_glew_ovr.exe: 0xC0000005: Access violation reading location 0x0000000000000008.).



You're zeroing out the memory in ovrRenderAPIConfig before calling ConfigureRendering, right? If you don't the HDC and HWND members of ovrGLConfigData will likely have garbage and could trigger such a crash.

I made that mistake before. Forgot to initialize DC.

rupy
Honored Guest
"jherico" wrote:
... I've said before that one of the biggest hurdles Oculus had to overcome would be the issues inherent in the Rift being treated just like another monitor by the OS.


Yes, but until they create 1) a completely stable workaround (this can take 10 years because of unknown unknowns, see steam, and they only had windows for many years) or 2) their own hardware graphics pipeline standard based on PCIe (this might take them also 10 years); they MUST use exisiting HDMI/DVI and then it's VERY simple to just say:

The standard for Oculus is extended mode, like they now have done (because the screen is in portait mode).

I will look for both portrait and landscape, then rotate the views 90 or 270 degrees if you are in portrait depending on a setting, so if you are upside down that's fixed too.

The bottom line is that the user should not have to select "direct" or "extended" mode. If my app is only compatible with extended, then that should be automatic. Thus removing the service.

If you need forwarding of the sensor data, you should write your own, unless of course everyone will forward the data. The service is over-engineered without adding anything, it's a m&m (managers and meetings) decision. Nobody said "no", or at least we don't know why anyone said "yes" yet!
"It's like Homeworld in first person." Disable Aero and vSync for a completely simulator sickness free experience with 2xHz FPS. Keep the config utility open for tracking to work.

renderingpipeli
Honored Guest
I had some luck getting a correct rendering on Win7 / NV / DK2 with this init order:

ovr_Initialize
ovrHmd_Create
glfwCreateWindow
ovrHmd_AttachToWindow
ovrHmd_ConfigureRendering

Creating the window before creating a HMD did fail as did calling ovrHmd_AttachToWindow after ovrHmd_ConfigureRendering (which I would have expected after reading the docs on page 29 as ovrHmd_AttachToWindow is explained after ovrHmd_ConfigureRendering...). The docs also note, that ovrHmd_AttachToWindow is needed for the direct HMD mode, however, after reading some of the tuscany code I suspect that it should be called always...

Remaining bug: I don't get keyboard input in this mode, but gamepad events.

renderingpipeli
Honored Guest
The init order:

ovr_Initialize
ovrHmd_Create
glfwCreateWindow
ovrHmd_AttachToWindow
ovrHmd_ConfigureRendering

seems only to work on Windows 7 (with the remaining bug of not getting keyboard events).

On Windows 8 however it fails:
When creating a GL context higher than 1.0 you normally create one context to get function pointers needed to generate your final context. When GLFW creates the second window and thus the second GL context, it fails. OculusWorldDemo forced to GL does the same: the final context is defective and thus the glGetString call in Render_GL_Device.cpp:723 returns a NULL pointer, comparing that with the known GL strings via strstr fails (passing NULL to strstr leads to undefined behaviour). So it crashes because of a bug in OculusWorldDemo with not testing for failed context creation but the real problem is that we don't get a valid second context on Win8 (but on Win7).

sth
Honored Guest
"renderingpipeline" wrote:
(with the remaining bug of not getting keyboard events).

Okay, I give up. If this is the best I can expect with direct mode in 0.4.0, I won't waste any more time on this and wait for the next release. Thanks for the info and the time you put into this.

renderingpipeli
Honored Guest
"sth" wrote:
"renderingpipeline" wrote:
(with the remaining bug of not getting keyboard events).

Okay, I give up. If this is the best I can expect with direct mode in 0.4.0, I won't waste any more time on this and wait for the next release. Thanks for the info and the time you put into this.


Sorry, my bad. The keyboard bug was on my side and introduced by when I reordered the init code to work with DK2.

So with the correct init order (and resetting the changed GL states) at least the extended mode should work for testing (even if it has judder) and only using the rift should be ok for testing without judder. Better than nothing and enough to start porting but I hope we will see a working direct HMD mode for GL on WIn7 & Win8 soon!

sth
Honored Guest
Extended mode is working fine for me (I don't even get judder), it's just direct mode that's giving me a headache.

The only thing I haven't tested yet is calling ovrHmd_Create before window creation because it would require some truly horrible hacks in my code.