These two cases are different between resolution, IPD and Projections matrix on the attached server logs even using the same Quest3 and server (CloudXR Server - SteamVR Log).
Attached are logs of the server/client and screenshot images for investigation.
(XrPlatformFingerprint.txt / CloudXR Server - SteamVR Log / Streamer Client Log / Streamer Server Log / etc).
Please let me know if any other logs are needed.
OK-android-build.zip (290.4 KB)
11:19:48.038 I (CxrDeviceDriver) Render parameters: 2064 x 2208 @ 72.00 (max 2476 x 2648)
11:19:48.038 I (CxrDeviceDriver) Target queue time: 0.012000
11:19:48.038 I (CxrDeviceDriver) Display type: Stereo, IPD: 0.063317
11:19:48.038 I (CxrDeviceDriver) Projections: (-1.376382 1.376382 -1.428148 1.428148) x (-1.376382 1.376382 -1.428148 1.428148)
NG-unity-plugin.zip (217.8 KB)
11:28:40.697 I (CxrDeviceDriver) Render parameters: 1680 x 1760 @ 72.00 (max 3024 x 3168)
11:28:40.697 I (CxrDeviceDriver) Target queue time: 0.012000
11:28:40.697 I (CxrDeviceDriver) Display type: Stereo, IPD: 0.063215
11:28:40.697 I (CxrDeviceDriver) Projections: (-1.376382 0.839100 -1.428148 0.965689) x (-0.839100 1.376382 -1.428148 0.965689)
Your main issue is a bug that I’m currently trying to track down.
The secondary issue, that the projection matrices and resolutions do not line up, is a known issue. The short version is that the Unity plugin uses Unity’s OpenXR-based plugins to talk to the headset, while the native client uses the deprecated Oculus OVR API. The Oculus API provides a way to get physical resolution, while OpenXR only provides “recommended” and “max” resolutions. The former is intended to guide on-device 3D games, the latter is set to the texture size limit (8192x8192 or something).
I will need to dig in and see whether the resolution is exposed directly in the configuration.
Thank you so much for providing the workaround for the Tracking Mode “floor”!
It modified correctly the misaligned issue in our environment (Quest3 - AWS EC2), as shown in the attachment.
But, in the case of the Tracking Mode “floor,”
the view in the Quest slightly shifts back in the opposite direction after finishing a head turn, as if the inertia works.
Could you please let me know if you have any way to deal with this?
We tried changing some settings on Unity, but it had no effect.
That documentation was based on a very early workflow, possibly predating a moment when I shifted to using OpenXR’s “stage” as the foundation of our streaming.
This “inertia effect” may be a new thing; have you fully re-enabled the reprojection shader / reprojection in the shader?