Official Improving Project Configuration for AR/VR

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.

 

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"

 

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 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!)

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

3. 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).

 

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 .

 

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

 

@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

 

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.

 

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?

 

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?

 

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();

 

• 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();

 

[/QUOTE]

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