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?

 

If i check my Rift S like this I get: "HP Reverb".
This approach doesn't work at all for me. God this is frustrating to work with.

 

You could XRInput API. Its much simpler.
https://github.com/reignstudios/Unity3D-XRInput/tree/master

Look at examples:
https://github.com/reignstudios/Uni...Reign/XRInput/Example/TestAssets/TestInput.cs

Or:
https://github.com/reignstudios/Uni...gn/XRInput/Example/TestAssets/TestVelocity.cs

 

Looks promising. So I could get with this a meaningful name for all (top 10 known) headsets/controllers?
Would not need more than that.

 

XRInput.GetControllerType(...) returns this emum.
public enum XRInputControllerType
{
Unknown,
Oculus,
PICO,
HTCVive,
HTCViveCosmos,
HTCViveWave,
ValveIndex,
WMR,
WMR_G2
}

This is determined here: Unity3D-XRInput/Assets/Reign/XRInput/API/UnityEngine_XR.cs at master · reignstudios/Unity3D-XRInput · GitHub

Specific types could be refined but normally on Oculus platforms you use the OVR integration SDK for this.
However XRInput maybe should be updated to support this info.

 

It's nice to know there are alternative ways of going about this, but I want to caution people on thinking this is a good long term solution. I think the most important major point of moving to OpenXR was to get rid of the patchwork XR plugins for every vendor, and to allow interoperability and futureproofing of your app's needed hardware inputs beyond the life cycle of just this generation's VR hardware. From the looks of it, this XRInput package seems to have the opposite effect of wanting to just build on top of a ever growing number of XR-plugins. While this is much better in terms of being able to query the headset's name -- it does not guarantee the vendors specific plugins in the future won't only be developing for OpenXR in two or three years, or that this middle-wear input utility will still be updated to support the specific hardware you're developing for by then. You're also buying into a strong dependency to on multiple XR plugins which have already been sunset (like legacy SteamVR). Plus you'll also need to manage switching between those multiple plugins/platforms, while potentially building for multiple store front or devices.

To me that seems like a lot of financial and logistical risk, vs just adding a dropdown menu where people can select what headset they're using / maybe not having all of the new option in a couple years if you stop updating it.

 

The problem with Unity's input systems have always been overly complex in the VR space.
And the sad truth is OpenXR is like OpenGL trying to force manufactures to design their hardware around software instead of software being designed around hardware (no matter what the claims are this is how these things play out). There are good reasons why Apple went with Metal instead of Vulkan long run (so they can model their hardware in ways that may not match Vulkan [same is true with OpenXR situation]) and so the solution will always be a high level agnostic layer. Even OpenXR itself may fail and many times in practical ways it does. Many vendors have not supported OpenXR the same way as their native APIs have and OpenXR many times has missed features or been slower.

Also Unity3D has its own agnostic layers around OpenXR for this very reason. Only problem with them is they are not simple to use and prone to allocs.

XRInput solves every problem I've personally ran into in this space. Can even target Pico2 which is not a OpenXR compatible device. Adding missing device support is very simple when new ones come up. Either way use what solves your problem but in my experience Unity's Input APIs have never been a stable solution.

Also I'm not sure Apples VisionPro or PSVR even supports OpenXR. Anyone know?

 

What I don't see being sufficiently addressed is player hand-to-controller orientation. We need to be able to make a virtual hand fit the relative position of a player's actual hand on each given controller type. Unless the profiles provided by each manufacturer provide some kind of standardized info regarding this, we will always still need to know the specific controller in use.

 

I've been thinking more about this and remembered other issues we've encountered that make it necessary for games to be able to discover the specific type of controller being used:

For example, one headset we support has controllers with joysticks that only "click" inward when held in the neutral position. They're supposed to be able to click when tilted too, but the flawed manufacture of the controller prevents it from actually working. So we had to know about this and remap functionality that is normally mapped to that action when we detect that particular controller is being used. In another case, there was a controller that had very noisy/imprecise trackpad input, so we had to remap functionality elsewhere after players complained that it wasn't usable on that device due to its specific lack of quality.

If the only thing we could know is what kinds of buttons, etc, are provided by the controller, we wouldn't be able to effectively work around these device-specific issues. In theory, I love the idea of all of this being able to be abstracted, genericized, and black-boxed away from we developers having to care about it. But in actual practice, things are never that ideal. Two controllers may have the same affordances, but suffer from subtle differences which affect functionality in ways that are not part of the specification. Yes, nudge things in the direction of abstraction and strongly encourage that approach, but leave us a fallback when needed, because it inevitably will be.

Also, I'll reiterate, if you're really wanting to make it possible for a new controller to be introduced and it "just work" in existing games without specific support being added, then you MUST adopt a standardized method of reliably specifying the relative position and rotation of a hand relative to the controller it is holding. At least half of all VR titles use a visual representation of an actual human hand, not a visual representation of a controller, meaning they need to know where the HAND is, not the controller. And if that virtual representation of the player's physical hand doesn't sufficiently align with where their brain knows their actual hand to be, it is a VERY BAD experience. Currently, as far as I'm aware, the only way to avoid that bad experience is to know specifically which controller is in use, and to manually position the hand models relative to it.

 

Just found this thread, and wow. I did not expect it to be such a pain to simply find out what headset is connected.

I gave up on OpenXR and I'm running Valves OpenVR because it lets me build to PCVR and so far it just works. However, I still need a way to distinguish Pico and Quest.

 

@zezba9000 your github is a lifesaver. Thanks a lot for putting it out there, I was about to write something like it

 

Wut?

Code (CSharp):

1. You should try to avoid using any hardware-detection, vendor ID, or system name/ID features you may find, if at all possible. They increase the likelihood of following an untested code path, they are brittle (being unspecified or only weakly specified), and they make it less likely that your software will run reliably across different systems, and more likely that your software will either fail to run or require specific compatibility workarounds in every single XR runtime.

I just want to know the headset device model for analytics purposes, not to do anything special. How many Quest 2s vs Quest 3s vs Pico, etc. If something returns as "Generic OpenXR device" so be it - that's on me to update my app regularly to support new devices listed in the runtime.

Furthermore, if a dev writes bad code, that's on them for breaking their app by not having a fallback case (or failing to use whatever failback case OpenXR provides). I do not understand...

 

I haven't tested it, but maybe 1.9.1 added getting the device name:
https://docs.unity3d.com/Packages/com.unity.xr.openxr@1.9/changelog/CHANGELOG.html

 

So what is the current "correct way" to check input profile name using only the OpenXR package?

I'm implementing model loader based on data from https://github.com/immersive-web/webxr-input-profiles/

The Chromium browser use both interactionProfile and XrSystemProperties systemName "so that different hardware revisions can return a more exact input profile."
https://source.chromium.org/chromiu...;drc=6cb3f4d2e93ee48a13f4ef3d9e3fe32c08c66ea1
https://source.chromium.org/chromiu...;drc=4a0d413ada84db50379ab8f35ec2630cd16c800b

 

Just scroll up...
"

1. foreach (var device in InputSystem.devices)
2. {
3. if (device is KHRSimpleControllerProfile.KHRSimpleController)
4. {
5. Debug.Log("KHRSimpleControllerProfile");
6. }
7. else if (device is OculusTouchControllerProfile.OculusTouchController)
8. {
9. Debug.Log("OculusTouchControllerProfile");
10. }
11. // .. others
12. }"

The last few posters: Please stop linking weird 3rd party packages which do the entire process a different way and while asking "how do I do this with Open XR" -- you don't! You get interaction profiles like this, you use a 3rd party package which isn't OpenXR, or you use a drop down for actual controller models.

This thread is one of the only places in the Internet that actually talkes about this underlying design flaw for OpenXR, and it's gotten responses from the design group itself explaining their design choices. Most of us don't agree on those particular choices on here on this one point, but they did a great job overall. It takes years to alter a sources design document and updated a complex API like this when you have dozens of industry partners across dozens of companies in an entire industry relying upon it. From the design goals and philosophies given to us in response to this thread "https://github.com/KhronosGroup/OpenXR-Guide/blob/main/chapters/goals_design_philosophy.md" it does not sound like they intend on changing this.

 

This does not answer my question.
It is only answer 90 percent of it, which is how to get the profile. But under one profile you can have different controllers.

It is indeed "one of the only places in the Internet that actually talks about this underlying design flaw for OpenXR".
And this is why I'm asking here for the up to date solution, as I couldn't figure out from the last few comments what is the "correct" one.

You want to keep the thread short? Don't post half baked answers while asking people to stop posting.