Hi,
I am using Unity OpenXR Plugin 1.3.0
I added this interaction profiles:
Khronos Simple Controller Profile
Microsoft Motion Controller Profile
Oculus Touch Controller Profile
Valve Index Controller Profile```
We I start the game I'm getting this errors:
```Failed to suggest bindings for interaction profile '/interaction_profiles/htc/vive_controller' with result 'XR_ERROR_PATH_UNSUPPORTED'.
Failed to suggest bindings for interaction profile '/interaction_profiles/valve/index_controller' with result 'XR_ERROR_PATH_UNSUPPORTED'.```
What am I doing wrong? what am I missing?
Thanks.
Youāre doing nothing wrong, Thatās expected behaviour. Basically itās checking the hardware and going āHey, this isnāt a Vive or Index controller!ā
When Unity Loads the OpenXR Controller Profiles, it asks the OpenXR API to connect to each loaded controller profile.
OpenXR, In Turn, is basically throwing the equivalent of a NullRef when trying to find that specific controller hardware and saying āYo, thatās not connected!ā
This is an error you can safely forget, however, if you want to get rid of it, you COULD do some fancy stuff with the Input System to work out what headset is connected, and load the correct controller profile in using the Unity OpenXR plugin APIā¦
If any other OpenXR experts would like to chip in here?
Technically this is a runtime bug as the runtimes are supposed to all support all of the core interaction profiles and both of those are core interaction profiles. All other interaction profiles are guarded by extensions so the runtime can tell the OpenXR plugin ahead of time that the interaction profile isnt supported and thus we wont send the bindings down for it. I assume you are running against the Oculus runtime which I believe is the only major runtime that does not support the entire core set of interaction profiles at this time.
That being said the error is harmless and you can ignore it, it just means that the bindings you send for those devices are being ignored by the runtime. It would only matter if those were the only interaction profiles you are sending, in that case you could get no input.
The error doesnāt seem to be as harmless as suggested. I have it, and itās stopped the input āpointerPositionā ā{RightHand}/pointerPositionā from reporting the correct positions, always returning (0,0,0). Removing the offending interaction profiles (valve index & htc vive), made the errors go away, and fixed those positions.
I tried the following configurations with the controller sample and in all cases both the grip and aim positions were tracking properly. If there is a setting or configuration that I missed please let me know. The way the devices and input system works in OpenXR only one device can be active at a time and providing data, so those other devices and bindings should be ignored. In the situation where you are getting invalid data can you also check the Input Debugger and see what devices are active ?
@the_real_apoxol
Iām getting an identical and always persistent set of error in the latest 2021.2.7f1 using all of the latest OpenXR packages (OpenXR Plugin 1.3.1, XR Plugin Management 4.2.1, Interaction Toolkit 1.0.0-pre.8) when using Oculus as my OpenXR runtime as well. The error messages always appear at startup around frame 2:
The pointer rotation path is the one which is erroring for me as well. This is an issue for me as the default rotations for Oculus and OpenXR are not the same (OpenXR is 90 degrees rotated up as if itās forward vector were pointing in itās transform.up direction unless I use this specific path bindingā¦).
The path unsupported errors are just from the Oculus runtime because it doesnt support those interaction profiles properly, but they should just be ignored.
As for the rotation the deviceRotation and devicePosition for the Oculus Loader do not match the deviceRotation and devicePosition for the OpenXR loader. This was a choice made by the Oculus runtime because OpenXR has two poses and the old Oculus loader only had one. The pointerPosition in OpenXR is a bit closer to the Oculus loader but still not 100% the same. What is the set up you are using here? Are you using the Oculus loader for Android and the OpenXR for windows?
Iām currently stuck in HDRP land so Iāve only tested it on OpenXR for windows so far. Using the Oculus plugin with the new mapping doesnāt provide any rotation, which makes sense from what you said.
Thatās good news! Do you know if they have any intention of fixing that? Every oculus developer who has correct controller rotations is currently stuck with have those error messages appearing all the time, and the errors are non-suppressible since they donāt happen in game developer controlled code. This seems like a bad design choice from Oculus, especially as itās literally just a Euler rotation from being able to support everyone elseās [non-negotiable] standard of having two aim posesā¦
Do you know what the exact offset is? All OpenXR developers submitting to the oculus store are going to need to know that since they require the controllers to 100% match their real world size/position/rotation. I originally reported similar [but different] set of problematic offset March here: https://discussions.unity.com/t/820905 page-5 (These old photos were using the non-pointer strings and were inconsistent between different OpenXR plugin providers at the timeā¦).
When I just now took a look the new rotation provided by the pointer string it looks like a 100% match. From the looks of it itās still just the position which is still offset by about half of a controllerās bounding box. (Now just in the opposite direction as the link above.)
I dont believe they intend to change it at all. The grip and aim positions are all correct by OpenXR standards. The issue is that controller model that is provided in the Oculus Integration package is not properly oriented to match their new grip and aim positions. Proper controller placement in OpenXR is tricky, especially because you dont actually know what controller is in the users hand, just which interaction profile is enabled which may not be the same.
Ok that makes a lot of sense, everyone needs to do a small amount of fact checking and manually fixing for their particular variants of the controllerās models position is not a lot to ask for each controller model a dev wants in their game.
Knowing that my previously correct reference was wrong in a new context ā is a lot easier to fix than having the underlying system be inconsistent.
Do you know if there is an intention to unify this at all? Since Oculus now runs on OpenXR Backend, why not have 2 poses, and make them match the OpenXR Standard regardless of which plugin is used? I donāt use the Oculus Integration package, so for me itās not even about controller rendering. I just want consistency
Unity is pushing an extension called the Palm Pose that would help do this, outside of that I dont know of any but we can discuss it with the runtimes.
