IVRSystem::GetProjectionRaw() pTop and pBottom reversed?

[birdman-linden]

With a retail Rift, GetProjectionRaw() returns -1.11 for top and +0.889 for bottom. This is unexpected because the vertical FOV should be skewed downwards (i.e. larger "bottom" value), not upwards. That is, the vertical center of projection should be above the center of the display, like this: Unsurprisingly, if I use the returned values as-is, the projection comes out very distorted in the headset, but if I swap them, it is perfect.

Meanwhile libOVR, using the function ovr_GetRenderDesc() returns in the ovrFovPort values of +0.889 for "UpTan" and +1.11 for "DownTan", which is skewed downwards as expected.

This was encountered using 0.9.16 (I've tested no other versions)

[LibreVR]

One of the contributors to the Revive project has also noticed this, that's why we invert these values when calling ovr_GetHmdDesc.

I also think you shouldn't trust ovr_GetRenderDesc, since it will probably just return the FOV you supplied to it in the first place. Which you are likely getting from ovr_GetHmdDesc anyway.

[birdman-linden]

Yes, good catch, ovr_GetHmdDesc is the source of truth for those values and I've confirmed that that is how we're fetching them. However, it's returning the expected and apparently correct results (DownTan larger than UpTan) whereas openvr's IVRSystem::GetProjectionRaw appears to have the figure upside-down.

[gkv311]

The GetProjectionRaw() definition is void GetProjectionRaw (EVREye eEye, float *pfLeft, float *pfRight, float *pfTop, float *pfBottom); while glFrustum() is void glFrustum(GLdouble left, GLdouble right, GLdouble bottom, GLdouble top, GLdouble nearVal, GLdouble farVal);

So maybe GetProjectionRaw() actually follows glFrustum() variables order and just has wrong signature (wrong variable names)?