Creating an XR provider

An XRAn umbrella term encompassing Virtual Reality (VR), Augmented Reality (AR) and Mixed Reality (MR) applications. Devices supporting these forms of interactive applications can be referred to as XR devices. More info
See in Glossary provider is part of a Unity project and minimally consists of a manifest file and one or more native plug-insA set of code created outside of Unity that creates functionality in Unity. There are two kinds of plug-ins you can use in Unity: Managed plug-ins (managed .NET assemblies created with tools like Visual Studio) and Native plug-ins (platform-specific native code libraries). More info
See in Glossary. It can also include other assets such as scriptsA piece of code that allows you to create your own Components, trigger game events, modify Component properties over time and respond to user input in any way you like. More info
See in Glossary and images. As long as these are in your project when you launch the Editor, Unity discovers them.

Note: You must relaunch Unity whenever you change a provider’s manifest or Editor native plug-inA platform-specific native code library that is created outside of Unity for use in Unity. Allows you can access features like OS calls and third-party code libraries that would otherwise not be available to Unity. More info
See in Glossary.

File layout

Native plug-ins must be in a subfolder relative to the manifest file, UnitySubsystemsManifest.json, and no more than two folders below the manifest itself.

UnitySubsystemsManifest.json

This manifest contains information about your provider, such as the subsystems it provides and the plug-in name.

For more information, refer to the UnitySubsystemsManifest.json page.

Building a provider plug-in

To learn how to build a native plug-in for your targeted platform, refer to documentation on the Unity native plug-in interface. After you get your dynamic library into Unity, ensure that all the options (such as the target platform in the Plug-in Settings) are correct.

You need to register a lifecycle handler for the subsystems that you intend to implement. For example:

extern "C" void UNITY_INTERFACE_EXPORT UNITY_INTERFACE_API
UnityPluginLoad(IUnityInterfaces* unityInterfaces)
{
  s_XrDisplay = unityInterfaces->Get<IUnityXRDisplayInterface>();
  UnityLifecycleProvider displayLifecycleHandler =
  {
    NULL, // This can be any object you want to pass as userData to the following functions
    &Lifecycle_Initialize,
    &Lifecycle_Start,
    &Lifecycle_Stop,
    &Lifecycle_Shutdown
  };
  s_XrDisplay->RegisterLifecycleProvider("Provider Plugin Name", "Display0", &displayLifecycleHandler);

  // Register with other subsystems
}

Note: The parameters passed to RegisterLifecycleProvider must match the name and id fields in your manifest file.

When you call your Initialize method at a later point, you get an instance handle you can use to call methods that take a UnitySubsystemHandle. Example:

/// Callback executed when a subsystem should initialize in preparation for becoming active.
static UnitySubsystemErrorCode UNITY_INTERFACE_API Lifecycle_Initialize(UnitySubsystemHandle handle, void* data)
{
  // Register for callbacks on the graphics thread.
  UnityXRDisplayGraphicsThreadProvider gfxThreadProvider = { NULL, NULL, &GfxThread_WaitForNextFrameDesc, NULL };
  s_XrDisplay->RegisterProviderForGraphicsThread(handle, &gfxThreadProvider);

  return kUnitySubsystemErrorCodeSuccess;
}

The SDK package includes an example project that builds sample plug-ins.

Loading in Unity

For more information about loading your provider in Unity, refer to the Runtime discovery and activation of subsystems page.