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.
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.
This manifest contains information about your provider, including the subsystems it offers and the plug-in name. It’s important to note that the xreditorsubsystem
keyword should be included in the package.json
file of any package that defines subsystems in UnitySubsystemsManifest.json
and requires these subsystems to function within the Unity Editor. The presence of this keyword is essential for ensuring that the Unity Editor recognizes and properly discovers these subsystems. Without this keyword, subsystems intended for editor usage may not perform as expected, though this does not impact the player build process.
For more information, refer to the UnitySubsystemsManifest.json page.
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.
For more information about loading your provider in Unity, refer to the Runtime discovery and activation of subsystems page.