Official XR Interaction Toolkit 1.0.0-pre.2 pre-release is available

We have just published a new preview of the XR Interaction Toolkit (XRI) that brings a number of bug fixes and improvements. For those who want to experiment with XRI, the best way to start is with our samples available at https://github.com/Unity-Technologies/XR-Interaction-Toolkit-Examples. As always, you can refer to our documentation for more information.

Pre-release
This 1.0.0-pre.2 version of the XR Interaction Toolkit is considered pre-release. Pre-release packages are supported packages in the process of becoming stable and will be available as production-ready by the end of this upcoming 2021 LTS release. Starting in 2021.1 Alpha, Unity is changing the way we publish and show packages in the Package Manager, and is designed to provide clear guidance around a package's readiness and expected support level. There will be additional iterations of XRI before we get to the final 1.0.0 release.

What’s new
For a full list of changes, refer to the Changelog in our documentation.

Many of the changes and fixes in this version were a direct result of feedback we received from the forum and from reported bugs. Thank you to everyone who took the time to make these issues known to the team and for your feedback!

Notable changes

• Added and improved Scripting API documentation and Inspector tooltips.
• Changed the signature of all interaction event methods (e.g. OnSelectEntering) to take event data through a class argument rather than being passed the XRBaseInteractable or XRBaseInteractor directly. This was done to allow for additional related data to be provided by the Interaction Manager without requiring users to handle additional methods. This also makes it easier to handle the case when the selection or hover is canceled (due to either the Interactor or Interactable being unregistered as a result of being disabled or destroyed) without needing to duplicate code in an OnSelectCanceling and OnSelectCanceled. See the Changelog for code snippets with instructions for how to upgrade and migrate scripts to use the new signatures of these events and methods. Use the Migrate Events button in the Inspector of Interactor and Interactable objects to move any serialized listeners from the old, deprecated events to the new events.
• Opened up the custom Editor classes to allow users to more easily customize the Inspector for derived classes. They now also apply to derived classes, so those users who override methods in behaviors will be able to continue using the customized Inspector rather than falling back to the default.
• Fixed XR Ray Interactor from clearing a custom aim direction when initializing. (1291523)

Known issues

• Custom reticles get displayed on objects without a custom reticle (1252565)
• Socket Interactor can apply the wrong rotation to an interactable and cause the interactable to skew in scale when the interactable has a parent with a non-uniform scale (1228990)
• Grab Interactables can cause undesired behavior when using Continuous Move locomotion where the Character Controller can be blocked from moving while holding it, or cause the rig to rapidly move away when the object overlaps with the Character Controller
• The end of the XR Interactor Line Visual lags behind and can appear bent when moving the controller fast (1291060)
• The Hover To Select property on XR Ray Interactor is not functional (1301630)

Roadmap
Use the public roadmap to see our latest plans, upvote existing feature requests, and/or submit new feature requests. We are currently working towards a public 1.0 release this year for Unity 2021.2 (LTS). Most of our focus and development efforts now are on bug fixes, UX improvements, and polished documentation & samples. The feature set for public release will primarily reflect what exists today.

Sharing feedback
This forum is the best place to open discussions and ask questions. As mentioned above, please use the public roadmap to submit feature requests. If you encounter a bug, please use the Unity Bug Reporter in the Unity Editor, accessible via Help > Report a Bug. Include “XR Interaction Toolkit” in the title to help our team triage things appropriately!

 

I would recommend that you open the VR example project directly rather than copying that folder into an existing project as you did since the example will depend on some project settings and layers that may not exist in your project. The Examples on github contains two Unity projects you can open with Unity Hub, the AR folder (a mobile AR example), and the VR folder. Follow the steps in Getting started to open the VR project so you can play around with the examples. If you want to extract some parts of the VR project example to copy into your project, you can follow the steps to create an Asset package and then import it.

As for why you were getting those compilation errors, my guess is that an older version like 0.10.0-preview.7 of XR Interaction Toolkit is installed in Window > Package Manager. Expand the foldout for XR Interaction Toolkit in that window, click See other versions, click 1.0.0-pre.2, and then click Install.

 

Thank you for the very detailed post! I agree, that is not desired behavior, and unfortunately there isn't a great way to resolve that as a user with the current version. I created an item in our issue tracking system to open up some of those methods and properties related to the UI raycasts after reading that post by Skinzart, but we have not made those changes yet. I've moved it up in priority.

A workaround until we release a fix for this would involve something like subclassing

XRRayInteractor

and overriding

GetValidTargets

to remove Interactables that are behind UI. You would need to call

TryGetUIModel

and compare positions. However, this would be pretty ugly without having all of the methods available for you to call or override.

If you report this bug with the Unity Bug Reporter, our team can provide a public tracking link and give updates on the status of a fix.

Yes this thread and forum are monitored. Questions and feedback can be posted here, and bugs can be submitted with the Unity Bug Reporter in the Editor.

 

I'm not exactly sure what's going wrong without looking at the Hierarchy and the model. What could be happening is if the object's pivot point is offset from the center of the model, that difference might cause that offset shown in the video. You can use the Pivot/Center button in the toolbar of the Editor to Toggle Tool Handle Position to visualize the difference. Since the Attach Transform is not set, it will use the pivot position and rotation of the Transform itself to determine how it orients with the Interactor's Attach Transform. You can create a child GameObject and set the Attach Transform on that Interactable to that child to manually adjust where the center should be by moving that Transform.

 

If you add this line to the

manifest

element in

AndroidManifest.xml

it should show the Oculus system overlay keyboard when the Input Field receives focus:

Code (csharp):

1. <uses-feature android:name="oculus.software.overlay_keyboard" android:required="false"/>

The keyboard is only dismissed when clicking the icon that looks like a keyboard with a down arrow under it. I don't know if there's a way to configure so the keyboard is dismissed when clicking outside the keyboard, that would be a question you should ask on the Oculus forums.

You should be able to use the Application.isFocused property and/or the Application.focusChanged event to determine when an Oculus overlay is opened, either the system menu or the system keyboard.

 

I was referring to that since

GetCurrentUIRaycastResult

is private, you would need to derive if

TryGetHitInfo

was using the result from Physics hits or from UI. You could do something like this in your overriding GetValidTargets method:

Code (CSharp):

1. if (TryGetHitInfo(out var hitPosition, out var hitNormal, out _, out _) &&
2.     GetCurrentRaycastHit(out var raycastHit) &&
3.     (hitPosition != raycastHit.point ||  hitNormal != raycastHit.normal))
4. {
5.     validTargets.Clear();
6. }

That would let the custom Ray Interactor not hover or select Interactables behind the UI. Again, this is a bug that we intend on fixing in the package, but this is a temporary workaround you can use in the meantime. Note that this solution still does not solve every issue with 3D and UI raycasts causing undesired behavior, such as still being able to hover and select things in the UI when there is an object in front of the UI.

 

It's intended behavior for multiple Interactables to be hovered by an Interactor at the same time. You can change that by deriving from Ray Interactor and overriding

GetValidTargets

or

CanHover

to make it only allow hovering one object at a time. We plan on adding configuration options in the Inspector of Ray Interactor so this can be adjusted without needing to create a custom script.

 

The lag in Grab Interactables is due to how the object is moved in Kinematic or Velocity Based modes, and the difference in update frequencies between Update and FixedUpdate. The Movement Type value in the Grab Interactable Inspector controls how the position of the object is updated. With Kinematic (the default), the Rigidbody is moved to a target position during FixedUpdate. With Velocity Based, the Rigidbody is moved by setting its velocity during FixedUpdate. With Instantaneous, the Transform of the object is moved both during Update and right before rendering to the VR device. The Continuous Move Provider updates the rig by either updating the Character Controller or the Transform directly during Update.

By default, Update occurs more frequently than FixedUpdate. Update can be like 90 Hz, whereas the default FixedUpdate is 50 Hz, which is adjustable in Edit > Project Settings > Time and setting Fixed Timestep. This difference is what causes the jitter when you move the controller fast while grabbing something (and even more apparent with a high move speed on the Continuous Move Provider).

Changing the Movement Type to Instantaneous will help to get rid of the jitter. We have plans to solve the jitter caused in a future version of the package by separating the visual component from the physics component of Interactables. That would allow us to move the Rigidbody with the physics timestep, and separately move the visual representation of the object in Update.

 

Fixing those bugs along with the wobbly Line Visual is my highest priority right now. Some or all of those fixes should be included in the next version (1.0.0-pre.3) within the next month.

As far as the changes to separating the visual from the physics goes, that will not happen for the final 1.0 release and will likely require a major version bump to implement. It will likely need to be done as a prerequisite before we add articulated hand tracking, so it is high on our list however. Timeline is subject to change of course, but we're likely talking somewhere in the half year to year timeframe.

It looks like you're triggering haptics fine, it doesn't seem like you're doing anything wrong from that code. Try updating your Oculus device and checking if there is an updated verified version of the Oculus XR Plugin package in Window > Package Manager. I'll forward this along to the Oculus package team to see if they can help.

 

That event will notify the listeners within the

OnSelectEntered(SelectEnterEventArgs args)

method. If you are overriding that method in your script, make sure you call the base method so the event will actually be invoked.

Code (CSharp):

1. protected override void OnSelectEntered(SelectEnterEventArgs args)
2. {
3.     base.OnSelectEntered(args);
4.     // Your additional code
5. }

The

XRBaseInteractable

also has

Awake

and

OnEnable

methods that do necessary things to register it. If your custom script has either of those two methods, make sure you're calling the base method similarly.

Also verify that the Interactable is actually being selected. Open Window > Analysis > XR Interaction Debugger and check that the Interactable shows that it is selected when you think it is.

 

I described some of what's happening up in post #20. For Velocity Tracking, the behavior is using some const multiplier factors for the velocity and angular velocity that introduces some easing that adds some lag. I'll work on making those available to be tweaked in the Inspector. There will still be some delay until we separate the visual representation from the Physics representation of interactables, but being able to tweak those multiplier factors should help.

Until a new version is released, if you want to adjust it now, you could counteract

XRGrabInteractable.PerformVelocityTrackingUpdate

by overriding

ProcessInteractable

to multiply out those factors from Rigidbody.velocity and Rigidbody.angularVelocity.

 

I touched on some of what you would need to do in another post. Unfortunately, that area of UI interaction has not been improved since that post so you will still need to write your own replacement Input Module that will support translating joystick input into either virtual scroll wheel values or drags. You will hit difficulties due to much of the API still being internal or private, so it will not be an easy set of changes. Look to

UIInputModule.ProcessMouse

which calls

ProcessMouseScroll

in order to send the scroll amount in the

PointerEventData.scrollDelta

to the hovered UI element. You will need to update your version of the

ProcessTrackedDevice

method to send the scroll amount in a similar manner.

Use the public roadmap to vote on or submit feature requests for this. I am also planning on opening up the API in XRRayInteractor before the final 1.0 release to significantly reduce the amount of code users will need to write to modify the PointerEventData generated by that class.

I don't know of any known issues with attach transforms in Grab Interactable, please submit bug reports so that we may address them. As for the Inspector, a change was made in the current version to make the custom appearance also apply to derived classes, which is great if you are just overriding methods, but not ideal if there are additional serialized fields that need to be shown in the Inspector. We are going to fix this so additional SerializeField variables will show up in the Inspector automatically without needing to create a custom Editor.

Until then, you will need to create a custom Editor. Instructions for doing this is described in the documentation in Extending the XR Interaction Toolkit. You can also use DrawDefaultInspector to ignore the custom appearance if you want to ignore it entirely.

Code (CSharp):

1. using UnityEditor;
2.  
3. [CustomEditor(typeof(ExampleInteractor), true), CanEditMultipleObjects]
4. public class ExampleInteractorEditor : Editor
5. {
6.     public override void OnInspectorGUI()
7.     {
8.         DrawDefaultInspector();
9.     }
10. }

 

You can change Elastic Ratio Limit on the AR Scale Interactable to control how much you can expand beyond the range limit before it cancels the gesture. If you want to disable it canceling entirely, set that value to

Infinity

so you can keep pinching to change size after it hits the elasticity limit controlled by the Elasticity property.

 

You can manually trigger a selection by using

XRInteractionManager.SelectEnter

. Add this component to a GameObject and set Source Interactable to the Simple Interactable, and Interactable To Select to the Grab Interactable. The script basically waits until the Simple Interactable is selected, gets the Interactor that did the selection, and then clears the selection before selecting the Grab Interactable. This assumes they are all part of the same Interaction Manager.

Code (CSharp):

1. using UnityEngine;
2. using UnityEngine.XR.Interaction.Toolkit;
3.  
4. public class RedirectExample : MonoBehaviour
5. {
6.     [SerializeField]
7.     XRBaseInteractable m_SourceInteractable;
8.  
9.     [SerializeField]
10.     XRBaseInteractable m_InteractableToSelect;
11.  
12.     XRBaseInteractor m_SourceInteractor;
13.  
14.     bool m_ForceSelect;
15.  
16.     protected void OnEnable()
17.     {
18.         if (m_SourceInteractable != null)
19.             m_SourceInteractable.selectEntered.AddListener(OnSourceInteractableSelected);
20.     }
21.  
22.     protected void OnDisable()
23.     {
24.         if (m_SourceInteractable != null)
25.             m_SourceInteractable.selectEntered.RemoveListener(OnSourceInteractableSelected);
26.     }
27.  
28.     void OnSourceInteractableSelected(SelectEnterEventArgs args)
29.     {
30.         // Save off the Interactor that selected the Interactable that triggered this.
31.         // Wait until Update to force select something else to allow any other listeners to
32.         // this event to process this selection before this behavior deselects.
33.         m_SourceInteractor = args.interactor;
34.         m_ForceSelect = true;
35.     }
36.  
37.     protected void Update()
38.     {
39.         // Requires that the Interactable to select and the Interactor
40.         // are registered with the same Interaction Manager.
41.         if (!m_ForceSelect ||
42.             m_SourceInteractor == null ||
43.             m_InteractableToSelect == null ||
44.             m_InteractableToSelect.interactionManager == null ||
45.             m_InteractableToSelect.interactionManager != m_SourceInteractor.interactionManager)
46.         {
47.             return;
48.         }
49.  
50.         var manager = m_SourceInteractor.interactionManager;
51.  
52.         // First deselect if the Interactor has something selected
53.         if (m_SourceInteractor.selectTarget != null)
54.             manager.SelectExit(m_SourceInteractor, m_SourceInteractor.selectTarget);
55.  
56.         // Now select the desired Interactable
57.         manager.SelectEnter(m_SourceInteractor, m_InteractableToSelect);
58.  
59.         // Done
60.         m_ForceSelect = false;
61.     }
62. }
63.  

 

See the last two paragraphs of my post #34. With all the properties and events on those behaviors, the default inspector wasn't great for derived classes. But that change to make the custom Editor apply to derived classes makes it bad for people who have added properties. I'm going to be updating the Editor classes to take advantage of

DrawPropertiesExcluding

to draw all of the unknown fields so users won't need to create a custom editor to see them.

EDIT: If you don't want to create a custom Editor until I fix it, you can also right-click the Inspector tab and switch from Normal to Debug to be able to see the field you added, and then switch back to Normal.

 

Either way of leaving feedback is fine with me, we'll see it in either case.

That feature isn't currently built-in to the package, but the OnSelectEntering method is protected internal which means that you can override it within a derived class. The signature of your method would be

protected override void OnSelectEntering(SelectEnterEventArgs args)

. You should be able to change the attach Transform pose within that method to achieve what you want.

 

1.0.0-pre.3 will be released very soon, it is going through QA and will be released as soon as that completes. In that next version, Ray Interactor will have new methods for obtaining the 3D RaycastHit and/or the UI RaycastResult, and the GameObject can be obtained through those structs.

See my post #39. 1.0.0-pre.3 fixes this so added fields in derived classes will appear in the Inspector without needing custom Editor classes.

The Interaction Layer Mask property on Interactors and Interactables uses the Layers defined in the project. The checks to determine if they are compatible to allow for interaction does not depend on the layer of any GameObject. An Interactor can interact with an Interactable as long as there is any overlap in the layer mask of that Interaction Layer Mask property. The Layer of the GameObject will affect whether Physics collisions and raycasts will hit, but that's separate from that Interaction Layer Mask property.