Controllables receive reversed angular velocity in Quest builds
Fairennuff opened this issue · comments
Environment
- Code source: Tilia Package importer
- Code version: Tilia.SDK.OculusIntegration.Unity 2.0.4
- Platform version: Unity 2021.3.5f1
- 3rd party dependencies: NA
Steps to reproduce
Create a blank scene and pull in the Tracked Aliases and Oculus Integration Camera Rig Prefabs. Add interactors to your controller aliases. Link up grab buttons with Input.OculusIntegration.OculusTouchXController inputs.
Create a controllable Angular Drive (Joint or transform doesn't matter). Change the interactable Follow method to Follow Rotate Around Angular Velocity. Set grab offset to none. Select the Z axis checkbox. By default the "In Target space" box should be checked in the internal follow method rotation object but doesn't hurt to double check that it is on.
Duplicate the controllable and turn it 90 degrees. Duplicate it again and turn it -90 degrees. Duplicate it one last time and turn it 180 degrees. Place each controllable so its convenient to reach when testing.
Change build target to Android and configure player settings for Oculus quest. Generate a build and try to turn the controllables.
Do not upload custom projects with custom code to demonstrate the issue.
Expected behavior
The controllable should follow your controller's movement.
Current behavior
When facing the global Z or global X the movement is reversed.
Side note: I have already tested this with the UnityXRFramework rig and the controllables work as expected. It also works in the editor correctly too. This issue only seems to occur in builds.
Using the average velocity estimator instead of the OVRAnchorVelocityEstimator does work but gets odd results sometimes where the controllable will snap to its min or max value with very little movement in the hand. Changing to total frames average makes a difference but it still occurs in both cases.
As a current work around I have created a duplicate of the OVRAnchorVelocityEstimator with a check in the Awake() method that checks if its a quest 1 or 2 and if it is sets a bool to true. In the angular velocity method I then reverse the angular velocity if the bool is true.
Futher findings -
Reversing the angular velocity on Quest 1 and 2 only fixes it in some situations. If you physically turn around in your play space it once again is reversed.
I have created a blank project with nothing but the oculus integration package in it and tested both in editor and in builds - the OVRInput.GetLocalAngularVelocity() method outputs world space coordinates (not local to the controller) and they are inversed. Hence why if you manually reverse them they appear to work correctly, unless you turn around in your space.
The XRNode velocity estimator seems to get the same results / suffer from the same issue.
If I totally remove the oculus integration and use one of the other camera rigs (like XRFrameworkCameraRig) it works fine in builds and editor.
I think this PR will fix this:
Although you'll need to manually change the Velocity Tracker AngularRotationSource based on whether this is running on Rift or Quest (for some reason Oculus handles the two headset differently?!)
You could use a pattern matching rule to do it in the scene, or just run some of your own code to make sure the enum is set correctly.
🎉 This issue has been resolved in version 2.2.1 🎉
The release is available on:
Your semantic-release bot 📦🚀