UnityEngine.XR.InputDevice Feedback

Hello!
I've been working on changing, adding, tuning these APIs and Feedback is greatly appreciated

1) That's a good point, and one that @jackpr caught onto a while back. Both Vive and Oculus had a 'Trigger As Button' input, but the former was the 'click' 75% pressed state, and the latter was a capacitive touch. Starting with the new XR plugins architecture, Vive will still be set to the 'click' state, and Oculus will be set to a 75% threshold.

2) This is something I'd like to fix, but I'm not sure the best way. We want to have all devices with a touchpad or thumbstick have the same 'primary' usage, but there is no good way to yet to provide context on individual features. Having PrimaryJoystick and PrimaryTouchpad would break some of the 'just get the 2D axis' simplicity. I could also add more context to individual feature info, but I want to do that carefully; it could easily blow out into a ton of weird, one-off bits of information and specifics. For right now, you can use device names and manufacturer's, but that doesn't work well when you want the game to work with platforms that may not yet be out, and on our side, if that is the way to go, I need to publish the best way to map names to devices. I need to make something official, but since the InputSystem uses the same info, my best guess at those name mappings can be found here.

3) It's hard for us to map to third party toolkits. Communication on changes and updates between companies is not always the best, and it's hard for us to keep up with why our own APIs don't work well in conjunction with somebody else's. This means that we don't really target our stuff to match VRTK, MRTK, Oculus Avatar, etc... and instead try to get them onboard with reading their data through our abstraction, so at least then we get the same source values.

That said, with Oculus Go specifically that's interesting. The Go controller is 3DoF, with Oculus providing a simulated arm model. This arm model is just reading the native position from the Oculus SDK. If the Avatar package doesn't sync up to that it means that it must be doing additional work to simulate that device's position. I can't really predict what that could be, and I'm not familiar enough with the avatar package to know if you can replace where they get their controller position from.

4) We are working on it . We think it's head and shoulders better than using the old UnityEngine.Input APIs. InputDevice showed up in 2019.1 as something simple, and we are slowly adding more features and making more well-rounded. 2019.2 added a few smaller things like OnConnected/Disconnected callbacks, and 2019.3 has some adjustment to usages, replacing the concept of device roles with something better, and tracking origin and boundary point APIs. The goal is one-stop cross platform, where you can connect an unknown device, as a developer check that it has the features you require, and map to those. But we are not quite there. I really want to avoid adding really device-specific things like 'isTouch', but I do agree that more feature-level context would really be helpful, and something I'd like to get down properly.

5) As for the InputSystem. It's on my own personal to-do list, but with delays in that package, and it's slower, more experimental roll out, we wanted to get the InputDevice APIs out and ready. I will be going back to that to properly document how that works and what it can do. In the long run, the InputDevice data is going to be sent to the InputSystem, and the action/binding systems available there will be able to provide a stronger abstraction than we can do at the InputDevice level.

6) Right now our suggestion is to use the InputDevice APIs, which in my opinion at least, provide a good, low level access, but if you want to use existing animated avatar systems, we suggest targeting the one that suits your needs best. I understand this is difficult right now because each avatar system targets a specific SDK. This is a problem for us too, and while too early to give any details, we are looking into providing a proper cross-platform avatar system. If you don't need built-in hand or controller articulation, the TrackedPoseDriver can map a game object to a controller, so you can use custom models that way, and animate based on InputDevice features. I do agree this should be a built-in, supplied utility for how common a feature it is, and we are working towards that.

Hope this helps, and we do appreciate the feedback; Keep it comin'. I shared this with the rest of the team, and we are already talking about point 2 & 3, and I personally got reminded about point 5.