Windows MR controller identifies as 'generic-trigger' controller in XR

[nbduke]

Bugs

Repro playground: https://playground.babylonjs.com/#AM07G2#46

When using a Windows MR headset, the controller model is incorrect and not all inputs are mapped. In the above playground, I print the profile ID of the controller; for me, it always shows up as "generic-trigger".

[RaananW]

Hey, can I ask what browser you are using? And what device as well? Older browsers don't support the method used to identify the controllers (profiles). Have you tried with latest canary?

I can add a fallback, but some browsers have already removed the ID from the gamepad object and don't support profiles, which makes it very hard to guess the device used

[nbduke]

Yeah, I was using EdgeDev 80.0.361.5. My device is an HP Windows Mixed Reality headset. I have not tried with latest canary Chrome/Edge.

Are you saying that all browsers are eventually removing the ID from the gamepad object? If that's the case, what's the future plan for making sure the correct controller model/input mapping is used?

[RaananW]

The future plan is a profiles array on the input device, which will map to the abilities of your device. You can read about it here:
https://immersive-web.github.io/webxr/#xrinputsource-interface

[RaananW]

I'll check this next Monday. I think a temporary solution would be to allow the dev to (optionally) force a type of controller as the default one instead of the genetic controller. I'll add it to the input options

[nbduke]

Did something in the XR spec change? It seems like this used to work before your recent refactoring of the XR controller-related classes.

[RaananW]

Nope, it didn't change, but it was simply not implemented and the default controller was the MR controller (this is why the Oculus controllers didn't load correctly). I added the generic controller as the last fallback and this is what caused this.
From all of my tests the id of the gamepad object is now empty. Meaning we have to start using the profile array. The latest canary works correctly (tested with Oculus and MR), but I'll soon check what can be done with older browsers. I did add a fallback for the quest which is using chrome 77 and still has the gamepad id. On a side note to this, there is currently no way of differentiating between the older Oculus touch and the newer ones. I hope the touch-2 profile will soon be available to support both the rift and the rift-s (and the quest, of course)

[RaananW]

I added an optional way of forcing a certain controller type (see the PR for usage example), I will work further on a better way to address this .

[nbduke]

@RaananW When you say that the latest canary works correctly, are you referring to Chrome Canary? I just tried the above playground on Chrome Canary and it was still broken.

Also, question about your fix: does the forceInputProfile option make that the fallback profile if no others are detected, or does it override the controller's profile if it has one?

[RaananW]

@nbduke - the menu button was removed from the specs in the latest so it throws exceptions and doesnt work, I will push a fix in a sec.
It also seems like the profile name was changed?... fixing now

[RaananW]

@nbduke - the forceInputProfile for older browsers will force those controllers (overriding the profile array). if they are not found, the profile array will be used.

[nbduke]

So I would need a runtime check to determine whether I should use forceInputProfile or not? What would I check for? It seems like it'd be easier if it was a fallback setting rather than something that overrides the correct behavior on an up-to-date browser.

Or maybe I'm not understanding what it does.

[RaananW]

I have just tested the latest PR locally with canary and it works including thumbstick animations. If you have any problems, please let me know. Shortly after merging it will also be available in the playground.

[RaananW]

about the force fallback - this is just a temporary solution until all browsers support the full profiles spec.
There are many fallbacks already registered, and you can technically register your own fallbakcs (see here:
https://github.com/BabylonJS/Babylon.js/blob/master/src/Cameras/XR/motionController/webXRMotionControllerManager.ts#L120
)

But this assumes the profiles array is populated. if it isn't (probably the case of older browsers) and the gamepad id is not available, you can force a certain type of controller so you can develop.

[nbduke]

Is there a way to check if the profiles array is populated?

[RaananW]

only when the controllers are connected and you are in webxr already. You can either check right after entering XR (xrSessionManager.session.inputSources will give you an array of connected XRInputSource along with their profile arrays) or you can attach to the xrInput.onControllerAddedObservable. If you add the callback first (a flag when using the .add function) you could catch it before the motion controller initializes. But check first if the profiles array is there.

Wait for the latest change, i also added a fallback between microsoft-mixed-reality and windows-mixed-reality , edge might have the latter.

[nbduke]

I can confirm this fixes the issues I was seeing on both Chrome Canary and Edge 80.0.361.23. Thanks!