Question Unity OpenXR error: Failed to suggest bindings

Hi,
I am using Unity OpenXR Plugin 1.3.0
I added this interaction profiles:

HTC Vive Controller Profile

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!"

 

But that's an error, Is it okay to use a build with such errors?

I also don't have hardware for Microsoft Motion Controller and Khronos Simple 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!"

https://www.khronos.org/registry/OpenXR/specs/1.0/man/html/xrSuggestInteractionProfileBindings.html

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?

 

In that case, could it be that these errors are only fired in editor and not on build?

 

The error doesn't seem to be as harmless as suggested. I have it, and it's stopped the input "pointerPosition" "<XRController>{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.

 

So now I can't seem to be able to reproduce it.
My apologies.

 

This is super helpful, thanks!

 

@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...).



Interaction Profiles Used


Full Error Log Dump

 

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://forum.unity.com/threads/unity-support-for-openxr-in-preview.1023613/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.)

 

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

 

Interesting, but the OpenXR runtimes all implement the OpenXR standard which means they have to report this data in both poses right? Or am I not correct there.

I can resolve most of the differences using offsets to approximate the poses on different runtimes, these are just transforms that are used as anchor points that objects can attach to. It looks like this:


As you can see I have the rig, then a height offset, and then Head & left/right hands, with aim/grip poses for each, then a whole bunch of offset transforms for each Plugin/Device. In an ideal world I would not need the offsets, but that's where we are right now. For oculus what I do is change the TrackedPoseDriver input mappings so that both aim & grip follow the aim pose reported by oculus plugin mapped to devicePosition - (which actually resembles the pointerPosition/aimpose), then the offset for the grip pose - `[OculusXR] OculusTouch Offset` resolves this and makes the GripPose's offset look like the "grip pose".

Less than ideal but I can make it work.

The issue I can't circumvent however is UI input. In the input manager must map to an input action - The input action I setup is called UI/LeftAim - It's mapped to pointer position - I guess I have to remap it just on oculus?

Surely there has to be a desire from Unity to unify these inconsistencies? Or is the attitude that, most users should only want to use one plugin?

 

So how would this sit with other devices? I try not to use device specific bindings, and try to use <XRController> where possible, so it can be cross platform, Do you think I can bind the this aim action to all 3. Oculus controller from oculus, Oculus controller from OpenXR, and XR Controller as a catch all ?

Also what's the ETA on OpenXR 2.0?

 

@jamie_xr Could you please please publish the Left/Right hands you have pictured right here as a prefab? That alone would save a hundred+ fellow game developers about 20 tickets trying to test/get all of the offsets from random online sources... (If you have all of them, and even if you only have some of them we could collectively still open source all of the other offsets here!)

 

I don't actually have the offsets yet, they are all just 0,0,0 I was just demonstrating how I set it up, so when we come to test our game on each device we can play with offsets in there to find an offset that feels correct.

 

In 2020.3 LTS, we get the suggested bindings error too...but for us, it seems a blocking error.
The engine gets stuck in Play-Mode and VR is not initialized fully, when we include profiles, that are not being used (e.g. Vive Controller and Oculus Touch)

Anyone else still getting that?

 

Correction:

We have been running on 2020.3.25f and 1.3.0 plugin

Now we are running on 2020.3.26f and 1.3.1 plugin - and things seem to work?
We're still investigating

 

Any updates on this?

 

I would also like a fix for these error messages. While I understand they are harmless, they do clutter logs and having fake errors being reported will lead to instances that you overlook real errors in the console because you are now conditioned to ignore errors.

I tried doing something like this in Awake:
OpenXRSettings.Instance.GetFeature<HTCViveControllerProfile>().enabled = false;
OpenXRSettings.Instance.GetFeature<ValveIndexControllerProfile>().enabled = false;
But that returns an error saying you cannot disable them once OpenXR has been started.

 

No this XR_ERROR_PATH_UNSUPPORTED
with this configutation:
unity 2021.2.0f1
XR plugin Management 4.2.0
Open XR plugin 1.2.8
Oculus XR plugin 1.10.0
Input system 1.2.0
but if i update to
unity 2021.3.1f1
XR plugin Management 4.2.1
Open XR plugin 1.3.1
Oculus XR plugin 3.0.1
Input system 1.3.0
this error appears.

 

Bump. There should never be an error that developers are asked to just ignore. We have thousands of players in our game and these sorts of errors will clog up our diagnostics.

 

I'm still confused about how this "should" work. Say I want to support Vive and Oculus Touch - I add them both in the interaction profiles section and set up specific bindings for them individually. But then say the Oculus runtime does now support and re-map the Vive interaction profile, it would presumably be the "Vive-specific" bindings that Unity would use, even though the runtime has remapped them to the Touch controllers. Do OpenXR runtimes have the concept of a preferred profile to handle this case?