Fix for eye gaze pinch controls and fix pointer naming bug

[RogPodge]

Overview

Previously, the eye gaze controls were broken and would not let the users pinch to manipulate objects. This PR fixes this by removing the hard-coded dependency on controller names, and it also fixes a bug introduced with pointer naming

old naming:

new naming:

Changes

• Fixes: [Stabilization 2.6.0] Eye tracking targeting example - Slider is not working #9336

Verification

This optional section is a place where you can detail the specific type of verification
you want from reviewers. For example, if you want reviewers to checkout the PR locally
and validate the functionality of specific scenarios, provide instructions
on the specific scenarios and what you want verified.

If there are specific areas of concern or question feel free to highlight them here so
that reviewers can watch out for those issues.

As a reviewer, it is possible to check out this change locally by using the following
commands (substituting {PR_ID} with the ID of this pull request):

git fetch origin pull/{PR_ID}/head:name_of_local_branch

git checkout name_of_local_branch

[RogPodge]

/azp run

[azure-pipelines]

Azure Pipelines successfully started running 2 pipeline(s).

[julenka]

FYI @sostel

[cre8ivepark]

Tested on the device and works well! Thanks!

[keveleigh]

We may want to move this below the if (this == null) check. If this == null, then gameObject will likely be null too and gameObject.name will null ref

[keveleigh]

The this == null check is meant to guard against the case where a hand is detected and lost within a single frame or a couple frames (either way, in fewer frames than it took for await EnsureInputSystemValid(); to return). In that case, the pointer might be cleaned up and gone when we get here

[keveleigh]

I think moving this out of the Controller setter might cause unexpected pointer names in the case where they're recycled and reused.

MixedRealityToolkit-Unity/Assets/MRTK/Core/Providers/BaseInputDeviceManager.cs

Lines 200 to 220 in 965f566

	if (EnablePointerCache)
	{
	var pointerCache = pointerConfigurations[i].cache;
	while (pointerCache.Count > 0)
	{
	var p = pointerCache.Pop();
	if (p.TryGetMonoBehaviour(out MonoBehaviour pointerComponent))
	{
	pointerComponent.gameObject.SetActive(true);
	// We got pointer from cache, continue to next pointer option to review
	requestedPointer = p;
	DebugUtilities.LogVerboseFormat("RequestPointers: Reusing a cached pointer {0} for controller type {1} and handedness {2}",
	requestedPointer,
	controllerType,
	controllingHand);
	break;
	}
	}
	}

in that case, we'll reuse a pointer GameObject which will retain its previous name, which might have been for a differently-handed controller

[keveleigh]

Currently, with the name update in the setter, the name will update when a reused pointer is updated at, for example:

MixedRealityToolkit-Unity/Assets/MRTK/Providers/XRSDK/XRSDKDeviceManager.cs

Lines 205 to 208 in 2948006

	for (int i = 0; i < detectedController.InputSource?.Pointers?.Length; i++)
	{
	detectedController.InputSource.Pointers[i].Controller = detectedController;
	}

[RogPodge]

Unfortunately this led to the repeating handedness bug we observed earlier. I suppose the best way to go about addressing this is to have another variable that denotes the pointerTypeName? Though, I'm not super enthuthiastic about setting that initially and then never touching it again. I also wasn't super thrilled that the naming methodology had started to get fragmented across the many different pointers.

[keveleigh]

Yeah, that's definitely fair! I wonder if we could split on _ and replace the first value with our new handedness or something?

[keveleigh]

I also wasn't super thrilled that the naming methodology had started to get fragmented across the many different pointers.

Also this though, yeah :(

[RogPodge]

Yeah, that's definitely fair! I wonder if we could split on _ and replace the first value with our new handedness or something?

I worry that we start relying too much on the naming structure of the object that's getting passed in, and the extra variable approach is slightly more appealing to me in this case...

[RogPodge]

Followup PR here #9371