Search Unity

  1. Good news ✨ We have more Unite Now videos available for you to watch on-demand! Come check them out and ask our experts any questions!
    Dismiss Notice

Is the list of supported VR devices used by Unity at all?

Discussion in 'AR/VR (XR) Discussion' started by MrDude, Oct 2, 2018.

  1. MrDude


    Sep 21, 2006
    Hi all

    I have run into an issue that I am considering a bug...
    Perhaps someone here can share some info to prove me wrong (PLEASE, PLEASE DO!) :

    What happened
    I installed the Oculus SDK into my project and now every single Android build demands that the phone be placed in a GearVR.

    This happens when my XR list contains "DayDream, None", "None, DayDream", "None, Daydream, Oculus" as well as when XR support is completely disabled.

    Why is the Oculus SDK being loaded when XR support is completely disabled? Why is it still active when I disable it at runtime?
    Why is it loaded when it's not in the list of supported devices?

    Unity warns that if you want to avoid initialisation issues when using conflicting SDKs then it would be recommended to duplicate your project and change the XR devices lists. Okay... but why then does the Oculus SDK get initialised even when it's NOT in the list with Daydream OR even in the list at ALL or even when XR is completely disabled?

    Surely that is not right, is it?

    How can you reproduce this error?
    Create a new project, set the build target to Android, add the Oculus SDK, now do anything you can think of to NOT build a GearVR project, watch as you fail every time.

    I even went as far as to do this during Start of my bootstrap scene:
    Code (csharp):
    1.         async void ForceEjectOculus()
    2.         {
    3.             while ( true )
    4.             {
    5.                 if ( XRSettings.loadedDeviceName == EVRDevice.Oculus.ToString() )
    6.                 {
    7.                     if ( project_data.TargetDevice == EPDTargetDevice.Gear_VR || project_data.TargetDevice == EPDTargetDevice.Rift || project_data.TargetDevice == EPDTargetDevice.Oculus_Go )
    8.                         return;
    9.                 }
    10.                 XRSettings.enabled = false;
    11.                 await Task.Delay( 150 );
    12.             }
    13.         }
    but it seems the SDK is initialised first and then my code is not run until after it is plugged into a GearVR so my code is useless.

    I can give you another example also:
    Install the GoogleVR SDK and turn off XR support. Now the project can't even build because the SDK demands XR support be enabled even if the SDK is not in the list of devices I want to target. Why does it need XR to be enabled if I'm not going to target it in this build?

    So my question is twofold:
    1. Does the supported device list serve any purpose at all?
    2. How can I NOT build for GearVR when I have the Oculus SDK in my project?
  2. EdBlais


    Unity Technologies

    Nov 18, 2013
    You've run into a less common and unfortunate scenario, but it is not a bug, just a poor situation that doesn't have a good solution.

    What is actually happening, is that you have added the Oculus SDK/Utilities to your project. In doing so, the Oculus plugin has been added to the Plugins/Android directory of your project as OVRPlugin.aar. That same plugin is normally shipped with Unity, but the Utilities may have provided a different version of the Plugin than what was shipped with the version of the Editor you are using. However, when the asset is in your project, it does not behave based on the player settings functionality and instead uses the plugin import settings. So, by adding the utilities to your project and accepting to take the plugin from the utilities, you're essentially adding an Android .aar that will be copied to all Android builds regardless of the Player Settings for XR.

    The above normally wouldn't be an issue, but Gear VR requires a specific Android manifest entry in order to start. That manifest entry exists in the OVRPlugin.aar's manifest that you now have being copied to every Android build. Therefore, every Android project that you make with that project will automatically see the manifest entry on Gear VR compatible phones and will start in Gear VR mode even if the app cannot run as a Gear VR application.

    The android manifest and Gear VR functionality isn't controlled by Unity and there is no way for us to work around it currently. It's a feature that Oculus and Samsung originally implemented when first making the Gear VR. They are working to resolve this issue, so that apps aren't forced into Gear VR mode, but it is not available yet.

    A similar thing happens for Daydream and the GoogleVR SDK. By adding the SDK to your project, there are scripts that prevent building the app unless you have toggled certain player settings. Those scripts are not controlled by Unity, and therefore you'd have to reach out to Google to help resolve making non-daydream/cardboard builds while still having the GoogleVR SDK in your project.

    And to finally answer your questions:
    1. Does the supported device list serve any purpose at all?
    It serves a purpose when you have not added additional third party XR libraries to your project that Unity does not control. I do agree though, that the list isn't extremely self explanatory, and we are working internally to find a better way to handle this. Unfortunately, we don't have a definitive solution yet, so we're open to suggestions.

    2. How can I NOT build for GearVR when I have the Oculus SDK in my project?
    The easiest thing to do is to disable Android in the plugin import settings on the OVRPlugin.aar and then build.
    MrDude and JoeStrout like this.
  3. MrDude


    Sep 21, 2006
    Thanks a bunch @Ed-unity
    That is quite informative!!!

    May I make a query at this point? If I were to remove the latest and greatest version of the Oculus SDK from my project and just use the internal version, would that then enable me to turn Oculus builds on or off just by either calling the LoadDeviceByName function or not? If I just sacrifice the latest version of the SDK will that fix all my woes?

    Next question... Why does one become two?
    The Oculus SDK comes in the form of a unity package that you install and you are done with it. Unity offers you both a desktop and a mobile version in the package manager. What's up with that? Do I need both or just one or why exactly do you have two versions when Oculus only has one? I've just always used the latest and greatest version so I never bothered much with the two versions but I was always rather curious as to why there are two...

    Small suggestion
    One thing that kept me busy for a few days was trying to figure out what to add to the devices list so the device/platform would actually appear. I mean, I would have "Daydream (not installed)" right above "Daydream" in the list (for example). I tried looking around for a list or an enum or something that could help me figure out what to go in there but I found nothing. All I found was that I can place strings in there and I can read strings back and that was that. EVENTUALLY I discovered that SOME platforms mut be written in all lowercase while others (Like Oculus) must NOT be written in all lowercase. Figuring this out was all trial and error.

    Choosing between oculus and Oculus was simple enough but choosing between openvr, openVR, Openvr, OpenVR, OpenVr, SteamVr, steamvr, etc and each time waiting for the SDK to install, seeing if the item is listed, changing to another build target then changing back to that one and seeing if it exists NOW, then doing it again.... it was a pain. Could you PLEASE replace the string[] with an enum[] instead? Please?

    Again, thank you for that very helpful post! Much appreciated!

    So I tried it out and deleted the Oculus SDK from my project. As soon as I have both Daydream and Oculus in the devices list Oculus (even with None first in the list) still takes over and it demands a GearVR but as soon as I remove Oculus from the list it builds a DayDream app. Easy as that!

    Again, thanks a bunch!

    P.s. Just as a side note, though: I don't currently have either of the Oculus packages installed under packages. So if the Oculus SDK is built right into Unity itself, then what is those two packages for, exactly? Oculus has one, you have two and yet we can get away with using none of the above...? Colour me more confused than ever about those two SDKs... :O
    Last edited: Oct 2, 2018
  4. EdBlais


    Unity Technologies

    Nov 18, 2013
    Looks like you tried this and made an edit in your post below, but just to confirm, if you have Virtual Reality Support enabled and Oculus anywhere in the XR SDK list, when you build for Android only (this does not happen on Windows) you will still end up being forced into a Gear VR application and be unable to switch in an out of VR mode with LoadDeviceByName. This is because the OVRPlugin.aar that we ship also has to include the manifest entry for Gear VR to work, but we will only copy the plugin if VR Support is on and Oculus is in the list.

    As you have noted, with Unity 2018.3 and up, Oculus is now provided as a package through the package manager. It is also split into a package for Standalone and a package for Android. The reason that we split the contents was partially because of the manifest entry, but mainly influenced by the fact the not everyone who is building their app for Standalone is also building for Android and vice versa. By splitting the contents, it helps reduce project size and keeps builds cleaner.

    Answer for your Edit:
    If you are on 2018.2 or lower, the SDK contents are included directly with the Editor and the packages should not be used. I believe a version is currently showing on 2018.2 that we will be removing from the server soon as it does not actually work with 2018.2. (It was our original goal to have to packages in 2018.2, but we had to push back to 2018.3, that's why they are there)

    This is something I also agree with and we will likely be resolving during the 2019.x cycle, but it's probably something we can add to 2018.3 as well. For now, the easiest way to check the strings is by using the Get after adding the ones you care about to the list through the PlayerSettings and then copy them into an array.

    The reason we use a string is modularity. We have a goal to be able to allow third party developers to create XR SDKs without needing a partnership with Unity and hard coded functionality in the Editor. As part of this, we need every type/container to be modular enough for third party developers to be able to add to the list. If we used enums, it would not be possible. If we did provide at least a list of all available strings for the player settings, this would resolve most of your pain. That is our fault, and like I said above, we'll aim to rectify this pain soon.
    MrDude likes this.