![]() For my project the "grip" pose made more sense for controlling hands so in steam I use that and correct for oculus. Unity seems to be utilizing what SteamVR calls the "tip" or "raw" pose/anchor by default. There were some issues where hands in the virtual world would seem displaced. 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. In the meantime, it would certainly be feasible to implement the full unity xr functionality on top of SteamVR which IS a superset. It's not a good situation for developers right now, but at least OpenXR is coming to ease things up. If someone has managed to do it I'd love to hear how. There's just no way that the middlewares from both can coexist. That being said, right now I have to maintain two different projects. I had to use it to get full coverage of hmds on steam and I can now say that it's good. OpenXR is essentially the steamvr architecture made into a standard. It is a strictly unity thing, a good option to have in my opinion. The unity XR plugin architecture has nothing to do with OpenXR and open standards. 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 Just to set the record straight I think there's some confusion here: 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. 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). ![]() 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 Later on you can probably switch them transparently to OpenXR via the unity plugin. ![]() 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. OpenVR is supposed to be a superset of what the unity plugin architecture provides right? On the previous repo input was almost working. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |