Search Unity

Resolved Is Unity leaving support for OpenVR entirely?

Discussion in 'VR' started by Flamacore, Jan 4, 2020.

  1. Flamacore

    Flamacore

    Joined:
    Dec 17, 2013
    Posts:
    140
    According to the manual page for 2019.3, the list below does not contain any OpenVR platform or device. Does that mean Unity is cutting support to OpenVR? What to do with gazillions of HTC Vives and other OpenVR device games/apps made with unity I wonder? Custom made, non-official plugins?

    Strange choice to me, if it's actually a choice. If this is the case, any guides, ideas or solutions to use for the future? I mean right now, even if it's deprecated, we can still use it nonetheless but what to do when 2020 hits?

    Ref: https://docs.unity3d.com/2019.3/Documentation/Manual/XR.html
     
    jashan, BlackDragonBE and ROBYER1 like this.
  2. ROBYER1

    ROBYER1

    Joined:
    Oct 9, 2015
    Posts:
    1,454
    https://forum.unity.com/threads/xr-plugins-and-subsystems.693463/page-3#post-5336781

    Developers with existing OpenVR projects should develop their VR apps using Unity 2018.4 LTS.

    Unity 2019.3 and 2019.4 LTS still offer built-in support for Open VR, but bugs and issues might not be prioritized and the package will be removed in future releases.

    More information regarding an OpenVR XR Plugin for Unity will be added at a later date.
     
    jashan likes this.
  3. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    That last sentence in particular, I find very concerning, as well as the recommendation to not even update to Unity 2019 when developing using OpenVR. Plus Unity staff being completely silent on this despite the frequent questions about OpenVR/SteamVR in various forum postings.
     
  4. ROBYER1

    ROBYER1

    Joined:
    Oct 9, 2015
    Posts:
    1,454
    I wouldn't worry too much honestly just wait and see, the documentation mentions it will be updated when ready.
     
  5. ROBYER1

    ROBYER1

    Joined:
    Oct 9, 2015
    Posts:
    1,454
    Blogpost about it coming January 23rd apparently
     
  6. bngames

    bngames

    Joined:
    Jul 3, 2012
    Posts:
    67
    So Unity will not support HTC, Index, Cosmos - Unity needs to support all hardware out of the box, old and new!!!!!!!!!!!
     
  7. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    Valve does have an UnityXR Plugin: https://github.com/ValveSoftware/unity-xr-plugin

    And there's also a version 2.6 of the SteamVR Unity Plugin that works with UnityXR: https://github.com/ValveSoftware/steamvr_unity_plugin/releases

    There are other issues you might run into when using UnityXR, so personally, for the time being, I'm staying away from it (I'm using Unity 2019.4 LTS, with the old approach, and it still works quite well).

    EDIT: Fixed type - "Valve does not have" was not what I wanted to say ;-)
     
    Last edited: Jul 30, 2020
  8. a436t4ataf

    a436t4ataf

    Joined:
    May 19, 2013
    Posts:
    1,933
    Was the "not" in that first sentence a typo?
     
    jashan likes this.
  9. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    Ooops, yeah, that was the opposite of what I wanted to say. Fixed it. Thanks for letting me know!
     
  10. Regulus343

    Regulus343

    Joined:
    Jul 4, 2013
    Posts:
    11
    I'm in the same boat as you. 2019.4 LTS, and I just upgraded over the past 2 days only to switch back. My reason was that "single pass" rendering is gone in favor of "single pass instanced", and so the water shader my project depended on was no longer working. "Multi pass" means a CPU performance sacrifice, and the WMR plugin doesn't have that, so WMR players would still not see the water correctly. So like you, I'm going to stay away from it for awhile and wait for it to truly be worthy of deprecating the legacy system.
     
    jashan likes this.
  11. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    Yup, same issue here. Moving to Single Pass had already been a major pain and it took a year or two until everything worked properly with Single Pass. Now that it's all working, Unity says "oh, you know, we don't support this anymore, change everything again."

    I can imagine that Single Pass Instanced does give us a significant performance boost over Single Pass ... but simply deprecating Single Pass seems like an incredibly lazy move from UT. But now that it's subscription based, they can get away with it. Except, people that had loved Unity for many many years are starting to hate the corporation with passion.
     
    Cynicat likes this.
  12. FlightOfOne

    FlightOfOne

    Joined:
    Aug 1, 2014
    Posts:
    668
    Now you can add the 'not' back in :)

    This is from the link below:

    https://github.com/ValveSoftware/unity-xr-plugin/issues/16
     
  13. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    That's not surprising, though. SteamVR Input is genius, Unity XR Input is "nice try, try again". If I ever update to Unity 2020.x, I'll have to see if there's a convenient way to use SteamVR Input for SteamVR, and "whatever-input-Unity-supports-for-VR-then" for native Oculus and other VR platforms (as long as the native SDKs let me directly access the buttons, like Oculus currently does, I don't see much need to use Unity XR Input for our project). For the time being, SteamVR will probably be the only VR platform that lets players remap the bindings.
     
  14. jamie_xr

    jamie_xr

    Joined:
    Feb 28, 2020
    Posts:
    67
    I wouldn't describe it as genius. The principle of abstracting input into actions that can be remapped easily to multiple controllers and providing a common api between devices is a good one. However.....

    That abstraction and shared API should come at engine level. Having the abstraction at that level assumes you are only building a game for SteamVR. Which a lot of people aren't. So I can do all this nice abstraction, define my actions and so forth for SteamVR. Now I have to go to oculus quest/oculus desktop. Guess what, all that work needs to be done again, and piped into another layer of input so my app can have a common API everywhere. I used rewired, so I will do this anyway, Rewired has all the same features as the SteamVR input system. I can just read actions from rewired. From my 3rd party sdks all I want is a low level "is button pressed API", and feed that into whatever I need.

    So my only real choice here is make actions for each button for each controller, and feed the actions into rewired, (making the whole thing obsolete).

    SteamVR's input system maybe great in it's own isolated context. To support open VR I need to import a unity package > 1500 files of bloat, Do loads of actions/binding (effectively binding every button itself) just get "is button pressed".

    How hard is for them to just support the XR Input at a basic level? If anybody has a workaround, another way to bind them or anything, that would be so helpful
     
    FlightOfOne likes this.
  15. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    In general, I agree with you. But you are missing one very important point here: What SteamVR offers is not just an abstraction that is useful for developers - but also for the actual players. And this is why I disagree with:

    ... because the "engine level" can never deliver customizability for players that is independent of game, and even game engine.

    Now, if Unity was properly collaborating with Valve, what they could do is have a system on the engine level that is compatible with the platform level solution that Steam / SteamVR offers.

    That would be the right thing to do it because then we, as developers, would have the best of both worlds, and ...

    ... would be as easy as you seem to think. They have tried and due to the way Unity has designed XR Input it just didn't work.

    There's more to it ... SteamVR / OpenVR does not only define button mappings but also has a really awesome way of handling skeletal input that could even be used with Oculus' handtracking - if Unity was using its position as engine provider for its actual users. You can still do it - but it's much much much harder than it should be.
     
    jamie_xr likes this.
  16. jashan

    jashan

    Joined:
    Mar 9, 2007
    Posts:
    3,307
    The funniest (or actually, sadest) thing about this: If you use legacy render pipeline, you cannot use PostProcessing with Unity's new XR plugin framework. All you get is a grey screen. And that's the case for 2019.4, 2020 and 2021 (see also my answer on Grey screen when using post processing stack V2 in VR Question).
     
  17. ROBYER1

    ROBYER1

    Joined:
    Oct 9, 2015
    Posts:
    1,454
    This is bad news, URP still has many bugs for me
     
  18. FlightOfOne

    FlightOfOne

    Joined:
    Aug 1, 2014
    Posts:
    668
    It's great you had such success with SteamVR but having used SteamVR on a title and spent a good amount of time with it, I am doing everything I can to steer away from Steam VR on my current project. In my case, neither myself (as the developer) or the players have a good time with it.

    In my new project I check to see if they are on a Valve device and if they are then I use SteamVR (with a wrapper, so I can ditch it without ever noticing it was there), if not I use the new input system. Hopefully, by the time I publish, they will have this resolved and I can simply move to the new Input System entirely. So far new input system has been a dream come true (except for SteamVR nightmare).

    Don't get me wrong I really liked SteamVR early on when there were only 2 devices on the market and my scope was much smaller. But trying to extend or do anything remotely beyond what is built into steam VR is not pleasant. Did not scale well at all! And trying to troubleshoot was an absolute nightmare too. Don't even get me started on how bloated that package is.

    My biggest scare was/is SteamVR updates, every time they did something, you had to adapt to that version and sometimes things just broke.

    On the contrary Unity, Input has been far more extendable and reliable for me. Also if you want to publish to the Oculus store you cannot use SteamVR.

    You definitely can customize/rebind with the Unity Input system. You just have to do the work yourself and create an in-game binding system vs SteamVR doing this for you outside of the game.

    https://docs.unity3d.com/Packages/c.../manual/ActionBindings.html#runtime-rebinding

    I think "independent" is irreverent because bindings are still very much tied to your game via game profiles. I just can't think of a use case for this. Only benefit I can think of is players can share the bindings, but then again you can do that with unity bindings too, they are just json files. I'd like to hear more, if you have any others.

    At the end of the day, I guess it really depends on your project and use cases -no one size fits all. If you just want to publish to Steam Store and want simple controls or do not need to scale beyond SteamVR, then yes maybe Steam is the way to go, especially if you're a new developer. They provide you with all these great solutions out of the box, such as the skeleton and finger tracking, etc... So you do not need to implement these on your own.

    My personal stance is, input should be handled by the engine, not by some 3rd party software that the engine or the 3rd party can't guarantee support for. I think people should give the Unity Input system a try. It has come a long way since the early, buggy days. And I think it (along with URP) is here to stay and not sure how long Unity would support the legacy input and the Render Pipeline. Better to be prepared if you ask me.

    Also, if you guys haven't seen, take a look here:https://forum.unity.com/threads/unitys-plans-for-openxr.993225/ I think it will finally happen!
     
    Last edited: Nov 4, 2020
  19. jamie_xr

    jamie_xr

    Joined:
    Feb 28, 2020
    Posts:
    67
    I ended up going with the wrapper solution similar to "Tony's Hack" described here. So when requesting buttons & axis, we check the common usages requested, if we are in steam VR, we use a steam vr binding. This won't be great for the user since they can bind to actions with names like "Trigger" "Primary Button" "Secondary Button". But it allows us to control bindings at our end. Non SteamVR code path just hits the UnityEngine.XR.InputDevice APIs as normal. It's annoying that we have to create a wrapper and a whole bunch of bindings in another system to bind them to our Rewired Actions, but there we go!

    Also, my first impressions of the steam vr plugin was not great, after using it for a while... my suspicions are confirmed. The GUI is a janky mess, Ugly, Terrible UX, and extremely buggy. Every time I open the window I feel like the whole project/bindings are just gonna break.