Distortion in image and tracking in the hangar

[morallo]

It would seem like the proper metric 3D reconstruction is not applied in the hangar.

Also, there is no positional tracking, but not sure if this can be solved or it's a current limitation of using mouselook.

[Prof-Butts]

Positional tracking is currently based on hijacking the "cockpit shake" mechanism. So, I'm not sure it's possible to enable it in the hangar.

I'll check if the hangar needs a different metric reconstruction. The way to do that is by dumping the 3D vertices to an OBJ file and then checking against an OPT. Is there a specific spot where the distortion is more evident?

[morallo]

Positional tracking works even after disabling it in CockpitLook hook, but with visible clipping in the cockpit model as the XWA engine will not render parts that it didn't expect to be visible.

[morallo]

Do we know if the right FOV from SteamVR is applied in the hangar?

[Prof-Butts]

Probably not.

From what I remember, SteamVR only provides the FOV for each eye when we request the data needed to build the eye projection matrices on our own. However, I believe we're still using the projection matrices just as they are provided by SteamVR. Either way, XWA only has one FOV, so we would need to somehow combine the FOV for each eye to provide a new FOV for XWA (maybe the average?)

On Sat, Nov 20, 2021 at 2:59 PM Marcos Orallo @.***> wrote:

Do we know if the right FOV from SteamVR is applied in the hangar?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Prof-Butts/xwa_ddraw_d3d11/issues/36#issuecomment-974723421, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAK2FAOZNIETEMFXNOVOB5LUNAR5PANCNFSM4UZ65E7Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[morallo]

Yeah, one single FOV is calculated when initializin SteamVR and injected into XWA. See https://github.com/Prof-Butts/xwa_ddraw_d3d11/blob/ea5d6a96e72ddbab3d17715af73a79aa8d69f0ac/impl11/ddraw/SteamVR.cpp#L140

It's not critical to use the actual combined FOV from the 2 eyes, as long as the one used is taken into account for the metric reconstruction to obtain an affine reconstruction (squares in game are squares in the reconstructed coordinates).

My question was if in the hangar that same value of FOV is being used, especially when showing external views.

There is no obvious reason for the game to use the same camera parameters for different scenes. Maybe in the hangar they want a wider angle to show more of the scene... I need to check the code in IDA.

Maybe we need to reinject the value with the adequate adaptation in that specific case/game state so that XWA renders the same FOV (new hook address?), or in the right address used for the hangar if it's different, to obtain at the end the same rendered FOV as in-flight.

Another option is to have the real final FOV value in the hangar into account in the Vertex Shader to do the reconstruction so our HMD projection matrix clips correctly.

[Prof-Butts]

Heh, alright, I guess we do use the FOV from the left eye after all! :D

I would expect the cockpit camera in the hangar to use the same FOV we set when flying, but the external camera may have a different FOV. There's an easy way to test this: just change the FOV while flying and see if that affects the cockpit and external cameras while in the hangar.

If we find that the FOV for the external camera (while in the hangar) is different from the cockpit camera FOV that would explain the distortion people have reported.

On Sat, Nov 20, 2021 at 9:34 PM Marcos Orallo @.***> wrote:

Yeah, one single FOV is calculated when initializin SteamVR and injected into XWA. See https://github.com/Prof-Butts/xwa_ddraw_d3d11/blob/ea5d6a96e72ddbab3d17715af73a79aa8d69f0ac/impl11/ddraw/SteamVR.cpp#L140

It's not critical to use the actual combined FOV from the 2 eyes, as long as the one used is taken into account for the metric reconstruction to obtain an affine reconstruction (squares in game are squares in the reconstructed coordinates).

My question was if in the hangar that same value of FOV is being used, especially when showing external views.

There is no obvious reason for the game to use the same camera parameters for different scenes. Maybe in the hangar they want a wider angle to show more of the scene... I need to check the code in IDA.

Maybe we need to reinject the value with the adequate adaptation in that specific case/game state so that XWA renders the same FOV (new hook address?), or in the right address used for the hangar if it's different, to obtain at the end the same rendered FOV as in-flight.

Another option is to have the real final FOV value in the hangar into account in the Vertex Shader to do the reconstruction so our HMD projection matrix clips correctly.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/Prof-Butts/xwa_ddraw_d3d11/issues/36#issuecomment-974759097, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAK2FAPRM4CSUHXGDJDMTKDUNCAHLANCNFSM4UZ65E7Q . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

[morallo]

This was fixed in Cockpitlook with the new matrix based injection.