Mismatch between IVRSystem::ComputeDistortion and compositor lens distortion

[tunabrain]

Hi!

I'm experiencing some issues performing manual lens distortion before submitting to OpenVR with EVRSubmitFlags::Submit_LensDistortionAlreadyApplied. I'm doing this by computing a warp mesh, i.e. a regular grid with UVs assigned according to IVRSystem::ComputeDistortion.

For the most part, this seems to work, and I can look around and don't notice any warping issues. However, I am seeing subtle color degradation around edges which seems unrelated to the chromatic aberration correction, and does not appear when I don't use manual distortion. Here's a zoom of what I mean (top edge of the lamp, for example):

This color separation happens even very close to the center of the field of view and is very noticeable in the HMD - the top edge for example sticks out as very green in VR. I can switch back and forth between manual distortion and distortion by the compositor at runtime, and the compositor distortion does not exhibit this issue, so I don't think this particular color shift is intended to correct for aberration. Additionally, these issues only appear on horizontal edges, not vertical ones, which is slightly puzzling.

I initially suspected an issue in my code, but I'm now at a loss what could cause this behavior. Ultimately I'm just feeding the values of ComputeDistortion straight to a vertex shader. If the image looked warped, I would suspect wonky scaling on my side, but any color shifts must be in the input data.

A few Qs:

• Is there any way to get at the warped output of the compositor? Currently my only way of comparing my warp to the OpenVR one is to put on the HMD and eyeball it.
• Is there any public, working example that performs manual distortion that's identical to the compositor? This would be a quick way of ensuring the API works as intended and would make debugging a lot easier
• Does the OpenVR lens distortion also call IVRSystem::ComputeDistortion internally to generate its warp mesh, or does it take a different code path? The former would also indicate that IVRSystem::ComputeDistortion is working correctly.

Please let me know if there's any data I can provide that would make debugging this easier (e.g. warp mesh, image data etc.).

Thanks!

[aleiby]

Is there any way to get at the warped output of the compositor?

Hit 'S' in SteamVR's mirror window to dump out all textures to runtime/screenshots - this will include both the textures submitted from the application, and the post-distortion backbuffer output (and any known overlay textures).

Is there any public, working example that performs manual distortion that's identical to the compositor?

You can probably make hellovr do this fairly trivially since it creates both distorted and undistorted textures.

Does the OpenVR lens distortion also call IVRSystem::ComputeDistortion internally to generate its warp mesh

Yes.

Have you tried flipping the V coordinate when applying the distortion? (i.e. 1 - V) Does your texture match the physical screen resolution, or are you using the recommended texture size (which should only be used pre-distortion)?

[tunabrain]

Hit 'S' in SteamVR's mirror window to dump out all textures to runtime/screenshots

This doesn't seem to dump the post-distortion output (only application submitted textures and overlays). I'm working with version 1.02, if that helps

Does your texture match the physical screen resolution, or are you using the recommended texture size

It matches the physical screen resolution. That's the reason we're doing the distortion manually - part of our application is raytracing-based and can shoot rays predistorted, which allows us to compose the predistorted raytraced bits on top of the manually distorted rasterized bits. If we do that, we can raytrace at the native resolution and avoid overrendering by the recommended 1.4 or more.

Have you tried flipping the V coordinate when applying the distortion? (i.e. 1 - V)

That was it! I feel very silly for not trying this. The solution was to flip both the warp mesh and the UVs upside down. I expected two flips to cancel each other, but that was not the case. Apologies - clear case of user error.

Thanks for the detailed reponse!

[aleiby]

One thing I forgot to mention: the Submit_LensDistortionAlreadyApplied flag stopped working on Oculus Rift when moving to their 1.0+ SDK as they removed the ability to supply pre-distorted textures to their compositor. Technically, it never worked since I was never able to get their "direct" layer to work correctly, but they have since removed that type of layer entirely. If they add it back in a future release, then I'll see about hooking that up again.

[tunabrain]

That's good to know, thanks! We're mostly targeting room-scale VR, so this should hopefully not be an issue.

Do you know of any issues with reprojection on the Vive when submitting predistorted textures? From what I can tell it still seems to work fine, but just curious.