New to the forums? Click here to read the "How To" Guide.

Developer? Click here to go to the Developer Forums.

DirectHMD mode still broken for OpenGL in 0.4.1

jhericojherico Posts: 1,420
Nexus 6
edited September 2014 in Support
Both my own examples and the OculusWorldDemo fail if I attempt to use them with OpenGL in Direct HMD mode. This is on a GeForce 650 Ti running driver version 340.52.

In the OculusWorldDemo the failure occurs on line 141 of Render_GL_Win32_Device.cpp:
	HGLRC context = wglCreateContextAttribsARB(dc, 0, attribs);

The context returned here is NULL, but the code doesn't actually check the return value, so the crash occurs much later in Render_GL_Device.cpp, where the code attempts to perform a strstr on the value returned from glGetString(GL_VERSION). Again, the return value here is null, but the SDK isn't checking for it, so the strstr is attempting to read from the NULL pointer.
Brad Davis - Developer for High Fidelity
Co-author of Oculus Rift in Action

Comments

  • dghostdghost Posts: 165
    Brain Burst
    Both my projects and a minimum viable SDL test harness fail too.

    Edited to add: interestingly, with the minimum test harness SDL doesn't appear to fail to create a context - it just simply doesn't work. Other projects crash when trying to call SwapBuffers on the device context, though.
    Current Quake II VR stable release: 1.3.1
    DK2 support: see this post
  • mscoder610mscoder610 Posts: 117
    Art3mis
    Yep, similar issues here.

    OculusWorldDemo (when switched to OpenGL) fails for me (on a Radeon 7950) at the line jherico mentioned.

    The OpenGL SDL demo (from here ) and Duke VR (work in progress with SDK 0.4.x) both fail at glGenFramebuffers / glBindFramebuffer, when using Direct Mode.
  • grodenglaivegrodenglaive Posts: 395
    Brain Burst
    Me to - I get BSOD when I try to run tuscany in direct mode. Works fine in extended mode though.
    I have an AMD radeon 7870.
    GA-Z97X-gaming gt; i5-4670k; Nvidia780Ti; 16GB PC3-17066; win7-64 bit; DK2
  • AnonymousAnonymous Posts: 124
    OpenGL is still crystalizing. Further fixes for OpenGL missed the last release train but will make it into the next release. I'm confident most, if not all, of your OpenGL issues will be resolved by then.
  • jhericojherico Posts: 1,420
    Nexus 6
    dghost wrote:
    Both my projects and a minimum viable SDL test harness fail too.

    Edited to add: interestingly, with the minimum test harness SDL doesn't appear to fail to create a context - it just simply doesn't work. Other projects crash when trying to call SwapBuffers on the device context, though.

    Previous experimentation has shown that if you create a context via wglCreateContext it works. The downside is that this function doesn't allow you to specify things like the OpenGL version or profile. Hence if I use GLFW3 to create a context without specifying anything (thus not triggering the use of wglCreateContextARB) then the context is created successfully. It still doesn't show on the HMD device in DirectHMD mode though.

    Similarly, if I create an OpenGL window with a version and a profile, but I defer initialization of the SDK until after the window has been created, I get a window, but no output on the HMD device.
    Brad Davis - Developer for High Fidelity
    Co-author of Oculus Rift in Action

  • FraxulFraxul Posts: 5
    dghost wrote:
    Other projects crash when trying to call SwapBuffers on the device context, though.

    I had this problem with crash on SwapBuffers in my custom GL4.1 engine -- it would crash on the second rendered frame. I managed to solve it by clearing all of the VAO and buffer binding state before passing control to the Oculus SDK (calling ovrHmd_EndFrame):
      glBindVertexArray(0);
      glBindBuffer(GL_ARRAY_BUFFER, 0);
      glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, 0);
      // now safe to call ovrHmd_EndFrame(...)
    

    Figured it out when my app managed to run once without crashing but the last thing that was rendered (UI overlays) had corrupted vertex data. I think the Oculus SDK rendering must be accidentally changing the state of a bound VAO or buffer object, though why that leads to a crash in SwapBuffers is a mystery.

    For initialization, the exact sequence that I use (raw Win32 calls for windowing + GLEW for extensions) is:
    • ovr_Initialize
    • ovrHmd_Detect + ovrHmd_Create + ovrHmd_SetEnabledCaps
    • use DwmEnableComposition to turn off Aero, though I might not actually need this for Direct-to-HMD mode -- still need to test
    • CreateWindow
    • ovrHmd_AttachToWindow
    • ShowWindow
    • Create bootstrapping GL context -- ChoosePixelFormat, SetPixelFormat, wglCreateContext, wglMakeContextCurrent
    • glewInit() to pull the WGL extension function addresses
    • wglDeleteContext to delete the bootstrapping GL context
    • Create "real" GL context -- wglChoosePixelFormatARB, SetPixelFormat, wglCreateContextAttribsARB, wglMakeContextCurrent
    • glewInit() again to ensure updated extension information from the new context
    • ovrHmd_ConfigureRendering and ovrHmd_ConfigureTracking
  • dghostdghost Posts: 165
    Brain Burst
    jherico wrote:
    dghost wrote:
    Both my projects and a minimum viable SDL test harness fail too.

    Edited to add: interestingly, with the minimum test harness SDL doesn't appear to fail to create a context - it just simply doesn't work. Other projects crash when trying to call SwapBuffers on the device context, though.

    Previous experimentation has shown that if you create a context via wglCreateContext it works. The downside is that this function doesn't allow you to specify things like the OpenGL version or profile. Hence if I use GLFW3 to create a context without specifying anything (thus not triggering the use of wglCreateContextARB) then the context is created successfully. It still doesn't show on the HMD device in DirectHMD mode though.

    Similarly, if I create an OpenGL window with a version and a profile, but I defer initialization of the SDK until after the window has been created, I get a window, but no output on the HMD device.

    Interesting. I haven't had time to keep on top of this stuff, so that's good to know. Thanks.
    Current Quake II VR stable release: 1.3.1
    DK2 support: see this post
  • c3c3 Posts: 4
    deanbeeler wrote:
    OpenGL is still crystalizing. Further fixes for OpenGL missed the last release train but will make it into the next release. I'm confident most, if not all, of your OpenGL issues will be resolved by then.

    Is there a general timeframe for when we can expect this next release?
  • jhericojherico Posts: 1,420
    Nexus 6
    c3 wrote:
    Is there a general timeframe for when we can expect this next release?

    In the history of software engineering, when has this ever been a useful question?
    Brad Davis - Developer for High Fidelity
    Co-author of Oculus Rift in Action

  • Gypsy816Gypsy816 Posts: 513
    Nexus 6
    c3 wrote:
    deanbeeler wrote:
    OpenGL is still crystalizing. Further fixes for OpenGL missed the last release train but will make it into the next release. I'm confident most, if not all, of your OpenGL issues will be resolved by then.

    Is there a general timeframe for when we can expect this next release?

    Not at the moment. When we have more info, we'll let you all know! :)
    Oculus Community Manager - kweh!
  • ctrlaltdavidctrlaltdavid Posts: 10
    NerveGear
    My needs for DK2 SDK:
    - OpenGL on Windows
    - Direct mode
    - Program starts up in a normal PC window and user can toggle in and out of HMD view
    - Optional mirroring to PC window
    - Health & safety warning either at program start or first time toggle into HMD view

    Also, I think it would be useful if OculusWorldDemo would compile with OpenGL and run in Direct mode on Windows.
  • 2EyeGuy2EyeGuy Posts: 1,084
    Trinity
    - Program starts up in a normal PC window and user can toggle in and out of HMD view
    Why do you want that?
  • toitoi Posts: 3
    2EyeGuy wrote:
    - Program starts up in a normal PC window and user can toggle in and out of HMD view
    Why do you want that?
    I'd say it has its uses. No need to recompile to switch where you render it. You might not always want to have the HMD on you, especially when you code. Putting it on and off all the time would result in unnecessary tare on the device.
    Although I believe this feature may be hard to achieve because how the different graphics APIs work.

    Is there a good place/thread to see current issues and when they are fixed? I really want to get going programming with SDL2 and hopefully in Linux soon using the direct to rift functionality.
  • toi wrote:
    2EyeGuy wrote:
    Is there a good place/thread to see current issues and when they are fixed? I really want to get going programming with SDL2 and hopefully in Linux soon using the direct to rift functionality.

    Maybe it is just glfw causing issues in my case, but I have a feeling openGl users are going to have to wait till the next oculus SDK update.

    The first obnoxious issue I hit, was having to call ovr_Initialize() after window creation. I read in another post that this issue might be specific to some operating systems. Also, the documentation doesn't mention this but make sure you copy the Additional Dependencies from OculusRoomTiny.

    Right now it seems as though there is no dedicated 'issue tracker.'
  • ctrlaltdavidctrlaltdavid Posts: 10
    NerveGear
    2EyeGuy wrote:
    - Program starts up in a normal PC window and user can toggle in and out of HMD view
    Why do you want that?
    My application is a Second Life / OpenSim virtual world viewer: http://ctrlaltstudioviewer.codeplex.com/ It's not a Rift-specific program and even for users that do have a Rift, they don't necessarily want to spend all their time with it on: many things (e.g., building) are best done in normal desktop view at this stage.
  • dghostdghost Posts: 165
    Brain Burst
    2EyeGuy wrote:
    - Program starts up in a normal PC window and user can toggle in and out of HMD view
    Why do you want that?

    Q2VR supports being used like this, in part because it supports multiple VR backends and in part because it's a game that isn't tied specifically to VR. Being able to enable/disable VR support on the fly is a pretty common use case for things that aren't expected to run in VR 100% of the time.

    And honestly, the fact calling ovr_Initialize() at all in your code messes with display contexts makes me a bit nervous. Currently, I can't even check HMD availability or if it's in Direct HMD mode without it entirely trashing OpenGL in SDL2, making it impossible to fall back to SteamVR or a (hypothetical) different HMD backend.
    Current Quake II VR stable release: 1.3.1
    DK2 support: see this post
  • aiaustinaiaustin Posts: 80
    Hiro Protagonist
    As @ctrlaltdavid noted there are use cases where we will start up in 2D modes and the Rift will be one element of a much richer environment in which content creation and many kinds of UI and interaction are employed and then elements of your session are done in 3D and via the Rift. These are far beyond 10 minute demonstrations and small scale experiences.

    Imagine a collaborative 3D product engineering session in which meetings take place in teleconferences and in which at appropriate times 3D views and interactions take place as part of the whole... Imagine that being a whole day session. Would you expect to have the Rift on for long meetings like that? Yet some of us are regularly running multi-hour mixed reality events now.

    Lack of DK2 and 0.4.1 SDK OpenGL availability is holding things up folks. Oculus, if you have fixed things in OpenGL can you push a 0.4.1 rev 2 or new version ASAP.

    P.S. constant reminders on every entry back to 3D, within one run of a program, of the health and safety warning is a real inappropriate intrusion on such use cases.
  • Hi,

    I'm trying to get a simple Polycode-Example working with DirectHMD Rendering.

    I got access violations at
    glBindFramebufferEXT
    

    I sorted that out by using GLEW.

    I now got the SDK do the distorion to the textures I provided. The only problem I have is, that the distorted textures are displayed in the application window on my main screen, but not the rift.
    ovrHmd_AttachToWindow
    

    is being called properly. Any clues, what's missing?

    You can find the sourcecode here. The Polycode-specifics should be minimal. There's no application of the headtracking yet. First I want the rift to show the stuff.

    The most relevant file is this one.

    Edit:
    I'm on Windows 7, with SDK 0.4.1, Rift DK2 and an NVIDIA-Card.
  • jhericojherico Posts: 1,420
    Nexus 6
    Smola wrote:
    Any clues, what's missing?

    Proper support for OpenGL on Direct HMD mode is what's missing. I've heard responses from Oculus that Direct HMD mode is known to be incompatible with AMD, but I've never seen it work on any hardware. It's possible that there is some combination of driver / hardware / OS versions that allows it to work, but it doesn't on my machine with up-to-date versions of the nVidia drivers and Windows 8.1 (running a GeForce GTX 650 Ti).

    Even the OculusWorldDemo included with the SDK doesn't work for me, and if Oculus' examples don't function, I consider the feature broken.
    Brad Davis - Developer for High Fidelity
    Co-author of Oculus Rift in Action

  • I understand that. Nevertheless I read that people manage to display at least something on the rift display using OpenGL DirectHMD, even if it is shifted, wrong, not properly distorted or whatever. I don't see anything on the display. I'd love to see something, even if it's wrong.

    I know, it's in vain to try to achieve that atm, but I want to learn. I haven't done any C++/OpenGL in a long while and I learned.
  • jhericojherico Posts: 1,420
    Nexus 6
    Smola wrote:
    I understand that. Nevertheless I read that people manage to display at least something on the rift display using OpenGL DirectHMD, even if it is shifted, wrong, not properly distorted or whatever. I don't see anything on the display. I'd love to see something, even if it's wrong.

    I know, it's in vain to try to achieve that atm, but I want to learn. I haven't done any C++/OpenGL in a long while and I learned.

    It's understandable to want to get it to work. But I think it's a waste of resources to fight with the SDK trying to do so now. Extended mode works, and if you're coding your application correctly, once Direct HMD mode does support OpenGL, you shouldn't have to do any additional work to support it.
    Brad Davis - Developer for High Fidelity
    Co-author of Oculus Rift in Action

  • jherico wrote:
    Extended mode works, and if you're coding your application correctly, once Direct HMD mode does support OpenGL, you shouldn't have to do any additional work to support it.

    Okay, so I've seen this mentioned plenty of times, and while it is useful for building now, I seem to be getting a lot of tearing/vsync issues. I thought that mirroring like with DK1 would be better, but now DK2 just rotates my screen so when i'm testing my app I can't ever see it on screen the same time as it's on extended displaying in the rift.

    i guess my question is what is the preferred workflow? pick up a directX11 book and hope to implement all my texture stuff like that asap?
  • aiaustinaiaustin Posts: 80
    Hiro Protagonist
    I see that SDK 0.4.2 beta is out but the release notes do not make any mention of OpenGL fixes... @deanbeeler did the fixes mentioned earlier make it into that release?
  • I also tried sdk 0.4.2 and OculusWorldDemo app with"GL" on my amd card, but it still fails
    when I launch the app. So I guess the new release doesn't fix the problem? Can oculus team confirm with that?

    Thanks!
  • jhericojherico Posts: 1,420
    Nexus 6
    trippedout wrote:
    i guess my question is what is the preferred workflow? pick up a directX11 book and hope to implement all my texture stuff like that asap?

    I don't really have a good workflow for rendering concurrently to the Rift display and a visible monitor. I suggest you include a compile flag or command line option to allow you to easily toggle rendering to a monitor or to the Rift. I tend to spend most of my time rendering output to a screen, and then only switching to the Rift for final testing and tweaks.
    Brad Davis - Developer for High Fidelity
    Co-author of Oculus Rift in Action

  • vrcatvrcat Posts: 23 Oculus Staff
    iiicaryp wrote:
    I also tried sdk 0.4.2 and OculusWorldDemo app with"GL" on my amd card, but it still fails
    when I launch the app. So I guess the new release doesn't fix the problem? Can oculus team confirm with that?

    Thanks!

    iiicaryp: Thanks for reporting this issue. Confirmed: This has been a known issue with the display driver that we are working on.
  • jherico wrote:
    I don't really have a good workflow for rendering concurrently to the Rift display and a visible monitor. I suggest you include a compile flag or command line option to allow you to easily toggle rendering to a monitor or to the Rift. I tend to spend most of my time rendering output to a screen, and then only switching to the Rift for final testing and tweaks.

    with DK1 it was so easy to mirror and work on rift and screen, seems impossible with 2 with the rotation issue among other things - i have a flag now that switches between auto-fullscreening my second monitor (rift) or just displaying in window on main monitor but there's gotta be a better way
  • toitoi Posts: 3
    deanbeeler wrote:
    OpenGL is still crystalizing. Further fixes for OpenGL missed the last release train but will make it into the next release. I'm confident most, if not all, of your OpenGL issues will be resolved by then.
    Yeah, I don't see any OpenGL fixes in 0.4.2 at all. I am kind of saddened that so major issues still exists.
    I would love to code on Linux (or even just OpenGL) with direct to rift, but what it seems like now is that it will take a very long time before that can happen. Sure I can do it with extended mode but it is such a hassle and direct to rift should really be working :(
    Hopefully we will see a fix soon! Any further communications on how the fixes are going would also be appreciated as DK2 have been out for many weeks now.
  • ConstellationConstellation Posts: 211
    Art3mis
    I think that direct mode is working for me in OpenGL with the OculusWorldDemo. I installed the 0.4.2 Beta SDK, loaded up the VS2010 solution file and commented in OpenGL support on line 228 of OculusWorldDemo.cpp as follows:
    //#if defined(OVR_OS_WIN32)
    //    const char* graphics = "d3d11";
    //#else
        const char* graphics = "GL";
    //#endif
    

    I have my display mode set to Direct HMD and when I debug into the demo I'm hitting line 150 which has a comment which seems to confirm direct mode:
            // In Direct App-rendered mode, we can use smaller window size,
            // as it can have its own contents and isn't tied to the buffer.
            WindowSize = Sizei(1100, 618);//Sizei(960, 540); avoid rotated output bug.
    

    When it runs I get a small window that looks like it's matching the Sizei(1100, 618) hard coded above. On the Rift everything looks fine. My frame rate is jumping around between 65-75 fps, though I'm guessing that may be normal for a 770M GPU. I am running on a laptop which does not have Optimus (Asus G750JX). Am I truly running direct with GL or is this just a misconfiguration?
Sign In or Register to comment.