Official XR Plugins and Subsystems

@LeonhardP I think this is very relevant for beta testing - currently there's no way to test VR support on HTC Vive with the new XR system. Could you please try getting an official response on this? It's a very unclear state and prevents both business decisions and testing.

 

Far clipping plane does not work with XR Management on Oculus Rift S, it worked with XR Settings

 

Where is it ?

 

Probably in few hours

 

I've been refreshing the blog almost every hour, hopefully it goes up soon. Looking forward to hearing more of the plans.

 

Same here. Hoping for good news.

 

Got my hopes up for a second after refreshing the blog...

https://blogs.unity3d.com/2020/01/23/explore-revit-models-in-vr-with-unity-reflect/

 

Same! I was like 'I wasn't expecting this'. Hopefully the Revit plugin helps fund more people to work on the VR support at Unity at least.

 

Is that weird Explore Revit models in VR with Unity Reflect blog posting the scheduled post you were referring to? Or is there another one coming later today? Or did you just want us to see the Overtone blog posting?

 

This is all a bit weird isn't it?

If Reflect supports Vive pro then I guess that's a good sign?

 

I'm tucking myself into bed now, hopefully the blog post appears tomorrow morning

 

I guess I'm the lone researcher who's curious if the 'Stereo (non-head mounted)' option will still exist in some form, or if it will be possible to write an XR Plugin to enable it (will the plugin API be exposed? documented? kept closed-source?).

I use viz clusters (CAVE etc) which have hardware stereoscopic support (nvidia quadro's with quad-buffering) and currently use Unity (currently using the 2019.3 preview with the deprecated support that still works).

Will Stereo non-head mounted still exist? Or are we stuck using old versions of unity or now having to write our own software/use UE4?

 

https://blogs.unity3d.com/2020/01/24/unity-xr-platform-updates/

It is not clear to me if the OpenVR XR plugin Valve is developing will be part of the Unity XR plugin framework or not.

 

Is there a blog post coming that explains why PC VR development had just taken a massive leap backwards?

Is there any realistic way to use Unity for cross platform VR now? Is Valve going to save us? Can we use any of the new stuff when this alleged Valve plugin is released?

Who's to blame? You or Valve?

 

That sounds more positive. In which case your blog post is really badly worded.

I'm very confused.

 

The most obvious question: Why isn't Unity supporting OpenVR anymore?

 

@mfuad what you just said is a lot more chipper than that blog post reads.

Can we get a clearer breakdown of WHY Unity is stepping away from in-house OpenVR support? This seems like huge move for Unity to make, and an issue for everyone building for and on Vive/Index hardware, so what's the reason?

 

The blog post doesn't explain the current state of Scriptable Render Pipeline for VR either as a future thought. The userbase is segmented across built-in and UniversalRP/LWRP. I understand it is ongoing development to support VR in SRP and the Oculus Quest/Go have had various issues with UniversalRP on OpenGles 3 and lack of Vulkan support - in which Unreal engine 4 is way ahead in the areas of for performant rendering. Even just the Fixed-Foveated Rendering on Quest is broken for UniversalRP which makes it unusable.

I also want to know why OpenVR isn't being Unity supported despite its vast headset reach.

 

My guess the answer is Money. Other vendors paid to be on the supported list.

 

Is there any reason to not continue support for OpenVR Desktop until an alternative comes out? Is the amount of support required too large or something? Just not entirely sure why something like 2019.3 LTS couldn't support it.

 

For me, this blog post is incredibly disappointing. The only new piece of information is "yes, we really dropped supporting OpenVR natively as you were all afraid".
Instead, here's a list of words/topics that this blog post carefully avoids:
- Quest
- Fixed Foveated Rendering¹
- Vulkan
- URP VR²
- HDRP VR³
- New Input System⁴
There have been uncountable discussions, fights, lost man hours and lost money over the last months in relation to these topics, and you really managed to fill an entire blog post not touching them.

¹: releasing on Quest is not practical without FFR. FFR does not work on URP. What are we supposed to do? Stay on the deprecated and much slower built-in pipeline?
²: while URP is out of preview for a comparatively long time, it's still very broken for VR development (mobile and desktop). When will URP work for VR (yes, including ShaderGraph and Instancing)?
³: will Desktop HDRP VR be out of preview with 2019.3 when HDRP is supposed to be production ready?
⁴: current XR requirements contradict each other (e.g., HDRP Wizard requests deprecated XR settings, XR Interaction Toolkit is only available for the old input system, AR Foundation in some places requires the new system and in others exclusively uses the old). What's the schedule for reaching a working state again?

 

You know, when I look at how Valve has been approaching VR, and how Unity Technologies has been approaching VR (during the last 5 or 6 years), maybe it was Valve that wanted to do their own thing? Right from the beginning, Valve has been leading the way, and Unity has been playing catch up. Don't get me wrong: I highly respect the engineers working at Unity Technologies. But from the outside, it very much looks like VR at UT has been driven primarily by the marketing department all along (buzzword driven development apparently is a thing).

It's pretty obvious that Valve not partnering more closely with Unity is Unity's loss, not the other way round. And if the Unity execs really had the hubris of asking money from Valve for "partnering", at least the people at Valve that were there probably had a good laugh (or silently cried in sympathy ... we'll probably never know).

Sadly, Unity having turned into what it is now during the last 8 or so years is also a major loss to the development community. Unity's founders witnessed the downfall of Flash and created an awesome alternative - but they don't seem to have much say in Unity's direction anymore, which is also a huge loss for the company (at least Joachim is still pushing it on the technology-side but long-term, that simply won't be enough). The change in leadership when David stepped down is probably why Unity is now going in 10 directions at the same time, with 9 of them usually not leading anywhere and the one that does lead into the right direction usually being deprecated prematurely. I don't blame David but it does make me quite sad that Unity Technologies, of all companies, has become another example of companies being passed on to other people just not working out well.

The blog posting is exactly the kind of PR-speak because of which a lot of developers avoid large corporations like what Unity has become. It's not easy to change engines but eventually the pain of using the wrong engine outgrows the pain of switching. I don't think anyone misses Flash much in 2020, and Flash once had a literal monopoly in their market.

/RemindMe 10 years

 

It would be really appreciated if we could get a response to fherbst's comment from here/the blog post. I've been dilligently reporting bugs in URP for VR on android + desktop for months leading up until now and still radio silence on what the future plans for UniversalRP in VR are.

 

Just as a hopefully constructive feedback: As a developer and small indie-gamedev CEO (in that order), I care about engineers collaborating to create the best possible solution. For me, a blog posting has value when it addresses the technical issues that I have to deal with and how those are addressed to improve my productivity when I use your engine as a tool to build things I'm excited about (which happen to be VR games).

When I see a blog posting that spends a lot of time elaborating on different levels of partnership, and then the one partner that is by far the leader in the field on many levels is missing from the "official partners", that tells me that the priority is not finding the best solution but something else.

The smart thing, in my opinion, would be licensing the tech from Valve and integrating it properly into Unity. That would help me solve actual problems that I have and "take the pain out of game development" as Unity once promised.

 

Thanks for the reply.
So to be more accurate, I should have asked will the plugin Valve are developing work with Unity 2020.1 and future versions? If not why not?

It seems that Unity has developed plugins for every platform themselves except OpenVR. Is this for technical or business reasons?

I think another blog addressing the other problems people have mentioned here would be good too.

 

@mfuad @Matt_D_work can you please clarify some things -

1) 2019.3 uses XR Management for all but OpenVR (and deprecated built-in VR for the others), while built-in OpenVR does not work with XR Management.
Is that correct?
So basically until Valve comes up with their solution cross-platform VR development is not possible with Unity 2019.3 + 2020?

2) Unity not officially supporting OpenVR but offloading the plugin development to Valve also means another thing - the last LTS version with guaranteed cross-platform VR support will stay 2018.4, 2019.4 LTS can't guarantee that since Unity officially has nothing to do with the OpenVR support for this. Am I understanding this right?

 

What about OpenXR and Vulkan? It's supposed to be the future right? UE4 have since the 4.22 version an excellent support for OpenXR.

 

Ok. The blog post makes sense now.

It's basically "We asked Valve for money to be in our special club but they said no. Therefore we need to make it sound bad to communicate to other partners the value of this club. Except we made it sound too bad and that made developers angry so now we've made it sound less bad"!

Whether or not it is actually bad remains to be seen but I don't think we'll get a straight answer here as it's directly tied to a revenue stream.

Instead we get an impenetrable blog post containing vacuous corporate double speak.

Unity needs to decide who the intended audience is for these blog posts. This style is writing doesn't go down well with developers (and probably doesn't go down terribly well with anyone who is a human being rather than a corporate droid)

 

Actually, I think Unity Technologies needs to decide who their customers are: Originally, Unity's customers were game developers and also people developing realtime 3D applications. For that audience, the only things that matter are the quality and affordability of the actual product.

But it looks as if for a few years Unity has been torn between investors, "partners" and the people actually using the engine. The investors only care about the value of the company: The more people using it, the better; the more people paying on a regular basis (subscription), the better. Eventually, the investors want a return on their investment, so the company will be sold - one way or another.

For "partners", Unity seems to be primarily about getting access to the developers that use Unity. In some cases, it's probably also about getting content for their platforms.

Now, if Unity acted in the best interest of its original customers (game studios, developers, 3D realtime application developers), partners would be chosen based on merit for those original customers. But that just doesn't seem to be the way it's happening.

 

There's separate forum threads for these discussions. Would be great if we stay on topic here and get some answers thanks!

 

I would like to give Unity the benefit of the doubt - Quote from https://github.com/ValveSoftware/steamvr_unreal_plugin/wiki “Valve maintains an Unreal plugin to smoothly interface SteamVR Input with Unreal.” Could be Valve just wants control of their own junk and does not want to leave their fate to any specific engine ...

 

Please, please, continue with the Cardboard VR support.

It should be at least one available alternative for them who want to use some VR without having to buy expensive dedicated hardware.

 

Google aren't supporting it themselves anymore so I'd consider it dead, can you not afford Oculus Go as an alternative?

 

Come on. Oculus Go has no more hardware power than the average phone almost everyone has anyway.

 

It is available, you just have to use the 2018 LTS version of Unity and tooling, and it's not being removed from there. It's normal practice to use older (stable) versions of Unity for older hardware/platforms, even for new projects when stability is critical.

You also have to look at it from Unity's perspective - Cardboard/GearVR/Daydream are being set to the wayside by their respective companies, so there's likely not going to be much demand to integrate these legacy technologies into each engine revision for limited demand in new projects. It's significant technical debt to keep up to date, test, deploy, revise documents, and support.

Most of the people here would likely rather Unity focus their limited resources on keeping the newest version of the editor up to date with latest technologies. Vulkin, OpenVR, fixed foveated rendering, support for new controllers and upcoming platforms, fixing rendering pipelines, etc.

 

I think the VR industry is digging its own grave when they expect people to continuously buy new hardware with so small difference in each iteration.

The only reason for VR in my opinion is to get some sense of present of being somewhere else.

I mean, you get a comparable FOV with Cardboard and an average phone, as when buying much more expensive dedicated VR headsets.

Who cares about super tracking of every finger when you can’t see the rest of your arms and body?

 

Oculus Go is almost as dead as Cardboard VR (and Gear VR). The minimal mobile / standalone system is currently Oculus Quest.

@arfish The difference between 3DOF devices (Cardboard, Gear VR, Oculus Go) and 6DOF devices (Quest, PSVR, Rift, Vive, Valve Index) is monumental. 3DOF devices are kind of okay to watch 360° stereo movies but you don't need Unity to build/play these. Anything 3DOF in a realtime engine is a complete waste of resources.

Regarding finger tracking: You don't need finger tracking but you do need proper hand tracked controllers. Again, the difference between VR without proper hand tracked controllers, and VR with proper hand tracked controllers is monumental and the former is already (almost) dead. Arms and body, on the other hand, hardly make a difference in terms of interaction. Some people like seeing them (and that can be done with tracked hands and IK), others find seeing them annoying. So whether you show those or not is a design decision you have to make as a developer.

Full body tracking is available for SteamVR (via Vive trackers, and also via special drivers for Kinect but that's an approach that is a bit hacky and requires extra calibration steps). It's nice to have and does open up new possibilities for interactions in VR but it's a comparatively small target audience. But that will change over time, so fully tracked bodies are the future (and therefore need to be taken into account when designing stuff like the XR plugins and subsystems that this thread is about).

 

Yeah, even Oculus Go seems to be on its way out, and what does the VR industry think is the future now?
Steampunk goggles with even smaller FOV, for them who wants to look nice when they are in a game?

If someone should spend money on VR headsets they want more FOV. Preferably combined with some kind of eye tracking to reduce the rendering workload. Two pair of IR sensors, and a few lines of code, could perhaps do a good enough job for that.

You get tired and dizzy if you have to move your head around which you must when the peripheral vision is not there. All action games dies totally when you can’t even se the enemy moving beside you.

6DOF is nice, when you have a dedicated large room cleared for you to move freely. Who has that?

 

This discussion is best had elsewhere on another forum!

@mfuad @Matt_D_work Could we get a response to @fherbst 's questions here please? (links to his comments in this thread below)

- as a Oculus Quest and PC VR developer, the lack of developer response or general communication around which parts of Unity like Scriptable render pipeline and Shader Graph work for VR on PC and Android or are still unsupported for the platform cause great frustration.

https://forum.unity.com/threads/xr-plugins-and-subsystems.693463/page-4#post-5406039

https://forum.unity.com/threads/xr-plugins-and-subsystems.693463/page-4#post-5406993

 

2019.3 still lets you use the old approach for OpenVR Desktop, Windows Mixed Reality, Oculus Desktop and Android, Google VR Android and iOS. In the package descriptions, it says "will be removed in 2020.1" for all of them, but they are still there, and those that I tested (OpenVR, Oculus, both with the proprietary integrations) do work in 2019.3.0f5.

So as long as you don't need to use XR Management, it looks like you're fine in 2019.3 (I have not seen Vuforia or Magic Leap "old-style" in 2019.3, so if you need those, you might be in trouble with 2019.3, too; I do see Vuforia in 2019.2 but not Magic Leap).

Unity 2020.1 breaks OpenVR, so currently 2020.1 is DOA. But it's also still in alpha. We'll see how that turns out.

With 2019.3, nothing changes compared to 2019.2, except Vuforia (and maybe Magic Leap), and that "bugs are not prioritized" (as they said in the blog posting and in the documentation). Bugs not necessarily being prioritized has been the standard in Unity for many many years, so people are used to that. The only difference is that in this case, it's official. Currently, there are other issues preventing us from moving from 2019.2 to 2019.3, so I can't say anything about the viability of using 2019.3 for production VR projects. That may change with 2019.3.0f6.

I came to this whole mess after trying out EditorXR and Unity's XR Interaction system. While both look interesting and promising, they both don't seem to be production ready. I lol'd when I saw that EditorXR doesn't even work with Single Pass ... in 2020! And while the XR Interaction Toolkit has a few fun things, I'm not sure it adds much compared to other systems except cross-platform, which it currently doesn't have. Also, as long as they don't publish the source code of the XR Interaction Toolkit, using it puts you into major risk.

Unity has a track record of not knowing what they're doing when it comes to VR (things have improved a little over time but progress is very slow, and just like now, the original native VR support that came in 2015 mostly broke things and was terribly designed). Also, Unity has a track record of deprecating things before they are actually usable. So in general, I would avoid relying on anything "built-in" as much as I can (this started with Unity's original RAKNET-based networking but has been spreading to many other systems like cancer).

So from the looks of it, you don't gain much in terms of cross-platform development when you use Unity 2019.3 - but you also don't lose much.

 

Wat?

6DOF is essential even for seated, static experiences. My first mind-blown VR experiences was exactly that. 3DOF doesn't really deserve to be called VR any more.

 

On the blog posting, someone from Vuforia chimed in about this, and Vuforia is still supported in 2019.3 - it's just no longer distributed by Unity (that's why I didn't see it in the package manager, when I tried):

 

@mfuad I noticed that in https://docs.unity3d.com/Packages/c...07.1163137976.1579106896-304168295.1564751497 under platforms, OpenVR is not even mentioned. Is this indicative of the platform's future within Unity?

 

@Matt_D_work any chance you happen to have any info on the 'Stereo Display (non-head mounted)' support and if it, or some other form of quad-buffering support, will still be available in Unity?