XRI 2.3 Upgrade

[Zee2]

This ticket tracks upgrade to XRI 2.3, along with the XR coreutils upgrade

• [ ] Evaluate new input simulator, how much of our own input simulator we can remove
  • [ ] Already works shockingly well, main problem is that they don't have a concept of the "anchor point" so the hand ray/grab flails around wildly (they just anchor on the device position, obviously)
• [ ] Evaluate Transformers and how they will influence our constraints/solvers story
• [ ] Evaluate the new datum feature in XR Coreutils, possibly use it for config on BC, UX?
• [x] Tests pass
• [ ] Check in with internal partners before bumping XRI minver
• [ ] Possibly refactor our Selectedness to point to their interactionStrength
  • [ ] This would require us to implement our poke logic as an MRTKPokeFilter
  • [ ] This would also require us to deprecate our IVariableSelectInteractor and migrate to IXRInteractionStrengthInteractor (phew, what a mouthful)
• [ ] Evaluate replacing our GazeInteractor with their XRGazeInteractor
• [ ] Evaluate replacing InteractionModeManager with XRI interaction groups
  • Groups may not support enabling/disabling based on external rules/detectors :(

Notes

• Something seems very wrong with our ray interactor/controller execution order, at least in-editor. The default XRI XRGrabInteractable goes crazy when grabbing/rotating. Definitely an execution order issue
• They have a hardcoded "Enable gaze interaction" checkbox on their interactable settings, which compares incoming interactors against their concrete impl of XRGazeInteractor, instead of any kind of generic interface like IGazeInteractor
  • This can/will confuse our users when our gaze interactor does not respond to the XRI options for gaze.
• Our line visuals do not respond to XRInteractableSnapVolume
• Most things seem to work just fine so far, even with some of the conflicts with gaze, etc
• Their new XRPokeInteractor does not do inter-frame collision checks so it may be susceptible to "phasing through" interactables
  • Confirmed, their poke interactor will not process pokes when the interactor is moving quickly
• Their "poking depth" is a property of the poke interactor itself, not the interactable, which is a really strange decision because buttons can be different sizes and depths 🤔🤔🤔
• Their new XRPokeInteractor implements IUIInteractor, which means we can do the exact same thing and get touch interactors on vanilla canvas!
  • Unfortunately, the API for adding this to our own interactors is internal, so currently only official XRI XRPokeInteractors can do UGUI interactions. Huge bummer :(
• They now have their own "Selectedness", which is "interaction strength". We can pretty easily adapt to this by implementing our own PokeFilter and just routing the Selectedness API down to their interaction strength value
• Their PokeFilter is hardcoded to only work with XRPokeInteractors, not any generic interface like an IXRPokeInteractor :(
• Our PokeInteractorVisuals script assumes a PokeInteractor which is a little silly. We should change it to a generic interactor.
• New input simulator already works shockingly well, main problem is that they don't have a concept of the "anchor point" so the hand ray/grab flails around wildly (they just anchor on the device position, obviously)
  • Not sure how feasible it is to alter their simulator to do this
  • Possibly we can change the joint synthesis subsystem to be smarter about this (i.e., anchor the simulated joints, not necessarily the simulated device pose)
• The new XRPokeInteractor and XRPokeFilter API is incredibly strange and I literally cannot make heads nor tails of it
  • I've tried for like 2 hours at this point to make a simple button that presses at a given distance and I cannot do it
  • This will require a lot more work to understand and possibly work with the XRI folks to improve things
• Looks like the XRInteractionGroups have a lot of limitations and won't support enabling/disabling based on external rules like we do with our modes

[RogPodge]

2.3 contains some API improvements for key features such as implementing custom reticles for bound handles. So long as our existing implementations don't break, I'd like to move to 2.3 even without completing the other evaluations listed on this task.

[Zee2]

@RogPodge I agree mostly, except for the most egregious issues here (i.e., two completely duplicate PokeInteractors., etc) I will be bringing up as many of these as possible in our meeting tomorrow.

[AMollis]

See #11298 for draft PR

[shaynie]

Need to go through the investigations and recommendations listed above and create feature requests.

[shaynie]

Updated to XRI 2.3 with https://github.com/microsoft/MixedRealityToolkit-Unity/pull/11452