Odd depth collision/offset issue on S5 w/ OVR

[drash]

I call it a "depth collision/offset issue" just for lack of a better phrase, but I don't really know what the underlying issue is. I'm experiencing a visual artifact that fluctuates as a function of distance and viewing angle, and I finally figured out that it only occurs when using the OVR camera setup in the S5 SDK. For the exact same scene on the S5 using a normal camera (with the same near/clip plane etc), the effect does not appear.

I've boiled it down to a simple project to demonstrate the issue without any clutter:

https://www.adrive.com/public/uGSBWu/TestDepthIssue-Drash.zip
(Password to download is "gooculus", without the quotes)
(Password to unzip is "oculusrocks", without the quotes)

From the included readme:

This app shows a solid sphere with a slightly larger inside-out sphere around it.  
 
When using an OVR camera setup, there appears to be a strange visual artifact inside the limb of the solid sphere that fluctuates as a function of distance and viewing angle, and this artifact is not present when using a normal camera, and only shows up when running on the S5.
 
Both of the included .apk's are built using the same Unity project (also included).   The only difference is that TestDepthIssue-NoVR.apk uses a normal camera, and TestDepthIssue-VR.apk uses an OVR camera setup.

If anyone's able to take a look at this at some point, I very much appreciate it. 🙂

[cybereality]

Is this related to the camera clear flags like in this thread?
viewtopic.php?f=61&t=9086

[dsmeathers]

I've not checked out your project but it sounds like an issue we've had. It's because the z buffer is only 16 bit when you're using the OVR Camera.

Take a look at OVRCameraController line 296:

		// Initialize all the rendertargets we are going to use for async time warp
		for ( int i = 0 ; i<EyeBufferCount*2 ; i++ )
		{
			CameraTextures[i] = new RenderTexture(1024, 1024, 16);
			CameraTextures[i].antiAliasing = 2;
		}

Changing it to 24 fixes this for us (we have objects close to the camera as well as very far away). Obviously if you can move your near clip plane further out then try that first !

[gkennickellvr]

After taking a look at the testmap, the biggest issue is indeed the near and far clip plane values [0.03,100,000] and the limited precision of the depth buffer. As pointed out in a previous comment, the eye rendertextures
use a 16-bit depth buffer. If you move the near clip plane further from zero, eg 0.15 and bring in the far clip a bit the issues should be resolved. Additionally, changing to 24bit will help resolve the issue at a slight cost to performance.

One additional note, the "use 24 bit depth buffer flag" in the Unity project settings appears to be ignored on Android, and we always get a 24-bit window depth buffer. The non-stereo camera was rendering to a 24-bit depth buffer (even though the option was not checked) while the OVRCamera was rendering to a 16-bit depth buffer.

[drash]

Excellent information! The fact that the "use 24-bit depth buffer" flag is effectively always on explains my confusion as to why it was working for the standard camera. I made the appropriate change in the OVR code and everything looks super now.

In any case, I know the camera near/far clips I'm using are on the extreme side.... the sad result of building a premise on extreme stuff in the first place. It doesn't help that I can't layer near+far cameras! 🙂

[cybereality]

Can you try using a logarithmic depth buffer? Is that supported in Unity?

[drash]

"cybereality" wrote:
Can you try using a logarithmic depth buffer? Is that supported in Unity?

As far as I know it's already logarithmic -- depth has higher resolution closer to the near clip plane. I saw someone post about the idea not long ago and I got all excited, and then found out Unity was already doing that. 😄

[cybereality]

Ah, OK. No problem.

[JohnCarmack]

24 bit depth buffer really isn't very expensive on Adreno as long as it never gets pushed out to main memory (it shouldn't, unless your graphics path is doing something else bad) so using that is probably the right thing to do, and should fix the problems.

However, if you still want to optimize depth buffer usage, pushing the near plane out makes a big difference. If you have an avatar body, you may need it to be only a few cm, but you probably want to stay 30+ cm away from world geometry anyway, to avoid vergence issues that can cause eye strain. If you only have very distant objects and very close objects, without a smooth continuum between them, you could also scale up the close objects and proportionately increase the interocular distance and neck model parameters.

[drash]

Indeed, I've been successfully using 24-bit depth buffer now without a perceptible hit to performance, so that's been very helpful.

And one part of the problem is the player has an avatar and can see shoulders etc. The player isn't expected to focus on them, but having the geometry clipped from an increased near plane doesn't look so hot. I'll see if I can find some middle ground here.

"JohnCarmack" wrote:
If you only have very distant objects and very close objects, without a smooth continuum between them, you could also scale up the close objects and proportionately increase the interocular distance and neck model parameters.

I guess it's possible that the faraway things are so far away that changing the scale and ICD of the nearby stuff isn't going to make a perceptible difference in scale -- thanks for the suggestion.