Question OpenXR -- Is it no longer possible to get descriptive device names?

Hi, everyone,

I'm having some trouble to identify the used HMD on the SteamVR.
Just to understand a little more, all the devices support for the OpenXR is on the image below?


And another question is: whats the best method to get the used VR device... Because as I understand, we don't have a good way to just return the device type and compare with a enum for example...

Sorry for a lot of information, but I'd like to understand more how to use properly the OpenXR plugin on my project.

Kind Regards,

Felipe Inoue

 

The tldr on openxr stance. Do what we want, not what developers actually want and need. Ridiculous.

 

Hi, @thep3000

Thanks for the response. I read the documentation and I found what I need one this section:


But this arise another question, how can I get the used current interaction profile using some library on the C# and whats the specify method to get it.
I set all the profiles on the OpenXR configuration but I don't know yet how can I detect well whats the current used device.

I saw the documentation below, but after read, I just find out how to return all the features (profiles)...
https://docs.unity3d.com/Packages/c...anual/index.html#interaction-profile-features


Kind Regards,

Felipe inoue

 

I found this documentation too, then I think this is possible on the section "Choose an OpenXR runtime to use in Play mode":
https://docs.unity3d.com/Packages/c...ual/project-configuration.html#openxr-runtime

 

So the interaction profiles are there to know what kind of controller you are using. There is a system name but it's recommended not to use it because it makes stuff fragile. It would help us if you could let us know what you're using the "headset name" for, in order to design a solution that will keep working in the future

The real tl;dr, as the main author of that writeup (which broadly represents the design principles of the working group over the past several years), is this: People will keep making new headsets and runtimes long after you stop working on your app. Every string comparison you make against an unknown set of "expected" values, is a future app crash bug when that string is something permitted but unexpected. By extension it's a piece of app-specific compatibility code every future runtime must include if your app is considered important enough (An app-specific lie the runtime must tell), otherwise it's a reason your app can't be used in the future. (All software is eventually legacy software.) We want what you want - we are looking with a longer time scale and broader scope than you might be, since that's our job.

The interaction profiles stuff works because you tell the runtime what values you are expecting, so there's no need for custom code for compatibility with your app.

Did we cover all use cases already? Definitely not. Did we make all the right choices? Of course not, we are human. Do we think we broadly got the balances right? In general yes. Will we keep trying to fill gaps and correct errors? Yes.

(Keep in mind, also, you are not actually seeing the OpenXR API directly as designed in most cases, you're seeing it as Unity has wrapped and exposed it. Not everything makes it through that translation layer conceptually intact. I think the issue of getting current interaction profile is one of these places: It's pretty straight forward if writing directly against OpenXR, you literally just call xrGetCurrentInteractionProfile with your subaction path you are asking about - generally /user/hand/right or /user/hand/left)

 

Hi, @rpavlik-collabora ,

Yeah, I need to show the correct model controllers on my game and for this, I need to know whats the controller/hmd used in the moment.

I understand that new headsets and updates will never stop coming. Then I'd like to at least to cover the main devices most used as Oculus Rift S, HTC Vive, Windows Mixed Reality, Oculus Quest 1&2 and Valve Index HMD.

If someone have a easy way to get this devices using the OpenXR, I'll be really grateful.
note: I'll use OpenXR on the Steam.

Kind Regards,

Felipe Inoue

 

Hi, @thep3000,

Thanks, I'll try here

Kind Regards,

Felipe Inoue

 

Ok, seems it worked

I tested using this code and the console log "OculusTouchControllerProfile" was printed

Code (CSharp):

1.     private bool _deviceDetected;
2.    
3.     IEnumerator Start()
4.     {
5.         do
6.         {
7.  
8.             Debug.Log("InputSystem.devices: " + InputSystem.devices.Count);
9.             foreach (var device in InputSystem.devices)
10.             {
11.                 if (device is KHRSimpleControllerProfile.KHRSimpleController)
12.                 {
13.                     Debug.Log("KHRSimpleControllerProfile");
14.                     _deviceDetected = true;
15.                 }
16.                 else if (device is OculusTouchControllerProfile.OculusTouchController)
17.                 {
18.                     Debug.Log("OculusTouchControllerProfile");
19.                     _deviceDetected = true;
20.                 }
21.             }
22.            
23.             yield return null;
24.            
25.         } while (!_deviceDetected);
26.     }

 

The high level controller profiles were always accessible in unity from the first openxr plugin. The device name held that information. The missing piece is exactly which oculus controller is in use, because all oculus headsets use the same profile.

 

It's worse than that, if you dig into the previous page other headset manufacturers apart from Meta can also use Oculus's controller profile, so you can't even know what headset manufacturer is being used. At some point you just have to have to add a dropdown menu so people can select which of the headsets' within the currently selected interaction profile they're actually using. There is no stable work around anymore for 2022.2.2f1+. (The script on the previous page did work for me before that version.)

Generally I think I agree with the design principles KhronosGroup is trying to put forward here. It's better to use hand models than controller models for future compatibility, it's better to have player controllable offsets for controller position on top of the pose offsets the runtime provides.

But it's also highly unsatisfactory to expect the player to want to tweak their controller's exact location to match where it is in the real world. This solutions is probably one of the best compromises given the design philosophy goals; but it leave large gaps like quickly getting exact and correct controller positions' real world offsets; from where the "standard" controller models are placed (e.g. the high quality Oculus CV1 models).

And it does nothing to address issues like vibration intensity differing between different headsets for the same output values specified in Unity. At the end of the day you can't just design out the hardware in a uniform abstraction layer for VR. There are always going to be limitations like what button layouts you want to require for your apps. Or if you want to support finger tracking, or if a given player even has all of their fingers.

 

Hi, @thep3000,

We couldn't find the Rift S profile...

Kind Regards,

Felipe Inoue

 

All Oculus/Meta headsets, and some not by Meta, use the OculusTouchControllerProfile.OculusTouchController

 

Until the user wants to know what button to press and their controller does not have "Primary" printed on it.

 

I find this absolutely insane.
The justification makes zero sense.

"People will keep making new headsets and runtimes long after you stop working on your app"
Yeah and they will work because my app will fallback to a default openxr controller position/rotation/pointer dir, not crash (why would it crash??)

"Every string comparison you make against an unknown set of "expected" values, is a future app crash bug when that string is something permitted but unexpected"
It's literally just: if (indexcontrollers) { apply fancy offset to controller position and pointer to match user's real hands}
in what universe is this a bug/crash again?

"it's a reason your app can't be used in the future"
wha- what? new controllers come out, app doesnt find a controller it knows about, app defaults to generic controller and asks user to tweak offsets to dial it in so it feels natural for them. In what universe would my app stop working?

this wouldnt be a problem even if the pointerRotation provided was standardized but each controller is held differently, so if you are holding something ingame like a pistol, ideally the barrel is parallel to your extended index finger, but openxr doesnt provide a normalized index finger pointer... noooo have this random pointer direction that depends on the controller, oh btw u can't know which controller exactly the player has, why? some bad vague ideology.
DIscussion on this: https://github.com/KhronosGroup/OpenXR-Docs/issues/118

Plus the whole thing about apps wanting to show controllder models that match the user's... Of course this would make the user experience way better, why wouldn't it be a priority?

 

https://github.com/KhronosGroup/Ope...sions/ext/ext_palm_pose.adoc#XR_EXT_palm_pose

Has anyone tried this extension in Unity to see if we can get the approx index finger axis?
Is it even supported yet?

thanks.

 

Is there a way to see which version of the OpenXR SDK is targeted by the Unity OpenXR Plugin?

The SDK version 1.0.27 added an InteractionProfile for the Pico headsets, which I would like to use.

OpenXR Plugin 1.7 (which I btw can't find via the Packaga Manager for some reason) was released earlier, but it does not state anywhere which SDK features should work

 

For the first question, pico has released their unity openXR support months ago. Just put it in packages and enjoy.

For those who want to see device name on android, you can get the device name via android instead

 

Since about one month my Quest 2 returns "unknown" as deviceName and as deviceModel I receive "Oculus Quest".
Has anyone found a reliable way to distinguish between Quest/Quest 2/Quest Pro in Unity using OpenXR/Android?