Incorrect FOV conversion (might not affect real programs)

[Sgeo]

Describe the bug

The FOV conversion at

Revive/Revive/CompositorBase.cpp

Line 481 in 4843c1b

vr::VRTextureBounds_t CompositorBase::FovPortToTextureBounds(ovrFovPort eyeFov, ovrFovPort fov)

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:

Screenshot of Revive:

[CrossVR]

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.

[Sgeo]

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

[CrossVR]

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]

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]

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