Forum Discussion
No sRGB inside HMD (OpenGL, SDK 0.4.3)
Hello,
Here is my experience with the DK2 so far. I work with SDL2, OpenGL 3.3 in default profile (compatibility ?) and Windows 7 64 bits for now. I was surprised to get the Direct HMD mode working flawlessly (with this initialisation order : ovr_Initialize, ovrHmd_Create, window and GL context creation, ovrHmd_AttachToWindow, ovrHmd_ConfigureRendering).
The only problem that disturbs me is that I can't get sRGB correction when outputing to the HMD in direct-HMD mode (colors are okay in extended desktop mode). I usually set my color textures to GL_SRGB8 format to get free conversion to linear space when reading textures, and when I output to color framebuffers (or FBO with GL_SRGB8 attached textures) I usually use the GL_FRAMEBUFFER_SRGB option.
With the rift, I use two SRGB8 textures as framebuffers and use the SDK deformation renderer. The ovrDistortionCap_SRGB flag is set in the ovrHmd_ConfigureRendering call, and I get a correct image on my desktop screen, but not in the HMD (too dark, like if I was outputing the linear colors directly). If I omit this flag, the images on both my screen and the HMD are wrong (again, uncorrected linear colors). And this is in Direct-HMD mode only, I have troubles using extended desktop mode (not related to the SDK) but I can see that colors are correct. If I change the texture formats of my framebuffers from SRGB8 to RGB8 I just lose precision in dark colors (banding).
I don't know if the situation is the same with DirectX, but apparently this is a bug in the SDK. Is there some other experience that contradicts mine, or some devs at Oculus who know what's happening in that part of the SDK ? I want to know if this is something that would get corrected in future versions or if I have to do the old trick of sqrt'ing color writes...
Thanks !
Here is my experience with the DK2 so far. I work with SDL2, OpenGL 3.3 in default profile (compatibility ?) and Windows 7 64 bits for now. I was surprised to get the Direct HMD mode working flawlessly (with this initialisation order : ovr_Initialize, ovrHmd_Create, window and GL context creation, ovrHmd_AttachToWindow, ovrHmd_ConfigureRendering).
The only problem that disturbs me is that I can't get sRGB correction when outputing to the HMD in direct-HMD mode (colors are okay in extended desktop mode). I usually set my color textures to GL_SRGB8 format to get free conversion to linear space when reading textures, and when I output to color framebuffers (or FBO with GL_SRGB8 attached textures) I usually use the GL_FRAMEBUFFER_SRGB option.
With the rift, I use two SRGB8 textures as framebuffers and use the SDK deformation renderer. The ovrDistortionCap_SRGB flag is set in the ovrHmd_ConfigureRendering call, and I get a correct image on my desktop screen, but not in the HMD (too dark, like if I was outputing the linear colors directly). If I omit this flag, the images on both my screen and the HMD are wrong (again, uncorrected linear colors). And this is in Direct-HMD mode only, I have troubles using extended desktop mode (not related to the SDK) but I can see that colors are correct. If I change the texture formats of my framebuffers from SRGB8 to RGB8 I just lose precision in dark colors (banding).
I don't know if the situation is the same with DirectX, but apparently this is a bug in the SDK. Is there some other experience that contradicts mine, or some devs at Oculus who know what's happening in that part of the SDK ? I want to know if this is something that would get corrected in future versions or if I have to do the old trick of sqrt'ing color writes...
Thanks !
20 Replies
- It might be failing for the default framebuffer if the context initialization is calling SetPixelFormat twice on the same window because this isn't allowed ( see remarks at http://msdn.microsoft.com/en-us/library/windows/desktop/dd369049(v=vs.85).aspx ).
The code at \oculussdk\samples\commonsrc\render\render_gl_win32_device.cpp in the Oculus 0.4.2 SDK calls SetPixelFormat twice on the same window/dc, so the second call where it tries to set WGL_FRAMEBUFFER_SRGB_CAPABLE_ARB is probably ignored. - Thanks for the hint. I dug a bit more, and correct me if I'm wrong. If we use the direct-HMD mode, what is displayed on the rift is not the surface where we created a DX/GL context (which is displayed on a window). I have no clear idea how the rift get those frames, I'm not even sure if it's part of the SDK.
By the way, the sample demos from Oculus don't seem to use an sRGB framebuffer, so they're fine whatever mode is used. "ockiller" wrote:
I was surprised to get the Direct HMD mode working flawlessly (with this initialisation order : ovr_Initialize, ovrHmd_Create, window and GL context creation, ovrHmd_AttachToWindow, ovrHmd_ConfigureRendering).
Thanks a lot for that piece of information! Following that exact order (and eliminating all other calls that might interfere), I finally got direct mode working!
However, it vsyncs at 60Hz, which leads to stuttering. :( Did you encounter this problem? (SDK 0.4.3)"ockiller" wrote:
The only problem that disturbs me is that I can't get sRGB correction when outputing to the HMD in direct-HMD mode (colors are okay in extended desktop mode). I usually set my color textures to GL_SRGB8 format to get free conversion to linear space when reading textures, and when I output to color framebuffers (or FBO with GL_SRGB8 attached textures) I usually use the GL_FRAMEBUFFER_SRGB option.I don't get correct colors in either mode. Normal (non-Rift) mode works fine, though.
Are you using SDL_GL_SetAttribute(SDL_GL_FRAMEBUFFER_SRGB_CAPABLE, 1); ?
Same here.- I didn't tried the SDK 0.4.3 yet, I will try it tomorrow. On 0.4.2 it vsyncs at 75 Hz, so when framerate is high enough I don't have stuttering. I overclocked my main monitor to 75 Hz though, it might explain why it works, I didn't tested with it at 60 Hz.
In extended mode are you able to set the DK2 to 75 Hz ? Also, try to play with VSync option in nVidia Control Panel. I also put a SDL_GL_SetSwapInterval(0) to try to disable VSync. I think it can interferes badly with SDK VSync. "ockiller" wrote:
In extended mode are you able to set the DK2 to 75 Hz ?
I used to get 75 Hz in extended mode - without judder, but with a visible tear line in the right eye."ockiller" wrote:
Also, try to play with VSync option in nVidia Control Panel. I also put a SDL_GL_SetSwapInterval(0) to try to disable VSync. I think it can interferes badly with SDK VSync.
Thanks! Setting VSync in the nVidia driver to application controlled did the trick (I had it set to adaptive VSync before; never had an application affected by it in Direct Mode).
Direct Mode is now perfectly smooth and running at 75 Hz.
However, I now get terrible judder in extended mode (even though it's running at 75 Hz)... *sigh*
Changing VSync settings via SDL_GL_SetSwapInterval() doesn't help and worst of all, I can't even get back to the more-or-less working state I had before. I'm at this point again, where I get the feeling that either Windows, the Oculus SDK or the nVidia driver is trolling me. :?
However, since Direct Mode is more important going forward, I'm going to concentrate on that for the time being. Next step: Get sRGB working: viewtopic.php?f=34&t=16186&p=211893#p211909 [edit]: WORKS!- BTW: Is TimeWarp working for you?
- Hmm... interesting. I get severe rendering errors since 0.4.0, whereas the same code worked fine with 0.3.2.
Do you do any special GL state setup before calling ovrHmd_EndFrame()? - No, nothing special. Maybe with the client distortion renderer you will get more information on your problem :|
I tried the 0.4.3 SDK, we have to apply skynet's workaround to get gamma-correct colors with direct-HMD mode. But now I have a new problem, if I set a fullscreen window I get most of the time a very low framerate (1 fps at most). The application seems to wait idly very regularly. If the window doesn't have focus it's back to normal. If I create a windowed window it's okay most of the time. It seems related to this : viewtopic.php?f=34&t=16171
