My understanding about the way OpenXR works is that if you are using a controller type which has an associated interaction profile which is not added in the XR Plug-in Management section of the project settings, then the controller would fallback to use one of the other Interaction profiles you have added. I thought this was their method of future-proofing, so that even if new controllers are developed, they would default to one of the profiles in your settings even if you have not added the new profile.
I was trying to test this today. I am using Quest 3 controllers. I have four interaction profiles added in the settings: Index, Vive, Oculus Pro, and Oculus Touch. When I enter play mode with these profiles, everything works fine. BUT, if I remove the Oculus profiles from the list and enter play mode, the controllers don’t seem to register at all and don’t even show up in the Input Debugger. I would think that the controllers would still be detected and fall back to using the index or vive profile. Is this a bug with OpenXR or Unity? Or am I misunderstanding how this is supposed to work?
Was advised to try this with the Meta Quest Touch Pro profile disabled in case there was a problem with that profile, but it didn’t seem to make a difference. Tried it with just the Index profile enabled:
Hey there,
A few questions. Are you using Quest Link to use the controllers with the editor play mode? Additionally, in the Input Debugger, what do you see when the device successfully shows up? A controller may not fall back and use a separate profile if it’s unable to match a profile that’s present.
Additionally can you also give us the XR-Plugin Management and OpenXR package versions you are using? This can help us reproduce the issue or otherwise identify if something is amiss
Sure! We are using Quest Link, yes. We’ve also tried using the new Steam VR app on Quest to run it through Steam VR, and tried changing the default runtime in the Open XR settings, but haven’t found any combination that works.
When the Quest profile is enabled, the Quest controllers show up in the input debugger. When the Quest profile is not enabled, no XR controllers appear in the debugger. We expect to include the Quest profile, but we were disabling it to test our fallback behavior when someone uses a controller that we don’t have a specific profile for.
The instructions with the profiles say to “only enable profiles you actually test,” and I would expect Quest to be able to fall back to Vive or Index considering there’s a lot of overlap between their inputs, but please let me know if this assumption is wrong.
We’re using the default versions for 2022.3.14. Our package manager shows:
So reading our docs, it seems the device runtime itself returns the interaction profile that the device is associated with. Unity then tries to match the interaction profile with a set of Unity Input bindings, and it uses the Enabled Unity Profiles to try to select the correct bindings. What may be happening is that the profile being provided by the Open XR runtime is quest specific, and thus are incompatible with our Unity Profiles for Vive or Index.
It sounds like the Quest device’s interaction profile is just incompatible with Vive/Index bindings, even though the controllers are pretty similar. It might just be a limitation with the Quest Runtime.
Thanks - I guess part of our confusion here comes back to the recommendation to “only enable profiles you actually test” that appears in the warning box above the profile list in the editor view. Our assumption would be that controllers should always attempt to fall back to one of the supported profiles, perhaps with incomplete functionality at worst, rather than controllers completely failing to be detected. If there is a list of profiles that cannot fall back, is there a list available so we know which controllers we need to test with at a minimum?
I don’t think there’s a published list out there. My recommendation is to include profiles for devices you know you’ll support as well as the Khronos Simple Controller for the best coverage.
The Khronos Simple Controller doesn’t support basic functionality required for most VR games (like a trigger or Vector2 input from a touchpad or joystick. It’s not viable.
We can get input working if we completely bypass the OpenXR controller profiles and avoid using that system altogether, but that means we can’t use the new input system at all. That’s what we’ve been doing for the past 9 years of releasing VR games on a variety of platforms and it’s not especially future proof, but it does work. We were interested in supporting OpenXR through the new system because of its promise for forwards compatibility (and we’re also required to support it in some way for Steam VR now that Unity and Valve no longer support the old OpenVR plugin).
I’d love to see a better solution from Unity here. I know this is a complicated problem, but if this fallback system is unreliable and undocumented, we’ll need to change course and roll our own solution again to reduce the possibility of new controllers being undetected in our live builds. At least with our own solution, we get some functionality from newer controllers even if it is occasionally a bit janky.
