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

I'm struggling with how to get descriptive device names in OpenXR -- this is specifically to identify which HMD the player is using to load the correct visual controller models for their headset.

With OculusSDK this code would return a useable name:

Code (CSharp):

1.  
2. // Get Headset Name
3. UnityEngine.XR.InputDevice headDevice = InputDevices.GetDeviceAtXRNode(XRNode.Head);
4. string hmdName = headDevice.name;
5.  

I know there isn't really any good method out there to find out what each headset's manufacturer internally names their piece of hardware -- making discovering all of the names for a headsets a major headache unless you already own all of them. From a variety of sources I was able to gather this list which worked well before I switched to OpenXR:

Code (CSharp):

1.  
2. /// <summary>
3. /// Static utility class contains the names of all the HMDs (I know of).
4. /// </summary>
5. public static class KnownHMDNames {
6.     // Strings may slightly differ, e.g. "Vive. MV" or "Vive MV.", and not just per OS
7.     public const string model_vive = "Vive MV";
8.     public const string model_vive_pro = "VIVE_Pro MV";
9.     public const string model_lenovoExplorer = "Lenovo Explorer";
10.     public const string model_hpWindowsMixedReality = "HP Windows Mixed Reality Headset";
11.     public const string model_samsungOdyssey = "Samsung Windows Mixed Reality 800ZAA";
12.     public const string model_acer = "Acer AH100";
13.     public const string model_rift_cv1 = "Oculus Rift CV1";
14.     public const string model_rift_s = "Oculus Rift S";
15.     public const string model_quest = "Oculus Quest";
16.     public const string model_quest_2 = "Quest";
17. }
18.  

Now whenever I run the same command as above this is what I get back (for the CV1 and Quest2):

"Head Tracking - OpenXR" ผ(•̀_•́ผ) ( ఠ ͟ʖ ఠ) ( ͡ಠ ʖ̯ ͡ಠ) .... Ugh ...

Anyone have a better method for finding out what device is attached in OpenXR?

Or even in the XRManagement parent plugin?

Being hardware agnostic is fantastic and all but this is taking it too far.

Am I up a creak without a paddle here? ... This can't be a rare thing to need to know.

 

bump

 

I understand the whole idea about OpenXR is that this is not necessary. Every maker has made sure that at least their newer devices and latest version of their platforms are somewhow OpenXR compliant. OpenXR does the matching/translation.

 

This looks good for differentiating fully separate brands of headsets, but it doesn't resolve the issue of determining within brands, e.g. the Oculus Rift CV1 controller from Quest2 / RiftS in OpenXR, as the controller are all named "Oculus Touch Controller OpenXR".

 

For raw vr specific inputs and outputs (like vibration) yes, but that's it.

You'll still need models for each controller if you'll want them in your game. Plus the logic for how to pose the player's avatar hands correctly for those controllers generally differs with the varying inputs on different controller/where that input is located. OpenXR minimized duplicate functionality, it can't necessarily eliminate it.

Another area which having deceptive full headset name is useful is automatically picking which microphone is for the connected HMD (especially if several mics/webcams/hmds are connected).

 

Omg that is going to be useful and amazing... "Downloading" the controller models directly from the plug-in API at runtime...

I had read on a few posts about the old Oculus SDK (pre XR management plugins) people signing up and using the omnibus Oculus package just to get controller models "showing up and running" in a few lines of code...

1) Do you happen to know if that was the case?

It never made any sense to me so I ignored it... I had only every used the package it when just the Rift 1 was released like 4 years ago, back then they already provided a fully animated and rigged controller model in the SDK... Which is why I was kinda shocked when they didn't release something of similar completeness/quality for the later controllers.

(Just a model w/o animations for the Rift 2/Quest 1. And for the Quest 2 just a model with a single animation you have to cut apart into dozens of clips and then restitched back together in an animator to make it useful...)

2) Is there any place that describes how those models are provided (model file formats/object setups/animator controller scripts)?

I would imagine something like an asset bundle would be necessary, but that wouldn't work between various other engines. It would have to be in a standard format like fbx... But I haven't heard of any system that can export controlling scripts for "Animator" like controllers cross engines... Just animations and skeletons/meshes.

 

Ok I think I've found a way of determining Rift 1 vs 2, it's not a huge difference but the aspect ratio of the per eye resolution for Rift 1 is 0.9 (1080 / 1200) while the aspect ratio for the Rift 2 is 0.8889... (1280 / 1440).

Edit (June 2021): Ok using the resolution aspect ratio has other problem I had not encountered when I originally wrote this, see AndreasWang's post below for details.

I think that plus the above method for using device controller type should (95%?) fix the identifying HMD problem for me.

 

At least for Oculus devices it may be possible to differentiate models using OVR. The below code should differentiate between Quest and Quest 2.

Code (CSharp):

1. OVRPlugin.SystemHeadset headset = OVRPlugin.GetSystemHeadsetType();
2. if(headset==OVRPlugin.SystemHeadset.Oculus_Quest){
3. // Quest 1 stuff here
4. }else if (headset==(OVRPlugin.SystemHeadset.Oculus_Quest+1)){
5. // Quest 2 stuff here
6. }

 

just want to track this forum

 

This is really frustrating because I need the actual controller models, not goofy looking hands for my application, and it seems like there's no way to show the proper controllers!
My other thought-of solution is to create a generic-looking controller that shows the common buttons and inputs across all controller models (touchpad/thumbstick, primary button, trigger, grip), but I can't think of a design that would work.
Any ideas?

 

I've attempted to use aspect ratios based on XRSettings.eyeTextureWidth and XRSettings.eyeTextureHeight as a means to identify the different types of oculus controllers, but it has its fair share of issues. The output of those two variables will change depending on the amount of supersampling that the user has applied through SteamVR (or other runtimes). It also seems like the scaling isnt quite uniform so you end up with slightly different aspect ratios for the same headset as the user changes their resolution multiplier.

You could potentially have a threshold that you use to test for specific aspect ratios but this feels like a very shaky solution that could result in an incorrect HMD type choice as it would need to be used for several vendors. If there is some way to fetch the base resolution of HMD instead of scaled ones then that might have helped.

Without the ability to determine the controller type, we cannot implement things like custom controller models (for example rift/quest controllers without the tracking rings at the front) and controller specific tooltips which is an requirement in my case

 

Bumping to see if anyone has any workarounds to figure out device type, is an important feature for us.

 

I've given up on attempting to automatically figure out controller/hmd type for now and instead opted to give the user a desktop dropdown where they choose the controller type. It's far from ideal, but it's better than nothing while we wait for the controller model related extensions to be implemented into the OpenXR spec. Hopefully it will get a bit easier to work with whenever that happens

 

This is the exact same thing I've fallen back to doing.

 

Turns out the HP Reverb G2 controllers report themselves to OpenXR as "Oculus Touch Controller OpenXR." Is there a way to determine the current OpenXR runtime in use? At least that way if you knew you were in a Windows Mixed Reality OpenXR session you'd know to load the Reverb G2 model.

Otherwise, I'll have to resort to the hack of measuring the distance between the grip pose and the aim pose (yeah). This doesn't work to distinguish Oculus controllers apart, as far as I can tell, but the Reverb G2 has a different aim pose from the "real" Oculus Controllers.

 

I just need to get a little rant out of my system.

With the above hacks I can fairly reliably determine that the OpenXR device is an Oculus device. I can make an educated guess that it's a Quest 2 or not, based on the display's aspect ratio. BUT you have to remember that the HP Reverb G2 also claims it has Oculus Touch controllers. So if the screen's aspect ratio > 0.925 and < 0.975 it's PROBABLY an Oculus Quest. Larger than 0.975 it's PROBABLY an HP Reverb G2. If the screen's aspect ratio is < 0.925 it's PROBABLY a Rift S or Quest 1.

BUT if Pico (for example) releases an OpenXR runtime, dollar to donuts it's going to report its controllers as Oculus Touch. Now you've got to figure out some quirk in the reported specs that let you uniquely identify the Pico. Maybe it's aim pose is also a little different from the Quest's?

Further, since you can run OpenXR apps in SteamVR with any of the above headsets, you need yet another way to identify the headset/controllers, because now you can't just rely on the name of the current OpenXR runtime and the name of connected controller.

If OpenXR is the future interface for the whole AR/VR industry, how are we going to deal with this moving forward? Say for example, I want to load low res assets for the Quest 1 and higher res assets for the Quest 2 (this isn't just about displaying correct controller models for everyone) how do I reliably handle that with OpenXR in its current state?

This idea that developers don't need to know about the device their application is running on is bananas.

This would be like if the people developing the JavaScript spec decided that nobody needs access to the userAgent string anymore. Any browser-specific quirks now have to be solved by browser vendors implementing extensions. So if div tag alignment is a little off in Microsoft Edge, just send a support request to Microsoft and they'll consider it for a fix in a future version of their browser, or not.

OpenXR simply needs to give us access to a string that tells us device model, the system its running on, and let developers get work done.

 

Have you reported this as a bug yet?

It might take them forever to fix it but that sounds like a really easy bug to address for whoever coded it.

Swapping the controllers in and out actually isn't too bad, I do it using the addressable system and it can swap out the controllers in a fraction of a second with no noticeable frame jitter.

It's basically just spawning in a new visual model which I then set as a child of a "empty holder" which I have spawning in as the "visual controller" in the standard action based controller. (I'm actually using a slightly customized one in this photo since I use my own abstraction layer on top multiple of Unity's default input processing system.)



At runtime I just check a user setting I have for which controller model is selected then I spawn in the controller like this:



For me I've decided that it's not work weeks for my time of try to hack something better together when the solution can just be addressed by a single dropdown menu.

<3.

Um.... A really good solution which doesn't use the names is listed above, I wasn't sure if you read it or not, see:

That might not get you the exact headset model or runtime, but it should get you the correct type of controller in most cases.
(Note: I haven't tested this yet.)

 

The problem is this isn't a bug. This is intentional. It looks like every XR controller that has ab/xy button layout with two joysticks is supposed to describe itself to OpenXR as an "Oculus Touch" controller so the running application knows how to map inputs. I think there are probably more controllers that do this, like the Vive Cosmo and Pico Neo 3, but I don't have those headsets to test with.

 

Ah that makes perfect sense from an input point of view.

 

This is insanely complex

 

@StayTalm_Unity I think its incorrect that OpenXR doesn't provide device/vendor details.

Looking at OpenXR Explorer (https://techcommunity.microsoft.com.../introduction-to-openxr-explorer/ba-p/2733927), all the data is there –
xrGetSystemProperties contains systemName, vendorId, and even some info when e.g. running Oculus via SteamVR.





Could this please be added to Unity's OpenXR implementation? Also, is there a workaround to get these values with the current OpenXR dll? From a cursory glance at the source it looks like (some) of the extern calls seem to be implemented but not on the C# side.

 

@StayTalm_Unity
I was just wondering what your thoughts are about what @fherbst posted above, if you've had any time to look it over yet.

 

You don't even have that, you have the button layout. See this above:

 

@StayTalm or anyone else at Unity:
Any update on @fherbst suggestions?

 

Somebody found my personal account

Unfortunately for you, I've moved on from Unity. When I left, I believe @the_real_apoxol was the most knowledgeable for that sort of question. So I tagged him in.

Best of Luck!

 

Thank you for bringing this to the point. It is an unbearable situation. Relying on resolution, refresh rates or other magic values to identify your connected hardware is absolutely nuts! There is no good reason to lock developers out from the most basic information only for the sake of abstraction.

In our application, we have hardware-specific controller models that we spawn according to the connected hardware. However, the HP Reverb 2 and Vive Focus 3 are both displayed as "Oculus Touch Controller OpenXR". For the Reverb, I was able to identify the device (roughly) using

OpenXRRuntime.name == "Windows Mixed Reality Runtime"

which is good enough for my purpose.
For the Vive Focus 3 this does not work because the runtime is "SteamVR/OpenXR" which all SteamVR devices have in common. So I have to check against the device resolution hoping that no other headset uses the same hardware resolution as the Focus. As far as I can tell, the Focus cannot even be easily distinguished from the OpenXR Explorer.

 

Dark table is 100% correct. Sure IN THEORY you shouldn't have to know, but not all controllers are the same!

Case in point: Despite Meta's dominance, Vive is still about 12% of the market.

1. Meta and Index controllers have 2 additional buttons per hand.
2. The Meta Quest's grip button has almost no resistance and can be pressed accidentally very easily. (I think it is moreso a ham-handed attempt to gauge how firmly you're holding the controller.) While for Vive its a functional and useful feeling button that you consciously press.
3. The Quest's trigger doesn't have a nice break point. Like the grip, the Quest's trigger is simply too loose, so what feels "good" as a hair trigger on the Vive can be pressed almost accidentally on the Quest. So you need to set the "hair trigger' pressure to like 80% while for Vive its like 40%.

These things mean that - frankly - we need to have branching code paths to make our games equally satisfying using different controllers. If there were some kind of manufacturing standard, where they all had to have the same buttons and the same weights on grips and triggers... then, sure, we wouldn't need to detect. But in this rapidly evolving space, its going to be some time before the "XBox Controller" of the VR world is settled-upon. Until then, we need to make code that can adapt to the peripherals, and to do that, we need to know what peripherals you're using.

If someone has a surefire solution, please let me know. Until then I guess I'll just have to ask my player at the start of the game and save their choice in settings...

 

Bump, currently also struggling with getting the HMD name. At this point, I'm considering just switching back to the SteamVR OpenVR plugin where this was no effort. (as it should be)

It's insane that we cannot get a simple device name here.

 

@the_real_apoxol or @daves would be nice to get a response here, thanks!

 

Bump

 

Bump

 

Bump

 

The reality is that this information is specifically hidden to limit user fingerprinting and empower futureproofing.

• Fingerprinting, in an app is really a moot point as C# can just read the MAC address, and current windows user name..
• Futureproofing on the other hand is a valid concern as coding to a specific model means that each time a new VR device is added, you will need to update your app to specifically support that new device or risk it not working.

While it's nice to show the user their actual equipment, the 'correct' (how dare you want to do something that Khronos says is bad) way of doing it is to iterate the connected device's inputs and dynamically assign event handlers. Unless your Microsoft who managed to add the corporate named XR_MSFT_controller_model to the spec.

What's needed is a Khronos driven spec change for the MSFT extension to be changed in favor of common vendor support. Granted I don't trust individual vendors to offer appropriately optimized/skin-able models, and the spec doesn't support LOD's for the returned model data.

That said, @fherbst indicates is that the naming data is avaliable, through the OpenXR Explorer at least so is this a Unity or Khronos group issue.

---

While it sucks for OpenXR, be glad that you don't have to develop for the WebXR offshoot of OpenXR where they specifically call out 'Fingerprinting' as a code smell, and go even further to codify identifiers out as best as they can to limit browser fingerprinting.

WebXR Spec
https://www.w3.org/TR/webxr/#fingerprinting-security

 

This is a valid point. I would actually be happy being future proof in terms of hardware. However, the data I get from different VR Controllers is not uniform enough to give people a consistent experience right now.

For example, in our app we have custom controller models for Vive and Oculus-like controllers. But because the spatial data we receive for each device corresponds to a different pose in respect to the real word controller, we have to apply individual offsets for every type of hardware. Otherwise controller models are completely off which is breaking immersion and overall feels low-quality. Maybe I'm missing something obvious here?

Another example is that every hardware controller has a different interpretation of haptic feedback pulses. What feels right for Oculus might be completely overblown for WMR. Therefore, we have to scale frequency and amplitude values specifically for each device.

There must be a proper way to deal with these kinds of issues.

 

The idea isn't to get the device name to enable functionality in the first place, it's to improve the default, cross-platform, device-agnostic experience when the device is known, for example by tuning color representation and post effects towards known display characteristics.

Regarding @hschulte 's concerns: if you're getting these hardware differences in OpenXR it would actually be bugs in Unity's OpenXR implementation or the respective vendors platform support – I believe the explicit goal of OpenXR is to abstract exactly these kinds of differences away and give you a reliable pose + haptics, besides other things. (you shouldn't need to know the device names to get matching poses + haptics)

The way I see it would be that app developers must assume not knowing anything about the device, thus fully staying future-proof, but can (not must, not should) implement device-specific improvements.

The information is available from OpenXR, it's just Unity not passing it through.

 

This is exactly the reason we need it. The displays on different headsets can vary a lot so being able to tune the colour per display is necessary if you really care about visual quality. Of course you'll have a sensible default profile (so future proofing isn't a problem) but being able to detect the most common headsets to present the game in the best possible way is really important.

This information is being provided by OpenXR, so don't blame them! It's Unity that is deciding not to expose it. You're really not helping us by blocking off parts of the API.

I've written an OpenXR feature to work around this, and it's identifying my Quest 2 ok. Hopefully it's of use to someone else.

Code (CSharp):

1. using UnityEngine;
2. using UnityEditor;
3. using System;
4. using UnityEngine.XR.OpenXR.Features;
5. using System.Runtime.InteropServices;
6. using System.Text;
7.  
8. #if UNITY_EDITOR
9. [UnityEditor.XR.OpenXR.Features.OpenXRFeature(UiName = "Get System Info",
10.     BuildTargetGroups = new[] { BuildTargetGroup.Standalone },
11.     Company = "Fireproof Studios",
12.     Desc = "Feature extension for getting system info.",
13.     DocumentationLink = "https://docs.unity3d.com/Packages/com.unity.xr.openxr@0.1/manual/index.html",
14.     Version = "0.0.1",
15.     FeatureId = featureId)]
16. #endif
17. public class OpenXRFeatureSystemInfo : OpenXRFeature
18. {
19.     /// <summary>
20.     /// The feature id string. This is used to give the feature a well known id for reference.
21.     /// </summary>
22.     public const string featureId = "com.unity.openxr.feature.example.getSystemInfo";
23.  
24.     // delegate for xrGetInstanceProcAddr() https://registry.khronos.org/OpenXR/specs/1.0/man/html/xrGetInstanceProcAddr.html
25.     unsafe private delegate ulong GetInstanceProcAddrDelegate(ulong instance, StringBuilder procName, IntPtr* procAddr);
26.     // delegate for xrGetSystemProperties() https://registry.khronos.org/OpenXR/specs/1.0/man/html/xrGetSystemProperties.html
27.     unsafe private delegate ulong GetSystemPropertiesDelegate(ulong instance, ulong systemId, void* properties);
28.  
29.     // XrSystemProperties structure https://registry.khronos.org/OpenXR/specs/1.0/man/html/XrSystemProperties.html
30.     unsafe struct XrSystemProperties
31.     {
32.         public ulong type;      // 64 bit
33.         public void* next;      // 64 bit
34.         public ulong systemId;  // 64 bit
35.         public int vendorId;    // 32 bit
36.         public fixed byte systemName[XR_MAX_SYSTEM_NAME_SIZE];
37.         public XrSystemGraphicsProperties graphicsProperties;
38.         public XrSystemTrackingProperties trackingProperties;
39.     };
40.  
41.     // XrSystemGraphicsProperties structure https://registry.khronos.org/OpenXR/specs/1.0/man/html/XrSystemGraphicsProperties.html
42.     struct XrSystemGraphicsProperties
43.     {
44.         public uint maxSwapchainImageHeight;
45.         public uint maxSwapchainImageWidth;
46.         public uint maxLayerCount;
47.     };
48.  
49.     // XrSystemTrackingProperties structure https://registry.khronos.org/OpenXR/specs/1.0/man/html/XrSystemTrackingProperties.html
50.     struct XrSystemTrackingProperties
51.     {
52.         public uint orientationTracking;
53.         public uint positionTracking;
54.     };
55.  
56.     // https://registry.khronos.org/OpenXR/specs/1.0/man/html/XrStructureType.html
57.     private const int XR_TYPE_SYSTEM_PROPERTIES = 5;
58.     private const int XR_MAX_SYSTEM_NAME_SIZE = 256;
59.  
60.     private static string SystemName = null;
61.     private static ulong XrInstance = 0;
62.     private static ulong XrSystem = 0;
63.  
64.     protected override bool OnInstanceCreate(ulong xrInstance)
65.     {
66.         XrInstance = xrInstance;
67.         return base.OnInstanceCreate(xrInstance);
68.     }
69.  
70.     protected override void OnSystemChange(ulong xrSystem)
71.     {
72.         XrSystem = xrSystem;
73.         base.OnSystemChange(xrSystem);
74.     }
75.  
76.     public static string GetHeadsetName()
77.     {
78.         if (SystemName == null
79.             && XrInstance != 0
80.             && XrSystem != 0
81.             && OpenXRFeature.xrGetInstanceProcAddr != IntPtr.Zero)
82.         {
83.             GetInstanceProcAddrDelegate getInstanceProcAddr = Marshal.GetDelegateForFunctionPointer<GetInstanceProcAddrDelegate>(OpenXRFeature.xrGetInstanceProcAddr);
84.             unsafe
85.             {
86.                 // call xrGetInstanceProcAddr() to get the address of the xrGetSystemProperties() function
87.                 IntPtr xrGetSystemPropertiesAddr;
88.                 ulong result = getInstanceProcAddr(XrInstance, new StringBuilder("xrGetSystemProperties"), &xrGetSystemPropertiesAddr);
89.  
90.                 GetSystemPropertiesDelegate getSystemPropertiesAddr = Marshal.GetDelegateForFunctionPointer<GetSystemPropertiesDelegate>(xrGetSystemPropertiesAddr);
91.                 if (xrGetSystemPropertiesAddr != null)
92.                 {
93.                     // call xrGetSystemProperties()
94.                     // the properties structure needs to have the type initialised otherwise xrGetSystemProperties() fails
95.                     XrSystemProperties properties;
96.                     properties.type = XR_TYPE_SYSTEM_PROPERTIES;
97.                     result = getSystemPropertiesAddr(XrInstance, XrSystem, &properties);
98.  
99.                     // convert the name from an array of bytes to a c# string
100.                     SystemName = "";
101.                     for (int charIndex = 0; charIndex < XR_MAX_SYSTEM_NAME_SIZE; charIndex++)
102.                     {
103.                         if (properties.systemName[charIndex] == 0)
104.                         {
105.                             break;
106.                         }
107.                         SystemName += ((char)properties.systemName[charIndex]);
108.                     }
109.                 }
110.             }
111.         }
112.         return SystemName;
113.     }
114. }
115.  
116.  
117.  

It uses unsafe code so it's best to put it in an assembly by itself so you don't need to enable unsafe code on your main assembly. You'll need to enable the feature in Project Settings -> XR Plug-in Management -> OpenXR -> Tick "Get System Info". Then you can just call
OpenXRFeatureSystemInfo.GetHeadsetName() to get the system name reported by OpenXR.

 

Thanks for the info. It's not just the color space though, some displays suffer from smearing with low brightness so we choose to remap the color to avoid these issues. We're not particularly technical about it, we just provide tools so that the color can be tweaked per headset and then let the artists adjust it by eye. I imagine whether you would want to do that would depend on the content, smearing is usually only a problem in dark or high contrast scenes.

This is what we're getting at: although it would be amazing if everything worked perfectly across all headsets without us having to worry about it, that's just not the reality. Unfortunately we do sometimes need to know what headset is being used, and so it's frustrating when that information is hidden. It's also impossible for Unity or OpenXR to anticipate and fix any issues that might arise for any headset ahead of time, especially if some of these issues are dependent on the content.

Thanks for pointing us in the right direction.

 

This may be of value if you want to know the OpenXR hardware "UnityEngine.XR.OpenXR.OpenXRRuntime.name".
Reports Oculus on Rift S for example.

 

I was finally able to differentiate Quest 1 from Quest 2 with SystemInfo.deviceName. Not sure what other devices give with that, though.

 

This is great, thank you. I 've tried adding it to it's own assembly using an asmdef as suggested, but when I do I loose the editor entry for the feature. Any insight is appreciated.

Edit - Figured it out
To make dsmeathers feature function as it's own assembly, you need to not only follow unity's tutorial on adding an asmdef file, but also need to manually define Unity.XR.OpenXR and Unity.XR.OpenXR.Editor as assembly definition references.

To add these references, uncheck 'Use GUIDS' on your asmdef assembly file and add two entries. Next drag and drop he two previously named assemblies from your Packages > OpenXR Plugin > Runtime, and Packages > OpenXR Plugin > Editor folders.

Edit 2 - Sadly
Looks like 'they' khronos nuked the ability to use device properties. When querying the OpenXR API directly I get the following, less than useful information. (I don't have enough unique devices to generate a meaningful matrix of system and vendor Id's)

Spoiler: Properties

===================
SteamVR - Vive Pro
===================
systemId: 1152980740795793747
vendorId: 10467
systemName: "SteamVR/OpenXR : lighthouse"

======================
SteamVR + WMR - HP G2 - Crashes SteamVR
======================
systemId: 1152967477936783641
vendorId: 10462
systemName: "SteamVR/OpenXR : holographic"

======================
WMR - HP G2
======================
systemId: 1
vendorId: 1118
systemName: "Windows Mixed Reality"

 

Bother, this is really bad for my use case.

I am doing user experiments on visual quality (among other things), and we use various headsets in addition to varying various other parameters (to compare the quality).

It is essential that we record the headset used in our output data, because if we publish results they should be repeatable, and if someone distrusts our measurements in five years I need to be able to show that I have recorded all the essential parameters.

 

I have noted that the OpenXR interaction profiles for each device do supply a name when InputSystem.RegisterLayout is called, but that name is at the pure whim of whoever last created the profile, and seems to change between packages.

You could modify the device profile file for each device you include to give you more useful device names, then extract that device name from the currently assigned InputActions profile.

Some profile files are located in your project directory after adding the OpenXR package. (Library\PackageCache\com.unity.xr.openxr@1.4.2\Runtime\Features\Interactions)

An Example, using the HP Reverb G2 WMR device profile:

Code (CSharp):

1.  //com.microsoft.mixedreality.openxr
2. //\Runtime\FeaturePlugins\HPMixedRealityControllerProfile.cs
3.  
4. //Around line #47
5.  private const string kDeviceLocalizedName = "HP Reverb G2 Controller OpenXR";
6.  private const string kDeviceDisplayName = "HP Reverb G2 Controller (OpenXR)";
7.  
8. //Around Line 273
9.  ActionMapConfig actionMap = new ActionMapConfig()
10.             {
11.                 name = "hpmixedrealitycontroller",
12.                 localizedName = kDeviceLocalizedName,
13.                 desiredInteractionProfile = profile,
14.                 manufacturer = "HP",
15.                 serialNumber = "",
16.  

It's not perfect as unity makes an educated guess as to which profile to load, but may help with your inernal device testing regime.

 

Just a reminder that the SteamVR OpenVR plugin is up-to-date on the asset store, and seems to work in Unity 2021.3. "OpenVR Loader" just shows up as another option in the "XR Plug-in Management" tab of project settings. As author of an application that supports a range of headsets and controllers that were always well-supported by SteamVR, this is definitely the best solution for me.

 

Well I ran into this issue as well. The Vive controllers and Oculus controllers have different angles and I need to know what angle to set the player's hands at. If there is no way to figure out what controller is being used, this is gonna be a pain in the butt.

 

Any news on this?
Especially on Pico 4 there is no info that I could use to detect controllers...

 

For me today after upgrading to 2022.2.2f1 with all of the automatic package upgrades, this script has stopped working for me and I had to disable it. The new changes which were introduced with the automatic upgrade from 1.5.3 to 1.6 (xr.openxr) should not be considered safe with the current workaround.