Search Unity

  1. We are migrating the Unity Forums to Unity Discussions. On July 12, the Unity Forums will become read-only.

    Please, do not make any changes to your username or email addresses at id.unity.com during this transition time.

    On July 15, Unity Discussions will become read-only until July 18, when the new design and the migrated forum contents will go live.


    Read our full announcement for more information and let us know if you have any questions.

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

Discussion in 'VR' started by colinleet, Feb 4, 2021.

?

Does your code need to know headsets your player is using?

  1. Yes

    250 vote(s)
    91.6%
  2. No

    19 vote(s)
    7.0%
  3. I liked how thing were in 2020.

    3 vote(s)
    1.1%
  4. Oh cool the hacked here might be actually work great for me!

    1 vote(s)
    0.4%
  1. fiwon123

    fiwon123

    Joined:
    Jul 11, 2018
    Posts:
    116
    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?
    upload_2023-3-9_14-20-17.png

    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
     
  2. thep3000

    thep3000

    Unity Technologies

    Joined:
    Aug 9, 2013
    Posts:
    400
    We brought the feedback from you all to the OpenXR working group. As an outcome of that, this document was drafted which describes the design and philosophy of why OpenXR is changing the way you get at device names and what your app should do instead. Please take a look and if you have clarifying questions either post them here or on that github as issues. https://github.com/KhronosGroup/OpenXR-Guide/blob/main/chapters/goals_design_philosophy.md
     
    DevDunk and fiwon123 like this.
  3. Cloudwalker_

    Cloudwalker_

    Joined:
    Jan 3, 2014
    Posts:
    141
    The tldr on openxr stance. Do what we want, not what developers actually want and need. Ridiculous.
     
  4. fiwon123

    fiwon123

    Joined:
    Jul 11, 2018
    Posts:
    116
    Hi, @thep3000

    Thanks for the response. I read the documentation and I found what I need one this section:
    upload_2023-3-9_15-24-7.png

    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
    upload_2023-3-9_15-25-0.png

    Kind Regards,

    Felipe inoue
     
    Last edited: Mar 9, 2023
  5. fiwon123

    fiwon123

    Joined:
    Jul 11, 2018
    Posts:
    116
  6. rpavlik-collabora

    rpavlik-collabora

    Joined:
    Sep 16, 2020
    Posts:
    1
    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)
     
    Last edited: Mar 9, 2023
  7. fiwon123

    fiwon123

    Joined:
    Jul 11, 2018
    Posts:
    116
    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
     
    Last edited: Mar 13, 2023
  8. thep3000

    thep3000

    Unity Technologies

    Joined:
    Aug 9, 2013
    Posts:
    400
    Example of checking which interaction profile is being used in unity:

    Code (CSharp):
    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. }
    Note that there will be a "device" for both left hand and right hand.
     
  9. thep3000

    thep3000

    Unity Technologies

    Joined:
    Aug 9, 2013
    Posts:
    400
    You may also want to check based on device changed, incase the active interaction profile changes you'll get notified:

    Code (CSharp):
    1. InputSystem.onDeviceChange += (device, change) =>
    2. {
    3.     if (change == InputDeviceChange.Added)
    4.     {
    5.         if (device is KHRSimpleControllerProfile.KHRSimpleController)
    6.         {
    7.             Debug.Log("KHRSimpleControllerProfile");
    8.         }
    9.         else if (device is OculusTouchControllerProfile.OculusTouchController)
    10.         {
    11.             Debug.Log("OculusTouchControllerProfile");
    12.         }
    13.         // .. others
    14.     }
    15. };
     
  10. fiwon123

    fiwon123

    Joined:
    Jul 11, 2018
    Posts:
    116
    Hi, @thep3000,

    Thanks, I'll try here :D

    Kind Regards,

    Felipe Inoue
     
  11. fiwon123

    fiwon123

    Joined:
    Jul 11, 2018
    Posts:
    116
    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.     }
     
    thep3000 likes this.
  12. Cloudwalker_

    Cloudwalker_

    Joined:
    Jan 3, 2014
    Posts:
    141
    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.
     
  13. colinleet

    colinleet

    Joined:
    Nov 20, 2019
    Posts:
    193
    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.
     
    Last edited: Mar 14, 2023
    glenneroo likes this.
  14. fiwon123

    fiwon123

    Joined:
    Jul 11, 2018
    Posts:
    116
    Hi, @thep3000,

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

    Kind Regards,

    Felipe Inoue
     
  15. colinleet

    colinleet

    Joined:
    Nov 20, 2019
    Posts:
    193
    All Oculus/Meta headsets, and some not by Meta, use the OculusTouchControllerProfile.OculusTouchController
     
    fiwon123 likes this.
  16. RiverExplorer

    RiverExplorer

    Joined:
    Jul 28, 2021
    Posts:
    23
    Until the user wants to know what button to press and their controller does not have "Primary" printed on it.
     
    lloydsummers and ElasticSea like this.
  17. NNighteyes

    NNighteyes

    Joined:
    Jul 9, 2017
    Posts:
    5
    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?
     
  18. NNighteyes

    NNighteyes

    Joined:
    Jul 9, 2017
    Posts:
    5
  19. areepen

    areepen

    Joined:
    Aug 28, 2017
    Posts:
    7
    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 :(
     
  20. DevDunk

    DevDunk

    Joined:
    Feb 13, 2020
    Posts:
    5,251
    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 :p
     
  21. Develle

    Develle

    Joined:
    Jan 18, 2023
    Posts:
    4
    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?
     
  22. Tanya_Li

    Tanya_Li

    Unity Technologies

    Joined:
    Jun 29, 2020
    Posts:
    109
    maybe
    Code (CSharp):
    1. public static SystemHeadset GetSystemHeadsetType()
    in OVRPlugins.cs using Oculus Integration Asset?
     
  23. chrpetry

    chrpetry

    Joined:
    Mar 7, 2018
    Posts:
    67
    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.
     
  24. zezba9000

    zezba9000

    Joined:
    Sep 28, 2010
    Posts:
    1,004
  25. chrpetry

    chrpetry

    Joined:
    Mar 7, 2018
    Posts:
    67
  26. zezba9000

    zezba9000

    Joined:
    Sep 28, 2010
    Posts:
    1,004
    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.
     
  27. colinleet

    colinleet

    Joined:
    Nov 20, 2019
    Posts:
    193
    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.
     
  28. zezba9000

    zezba9000

    Joined:
    Sep 28, 2010
    Posts:
    1,004
    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?
     
    Last edited: Jul 25, 2023
  29. Brady

    Brady

    Joined:
    Sep 25, 2008
    Posts:
    2,478
    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.
     
    AndreasWang, colinleet and DevDunk like this.
  30. Brady

    Brady

    Joined:
    Sep 25, 2008
    Posts:
    2,478
    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.
     
    RazNayr likes this.
  31. cecarlsen

    cecarlsen

    Joined:
    Jun 30, 2006
    Posts:
    874
    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.
     
  32. Autarkis

    Autarkis

    Joined:
    Oct 10, 2011
    Posts:
    319
    @zezba9000 your github is a lifesaver. Thanks a lot for putting it out there, I was about to write something like it :p
     
    zezba9000 likes this.
  33. dustin_tripp

    dustin_tripp

    Joined:
    Apr 20, 2023
    Posts:
    15
    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...
     
  34. DevDunk

    DevDunk

    Joined:
    Feb 13, 2020
    Posts:
    5,251
  35. De-Panther

    De-Panther

    Joined:
    Dec 27, 2009
    Posts:
    591
    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
     
  36. colinleet

    colinleet

    Joined:
    Nov 20, 2019
    Posts:
    193
    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.
     
    Last edited: Nov 7, 2023
  37. De-Panther

    De-Panther

    Joined:
    Dec 27, 2009
    Posts:
    591
    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.
     
    cecarlsen and Arnold_2013 like this.
  38. colinleet

    colinleet

    Joined:
    Nov 20, 2019
    Posts:
    193