Improving Project Configuration for AR/VR

Unity Engine
,
1

XR Plug-in Management
In 2019, Unity migrated its AR/VR platform integrations to support a new plug-in framework (XR SDK) that improved our ability to address issues more quickly, distribute SDK updates from our partners more easily, and unlock performance optimizations for hardware vendors. Part of the update involved “XR Plug-in Management”, a new UI system for managing AR/VR platform support in your projects. We have been working on improving the overall user experience and project configuration process, and want to share our latest updates.

New Improvements
We have released a new version of XR Plugin-Management (3.2) that reduces the number of steps required to enable AR/VR in your project. It is verified in Unity 2019.3 and later, and we recommend upgrading to XR Plug-in Management 3.2 to use this interface.

Note that we’ve listed currently known issues at the end of this post.

kindheartedoptimisticconey
Left side displays initial workflow (XR Plug-in Management 3.0); right side displays improved workflow (XR Plug-in Management 3.2)

Previously, we required multiple steps to install and load XR plug-ins for device support and input tracking. We’ve now streamlined that workflow using a checkbox system that will automatically enable the appropriate XR plug-ins for the corresponding build target with a single click.

1318×898 91.8 KB

Project Settings window using XR Plug-in Management 3.2

Using XR Plug-in Management
To configure a new Unity project for XR, follow the steps below. Note that using the Package Manager is not required.

  • Open the Project Settings window (menu: Edit > Project Settings), and select XR Plug-in Management.

  • Click Install XR Plug-in Management if the package hasn’t been installed already. You can also install it from the Package Manager window.

  • After the installation completes, select a Plug-in Provider to enable it for the corresponding build target. To do this:

  • Select a build target (for example, Android).

  • Select the checkbox to the left of each plug-in you want to use for that build target.

  • Note: The appropriate plug-in package will be installed if it’s not already present.

  • After a plug-in loads, its name is displayed in the navigation panel on the left-hand side of the window, under XR Plug-in Management. Click the plug-in to configure its settings for each build target.

The above can also be found in the Unity documentation manual.

Setting Up Tracking
To make sure XR tracking is properly configured in your project, follow the steps outlined in the Unity documentation manual. We recommend using the “XR Rig” for tracking, though adding a “TrackedPoseDriver” to the main camera will also enable tracking.

Provide Feedback
While we’ve done extensive testing to make sure the latest version of XR Plug-in Management (3.2) works with all of our supported XR plugins and related packages (AR Foundation, URP, HDRP), we want to hear from you. Leave us a comment in this thread with any feedback on the new improvements, or any issues you may have encountered.

If you are reporting an issue, please include the Unity Editor version you’re using and any other packages in your project so we can best understand the issue.

Known Issues

  • Restarting the Unity editor may be required after any XR plug-in is upgraded / uninstalled from the Package Manager. Otherwise, entering “Play Mode” using any XR plug-in provider will not work. We are working on a fix for this issue.
  • Converting your Main Camera to an XR Rig for tracking may produce the following error when using the Universal Render Pipeline: Your Main Camera has additional components that we do not recognize. We are unable to automatically convert your scene. Please see the documentation on how to upgrade your scene. We’re working on a fix for this issue.
2 Likes
2

Is it possible to bring back the loader plugin list order to arrange which way the plugins now load? That feels like the biggest change aside from the improvement of setup time, we now have to make a script to rearrange the order the plugins load.

3

EDIT: this probably was too negative. Removed some bits.

This seems to be more confusing and harder to work with than the existing setup.

I appreciate that you’re trying to make it easier. Many people screw it up but only because there was zero messages / dialogs, and so you needed to go into Project Settings and actually view it - which is something you’ve never before needed to do for UnityEditor features, so it was something people didn’t even think of doing - at which point it is 100% obvious what you need to do. All they needed was one popup or console log to say “you now need to go into Project Settings and reivew what is there”. Even better: automatically open it.

Given we have to have this new UX instead, I’m adding a vote for:

“please can you add an option for us to use the previous UI that already worked great”

4

Also a few side notes / feedback:

  1. Scanning HMD’s and interacting with “what the user has installed” is a real and bigger problem for me on this area right now (by the sounds of things, @ROBYER1_1 has got it working well in 2019.3 - if you have pointers I’d be grateful :)) but I have not, and I’ve asked around a lot and read everything I could find: I still haven’t found the magic setup that lets a project run without HMD, with HMD, and with two different HMDs, all without any errors on console.

i.e. programmatically, within the scene, and within 3rd party libraries/frameworks (think: AssetStore assets!)

  1. I’m all in favour of better UX, and glad to see how much activity your team(s) are putting in here right now :). Unity XR has the potential to be great.

  2. If it doesn’t work with 2019.3 then you’re going to get misleading/inaccurate feedback.

EDIT: we already have a new thread by someone who “updated to 3.2 with 2019.3 and now everythign is broken. What’s wrong?” That was fast! But yeah … the minimum standard should be “works in 2019.3 or isn’t published” IMHO.

TL;DR: Serious devs aren’t touching 2020. Major problems with SRP (which is a huge mess - well documented on these forums already), serious bugs everywhere (got my first 100% reproducible UnityEditor-crash for the last five years … with 2019.3. Prefabs and ScriptableObjects are fundamentally broken and being fixed (or trying to - not succeeded yet) by Unity teams - and this is major core engine components. We need this to be stable before 2020 is a realistic option).

5

Also … the “known issues” list is hugely helpful. I think some Unity teams underestimate how valuable it is to us as developers to see these up-front and manage our own upgrade strategy, and plan whether to upgrade now or later - and pre-test / post-test what we need :).

6

Hi @a436t4ataf , thanks for your feedback. I’m going to respond to the parts that are relevant to this post’s topic; feel free to send me a DM regarding other topics you touched on and I’m happy to chat.

You mentioned that our new changes seem to be more confusing and harder to work with than the existing setup. To clarify what you mean by “existing setup”, are you referring to XR Plug-in Management 3.0? I’m curious to understand how the new improvements have made things more challenging for you. In the existing setup, users have to install XR plugins, add loaders for each of those plugins, install a separate package for device tracking, and add a TrackedPoseDriver to enable tracking. There were too many steps involved, let alone terminology that users frankly shouldn’t have to learn. With our new improvements, we’ve removed all of those requirements and now all a user has to do is select the platform they want to enable in their projects.

You did mention (looks like you edited it out now) that the text we included in the UI is a reflection of how poor the UX is. We included that detail there for clarity, but perhaps it’s causing a misperception of how simple this workflow now is. We’ll consider moving those implementation details to our documentation.

You also mentioned the idea of automatically opening Project Settings to enable XR. The problem with that is not every user is developing an AR/VR experience. However, we are exploring additional ways to further improve project configuration for XR – these include XR project templates, setup assistants, and more. We’ve also significantly improved our documentation manual to help our XR developers get started quickly.

Regarding 2019.3, we’ve done extensive testing on both 2019.3 and the 2020.1 beta. This includes testing for all supported platforms, on both these releases, and in scenarios where a new project is created / project upgrades from XR Plug-in Management 3.0 to XR Plug-in Management 3.2 / project upgrades from built-in XR to XR Plug-in Management 3.2. That ends up totaling multiple rounds of more than 150 test passes! We haven’t found any issues (beyond currently known issues) in either of the releases, but even then, we know there’s always a chance that an issue gets discovered in the wild. That’s why at this point in time we recommend testing these new improvements using the 2020.1 beta release. Once we have sufficient validation from the community, we’ll proceed to releasing a verified version of XR Plug-in Management 3.2 and communicate that developers can upgrade their 2019.3 projects to this new version in time for the 2019 LTS release. To summarize, we recommend creating a new project using the 2020.1 beta if you’re interested in testing the new workflow. Otherwise, users with existing projects in 2019.3 should hold off on upgrading XR Plug-in Management until we have a verified version of 3.2 available.

Lastly, you asked if there’s an option to remain using the previous UI. Projects using XR Plug-in Management 3.0 will still work, and if you still prefer that UI, that option will still be available. Thanks again for your feedback and let us know if you have any additional questions!

1 Like
7

Hey @ROBYER1_1 , current solution for arranging the way plug-ins load is to use a script. We don’t have further plans than that as it is not a common requirement, but we’re aware that there are some who need that functionality so we’ve documented it and included a sample script.

Would be great to understand the outcome you’re trying to accomplish that requires re-ordering, and we’ll definitely take that into consideration.

3 Likes
8

Thanks for the detailed reply. I’m suddenly very busy this week, didn’t want to leave it longer without respinding, so here’s a brief response:

It sounds very difficult when phrased like that, but that doesn’t fit with my experiences in reality (both as an individual doing this many times, and when coaching novice developers through it). I’ve had to do this myself a lot more than I would like :slight_smile: (each time I log a bug on XR, I have to re-do this whole dance from scratch - incidentally: I’d greatly appreciate something that sped that up. I’m considering making a pre-made empty XR project just so that I can clone it for new bug reports).

But I’d phrase it as: “There are a small number of giant, easy to read, buttons with very short, clear text. It’s largely idiot-proof assuming someone opens the ProjectSettings Window”. The process as a user/developer is approximately:

Click. Click. Wait. Click. Click. Wait. Click. Click. Click. Done. (not actual sequence, but pretty close I think)

Total mental effort? About as much as it takes to stare out the window and sip coffee for a few minutes while I think of something else, waiting for the progress bars to finish. The issue is more how long it takes waiting for all the file-downloading and copying.

I decided my tone might sound unfairly critical and aggressive, and was in danger of overshadowing the meaning. The intent was: if a UX is sufficiently non-obvious that it requires sentences of docs embedded in it, then it’s failing at the things you have been saying it fixes/is intended to fix (simplicitly, low cognitive load, etc).

e.g. As someone who’s recently built a lot of XR projects, I made three attempts at parsing the sentence and still couldn’t understand what the significance and side-effects of it were - did I need to change something? Do I have to watch out for future issues that I don’t currently? - I couldn’t figure it out.

If it’s needed, then it’s needed. I wouldn’t remove it if it’s needed. Moving it elsewhere won’t change that. But if it’s needed in the UI, then there’s something non-user-friendly … somewhere … in the system that’s forcing that need in the UI - with the overall effect of weakening / undermining otherwise good UX.

If they’re not making an AR/VR experience, why are they using XR? Is there some other tech it’s used for? Sorry for my ignorance here! I thought it was purely AR/VR (hence the X in XR?)

But let’s take a lead from the commercial plugins in AssetStore: they’re judged on star-ratings and it’s “survival of the fittest” for the ones that are easy to use. Generally the UX on (good/top) AS plugins is much higher than in Unity core features - which is to be expected: these guys live or die on their UX, so they have to put a lot of extra effort into it.

And … they pop-open windows like the ProjectSettings automatically when the user installs something that needs them to go there. I’ve seen it a bunch of times (and used the API that does it myself!)

(incidentally, there’s a bug in 2019/2020 I haven’t got around to logging: opening ProjectSettings programmatically sometimes fails (e.g. if the PS window is in a tab that’s not currently open - instead of opening the tab, UnityEditor silently fails). Maybe the presence of that bug is why this wasn’t done autoamtically by the current/original XR UI?)

Sounds exciting - I look forward to trying these out. From your comment below, 2019.3 should be a safe enough testbed, but I’ll probably wait til next week when I have time to make a new project with a sandboxed Editor, and make sure I don’t break an existing one :).

9

@mfuad That’s fine for now, we can disable the plugins we don’t want to run at editor time, we develop on many different headsets in 1 project, I would often re-order the plugins in the list to sort out which headset plugin was used by the Editor first e.g. Oculus running before SteamVR if we wanted to use Oculus specifically.

I have also found the following bugs on Unity 2020.1.0b5

1237811 (Open) [XR Management] XR Management 3.2.6 settings menu is greyed out in a new project
1237805 (Open) [XR Management] The tickbox of plugin loader selection boxes does not allow you to enable/disable them

10

@ROBYER1_1 Is this on Windows or Mac? If on Windows, When you can repro the grayed out state, can you check the registry under Computer\HKEY_CURRENT_USER\Software\Unity Technologies\Unity Editor 5.x and see if you have a value starting with “Installing XR Package”? If so can you do the following:

  1. Double click that Value and either copy the data or take a screen shot and reply back with that?
  2. After 1, delete that value and see if you get out of the grayed out state?
11

So now I’m hearing a different point of feedback :slight_smile: Initially, you had mentioned the new UI is now more confusing and harder to work with. Now you’re saying it requires no mental effort, but it’s the wait time that’s felt painful. And to clarify, I think the process you described is the UX that we have just improved? Have you tried the new improvements that landed in XR Plug-in Management 3.2? I think we’re on the same page here in that the existing setup was unnecessarily cumbersome, like I described. I hear you on the wait times, but our new improvements with XR Plug-in Management 3.2 have reduced the overall time it takes to configure your project by about half. That’s fairly significant, so we’re hopeful that this new UI will be received well by our users.

Agreed, I think our intent to add clarity may be undermining our new UI that is now self-evident. Great feedback.

I should have expanded on this one; not every user is developing an AR/VR experience and thus won’t need Project Settings to automatically pop-up with our UI. Unity is used for everything and anything – an open-world multi-player FPS title, a match-3 mobile game, an animated TV series, etc. Once we’ve captured a user’s intent to create an AR/VR experience though, we absolutely want to make the project configuration process as streamlined as possible. And we’re thinking through ways that won’t necessitate things like opening Project Settings.

2 Likes
12

Well the PC was switched off after and when I turned it on today I couldn’t find the key in the registry but now the XR Management windows work fine.

The cause of the problem was identified and I have updated the bug case with more information as I was able to reproduce it today.

13

@ROBYER1_1 Thank you. This will be resolved in management 3.2.7.

1 Like
14

Used them a bit this week. As a developer, I noticed that I had to press one less button (the one where you had to press the button to “install legacy input”). Total install time felt noticably quicker - I did a few projects, and it felt like about 2x as fast to get to the point where XR is running. The biggest pain point now is how long it takes Unity to create a new project :).

Sadly, I also had a crash-to-desktop on an empty project where all I’d done is install XR, create a UI Canvas, add a textfield and hit Play. I’ve sent in the crash-report for that - the 3.2 plugin is the only thing in that project that was new/changed, so it might be related (or it might just be coincidence - since Oculus does automatic “upgrades” we can’t seem to disable, they could have broken something in the background).

If someone has selected “install XR package” from the package manager then they’ve pretty much declared that the ARE developing such a thing, no? My point was that: as soon as XR anything is installed (Which is the user’s first step), you know they are setting up an XR project, so there’s no uncertainty left: they need to go to project settings, so why not send them there?

15

For those who are keeping tabs on updates in this thread, I posted a few announcements here . We have now published a verified version of XR Plug-in Management 3.2 in 2019.3 and later, and recommend upgrading to that version moving forward.

16

Hi @mfuad I tried today to use the option Convert Main Camera to XR Rig, but it produces an error (empty scene, just created):
Your Main Camera has additional components that we do not recognize. We are unable to automatically convert your scene. Please see the documentation on how to upgrade your scene.
UnityEditor.GenericMenu:CatchMenu(Object, String[ ], Int32)

Is it because of the Universal Additional Camera Data script attached by the URP to the camera?

1 Like
17

Hi @alevillalba , you’re correct and this is a known issue. A fix is coming soon, we’ll keep everyone updated once that’s released.

1 Like
18

I have big problems with XR Plug in my HDRP project (with oculus rift s).

With XR Plug-in Management
what should i use to have the controllers working in oculus rift?

In my scene i have FPSController->FirstPersonCharacter.
If i attach to FirstPersonCharacter an tracked pose driver component the image in Oculus result mono (not stereo).
If i attach the XRRig prefab gameobject to FPSController the image in Oculus is ok (stereo) but the controllers are ignored, i cant move or rotate with them.

Others problems are: the planar reflection probe is wrong clipped and i must disable bloom because bad rendered in sx eye. The screen space ambient occlusion is also inusable if the fps are low.

I would like to initialize xr drivers in scripts but those commands don’t work:

XRGeneralSettings.Instance.Manager.InitializeLoader();
XRGeneralSettings.Instance.Manager.DeinitializeLoader();

19

  • Add TrackedPoseDriver to both hands and the Main Camera

  • Main Camera: Under Tracked Pose Driver:

  • For Device select: “Generic XR Device”

  • For Pose Source select: “Center Eye - HMD Reference”

  • Left hand:

  • For Device select: “Generic XR Controller”

  • For Pose Source select “Left Controller”

  • Right hand:

  • For Device select: “Generic XR Controller”

  • For Pose Source select “Right Controller”

XRGeneralSettings.Instance.Manager.InitializeLoader();
XRGeneralSettings.Instance.Manager.StartSubsystems();

20

[/QUOTE]

Yes precisely, I would like to tell you a few words about the restart of the Unity editor