Search Unity

XR의 혁신이 이루어지고 있는 가운데, 유니티는 크리에이터와 생태계 파트너 사이에서 가장 탁월한 개발 플랫폼이라는 명성을 이어가고자 합니다. 이번 포스팅에서는 현재의 생태계를 강화하기 위한 새로운 XR 플러그인 프레임워크를 소개하고, 이러한 변화가 2019.3 이후 버전의 개발에 미칠 영향을 다룹니다.

Unity XR 플러그인 프레임워크

유니티는 단일화된 플러그인 프레임워크를 통한 직접 통합을 실현하여 멀티 플랫폼 기능을 개선하고 있습니다. 유니티가 목표로 하는 기술 스택은 지원되는 모든 플랫폼에 공통적인 기능을 원활하게 제공하는 API로 구성되며, 동시에 XR 하드웨어 및 소프트웨어 제공업체가 자체 Unity 플러그인을 개발하도록 지원합니다. 이러한 구조는 다음과 같은 이점을 제공합니다.

  • AR 파운데이션 및 XR Interaction Toolkit과 같은 멀티 플랫폼 개발자
  • Unity 패키지 관리자를 통해 지원되는 플러그인에서 더욱 신속한 파트너 업데이트
  • 더욱 다양한 플랫폼을 통해 인터페이스에 액세스하여 Unity의 XR 렌더링 최적화 및 개발자 툴 활용

유니티는 이번 업데이트에서 지원 플랫폼을 위한 XR 플러그인을 새로 개발했습니다. 또한 2019.3 버전에서 빌트인 플랫폼 플러그인 지원을 중단했습니다.

이 프레임워크는 다음과 같은 유형의 플랫폼과 채널을 지원하는 방식에 영향을 미칠 것으로 예상됩니다.

  • 공식 지원 플랫폼
  • 검증된 솔루션 파트너
  • Unity 사용자가 개발한 솔루션

공식 지원 플랫폼

한 번의 빌드로 어디로든 배포’는 유니티의 핵심 원칙이며, 유니티는 전략 파트너와 긴밀히 협업하여 모든 크리에이터가 다양한 플랫폼을 타겟으로 개발을 진행할 수 있도록 전폭적인 지원을 제공합니다. 이러한 지원에는 심층적인 플랫폼 통합, 엔진 성능 향상, 플랫폼에 따른 XR 기술 스택 최적화가 포함됩니다. 유니티는 2019.3 버전부터 다음을 공식적으로 지원합니다.

  • ARKit
  • ARCore
  • Microsoft HoloLens
  • Magic Leap
  • Oculus
  • Windows Mixed Reality
  • PlayStation VR

기타 플랫폼 업데이트

  • Oculus가 최신 하드웨어에 집중하고 있으므로 Gear VR은 2019.3 이상 버전에서 더 이상 지원되지 않습니다.
  • Google이 Daydream View의 판매를 중단하고 Cardboard Open Source Project를 출시함에 따라 2019.3 버전부터 Google VR이 더 이상 지원되지 않습니다.
  • 새로운 플러그인 프레임워크를 향한 변화의 일환으로 Valve는 유니티의 XR SDK를 사용하여 2019.3 이상 버전을 위한 OpenVR Unity XR 플러그인을 개발하고 있습니다. 플러그인 출시 후 설치 방법이 공유될 예정입니다. 플러그인 출시 전까지 2019.3에서 OpenVR 빌트인 지원을 이용할 수 있으며, 유니티는 주요 수정 사항과 관련하여 필요한 지원을 제공할 예정입니다.

참고: Gear VR, Google VR 및 OpenVR은 Unity 2018 LTS에서 계속 지원됩니다.

검증된 솔루션 파트너

XR 분야에 계속해서 새로운 업체들이 진입함에 따라, 유니티는 생태계 전체를 더 효과적으로 통합할 수 있는 프레임워크를 만들고자 합니다. 유니티는 Unity XR SDK와 검증된 솔루션 파트너 프로그램을 통합하여 타사 공급업체가 크리에이터를 위해 직접적인 가치를 창출할 수 있도록 합니다. 이 프로그램은 테스트 검증 및 플러그인 출시 후 프로모션 등 다양한 수준의 지원을 제공합니다. 검증된 솔루션 파트너가 되면 개발자에 대한 신뢰를 형성하고 플러그인을 더욱 원활하게 도입할 수 있습니다.

프로그램에 관한 정보와 검증된 솔루션 파트너가 되는 방법에 대한 자세한 내용은 여기에서 알아보실 수 있습니다.

사용자가 개발한 솔루션

크리에이터와 혁신가가 모인 커뮤니티가 없었다면 유니티는 지금과 같은 플랫폼으로 성장할 수 없었을 겁니다. 유니티는 혁신을 저해하지 않는 선에서 생태계의 새로운 도전을 응원하기 위해 사용자가 유니티 인터페이스에서 자체 Unity 플러그인을 개발할 수 있도록 합니다. 이러한 솔루션 및 파트너는 Unity에서 직접 지원하지는 않습니다.

여기서 등록하여 XR SDK의 헤더, 기술 자료 및 테스트 제품군에 대한 정보를 받아보세요.

XR 플러그인 변경

앞서 언급한 바와 같이 빌트인 XR이 2019.3에서 지원 중단되므로 지원되는 XR 플러그인을 사용할 것을 권장합니다.*

아래 표를 참조하여 각 플랫폼에서 개발을 진행하는 방법에 관한 최신 가이드를 확인하세요.

Platform Recommendation
ARCore 프로젝트에 ARCore를 사용하는 AR 개발자는 AR 파운데이션을 계속 사용해야 하며, ARCore XR Plugin 로딩을 위해 XR Management를 사용해야 합니다.
ARKit 프로젝트에 ARKit를 사용하는 AR 개발자는 AR 파운데이션을 계속 사용해야 하며, ARKit XR Plugin 로딩을 위해 XR Management를 사용해야 합니다.
Magic Leap Magic Leap 개발자는 AR 파운데이션을 계속 사용해야 하며, Magic Leap XR Plugin 로딩을 위해 XR Management를 사용해야 합니다. 또한 개발자는 Magic Leap Lumin SDK를 다운로드해야 합니다.
Microsoft HoloLens / Windows Mixed Reality 2019.3 이후 버전을 사용하는 HoloLens 개발자는 AR 파운데이션을 계속 사용해야 하며, Windows XR Plugin 로딩을 위해 XR Management를 사용해야 합니다. 또한 Microsoft는 이번 달 말에 2019.3 이후 버전에서 Windows XR Plugin과 호환되는 새로운 버전의 Mixed Reality Toolkit(MRTK 2.3)을 출시합니다.

버전 안정성을 위해 Unity 2018 LTS를 사용하는 개발자는 HoloLens 및 Windows MR 기기를 위한 개발을 계속 진행할 수 있습니다.

참고: 2019.3에서 Windows MR(Windows Mixed Reality) 빌트인 지원이 중단되었습니다.*

Oculus 2019.3 이후 버전을 사용하는 Oculus 개발자는 Oculus XR Plugin 로딩을 위해 XR Management를 사용해야 합니다.

버전 안정성을 위해 Unity 2018 LTS를 사용하는 개발자는 Oculus 기기를 위한 개발을 계속 진행할 수 있습니다.

참고: 2019.3에서 Oculus(Oculus AndroidOculus Desktop) 빌트인 지원이 중단되었습니다.* 

OpenVR Valve는 유니티의 XR SDK를 사용하여 2019.3용 OpenVR Unity XR 플러그인을 개발하고 있습니다. 플러그인 출시 후 설치 방법을 자세히 공유할 예정입니다.

플러그인 출시 전까지 2019.3에서 OpenVR 빌트인 지원을 이용할 수 있으며, 유니티는 주요 수정 사항과 관련하여 필요한 지원을 제공할 예정입니다.

OpenVR은 Unity 2018 LTS에서 계속 지원되며, 개발자는 기존 프로젝트에서 OpenVR을 계속 사용할 수 있습니다.

참고: 2019.3에서 OpenVR(OpenVR(데스크톱)) 빌트인 지원이 중단되었습니다.*

Gear VR 2019.3 이후 버전의 Oculus XR Plugin은 Gear VR을 더 이상 지원하지 않습니다.

Gear VR은 Unity 2018 LTS에서 계속 지원되며, 개발자는 기존 프로젝트에서 Gear VR을 위한 개발을 계속 진행할 수 있습니다.

참고: 2019.3 버전에서 Gear VR(Oculus Android) 빌트인 지원이 중단되었습니다.*

Google VR 2019.3 이후 버전에서는 Google VR 버전이 더 이상 지원되지 않습니다.

2019.3 이후 버전을 사용하는 Cardboard 개발자는 항상 Unity용 Cardboard Open Source XR Plugin의 최신 버전을 사용해야 합니다. 업데이트는 Google VR 개발자 사이트에서 확인할 수 있습니다.

Google VR은 2018 LTS에서 계속 지원되며, 개발자는 기존 프로젝트에서 Daydream 및 Cardboard를 위한 개발을 계속 진행할 수 있습니다.

참고: 2019.3에서 Google VR(Google VR AndroidGoogle VR iOS) 빌트인 지원이 중단되었습니다.* 

Vuforia Vuforia Engine 빌트인 패키지(Vuforia Engine AR)는 Unity 2019.3부터 Unity에서 배포 및 직접 지원되지 않습니다. 올해 3월까지 Unity 패키지 관리자를 통해 최신 Vuforia Engine 패키지를 이용할 수 있습니다. 3월 이후에는 Vuforia 개발자 포털에서 Unity용 Vuforia Engine 최신 버전을 계속해서 다운로드할 수 있습니다.

*’지원 중단 서비스는 2019.3에서 빌트인 플러그인으로 계속해서 사용할 있으며, 새로운 기능 없이 필수 버그 수정사항만을 포함한 버전을 2019 LTS에서 계속 사용할 있습니다.

53 replies on “Unity XR 플랫폼 업데이트”

I think a radical reorganisation and consolidation of all the fragmented tools is a good thing long term and I applaud the initiative. I just hope the LTS 2019.4 version can bridge the gap for everyone until we get there.
I’m looking at AR foundation and thinking it just doesn’t have the feature set of vuforia quite yet, but here’s hoping…

Why do you guys always botch the announcements of these things? Stuff often feels infinitely more frustrating than it needs to be cause the roll out of information is never slow always sudden and alarming at worst.

The mention of Vuforia no longer being supported in Unity 2019.3+ are inaccurate. The
PTC/Vuforia team will have a full response posted on our developer portal shortly.

The audience/user reaction here and on other recent posts (https://blogs.unity3d.com/2019/12/12/2019-3-is-now-in-the-final-stages-of-beta-testing/ ) and in many sections in the forums should be and hopefully is a wakeup call for Unity, because that is extremely needed obviously.

Yes, it was maybe just a “slight” mistake to not explain the OpenVR situation as it is properly, but how could this mistake have happened?
Because your whole situation is a complete ridiculous mess.
Maybe you don’t understand it or don’t want to understand it, but this splitting out of many engine aspects into separate packages separately to be downloaded via package manager and now also in similar vein this externalizing of the previously integrated support for VR on more and more ends is complete and utter nonsense.

It is insanely difficult to maintain for your users, not just you.
This is unacceptable.

Yes, your team and evangelist youtubers/twitter people etc hype each and every new such development and feature up like it is oh so awesome, but in reality, it has been nothing but an extremely convoluted, huge timesink mess for at least the last 1-2 years, and with you not course correcting and instead doubling down on this completely misguided path it is constantly getting worse, not better.

Then i see replies by the staff apologizing for the mess in messaging (of course it is a mess, because the situation itself is a mess) and then repeatedly users post comments about all their worries about current and 2019.3 VR feature/functionality states (broken), like Fixed Foveated rendering, proper vulkan support, proper post processing working in single pass on all VR platforms (and what about in acceptable performance on top, that’d be great) and many other such things
and yes, these and many others are all issues in latest (also on many other ends broken) 2019.3 betas, not “just” in stable versions 2019.1,.2 etc and then the team person replies about the great new upcoming XR improvements on such ends in 2019.3, seemingly not even realizing how off this marketing reply is when users are complaining about those issues in not just the current stable release but also this beta you are talking about having improvements on those ends.

Seriously, UT, you have to get your stuff together, too many things are going in bad direction there.

Sorry about rude tone, but this messed up situation is costing us paying users way too much time and money meanwhile with your constant instability, tons of new bugs added, always adding half baked new features while abandoning old more stable stuff which despite it’s age just got made barely stable, hardly ever made fully feature complete to a level it should be.

If someone is to start with Unity VR now, which version should i recommend him/her to use with which of these convoluted mess options?

besides marketing blabla you could not even give me a good option for a fully stable reliable option there which performs well on all platforms.

I have to stay on 2019.1.2F1 or older version with most of my projects because it just got more buggy and more new issues and even worse performance in most of my projects with the newer versions.

Each time a new alpha/ beta comes out i give it a try with several projects (another huge timesink) and each time there are different new issues for each.
Now one could say of course there are bugs in alphas an (early) betas, but 2019.3 has now F (release candidate) labels at the end. This is also compltely unacceptable when one looks at the list of just the known bugs listed where there are several major complete no go shipstopper grand scale issues remaining.

Who in their right mind forces the dev team to label something like that a release candidate? This is now at best early beta quality level, at best.

Same with all the render pipeline stuff you label as production ready now.

With such extremely false marketing you are really loosing A LOT of trust and respect and tarnishing the brand bigtime.

Really, what is going on there?

Maybe actually try to make a proper production project (not just a fancy demo you abandon within two months after showing it) and try to use a few of the many packages from package manager in it and you’d quickly see what kind of totally unacceptable workflow that is when one has to search together which versions of all those packages work together halfway acceptably on each platform and with which renderpipeline and with which external plugins etc etc.
Deploy your project to multiple platforms, in VR and for regular screen. Work in it for 3+ months so you see how with every engine dot upgrade and any of the way too many packages updating in the package manager each time instead of nice imprvements promised you get many new bugs when you try them.

We are paying for you to use a stable reliable engine, not a patchwork of marketing message package manager packages which only work together in random combinations for each platform for random short durations at best until the next update of any of the patchwork pieces breaks 10 new things.

That’s Exactly what every unity power users are feeling, At the start when I was a noob I thought unity is best but slowly when I gained a bit of knowledge about unity and started working on various projects, there is no project where I never damned by weird bugs all the time. It’s getting messy with every new update catching up like windows updates lol

Will the upcoming, new Cardboard Unity SDK will be compatible with the new Unity XR plugin system? Please let me know!

Very disturbing and disappointing.
It reminds me of Adobe a few years ago, which, after embarking on multiple technological paths, failed them drastically a few years later. This seriously undermines the credibility of Unity.
The next time Unity launches a new feature, I will seriously hesitate before offering them serenely to my customers since at best everything changes perpetually for the same techno (which poses a problem in terms of project maintenance), worse, it is abandoned …

Hi Matt, thanks for the detailed response. I am aware that all these areas are being worked on (being a heavy beta tester), but there’s a difference between “enabling Vulkan support” and “Vulkan on Quest actually working in real-world projects with ShaderGraph, Instancing and Texture Arrays” (which is of course just one example). I’m not talking about theoretical support here, but actual stuff working. I’d be happy to give more feedback about that via email, and a glimpse at the XR forums subsection should be enough to see what I’m talking about.
Also, would be great if you could give an answer to (4) – yes, XR Management is partially ready for the new input system (but says in red exclamation marks that the legacy input should be used), but XR Interaction Toolkit totally isn’t, while the pose driver situation is even worse (there’s 3 different ones now, for 2 different input systems).

(I’ll also make forum posts for this, I don’t think this blog format is very suited for discussion.)

Good news the fact that you’re working towards a write one, deploy everywhere solution, but actually now the situation is more confused than ever, with existing plugins from vendors available, but at the same time your XR tools being there… but still in beta. Furthermore, the removal of Vuforia shocks me… it was my to-go tools when developing certain kinds of AR solutions in Unity… it’s a pity it won’t be available anymore!

Vuforia will still very much be available. The mention of removal of Vuforia support from Unity is inaccurate. Our team will have a full response on the Vuforia Dev Portal soon.

Hey Matt, thanks for clarifying the state of XR in Unity. Can you share any information about whether the new OpenVR support is planned to be ready for 2020.1?

Apparently Valve is responsible for that now. So we do not know. They didn’t even bother to provide a joint announcement (Valve and Unity) that would provide clarity and delivery commitments. That is why many people are upset. Unless you are a hobbyist, your business depends on it, and you can’t make production choices with fingers crossed.

What’s wrong with you, people? This post is clearly stated that Unity WILL continue to support OpenVR. Saying literally that. But every comment blames unity for dropping support for OpenVR. Did you try read the post?

Hey Alex, you are a smart person. So read again, and think.

A. Does that mean that Unity 2020.1 is going to work with OpenVR out of the box as it used to?

B. Say you are a VR studio that has invested on Unity as its main technology platform and has planned projects lined up based on OpenVR (either on Steam or Location Based businesses) and business plans of hundreds of thousands or millions, (yours or from clients), the future of your Business, are based on these productions. Plans that in order to work at the quality level required NEED the HDRP improvements for VR that 2020.1 brings.

How are your development plans affected if Valve delays to create a plugin that is fully functional by the time 20.1 comes out? Or in the adverse chance that Valve never manages to create a fully functional plugin for whatever reason.

(There is strong precedent with other technology vendors that fell from official support)

C. As someone asked: How is someone going to create a title that works both for Oculus and SteamVR with the same project using 2020.1? As it is right now in terms of revenues and production costs, the ability to do that is crucial for a small team.

I do not understand all the whining going around in the comments here. First of all, no one forces you to move to 2019.3 and it’s probably a bad idea anyhow until LTS kicks in. OpenVR is still supported and if valve won’t do the job of eventually integrating it to the XR SDK some developers will join forces and do so.

This is actually amazing news. One SDK to rule them all and in the darkness bind them? I will serve any dark lord for this. As for the projects i’m currently working on, they’ll remain at 2018.3 LTS where they belong.

Loosen up FFS.

I am extremely excited about this important progress Unity is making in unifying the fractured VR/AR SDK ecosystem with the XR Platform architecture. We will all benefit from your thoughtful work. As an XR developer we’ve been plagued by incompatible device-specific vendor-specific platform-specific SDK and toolkits. Various other “solutions”, both open source and proprietary have serious shortcomings and limited support. Kudos to Unity for moving the industry forward in a positive direction.

Can you explain how one can make a VR game now that supports OpenVR and Oculus with the new system in a single project? That’s my main frustration at the moment.

That is to answer for Vuforia is easy. The engineering CAD company PTC bought Vuforia more than 5 years ago and really tried to leverage it with their CAD software. My company uses PTC software and we looked into Vuforia. PTC doesn’t care about Vuforia for AR gaming that is not their goal. It’s for enterprise. But the related software needed to run Vuforia is/was crazy expensive. We have price quotes to make Vuforia enterprise stuff and it was just way to costly

Hi,
The information on Vuforia no longer being supported in the blog post above is incorrect.
Vuforia Engine supports Unity 2019.3 today and will continue to support upcoming Unity versions in the future.
What is changing is that the Vuforia Engine package will no longer be distributed by Unity, but can be easily obtained from an NPM registry hosted directly by Vuforia/PTC. Check out this article to learn more:
https://library.vuforia.com/content/vuforia-library/en/articles/Solution/vuforia-engine-package-hosting-for-unity.html
Thank you.
Vuforia Engine Support

I feel the same way. This seems like an about-face to just a few years ago when Vuforia was pulled in to the Unity distribution. So now I have to make a choice between using Vuforia (which we have thousands of dollars of development and licensing costs into) and staying updated with Unity (that I pay a monthly fee for).

Why is this happening? Is this just to push your own AR framework? Was there a breakdown in your partnership? I need some answers before I can go back and tell my CEO Why we just wasted thousands of dollars.

“I need some answers before I can go back and tell my CEO Why we just wasted thousands of dollars.”

This is what the average enthusiast, and sadly and more importantly, Unity doesn’t seem to understand and care about.

This is so confusing…
How could Unity think that not showing OpenVR from the supported platforms and the tech stack is a good idea? This announcement is just bad.
OpenVR is one of the most important things for VR games, how Unity could miss that? It’s really exasperating to see Magic Leap on the list and not even OpenVR.

Also, this announcement is contradicting itself:
In the Migration to XR plugins / OpenVR part, it’s written: “Until that plugin is available, built-in support of OpenVR will continue to be functional and available in 2019.3, and we will support our users with any critical fixes.”
And just one sentence after, it’s written: “Note: Built-in support for OpenVR (OpenVR (Desktop)) has been deprecated in 2019.3.*”
Going to asterisk is even more frightening: “*Deprecation means built-in implementations are still available for use in the 2019 TECH stream and will remain in 2019 LTS. However, it is not guaranteed to remain functional as bugs and issues may not be prioritized. Additionally, the packages will be removed in future releases.”
I’m sorry, but at this point, and with all the bugs that are still not fixed with URP, Oculus Quest issues and so on, it really looks like Unity don’t care a lot about VR.

I get that this AR companies is more interesting financially than indie devs, but please Unity, don’t forget that a lot of your client are still indie devs, you reputation as a good engine is going down at high speed, right now I can’t even recommend Unity for a new project anymore. You also hurt your own reputation among players, as we sometimes don’t have the choice but inform them that all this bugs and updates delay are Unity related.

This had to be done 3 years ago. You left us alone with the providers. Although your main goal was multi-platform development, you went the opposite way in VR, it was ridiculous. The part of my job as a VR developer was to eliminate the errors in the VR SDKs offered by the providers and to work properly together. This completely undermined my productivity. I should spend my time to create content with my skills.

I hope a big lesson has been learned from now, and providers are required to make high-quality integrations. Because I’m completely tired of repairing VR SDKs. Please hire more QA person if required. Make sure integrations much better than before. And please provide understandable and detailed documentation about XR Toolkit etc.

Vuforia is no longer supported in 2019.3 and beyond…
I’m now confused with this tool.

It’s not that long since Unity partnership with Vuforia. So we put around 400$ and buy a license, invest time to learn the product. Then the license changed to a monthly fee (just because « The Cloud » you know). Finally, Unity starts to put extra layer of XR on his own, things get messy and now the partnership seems to be over.
So on one side you have Vuforia, a now-expensive SDK no more officially supported by Unity, and on the other side Unity own solution with mixed result and poor feature set.

It’s starting to be difficult to explain to my colleagues and clients that I’m no longer able to carry out certain projects, or that they now have to pay per month and above all see no real change.

I’m getting more and more concerned about the evolution of Unity.

Vuforia will still very much be available. The mention of removal of Vuforia support from Unity is inaccurate. Our team will have a full response on the Vuforia Dev Portal soon.

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

“Built-in support for Windows MR (Windows Mixed Reality) has been deprecated in 2019.3.* ”
“OpenVR is no longer a Unity supported platform in 2019.3 and beyond.”

Horrible news.
Steam is the most important VR platform and WMR is one of the very popular enterprise device families.

You owe a very solid explanation to the VR community supporting Unity and a very good reason why we should not move to a different engine.

This is quite sad. So Unity is again dropping support for a feature in favor of something thats not yet working or even released. And this one especially hurts since Im heavily invested in VR.
If I didn’t have so much time and money sunk in Unity Id be jumping ship about now…

I am jumping asap. Migrating my next project as I type. I do not feel betrayed, I feel sabotaged and if I could, I would sue.

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?

I hope that “Universal” support come to reality soon as Unity 2019 and also URP or Post Processing Stack has been a step back in VR reliability.
No need to submit more bug reports – just try Oculus Quest with URP.

When you say “OpenVR is no longer a Unity supported platform in 2019.3 and beyond. Valve is currently developing their OpenVR XR Plugin” does that mean their plugin will work with XR Interaction Toolkit like other Unity supported plugins?

Dropping support for OpenVR is killing me. How are we supposed to
continue developing for multi-platform XR when this type of curveball Is being thrown? I currently have several 2019.3 projects built for OpenVR (some multi-platform) perhaps this move by Unity is premature? I’m
About to kickoff anothe major VR film in 2019.3 + OpenVR and am really feeling burnt at the moment. I should stop now before I seriously go off on a screed.

Some update on Vulkan for Oculus Quest/Go rendering would be great, as well as Vulkan Fixed-Foveated Rendering support for VR (cross platform FFR). Also still clueless as to what is happening with UniversalRP for VR since that is meant to be the new standard for rendering when the built-in renderer is eventually deprecated?

It’s a start… things HAVE been a bit tits up recently so lets hope there’s a strong Universal Pipeline Vulkan future for all of us Tron fanciers.

so official word on OpenVR is what was already stated, that it is no longer a Unity supported platform in 2019.3 and beyond. Okay, can we get a breakdown on WHY?!?! 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?

Comments are closed.