SDK 0.4 feedback

- ovrHmd_EndFrame() sets GL_FRONT_FACE to GL_CW. OpenGL default is GL_CCW. (didn't happen with 0.3.2)

Bingo! Nice find, thanks.

- Direct mode doesn't work at all for me, despite calling ovrHmd_AttachToWindow(). Works with the Oculus demos, though.

Likewise with my DK1. Recompiling the OculusWorldDemo to use GL - that still works in direct mode, so I'm not sure what we're doing wrong here.

"sth" wrote:

- ovrHmd_EndFrame() sets GL_FRONT_FACE to GL_CW. OpenGL default is GL_CCW. (didn't happen with 0.3.2)
- Direct mode doesn't work at all for me, despite calling ovrHmd_AttachToWindow().

The SDK has a mode to restore the old GL state, however, the switch to GL_CW is done during the health warning rendering (see CAPI_GL_HSWDisplay.cpp line 397). There are other states set in that function (blending, depth test etc.).

I also found: ovrHmd_EndFrame somehow modifies the bound vertex array object and fails if VAO 0 is bound - I had to create a VAO for the SDK an now bind it before that call (didn't look into that function to check what the problem is excactly)...

Direct rendering mode works for me (OpenGL, GLFW) - but seems to be very slow. Extended desktop mode does not work for me, the Rift shows my desktop but the rendered GL window flickers (rendered view and black).

(I still have some rendering artefacts that might also come from changed states by the SDK).

(I'm testing on a DK1, Windows 7, GeForce 560.)

* Seems like somewhere inside of the SDK rendering the satet of glDepthMask is changed but never set back.

* CAPI_GL_HSWDisplay is checking for GL errors (OVR_ASSERT(glGetError() == 0);, line 417), however, if there was an old error from the client code, the SDK code will fail. Found this as I had to switch from GL core to compatibility as the SDK does not support core profiles and a core-compatibility issue generated a harmless gl error.

* The SDK does not support core profiles (the SDK shaders fail to compile in a core context).

I solved the flickering and the slow rendering issue (in case anyone else encounters this): there was still a glfwSwapBuffers call in the code - the swap is handled by the SDK and somehow this swap was no issue in SDK 0.3 on Linux (could be another side effect of the client code). Bottom line: make sure you don't call any swaps yourself.

Did a bit more investigation:

• Core profile (OpenGL 3.2 context) works for me, but as with legacy mode, I get severe rendering errors when TimeWarp is enabled (see below).


• I tried adding lots of different state resets before and after ovrHmd_EndFrame(), including giving it its own shiny VAO and enabling the depth buffer for the screen (only have one for the eye renders normally), but no change.


• The Oculus service (or the communication with it) seems really buggy. Right now, after ~1 hour of debugging since the last reboot, the state is the following: My application does a little check* at startup to determine if an HMD is present. Right now I'm at a point where this check succeeds while actual initialization (shortly afterwards) fails in ~20% of cases. And in the cases where it succeeds, I don't have head tracking most of the time. A reboot (probably even a manual restart of the Oculus service) fixes some of these issues temporarily.


• I still can't get direct mode to work. I get a black window on the desktop and "No signal" on the HMD. It also crashes my app on exit and I sometimes get crashes in ovrHmd_EndFrame(), although I haven't been able to reproduce these reliably. Direct mode with DK1 Legacy App Support works (by using extended desktop) and so does the normal extended desktop mode.


• Some errors in the Oculus service might be triggered by crashing client applications. I'm having these problems often while debugging and also had this happen when Oculus' own applications (Tuscany, Config Util Demo Scene) crashed.

* Basically just ovr_Initialize(), ovrHmd_Detect(), ovrHmd_Create(), ovrHmd_Destroy(), ovr_Shutdown()

Direct rendering mode works for me (OpenGL, GLFW) - but seems to be very slow. Extended desktop mode does not work for me, the Rift shows my desktop but the rendered GL window flickers (rendered view and black).

Did you have to pass any particular glfwWindowHint? For me the glfwCreateWindow call return NULL when trying Direct Rendering Mode.

"Foogywoo" wrote:

Did you have to pass any particular glfwWindowHint? For me the glfwCreateWindow call return NULL when trying Direct Rendering Mode.

I create the window before I do anything with the Rift SDK. In older SDK I checked if a Rift is present and then looked for the Rift monitor to get fullscreen on that one but with direct mode it's not needed anymore.

I do the following:

* glfwCreateWindow(...) (I use hints for the GL version but this should not be a problem with the Rift)
* ovr_Initialize();
* ovrHmd_Create(0);
* ovrHmd_ConfigureTracking(...);
* configute the textures, rendersize (ovrHmd_GetFovTextureSize) etc.
* ovrHmd_ConfigureRendering: here the ovrGLConfig object needs the window handle: cfg.OGL.Window = glfwGetWin32Window( _window ); cfg.OGL.DC = GetDC(cfg.OGL.Window);
* test if the system is configured for direct HMD access: bool riftIsUsingExtendedDesktop = (bool)(_hmd->HmdCaps & ovrHmdCap_ExtendDesktop);
* if no extended desktop is used: if(!riftIsUsingExtendedDesktop) ovrHmd_AttachToWindow(hmd, cfg.OGL.Window, nullptr, nullptr);
* rendering: ovrHmd_BeginFrame & ovrHmd_EndFrame - NO glfwSwapBuffers!

You see, the window creation is independent on the Rift, so that should not fail.

"renderingpipeline" wrote:
I do the following:

* glfwCreateWindow(...) (I use hints for the GL version but this should not be a problem with the Rift)
* ovr_Initialize();

I think the problem is that most people will be calling glfwCreateWindow after ovr_Initialize and ovrHmd_Create in order to use the HMD information to get the size and position of the window. But from my testing, if direct HMD mode is enabled then wglCreateContextAttribsARB fails to generate a context. If you call glfwCreateWindow without any hints, it relies on wglCreateContextAttribs, but if you specify the OpenGL version or other things like the profile, then it uses wglCreateContextAttribsARB and you get a failure or crash.

I create the window before I do anything with the Rift SDK. In older SDK I checked if a Rift is present and then looked for the Rift monitor to get fullscreen on that one but with direct mode it's not needed anymore.

Thanks, the window now create and render properly, but I'm still not able to have the output on the Rift. Extended mode is working fine for me. At which point in your init steps are you calling glfwMakeContextCurrent(window)?

Thanks!

"Foogywoo" wrote:

Thanks, the window now create and render properly, but I'm still not able to have the output on the Rift. Extended mode is working fine for me. At which point in your init steps are you calling glfwMakeContextCurrent(window)?

Same here, if I create a GLFW window before calling ovr_Initialize it works fine, and I can then call move and size to position it based on the HMD I set up later. Creating a GLFW window with a specific version after ovr_Initialize always fails.

Sometimes I feel like I'm being tested.

"jherico" wrote:

Sometimes I feel like I'm being tested.

You're not. Now please proceed to the next test chamber to receive your cake.

I call make current just after I created the window. Moving the window later is a good idea, I'll try that out. How do you detect the Rift in extended mode (in GLFW)? I would go by the resolution (and assume it's not the primary) but that could fail of course...