Problem detecting MetaQuest 3 controllers, incorrect axis, bad raycast and interactions

[hedkaoz]

Good day, my problem is that when I start the VR demo of the new 2.21, my controllers are incorrectly oriented in my hand, as you can see in the screenshot(left side). I can correct this in "VRHandController.cs" by adding Xr.AdditionalRotation, but that only fixes the visual issue (image in right side). The raycast is still being sent to the sides of my hand (the red arrowcomming out of the controls ) from my thumb towards my pinky finger, instead of in front of my hand. I can change the Axis to Z, which is theoretically the correct one for teleportation, but that doesn't solve the interaction with GuiMesh. Even worse, when I try to throw a cube in one direction, it throws it in a completely different direction, as if inertia didn't exist.

I should clarify that this doesn't happen to me in version 2.20, but when trying to migrate with the Upgrade button, many scripts and almost the entire VR system break.

[bmyagkov]

Hi there,

This is a known issue affecting Meta HMDs when using OpenXR [Oculus]. The root cause is that the controller coordinate systems are rotated incorrectly. Meta describes this behavior in their documentation:

Quote

Clients linking against OpenXR version >= 1.1.49 will have "/user/hand/{left|right}/input/aim/pose" match the system shell. However there was a bug in this implementation that resulted in the pose being rotated 180 degrees around the z axis; this bug will be resolved in OpenXR version >= 1.1.53.

Until Meta fixes the issue in their runtime, please try the attached component. It uses a more detailed implementation based on the GRIP transform, includes manual hand-anatomy position correction and takes the controller side (left/right) into account. The comments in the code explain the changes in detail and should help clarify the implementation.

Meta also explicitly recommends rendering controllers using the grip pose:

Quote

This is preferred because the grip pose is preferred for rendering the controller.

To verify the behavior, please create a new VR Template project using SDK 2.21 from SDK Browser and replace the corresponding file with the attached version.

Regarding the migration issue:

Quote

I should clarify that this doesn't happen to me in version 2.20, but when trying to migrate with the Upgrade button, many scripts and almost the entire VR system break.

This is expected behavior. The migration process only upgrades the engine binaries and does not automatically update user-side logic. Since the API has changed in 2.21, project code may require manual adjustments after migration.

Please refer to the Migration Guide for the required code updates: https://developer.unigine.com/en/docs/2.21/upgrade/?implementationLanguage=cs&precision=d

Thanks!

VRHandMenuInteraction.cs

[hedkaoz]

Thank you so much for your time. I guess I'll wait for Meta to update its software or OpenXR version. I modified the script, but it only fixed the menu issue; the inertia-based object grabbing and throwing is still broken. But as I mentioned, I'll wait.

I have another big question I'd like answered about VR image rendering. Is it possible to disable mirroring from the headset to the desktop screen and use a different camera to render in it? I'd like to record video with a wider angle, but it only captures one eye, and a lot of detail is lost when recording with Meta Quest.

[bmyagkov]

Hi,

Regarding the controller orientation — there is no clear timeline for Meta to ship the fix in their runtime, so waiting on it is not the most practical path. The easiest solution is to switch your interaction logic to the GRIP pose, as shown in the example we attached earlier. In upcoming UNIGINE SDK releases the default pose will also be changed to GRIP, so once that change lands on our side nothing will need to be adjusted on yours — the behavior will already be consistent.

As for the throwing/inertia issue, it can be addressed the same way. Please replace the relevant components in your project with the ones attached to this message and verify the behavior on your side.

On 6/13/2026 at 3:58 AM, hedkaoz said:

I have another big question I'd like answered about VR image rendering. Is it possible to disable mirroring from the headset to the desktop screen and use a different camera to render in it? I'd like to record video with a wider angle, but it only captures one eye, and a lot of detail is lost when recording with Meta Quest.

We would like to make sure we understand the request correctly. At the moment the HMD image is mirrored to the desktop window and shows the viewport for each eye. If we simply keep only one of the eyes there, the result will most likely not look the way you would expect.

A more flexible approach would be to attach a separate camera with a wider FOV to the player at eye level and render it into its own Viewport window — that camera would be independent of the HMD rendering and can be used for recording. Is that what you had in mind, or did we misunderstand the request?

Thanks!

throw_fix.zip