Unity XR Input / Unity Input System not working #16
Comments
|
Unfortunately we were unable to find a good compromise between the Unity Input System and OpenVR (legacy input). Additionally, further work on that front is prolonging access to OpenXR. This means Unity XR Input (or Unity Input System) will not work with this OpenVR plugin. We're now directing our efforts towards OpenXR. You can read more about this decision in general here: https://store.steampowered.com/newshub/app/250820/view/2522527900755718763 |
zite
changed the title
|
@zite So does that mean the will be a future version of this or another plugin that will support Input via OpenXR which will work with the Unity XR Input? It's nice having a single input system that works for Oculus, WMR and PSVR. We used to use VRTK to facilitate input across the various platforms, but that is no longer a viable solution. |
|
A single input system is definitely the goal. We'll either support or work on a plugin that enables vr developers to target one cross platform api. But, it won't be in this plugin. |
|
@zite what do you mean it won't be in this plugin? isn't the whole purpose of this plugin to support the Unity XR Tech Stack (https://docs.unity3d.com/Manual/XRPluginArchitecture.html)? What's the purpose of having this plugin if that doesn't work? The XR Interaction Toolkit also depends on the Input subsystem, so it won't be working if the Input subsystem doesn't. |
|
Am I understanding this correctly: There's nothing at the moment that will let me use an Valve Index with Unity 2020.1? |
SteamVR works great with the normal SteamVR Unity Plugin (that adds this plugin automatically). You'll need to use the beta here for now though: https://github.com/ValveSoftware/steamvr_unity_plugin/releases/tag/2.6.0b3 |
|
Cool, Thanks! |
We're handling input through our own plugin while we work with Unity on a solution to get their input system working with modern input standards (OpenVR / OpenXR). |
|
@zite so how do you suggest the XR Interaction Toolkit should be used if that depends on Unity Input? |
|
I found that the XR Interaction Toolkit works with SteamVR on Unity 2019.4, it still has legacy VR support. (Don't install any OpenVR plugins, just tell Unity in Project Settings you want OpenVR support.) It won't work on Unity 2020.1 because that requires the new OpenXR. But assuming the OpenXR ends up getting updated, you can just develope on 2019.4 for now and upgrade when it's available. |
|
@kendrome but can you still use XR Plugin Management then to target other platforms? otherwise there would be no point in using the XR Interaction Toolkit, no? I wanna add: This is a huge mess. As I understand OpenXR doesn't even have the device plugin interface yet (so what's the point without it?). Why always deprecating an unfinished solution while the next one is still not yet ready instead of once finishing a thing? |
|
@zite OpenVR is supposed to be a superset of what the unity plugin architecture provides right? On the previous repo input was almost working. I'm not saying to postpone OpenXR but a lot of developers with titles on the market right now could double their reach instantly if basic controller support was provided. And players could enjoy more games. Later on you can probably switch them transparently to OpenXR via the unity plugin. It may be a little more work and seem redundant to you but it will be beneficial for many so It's a worthy cause imho |
I second that, especially since it was working fine before splitting the repository out from the steamvr_unity_plugin.git#UnityXRPlugin branch (at least for VIVE that is). Can‘t you just re-add the same kind of controller input that you had working before splitting the code into its own repository? We use the OpenVR plugin only to target the VIVE and I understand that maybe other OpenVR compatible devices don‘t map the input well - but the Quest and the Vive are the two most important headsets to target and it must be possible to use the Unity XR Plugin architecture to target them both. This is more important than having all possible OpenVR compatible devices map their input well (important too for the future, agreed, but don‘t remove a feature that was working well for the most important device class just because it doesn‘t work optimally yet for less important ones) |
|
Actually if you just made sure that this plugin works with the vives and the index we have full coverage along with the existing oculus and wmr plugins. Sure it won't be the ideal but right now VR is still a developing market and we need all the reach we can get. We are also mostly indies doing it and short of resources. I'm sorry to be blunt but at this point giving us something crude to work with is more important than standards. I dare to say that the livelihood of small studios is at stake here |
Just to confirm, with this you do not need XR management + Valve XR plugin either? @kendrome |
It works without the XR plugin from Valve. I'm using the depreciated XR Settings under Player Settings. I'm able to use the XR Interaction Toolkit with both SteamVR and Oculus in the same project. It looks like when you enable OpenVR it installs the OpenVR Desktop plugin from Unity, so doesn't really use OpenXR, but should provide a direct upgrade. |
|
Seems to me like this stance is the exact opposite of wanting to support the OpenXR standard. Instead you want to change the standard to fit your own legacy system. And in the mean time you leave everyone with no choice but to put in a bunch of extra work to support your legacy system, a choice which is made even harder by not providing any ETA on when yet another change to the input system might happen. And the whole situation is even worse for those of us who already started using this OpenXR plugin for input when it was first working, only to have it pulled later. |
|
@halfpasttense Just to set the record straight I think there's some confusion here: The unity XR plugin architecture has nothing to do with OpenXR and open standards. It is a strictly unity thing, a good option to have in my opinion. OpenXR is essentially the steamvr architecture made into a standard. I had to use it to get full coverage of hmds on steam and I can now say that it's good. That being said, right now I have to maintain two different projects. One for oculus and one for steam. There's just no way that the middlewares from both can coexist. If someone has managed to do it I'd love to hear how. It's not a good situation for developers right now, but at least OpenXR is coming to ease things up. In the meantime, it would certainly be feasible to implement the full unity xr functionality on top of SteamVR which IS a superset. I think the main problem the devs encountered and made them decide to go half way was the disparity of the anchor of the action poses. There were some issues where hands in the virtual world would seem displaced. Unity seems to be utilizing what SteamVR calls the "tip" or "raw" pose/anchor by default. For my project the "grip" pose made more sense for controlling hands so in steam I use that and correct for oculus. Still, I think it would certainly be possible to craft an actionset and bindings in SteamVR to handle the most common controllers and provide an adequate solution for now. Standards are good when they help shipping projects faster and better. And right now OpenXR cannot help with that, maybe in some months but we don't all have the luxury of waiting it |
|
@wizgrav ah, I see. I thought The Unity XR Plugin system was Unity implementing the OpenXR standard from the engine side, but it appears I was mistaken. Regardless, not supporting the XR Plugin system for controller input is still a giant pain in the ass right now. Your explanation of why they may have chosen not to support it doesn't make sense to me. What do action poses have to do with simply getting the damn inputs off controllers? I don't even care about action poses. Also, they DO provide controller positional tracking data... They just refuse to provide the controller inputs. And also I'll reiterate that they had a version that had controller inputs and it worked fine. In fact I still have that version and am still using it for testing because I haven't had the time or the will to go back to their damn legacy plugin. Unfortunately I can't continue to use this old version of the XR plugin because while it works fine running in the Unity editor, it doesn't work at all when compiled to a standalone app. If they still provided the controller input I could get away with having almost 0 code difference between building for Oculus vs building for SteamVR. As you stated, the only difference is a slight adjustment to the controller placement depending on the platform. My guess as to why they don't want to support input is because they want developers to adopt the full SteamVR binding system that binds in game actions to inputs, instead of just listening for raw inputs. It's a pretty lame reason, and that choice should be left up to the developers, not forced on them. |
|
Action poses are a rather nifty feature in steamvr where you can tell the middleware to report the rotation/translation for a specific part of the controller like the base or the tip. You could achieve the same with a simple transform of your own but still is a good feature. In general the transition from steamvr->OpenXR should be pretty straightforward, valve wrote the standard for the most part from what I can tell. Even though we are on the same page and I feel we are not treated well. I still suggest you to take a little time to use the functionality provided by steamvr for now. You can use the tracked pose driver component for the head and the steamvr plugin provides a SteamVR_behavior_pose which works more or less like the tracked pose driver for the controllers. For key input you'll need to fiddle a bit with the bindings tool included in steamvr. From the code side you get simple getters to check the state of buttons and some niceties like being able to tell to joysticks to report like dpads which saves you the trouble of parsing the analog values yourself(if you actually need them to behave like that and not that it would be that hard to do manually but it's a nice feature nevertheless) It's not a big hassle overall, if you need help feel free to pm me. I have to warn you though that I haven't yet managed to have a single project that produces builds for both oculus and steam so I suggest you to do the same split |
I've never had a problem with them co-existing, what kind of trouble are you having that forces the two projects? The only thing I have to do is when building for Oculus is to exclude the SteamVR dlls that I use for Steamworks. If I didn't use Steamworks then same build works for submitting to both Steam and Oculus. With the Unity XR Input it's easier than it used to be when I had to rely on VRTK. The platform specific code is really minimal now. The only thing is I have to stay on Unity 2019 until Valve updates the plug-in to support XR input. |
Yes its to be used with this repo. Because Valve doesn't support Unity3D's generic/agnostic input system like Oculus does, it exposes OpenVR's existing Input system (thats modeled correctly & been around since day one) or Unity3D's Input system through its own generic/agnostic layer. In short enable SteamVR/OpenVR input when publishing to Steam store or disable it & it falls back to Unity's input system that supports Oculus, etc |
I see, so that means I have to manually enable/disable it based on the platform (Oculus or Vive) I'm running it on, correct? the same build won't work on both platforms automatically until Valve gets around to fixing inputs in this plugin and we no longer need to use your repo. Is my understanding of the situation right? thanks loads for sharing your solution btw, I'm desperately trying to figure out what I'm supposed to use right now to support both Oculus and Vive since none of the OpenXR stuff seems to be ready. |
Yes thats correct. While I could update & add support for this & auto detect what platform Unity has init, its actually a bad idea in general. If you have for Example Oculus store/services running but try to play a game using Oculus with SteamVR... Unity3D gets very confused & triggers something in OpenVR inputs layer to stop working. This situation is actually rather common so its best make builds & publish for a specific platform. Compile once run-everywhere is a failed concept in general for a lot of situations IMO. |
|
If you're looking for cross platform support I would take a look at unity's openxr plugin. That supports both oculus and steamvr in one plugin. It is still in development, but there's a preview linked above: https://forum.unity.com/threads/unity-support-for-openxr-in-preview.1023613/ |
|
Also I will add OpenXR support to the agnostic Input layer later which avoids needing to change game code yet again to a new Input system. Native OpenXR input solutions are going to be far more verbose anyway. |
|
The point of OpenXR is to be a singular platform agnostic layer. Otherwise people like you (and me at a previous company) have to continuously update their abstraction layer whenever any of the supported plugins have a change. If you happen to stop updating it for some reason, it may stop working (like mine did). All the major vr companies are moving towards OpenXR to solve these problems. Also, utilizing legacy input as you suggest, finger tracking data will not be available to you as those functions require SteamVR Input. But of course, you're welcome to make your own thing if our options aren't working for you. |
Naturally this would be the ideal plugin to use. But it's been released for a month and is still in preview only (Vive and Oculus aren't even considered officially supported devices, you can't deploy to the Quest, and users are reporting all sorts of bugs on the forums still), so it's barely useable. Unfortunately I need to start a project right now and don't have the luxury of waiting for OpenXR to mature. |
Ah, that is unfortunate. Hopefully those issues will be resolved soon. |
Are there still plans to support controller inputs with this Unity XR Plugin from Valve? Or are we just going to have to wait for Unity's OpenXR Plugin to mature? |
This is the argument people made for OpenGL or Vulkan. Its simply doesn't hold true. Of course it depends on your targets. Not everyone uses OpenXR like Pico for example & if you're on Unity LTS OpenXR isn't a solution either. Also OpenXR is not structured in a simple way from what I've seen (unless mistaken its over engineered to solve problems people don't have such as rigging structures etc better suited as frameworks). Input APIs have been done correctly since the 80s (button bit-fields & axis values with extra meta-data if needed and thus IDK what ppl are thinking with this new stuff to be frank). Also I made this specifically because people at work were complaining so much about how bad the input options are. So figured I'd just share what helped them. |
I'm not sure how far along they are, but it looks like Pico is at least working on OpenXR support: https://sdk.picovr.com/docs/OpenXRMobileSDK/en/index.html There is certainly UX work to be done around making OpenXR Input easy to use, but we believe it solves a lot of issues that developers have had. Namely: new controllers with different layouts coming out, development time reduction for developing against a singular api, and input actions that allow for users to control how they interact with your game (accessibility, preference, half broken controller, etc). That said, it is quite different than what we've been doing for decades, and changing something like that takes a bit of iteration. Hopefully you'll take a look again once Unity's implementation has matured. |
|
Does that mean we shouldn't expect any updates to this particular repo to support inputs in the near future (next 6 months)? Should I just stick to looking out for Unity's implementation to mature? |
This package will not support input using Unity XR. More info in my post at the top: #16 (comment) |
Which makes my point about over-engineered. Those kinds of features go into frameworks abstracted away from low level APIs.
I will only to force the input system to work within the agnostic layer I've made most likely. This allows global wide changes Unity or OpenXR decides to make irrelevant as they can be updated in one place. Even if OpenXR was perfect, this specific issue still arises. I'm not the only one who shares this view. Also sorry for being argumentative, its just something I've thought quite a bit in other projects. |
|
ok, so I finally got openXR input to work at all. Now I can't figure out: how do I code for controllers I don't have in my list? For example, for unity XR, I use finger trigger, hand trigger, primary button, secondary button, joystick, system button, menu button. I expect all systems using unity XR to work with this system. But for Open XR, there is no such thing. I have to select something like Pinch, Snapleft. etc. So if I want to define something the will work off of every joystick, I have to add my own controller mapping, or even a new set. How does this set work on new controllers? How does this new set get distributed to other users. Soooo many questions. I have never had any such problems when I was using input 1.0 where all I did was ask "what is the button mask", or "what is the vector value of some key with id". I've been working on this for so long and it has been one of the most frustrating things ever. Please please please, never ever remove functionalities from developers. You want to add some nice helper methods and functions? Awesome, do it. Do not remove the raw stuff. Always let the developer get the raw value of a button. I don't want to be forced to use a black box when I don't want to. |
|
You don’t, You will need that headset otherwise find an example file from another game and hand code it.
|
|
@carrotstien Actually you only need the various steam installs, like the mixed reality download for the MS and HP devices. These will also install the configurations and have the controllers show up in the tool |
|
I'll try that, but wmr have different controllers for different headsets.
The new g2 one isn't the same as the old odyssey one.
Will they come up as two different controllers?
As far as other headsets..There can be so many different ones I'm unaware
of.
I really wish there was still access to the raw input values...
I just know in going to be inundated with complaints when the game stops
working for someone using some proprietary headset which worked fine before
…On Tue, May 11, 2021, 11:42 AM Yannis Gravezas ***@***.***> wrote:
@carrotstien <https://github.com/carrotstien> Actually you only need the
various steam installs, like the mixed reality download for the MS and HP
devices. These will also install the configuration and show up in the tool
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#16 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AABZJT5NQZBRHPVDDHTILHDTNFF5FANCNFSM4PE3AYWQ>
.
|
@carrotstien installing the WMR runtime on steam will install two new controllers, the classic wmr and the g2 one. In general if you support oculus, knuckles, vive and wmr you've pretty much covered the whole market. If something new comes up and takes the vr world by storm it will probably just need to install its package on steam and tweak the config. I'm not sure it would be faster to work with the unity XR controls instead. The steamvr/openxr backends have a very useful feature where the controllers come with several poses, so for instance you can set the grip pose in the bindings tool and have all controllers align similarly. With the unity xr system you still have to tweak each controller type separately |
|
ok, installed wmr runtime, set up both controllers. I have verified with my colleague that they see it when they go into the input ui..but I don't see it in the project as recently updated. Any idea where this goes? Is it going through steam servers?
|
|
actually, scratch that, the bindings haven't been transferred. some seem to have been auto set (black box magics), but not everything. |
|
I have the binding for holographic controllers on my project, did you click on "replace default bindings"? After that you have to go back to the type of controller selections and activate the config you just did. Try this and it may do the trick |
|
another day another set of problems. Bindings work fine in unity on all headsets i need. Now I make the build - bindings no longer work. I see the following at the top of the json: how is this string referenced? If the final exe is a different name will it fail? |
|
i think i'm just going to give up on this, and just have to keep older unity project (for steam) and newer unity project (for oculus/pico) in sync... until I try OpenXR meanwhile, i got something to work yesterday (not sure why it doesn't work). Had some users try it to compare, and they instantly said the tracking was much worse. I have tried to start multiple conversations with steamvr folks about tracking and they all end up in silence or a dead end. Can anyone suggest an actual dev support contact point in steamvr/valve? |
Maybe this API will solve your issue? https://github.com/VRStudios/Unity3D-XRInput
There are some oddities in in each input API which I've dealt with in the XRInput abstraction to a large degree. |
|
thanks zezba9000, |
|
No problem, sent you PM on Discord. |
|
for anyone seeing this. @zezba9000 is an angel...helped me sort everything out. XRInput is basically how the default platform behavior should be :D |
and others
While I do get hand positions and controllers all the buttons are false or 0. I am using Unity 2020.1 16b and beta 7. I am testing with an htc vive with wand controllers, and STEAMVR 1.13.10.
The text was updated successfully, but these errors were encountered: