Saturation and Framerate Issues with OVR SDK 0.4.4

"Jyakku" wrote:
before 0.4.4 my framerate was getting up to about 120. After integration it stays below 60 FPS

That's odd. What version were you using before? Moving from 0.4.3.1 to 0.4.4, the main change was some additional locking at start-up and shutdown to prevent crashes. There should be no new per-frame overhead in the Unity SDK itself. You might want to try using the 0.4.3.1 Mac runtime in case something changed there. Can you run the Unity profiler and let me know where the bottleneck is?

"Jyakku" wrote:
about half the time I run the app, all colors appear oversaturated.

Does the issue still occur if you use linear lighting? If not, my might want to try removing OVRScreenFade from the left and right eye anchors.

Thanks for the reply, Dave. For whatever reason my framerate is back up now, so I'm not too worried about that aspect; however, I'm still getting the saturation, so I'll try using linear lighting and removing the OVRScreenFade.

I encountered another issue with the new SDK, when I switched to my Windows machine and built it there: the screen will blink on for a fraction of a second, and then turn black. It also appears to not recognize the Rift in Direct To Rift mode, as the focus window is still one of the desktop windows even with the Rift plugged in and working with the calibration demo. The only way I've been able to get it to work is by unchecking the option to use DirectX 11. It's worth mentioning that I can still see the normal Rift display in the Game window of the Unity editor; this problem only occurs when I build it out.

As these problems are both crucial and unique to their respective platforms, I've rolled back to 0.4.3.1 (with the 1.5 runtime) that still works so that I can continue releasing cross-platform builds. However, I'd be happy to fork my repo and replicate the issues I had in 0.4.4 if it would help answer any questions that lead to identifying bugs in the SDK.

Thanks for all of the hard work that you folks at Oculus continue to put in!

Switching to linear lighting fixed the problem, but gamma lighting still produces the issue without any fade scripts on the eye anchors. Is there anything further I can do to fix the saturation while maintaining gamma lighting?

EDIT: I had thought switching to linear lighting fixed the issue, but it just happened to work a few times after switching; I ran it again right after making this post and the saturation persists in both lighting modes with no screen fade scripts.

I'm also experiencing this issue.

Seeing over and highly under saturation while testing. This can happen on both eyes, or just one eye. Appears to be limited to the editor only. No image effects on any cameras.

I'm seeing this on a Macbook Pro with an AMD Radeon HD 6750M and 8GB ram on OS X 10.9.5. Using Unity Pro. Our PC development rigs don't see this.

Thanks!

I'll echo the point that this saturation doesn't appear at all on my Windows rigs (when I force D3D9 to be able to see the build). However, unlike CubicleNinjas, the saturation issue isn't limited to the editor; I experience it occasionally on both the editor and the builds.

Bumping this because I'm still experiencing saturation issues, now even on 0.4.3.1. Could it possibly be related to the installation of the runtime instead of the SDK used in Unity? Any insight from Team Oculus and/or other developers experiencing this would be appreciated.

It sounds like there may be a problem with sRGB conversion. In D3D9 and GL, we force sRGB read on the eye buffers to get more precise interpolation when re-sampling for lens distortion. It can significantly reduce aliasing. It should be doing the gamma and de-gamma operations at the right times, but there is a chance something went wrong. Does it help to disable sRGB in one of your Start methods, as follows?

OVRManager.display.distortionCaps &= ~(uint)DistortionCaps.SRGB;

Dave, thanks for the reply. Putting that line into a Start function doesn't fix the problem on either 0.4.3 or 0.4.4, but I poked around with the distortion caps based on your suggestion and discovered that this line in a Start function fixes it:

OVRManager.SetDistortionCaps ((uint)DistortionCaps.SRGB);

I've run it several times and the saturation has been consistently proper. Thank you for helping me get there; I hope this can help anyone in a similar situation.

DistortionCaps is a bitmask, so when you set it to DistortionCaps.SRGB you are clearing all of the other caps. That will cause other issues, such as higher latency. Is there a specific cap that was causing the original problem? Does the following work?

OVRManager.SetDistortionCaps ((uint)OVRManager.display.distortionCaps & ~(uint)DistortionCaps.Overdrive);

Whoops, thanks for pointing that out, I didn't realize there would be other distortion caps that I could clear even if I didn't set them elsewhere in code.

That line fixed a lot of my issues--thanks so much! D3D11 is now working on my Windows builds and GL is working on my Mac builds. The only thing that remains broken is D3D9--it still displays a saturated view no matter what distortion cap settings I use. This matters less to me now, though, as D3D11 is no longer displaying a black screen in Direct To Rift mode.