Search Unity

Question Swapping XR Subsystem throughout the lifecycle of an application

Discussion in 'AR/VR (XR) Discussion' started by fherbst, Jul 15, 2020.

  1. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    802
    From the blog posts and docs this is not quite clear I think – is it possible to change the XR backend used by an application throughout it's lifecycle?
    The reason for this is that there are devices and platforms coming up that allow for different feature sets during a single run – e.g. WebXR, which would allow an application to seamlessly switch between Desktop usage, AR usage, and VR usage either during the exact same session.

    A good example of this is here: https://de-panther.github.io/unity-webxr-export/Build/
    This is currently not using an XR Management backend (but rather custom code do send camera matrices around), but could move to XR Management if changing subsystem on the fly was possible.
     
    Last edited: Jul 15, 2020
    fherbst, Jul 15, 2020
    #1
    De-Panther likes this.

  2. joejo

    joejo

    Unity Technologies

    Joined:
    May 26, 2016
    Posts:
    958
    There is no supported option for changing loaders at runtime. If you need to flexibly move between different subsystem sets and XR platforms types on the same build target you'll need to manage all that your self.
     
    joejo, Jul 15, 2020
    #2

  3. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    802
    Managing it is fine, can you elaborate on what parts are missing? Are the basics there – e.g. starting/stopping subsystems, Unity not crashing when doing so, other pieces of Unity-side code properly picking up changed subsystems?
     
    fherbst, Jul 15, 2020
    #3
    De-Panther likes this.

  4. joejo

    joejo

    Unity Technologies

    Joined:
    May 26, 2016
    Posts:
    958
    1: starting/stopping subsystems:
    Yes
    2: Unity not crashing when doing so:
    That's a little overly broad but if that were the case you'd run into crashes all the time. We manage starting and stopping subsystems all the time without issue.
    3: Other pieces of Unity-side code properly picking up changed subsystems?
    What do you mean by changed subsystems? As long as there is a UnitySubsystemManifest.json file that describes the information needed for us to find, create and manage the subsystems at launch you should be fine.
     
    joejo, Jul 15, 2020
    #4

  5. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    802
    Thank you!
    Regarding the crashes, as you said Unity does not support / test / use changing subsystems at runtime (not at launch, but during an app running). So not sure if we're talking about the same thing here.

    Maybe I'm understanding this a bit wrong – for the usecase laid out above – an app supporting Desktop (no XR), ARFoundation, and VR at the same time during the same application lifecycle –, would I build one complex uber-subsystem with all the features and then somehow dynamically turn them on and off, or (what would make more sense to me) create separate backends that are completely switched out for each other? (or in the case of desktop, unloaded).
     
    fherbst, Jul 15, 2020
    #5

  6. joejo

    joejo

    Unity Technologies

    Joined:
    May 26, 2016
    Posts:
    958
    Not really 100% sure as I don't believe we've ever tried anything like this. My suggestion would be:

    1) Make a loader for each set of features you want to use at a time. And make sure you have a UnitySubsystemManifest.json file (or files) that define all the supported subsystems and what libraries they use.
    2) Make sure that the loader list in management has all the loaders in it that you want for the platform you want.
    3) Make sure you disable "Initialize at Startup" so that you control XR lifetime yourself.

    At this point you can manually init, start, stop, deinit a loader (and this all the subsystems it is managing) yourself.

    Here is where I'm actually not sure how well this will work: At runtime you have access to the loaders list. You can't replace the list, but it's possible the you can adjust the ordering within the list. Doing that before you init the system should allow you to switch the first potentially active loader. Now, should that loader fail to init, management will fall back to the next loader in the list as that is it's primary function.

    Now all of this presumes that you already have packages supporting all the subsystems and libraries you are wanting to use. If not, then you'll need to make your own package(s) with full provider support for XR Plug-in Management.
     
    joejo, Jul 16, 2020
    #6
    De-Panther likes this.

  7. fherbst

    fherbst

    Joined:
    Jun 24, 2012
    Posts:
    802
    Thank you, sounds do-able and something that I can test against. Will let you know hot it goes :)
     
    fherbst, Jul 16, 2020
    #7
    De-Panther likes this.