Revive icon indicating copy to clipboard operation
Revive copied to clipboard

Incorrect FOV conversion (might not affect real programs)

Open Sgeo opened this issue 4 years ago • 3 comments

Describe the bug

The FOV conversion at https://github.com/LibreVR/Revive/blob/4843c1bed72c9c7888e6bfa429f263584c7586c1/Revive/CompositorBase.cpp#L481 can be incorrect when the game-provided bounds are neither the default FOV bounds nor symmetrical. I imagine that those two cases do cover the vast majority of games. The attached reproduction is intentionally bizarre.

I believe that the correct calculation is taking the headset-suggested tan bounds and multiplying them by the game's projection matrix. If left tans were negative, then uMin = vrTanAngleLeft * 2 / (gameTanAngleRight - gameTanAngleLeft) - (gameTanAngleRight + gameTanAngleLeft) / (gameTanAngleRight - gameTanAngleLeft)

Even if I'm wrong about what the correct conversion is, the attached demo shows incorrect behavior in Revive.

To Reproduce Steps to reproduce the behavior: OculusRoomTiny_GL_modified.zip

  1. Run program, in Revive and on real Oculus headset

Expected behavior The 3D view should look almost good, except there's a black area on most of the left of the view

Actual behavior Weird distortion. The view is pushed excessively to the right, and does not behave properly as the head moves

Environment (please complete the following information):

  • App: Modified version of OculusRoomTiny_GL
  • OS: Win10
  • Headset: Oculus Quest 2

Versions (please complete the following information):

  • Revive: 2.1.1
  • SteamVR: beta 1.19.7

Additional context The attached program contains the below code, to force an asymmetric FOV:

	hmdDesc.DefaultEyeFov[0].LeftTan = 0.17f;
	hmdDesc.DefaultEyeFov[1].LeftTan = 0.17f;

Screenshot of Oculus headset: image

Screenshot of Revive: image

Sgeo avatar Aug 24 '21 00:08 Sgeo

Have you tried testing that demo on the latest beta version of ReviveXR? The OpenVR version is mostly deprecated and all development should focus on the OpenXR version which offers superior compatibility.

You'll have to build from source though, since the last development binary was deleted due to inactivity.

CrossVR avatar Aug 24 '21 08:08 CrossVR

Just tried testing the most recent build from https://ci.appveyor.com/project/librevr/revive/build/artifacts, it closed immediately when I tried.

Sgeo avatar Feb 10 '22 03:02 Sgeo

It looks like we'll be on OpenVR a while longer anyway. To check if your calculations are correct I'd recommend running Lucky's Tale on your modified build, if you have it.

That game uses a symmetric field of view which is the main reason for these calculations.

CrossVR avatar Feb 10 '22 12:02 CrossVR

A little late, but I have figured out the correct math:

// Adjust the bounds based on the field-of-view in the game
result.uMin = (fov.LeftTan - eyeFov.LeftTan) / (fov.LeftTan + fov.RightTan);
result.uMax = 1.0f - (fov.RightTan - eyeFov.RightTan) / (fov.LeftTan + fov.RightTan);
result.vMin = (fov.UpTan - eyeFov.UpTan) / (fov.UpTan + fov.DownTan);
result.vMax = 1.0f - (fov.DownTan - eyeFov.DownTan) / (fov.UpTan + fov.DownTan);

CrossVR avatar Mar 12 '23 14:03 CrossVR

Here's a quick paint graphic I used to figure out the correct answer:

image

CrossVR avatar Mar 12 '23 14:03 CrossVR