Official XR Plugins and Subsystems

The Unity Google Cardboard SDK has been archived, this could be bad news for you https://github.com/googlevr/gvr-unity-sdk

 

Hey Matt is the certainty still very high? Excited to try it out

 

Me too. There's a bunch of stuff I'm holding off on because I don't want to either a) reinvent the wheel or b) commit to Oculus/SteamVR SDKs and have to redo it later.

 

yeah I think there's a lot of us in the same boat.

 

If I'm looking at the correct API documentation. I'm guessing this is because the api is based around legacy input patterns like "primaryButton", "trigger", etc instead of actions. Making the API incompatible with the OpenVR Input API and OpenXR.

Which worries me.

 

So I'm on 2019.2.0f1 and the XR packages or the new Oculus integration from the store seems to be moving me out the environment for my scripts, nothing VS loads correctly and I get this error when I go to attach, does anyone know if there is a fix to this, if I remove all the Oculus stuff and XR it goes back to normal:


Severity Code Description Project File Line Suppression State
Error The "GetReferenceNearestTargetFrameworkTask" task was not found. Check the following: 1.) The name of the task in the project file is the same as the name of the task class. 2.) The task class is "public" and implements the Microsoft.Build.Framework.ITask interface. 3.) The task is correctly declared with <UsingTask> in the project file, or in the *.tasks files located in the "C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\15.0\Bin" directory. Oculus.VR.Editor

 

Looking at the xr packages in 2019.3 beta I see that both the openvr and oculus legacy xr desktop packages says they will be deprecated in 2020.1. Looks like xr manager or fall behind on unity versions rather soon.

 

Wondering what will replace OpenVR in 2020 then, also sucks that even when 2019.3 is finally released, will have to migrate to whatever standard is coming next in 2020.1. I may as well continue working in alpha/beta releases.

Will it be replaced by OpenXR or something built into the editor itself?

 

Curious if anyone has run into issues with cross platform VR/AR projects on the new plugin system. We've been using one project for Oculus, Windows MR, and Magic Leap, and we've been running into issues with swapping between platforms. We've tried to get the appropriate packages to load on each platform via script, and have been having issues getting loaders configured at application start-up. (We've also seen namespace conflicts between WinMR and ML, but that's a different issue)

Anyone have any tips or code samples for this?

 

The OVRPlugin in Oculus Integration Assets from the asset store no longer collides with the Oculus Loader in the latest version. Not sure what this means for the future of FFR but at least it can be activated now while using XR Subsystems!

 

Hi,
I'm trying to use the new XR integration for Oculus (Android), so I managed to build a working apk, but when I try to upload it on the Oculus platform, the apk is discarded as it was v2 signed, albeit the "V2 Signing (Quest)" checkbox on the Oculus settings in unchecked.

Any suggestions?

 

I just updated now to the new XR Plugin System (Oculus).
But now there's no Eye Target Option at the Camera Component. And also no Stereo Rendering anymore.
Documentation from Unity == null . That's really great :/

 

I'm hitting an exception when entering playmode in macOS Unity editor:

DLLNotFoundException: XRSDKOculus

This DLL appears to be Windows-only, however since XR Platform Manager does not discriminate between desktop platforms I'd recommend that the Unity devs downgrade this to a warning or suppress it entirely.

 

Yeah the Documentation for the Oculus Loader might as well be nonexistant!

 

Why no "Single Pass" anymore for Oculus Desktop? I found there are only 2 options, multi pass and single pass instanced, while legacy XR has 3.

Also, as a lot of people here already mentioned, I need OpenVR support too. Package Manager says Legacy XRs will be deprecated in Unity 2020, but I will not be able to use the new one without these supports.

 

I am a bit confused regarding ARFoundation support in Unity 2018.4 LTS. The last update I received was 1.5.0-preview.5. Will 2018.4 continue to receive AR package updates or do I have to switch to 2019.2?

 

I have a question: At the beginning of this thread it says support for Daydream but in the package there is none. Also the google VR package says it will be deprecated. Has Daydream support for the XR subsystems package been dropped?

 

Since Google has discontinued Daydream, is it reasonable to expect Unity to continue to invest in it? I would personally rather see effort invested in platforms that are still alive.

 

Looks like we're not getting anything until next year.

 

Any source for that? (other than looking at a calendar and using one's innate pessimism!)

 

I was wrong, looks like the toolkit is coming next week! https://forum.unity.com/threads/where-is-the-xr-interaction-toolkit.787874/

I'll stick with innate pessimism though, it's the hope that kills you

 

Hi,

Regarding this warning:
'PlayerSettings.virtualRealitySupported' is obsolete: 'This API is obsolete, and should no longer be used. Please use XRManagerSettings in the XR Management package instead.'

So, what I need to check is if VR is enabled (it's not using VR at all but one of my assets needs to check if VR is enabled to adjust certain features). If virtualRealitySupported API is going to be removed how can I safely check if VR is enabled without importing the XR Management package? (Because otherwise the asset would break if that package is not installed). Again, this is for an asset that can be deployed on VR and non VR projects.

Thanks

 

Thanks Unity for the toolkit. Could really do with an update on OpenVR now.

 

Is it possible to use the Oculus mode and still make use of their cross-platform capabilities? https://developer.oculus.com/blog/oculus-unity-integration-experimental-cross-platform-support/

Or do we need to load the official Oculus SDK to get this?

i.e. What happens if we build for Oculus and then run it on an OpenVR headset?

 

Just gave it a quick try, doesn't seem to work.

 

That rather underlines the urgency of the question around OpenVR. We can hardly ignore approximately half the PC VR market.

Please can we have an official word on this?

 

I know what I want Santa Claus to bring me: some official information on the OpenVR XR Plugin support. Some of us have to plan strategic roadmaps for migration and business needs for the coming year. Any reliable "official" information would be appreciated.

 

Not sure what I'm doing wrong:

* Unity 2019.3.0f3
* Oculus app version 12.0.0.241.268 (12.0.0.241.268)
* Fresh project
* Added nothing external (no asset store, no package manager) - only enabled XR plugin Management Oculus stuff
* Oculus Quest with Link (works through Oculus App)

No dice for play mode in Editor. A full build/publish cycle might work (dunno) but that doesn't solve my problem - I need to be able to quickly iterate and see changes in play mode from the Editor

I've tried all 3 approaches:

1. Not having oculus desktop app started
2. Having app started but not so that the Quest is acting like a Rift
3. Having the app started and in the Quest I see the Rift experience (hand, can launch virtual desktop etc.)

(as an aside I also tried using the older plugins, asset store package, etc. posted about that elsewhere)

Some screenshots:

 

Interesting. Great intro post exactly the type of information I look for when an architecture changes. A few questions from the point of view I have of having built a demo and gotten it running in Oculus Quest.

- is there a MockHMD SDK available yet? I'd love to have some rudimentary functionality while in an editor.
- do we need / have an HMD-none option in the case where we want OPTIONAL VR in our experiences?
- is it the case that I should expect to be replacing the OVRPlayerController / OVRCameraRig with a TrackedPoseDriver?

In my first attempt to get this running I was successful on a from-scratch build, but when I started add packages around BURST/JOBS/DOTS things went really bad. I actually never got it to work. In the second time round, I worked backwards from pre-existing DOTS project and have added Occulus XR to it, haven't finished the demo-scene build yet but it is working a little better. ... the point of feedback is that package versions *really* seem to conflict a lot, jobs requires a certain version of collections but burst installs a different version as a dependency, DOTS.editor uses the new unity-ui, but doesn't have it listed as a dependency so you have a bunch of compile errors until you install the new UI package (assuming you know there even is a new UI to install)

Things feel *messy* in the package ecosystem - especially with things moving from one namespace to another. I'm just waiting for the situation where packages have conflicting dependencies or namespaces move for one's dependency versus another.

I don't know if there's a point to that It's mostly my own fault for playing in the alpha/beta land of pre-release software here.

 

I've had some luck following those same steps while using the OCULUS utilities from the asset store. I dropped the OVRPlayerController into the scene instead of using tracked pose driver. Did you remember to add your DEMO scene to the build list?

Unfortunately my laptop doesn't work with quest-link so I can't speak to that, but I built to android / quest and was successful.

 

Sorry, I'm talking about editor/play mode for quick iteration and development. Edited the original post to reflect that. Thanks!

 

When will OpenVR be supported? You know, the most used system on the PC market.

 

Maybe we should conclude that the standalone XR support will not be removed from 2020.1 due to the lack of OpenVR plugin support? There's isn't even so much as a preview package for the OpenVR plugin.

 

Building for Oculus Quest seems a bit wonky.

When I build Multi Pass, I get a single view in the left eye.

When I built Multiview, I get 2 renders overlayed both on the left eye.

In neither approach does the right eye appear to function. Anyone have different results?

EDIT: I got it working. I made a few changes to my player settings. Switched the API version to minimum on 23, pulled the OpenGLES3.0 above Vulkan, and made the .NET version 4.x instead of 2.0.

 

Vulkan isn't release ready.. yet

 

So this new system doesn't support all major headsets on the market, and you've deprecated the working solution (UnityEngine.XR) that I was just getting the hang of. Bravo.
What's the recommended way moving forward for people that want to target Oculus, Windows MR and OpenVR in a single project? Use the deprecated solution? Wait until the Unity dev gods finally decide to grace us with some information?

Seriously guys, this sucks big time. I write XR tutorials and books and I was planning on covering the built-in XR system as it was easy to use and cross platform and now you throw a curve ball and I'm stuck in limbo, having to wait for news and documentation. Maybe you should consider marking stuff like this as alpha and not deprecating the "old", working solution before the new one actually fully works.

 

This^

Come on, folks. We need at least a whisper on the status of SteamVR/OpenVR support. I know the hand pose/action mapping stuff makes it complex (but something similar needs to be tacked for Oculus too now they've got hand tracking in their SDK). We're not asking for a release date - just some acknowledgement that you're aware of it and some sense of whether it's going to be days, weeks, months or "probably never". At the moment it's the latter we fear.

 

since they worked on the new render pipelines, a lot of things at unity goes messy. Out of preview Packages are not really production ready. Lag of documentation (or messed outside of the official documentation). Deprecated Code without fully new replacement.

 

All I can find is here: https://docs.unity3d.com/2020.1/Documentation/Manual/XRPluginArchitecture.html

"
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.
"

 

Can I ask if it is true that Unity won't support HTC Vive headset for development with the new system at the moment?

I installed the latest XR management package, have installed Oculus Package and added Oculus Loader as well as added a device tracker on camera in scene. It is not working at all. Anyone?

 

Any Unity official here? Can we get a word, a single word on the future of OpenVR support? what should I say to my clients who use a lot of HTC Vives? A simple "It's coming, wait till eternity" would suffice honestly

 

Hmm. From their documentation page https://docs.unity3d.com/2020.1/Documentation/Manual/VROverview.html

It does say "Valve documentation on OpenVR will be added to this page when available."
Sooooo my guess is that it's going to be supported? Perhaps?

 

I'll be supported but we don't know when. According to the doc, OpenVR projects must uses the old implementation or Unity 2018.4.

 

Wow, nice to see that I wait a few months to check back and Unity is still radio silent about OpenVR support. Is it seriously that hard to give a concrete answer? Seriously, being a Unity developer for the past two years is about as fun as pushing pins into my eyes. All of these unfinished packages with missing features and lack of a concrete roadmap...what a mess.

 

I uploaded my app to oculus quest, everything works fine but I've got a lot of debug logs in console:

[XR] Failed to BeginFrame on display.

Someone knows how can I fix this?

 

When using Sockets and Grabbables, we are finding there is some issue with the hovering preview mesh render that appears when the grabbable is near the socket.

The socket renderer seems to use the center of the gameobject, or its pivot, but there is a discrepancy between the two, I have tried moving things around, but Unity seems to give the object a pivot itself. The pivot of the mesh is the base of the cup, but nothing lines up!
See the video linked

https://drive.google.com/file/d/1NmN-9C844GJ5jA-BPVXiAIQIiWn71jbP/view?usp=sharing

 

I don't know what the issue is with Unity, Valve and VR.

It's been a nightmare in 2015 when Unity introduced their first "native VR" support, while we already had a very awesome SteamVR Unity Plugin that did pretty much everything better than how Unity approached things with their "native" support (which looked very much like someone from Oculus coded it ;-) ). Unity finally kind of caught up around 2018 (IIRC) and finally started doing things the way any reasonable person would approach it.

And now, it seems it's the same mess all over again.

I was really excited about EditorXR but after looking a little into all the "fancy new VR stuff" coming from Unity Technologies, suddenly Source engine looks incredibly interesting with what they announced in the context of Half-Life: Alyx ... if moving to another engine just wasn't such a huge PITA.

Just one brief look at the XR Interaction Toolkit Examples in the current Unity 2019.3 version, and comparing it to the Interaction Demo that came with the SteamVR Unity Plugin like three years ago kind of tells me everything I need to know: I just wasted half a day with Unity's new VR initiative.

I'm silently saying the famous Witcher word in my mind. And it's not "Hm". It's the other one. ;-)

 

The issue here is mainly the lack of communication on what's happening with OpenVR.

In the nutshell, what people want to know:
- ETA for OpenVR plugin for the new XR management system
- What are the blocking issues right now? (there has to be some because there can't possibly be WMR and Magic Leap but no OpenVR support unless there's some major blocking issue behind it, neither of those are anywhere as significant as OpenVR is for the VR devs).

 

Would also love to know what the plan is for Vive support. In addition, if we're supposed to transition to the XR Plugins / XR Management, why does the XR Interaction Toolkit Example use the OpenVR Desktop package that is going to be deprecated in Unity 2020.1?

 

It's practically deprecated on 2019 already according to Unity.. and support is removed on 2020.1 (old OpenVR package does not work anymore on recent 2020.1 alphas).