BaseControllerPointer.cs Error Quest MRTK or MRTK? about mrtk-quest

[provencher]

As you mentioned, this is a bug report for MRTK, not for MRTK-Quest. Please file that report on their github.

If you have a fix that can avoid it on MRTK-Quest without touching the MRTK code, I'm open to that, but there's not much I can do otherwise. Thanks.

[keveleigh]

transition between pulling the headset up on my head and pulling it back down while simultaneously having my hands being captured.

This feels like a bug in the implementation here. I can't recall seeing this case in any of the MRTK-defined device managers, but maybe we have a race condition that only shows up in a specific case.

Why would the source be lost (or maybe back-to-back found and lost) when the headset is pulled back down? It seems like hand tracking should be successful at that point.

I think that might be a red herring though. An input source should exist for as long as the controller exists, and an input source is required for a controller to exist. It's not a Unity object, so there's no chance of it being destroyed from the scene. How is it null? Since this is happening in the Editor, it should be pretty easy to run a debugger against to check (I don't have a Quest, or I'd try), or even just add some Debug.Logs to see when / how often RemoveHandDevice is called.

The following code grabs a generic input source and sets it on the pointers. It appears to run on Unity's Update loop, so I can't think of a reason it'd be running out-of-sync with a lost event:

MRTK-Quest/Assets/MRTK.ThirdParty/MRTK-Quest/Scripts/Input/DeviceManager/OculusQuestInputManager.cs

Lines 370 to 387 in 896d2e1

	// Add new hand
	var pointers = RequestPointers(SupportedControllerType.ArticulatedHand, handedness);
	var inputSourceType = InputSourceType.Hand;
	IMixedRealityInputSystem inputSystem = Service as IMixedRealityInputSystem;
	var inputSource = inputSystem?.RequestNewGenericInputSource($"Oculus Quest {handedness} Hand", pointers, inputSourceType);
	if (!inactiveHandCache.TryGetValue(handedness, out var handController))
	{
	handController = new OculusQuestHand(TrackingState.Tracked, handedness, inputSource);
	handController.InitializeHand(ovrHand, MRTKOculusConfig.Instance.CustomHandMaterial);
	}
	inactiveHandCache.Remove(handedness);
	for (int i = 0; i < handController.InputSource?.Pointers?.Length; i++)
	{
	handController.InputSource.Pointers[i].Controller = handController;
	}

After digging in a bit more, I thought it might be based on the device manager firing multiple lost events for the same hand, but I can't find the exact path to support this theory:

1. RemoveHandDevice is called
2. RecyclePointers is called, which calls Reset, which sets the Controller to null https://github.com/microsoft/MixedRealityToolkit-Unity/blob/33781c0bcebbcb5f9c0df9160f13db300e13cc27/Assets/MRTK/SDK/Features/UX/Scripts/Pointers/BaseControllerPointer.cs#L406-L412
   1. This is where my theory falls apart, I think, since the Controller setter won't change InputSourceParent unless the new value is non-null
3. RemoveHandDevice is called a second time
4. InputSourceParent is null due to the previous recycling / cleaning up of pointers?

[keveleigh]

All that being said, I'm not fully against just adding that null check to fix things, but it feels like it might be hiding either an invalid set-up or a case we need to explicitly handle another way (recycled pointers that are still getting events but shouldn't be? not sure)

[JShull]

Let me try removing that null check and dump you the full log and see if that helps - will add this towards my items for tomorrow and will follow back up to provide the best information I can.

[keveleigh]

@JShull Appreciate it!

[JShull]

Here's what I noticed:

The error throws three times - all point to the same BaseControllerPointer.cs Line 475, but the second error of the three has a slightly different path, right before BaseControllerPointer.cs it is coming from PokePointer.cs 460... is this the missing path?

Here's the updated images from Unity on the NullReference Exception (this time all three of them)

Also noticed this go around at the end some 'task.rasterData.vertexBuffer = = NULL' was thrown not sure if that's related or just fall out from the other errors.

Hope this helps!