Mixedrealitytoolkit-unity: Errors in the on device console related to controllers, input and teleport system.

[davidkline-ms]

When running a VR application built using the following:

• Unity 2019.3.12f1
• Legacy XR pipeline: Windows Mixed Reality 4.2.1
• Default MRTK Configuration Profile
• BoundaryVisualization demo
• UWP build target

Two TeleportPointer messages are present in the headset's diagnostics panel. Teleportation works, though there is no cursor apparent in the world.

I have been able to reproduce releated(?) errors using Unity 2018.4 and the HandInteractionExamples demo.

I can NOT repro when using MRTK 2.3.0.

[julenka]

Whoops. Accidentally pressed "close and comment" which I thought said "cancel" for a minute :-)

[davidkline-ms]

This was first filed using the boundary visualization demo.

With the hand interaction examples demo, i am also seeing messages stating that the 'given key is not present in the dictionary' as well as 'xxx controller has not been registered with the input system'.

The app is functional. Both controllers appear and are operational.

[davidkline-ms]

I will have to double check the registration error to confirm whether or not it says "not been" or "already".
I believe i miss-read the message as this appears to be the relevant message from the input system (RaiseSourceDetected):

c# if (DetectedInputSources.Contains(source)) { Debug.LogError($"{source.SourceName} has already been registered with the Input Manager!"); }

[davidkline-ms]

Searching the MRTK code, i am not finding a message re: "given key is not present".

[keveleigh]

I think "given key is not present" is just the standard dictionary message

[davidkline-ms]

So far, I have been unable to reproduce this with MRTK 2.3.0 and Unity 2018.4.22f1

[davidkline-ms]

@vaoliva has confirmed this also occurs on a WMR ultra pc.

[keveleigh]

Looks like this was introduced in #6939, which added some awaits while the controller model loads. Previously, we fired a source detected the same frame the pointers were created, and the controller continued to load the controller models in the background. Now, pointers are created, then the source detected event waits for the controller models to be loaded.
Currently, the teleport cursor checks every Update for its pointer to be registered (which happens on source detected). If its pointer isn't registered, it destroys itself, leading to the behavior described above.

Possible solutions:

1. Don't await (this is how every release prior behaved, though i do see the value in waiting until the controller model actually exists)
2. Allow cursors to fail gracefully when their pointer doesn't exist yet (I think this is maybe the one we should do, though it could lead to cases where cursors aren't cleaned up properly? but that should be handled in the pointer lifecycle, and cursors shouldn't be expected to always ask if its pointer is alive)
3. Don't instantiate pointers / cursors until the source is ready to go (I think this one is the "best" behavior-wise, so we don't have pointers / cursors sitting around in the scene without their source existing, but also the most invasive, since controllers depend on input sources depend on pointers, and it would take a bit of a re-architecture to resolve that dependency chain)

[davidkline-ms]

@keveleigh, thanks for helping root cause this!

Option 2 seems reasonable

[davidkline-ms]

In working on option 2, there are enough new issues being uncovered. I am going to revert to the 2.3 Windows Mixed Reality Controller behavior and open a new issue to re-implement #6939 and resolve the side effects properly in the input and teleport systems.