Search Issue Tracker
Fixed in 2.0.0
Votes
3
Found in [Package]
0.9.3 - preview
Issue ID
1228990
Regression
No
[XR][XR Interaction Toolkit][Quest][Link] Socket Interactor intermittently applies wrong rotation to grabbable object
Repro steps:
1. Open attached project
2. Enter Play Mode with Quest connected and Link set up
3. Try grabbing and releasing the plant constantly
Actual: Eventually the plant snaps back with a wrong rotation applied
Reproducible with: XR Interaction Toolkit 0.9.4-preview
Add comment
All about bugs
View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.
Latest issues
- Crash on ShaderLab::ShaderState::ApplyShaderState when entering Play Mode and calling ShaderWarmup.WarmupShaderFromCollection with a shader that has dynamic_branch
- Crash on operator delete[] when a serializable structure in the System namespace is serialized by a MonoBehaviour
- [macOS] forward and backward mouse buttons are recognized as middle mouse button
- NavMeshModifier.OnEnable/OnDisable gets progressively slower when called repeatedly
- "System.Net.CookieContainer" throws an "ArgumentException" error when using a non-UTF-8 machine locale and hostname
Resolution Note (fix version 2.0.0):
A warning message was added to the Inspector of XR Grab Interactable GameObjects with non-uniformly scaled parent GameObjects as of version 2.0.0. A child XR Grab Interactable with non-uniformly scaled parent that is rotated relative to that parent may appear skewed when you grab it and then release it. Unity limitations with non-uniform scaling is documented on https://docs.unity3d.com/Manual/class-Transform.html
A number of other changes to the package have also been made since this bug was reported, starting with 0.10.0-preview.3 where the select events have been split up so that both interactor and interactable have a chance to process the interaction state change before raising a UnityEvent for subscribers. The XR Grab Interactable's method for computing the target location was also updated as of version 1.0.0-pre.4 so it no longer uses the scale of the selecting Interactor's Attach Transform and it computes a consistent attach point between all Movement Type values.
As of 2.0.0-pre.3, the interactor now has both a PreprocessInteractor and ProcessInteractor method to help ensure the hover mesh can be drawn accurately without a frame delay. The bug regression of the position of the hover mesh introduced in 2.0.0 where it did not render in the correct location when the Attach Transform was null was fixed in 2.0.1.
If you have a project which can reproduce the bug described by this issue when uniform scaling is used with the latest version of the package, please report a new bug so the team can correct it.