Subsysteme — MRTK3

MRTK3 nutzt die Unity XR Subsystem-Management-Infrastruktur zum Schreiben erweiterbarer Module, die Ihnen helfen können, plattformübergreifende Unterstützung für Features wie Sprache und Handverfolgung bereitzustellen. Diese Subsysteme werden von Unity initialisiert und geladen, neben den vorhandenen Unity-nativen Subsystemen wie XRMeshSubsystem und XRInputSubsystem. Mehr dazu finden Sie in der Dokumentation zur Funktionsweise von Unity-Subsystemen.

Philosophie

In MRTK v2 stellten „Dienste“ einen großen Teil der Funktionalität in der Szene selbst zur Verfügung. Sie übernahmen die Instanziierung von Objekten, das Positionieren von Objekten, das Aktualisieren der Szenenhierarchie usw. In MRTK3 ändern die Subsysteme die Szene nicht explizit. Die MRTK3-Subsysteme sind modulare Anbieter von Daten, Informationen oder Ereignissen, oder sie führen Berechnungen für Endbenutzer aus. Wenn sich etwas in der Szene ändern soll oder eine Aktion auf der Grundlage der Dateneingabe erforderlich ist, muss eine separate szenenbasierte Visualisierungskomponente vorhanden sein, um auf die Daten zu reagieren. Durch diese Aufteilung wird sichergestellt, dass die Subsysteme hinsichtlich Szenenänderungen nicht destruktiv sind und keine szenenbezogenen Nebenwirkungen verursachen.

Während MRTK v2 Systeme und Dienste für die Verarbeitung von Eingaben tolerant verwendet, verwendet MRTK3 in der Regel OpenXR und das Unity-Eingabesystem für plattformübergreifende Eingaben. Einige Datentypen werden jedoch noch nicht vom Eingabesystem umschlossen. In diesen Fällen bieten wir plattformübergreifende Schnittstellen über unsere Subsysteme.

Lebenszyklus von MRTK-Subsystemen

Die Subsystemdefinitionen, die in der Unity-Infrastruktur enthalten sind, bieten einfache Lebenszyklusmethoden wie Start, Stop und Destroy. Wir erweitern diese Definition um nützliche „Takt“-Methoden wie Update, LateUpdate und FixedUpdate. Unser MRTKLifecycleManager verwaltet Subsysteme, die unsere Lebenszyklus-Schnittstelle implementieren. Dieser Lebenszyklus-Manager ist das einzige MonoBehaviour, das Teil der Subsystemarchitektur ist; er kann überall in der Szene platziert werden, aber wir neigen dazu, ihn irgendwo auf dem Rig zu belassen.

Abfragen

Das Abfragen nach einer Subsystemimplementierung ist einfach und performant.

// Gets the first valid implementation of T that is started and running.
T mySubsystem = XRSubsystemHelpers.GetFirstRunningSubsystem<T>();

// Gets the first valid implementation of T, even if it hasn't been started.
T mySubsystem = XRSubsystemHelpers.GetFirstSubsystem<T>();

// If multiple implementations of T are loaded, get all of them.
List<T> allOfThem = new List<T>();
GetAllRunningSubsystemsNonAlloc<T>(allOfThem);

Deskriptoren

Unterschiedliche Implementierungen eines Subsystems können unterschiedliche Funktionen aufweisen. Beispielsweise können die unterschiedlichen Implementierungen des HandsSubsystem ihre Funktionen für die Meldung physischer Daten oder synthetisierter Daten angeben. Diese Funktionsinformationen werden im Subsystemdeskriptor gespeichert und können für jede bestimmte Implementierung abgefragt werden.

// Get the first running hands subsystem.
var handsSubsystem = XRSubsystemHelpers.GetFirstRunningSubsystem<HandsSubsystem>();

// If we found one...
if (handsSubsystem != null)
{
    // Read the capability information off the implementation's descriptor.
    bool isPhysicalData = handsSubsystem.subsystemDescriptor.IsPhysicalData;
}

Profiles

Die Profile des MRTK3-Subsystems dürfen nicht mit den Profilen von MRTK 2.x verwechselt werden und stellen eine plattformspezifische Ressource dar, die definiert, welche Subsysteme erstellt und gestartet werden.

Subsysteme, deren entsprechendes Kontrollkästchen aktiviert ist, werden vom MRTKLifecycleManager erstellt und gestartet, und ihre Lebenszyklusmethoden werden aufgerufen. Verschiedenen Bereitstellungszielen können unterschiedliche Profile zugewiesen werden.

Die hier gezeigten Subsysteme werden durch die von Ihnen installierten Pakete bestimmt. Wenn ein Paket nicht installiert ist, werden die diesem Paket zugeordneten Subsysteme hier nicht angezeigt, und die Liste wird automatisch aktualisiert.

Als Teil des MRTK v3-Pakets wird ein vordefiniertes MRTKProfile zur Verfügung gestellt. Es stellt ein unveränderliches Objekt dar. Wenn Sie jedoch eine benutzerdefinierte Auswahl von Subsystemen erstellen möchten, die ausgeführt werden sollen, sollten Sie Ihr MRTKProfile-Objekt in Ihrem Projekt erstellen.

Konfiguration

Subsystemen können Konfigurationsobjekte zugewiesen werden, um ihr Verhalten anzupassen.

Auf diese Konfigurationsobjekte kann von überall über die XRSubsystemHelpers-API zugegriffen werden.

XRSubsystemHelpers.GetConfiguration<TConfig, TSubsystem>()

Subsysteme definieren in ihrem MRTKSubsystemAttribute, welcher Konfigurationstyp für sie relevant ist. Parallel dazu definiert das Attribut außerdem verschiedene Metadatenelemente sowie die konkreten Typen des implementierten Anbieters. Dies ist beispielsweise das Attribut, das das MRTK-Handaggregator-Subsystem verwendet.

[MRTKSubsystem(
        Name = "com.microsoft.mixedreality.hands",
        DisplayName = "MRTK Hands Aggregator Subsystem",
        Author = "Microsoft",
        ProviderType = typeof(MRTKAggregator),
        SubsystemTypeOverride = typeof(MRTKHandsAggregatorSubsystem),
        ConfigType = typeof(MRTKHandsAggregatorConfig))]

Wie bei Profilen werden Standardkonfigurationsobjekte bereitgestellt. Sie sind unveränderlich und müssen in Ihrem Projekt dupliziert werden, um bearbeitet zu werden. Darüber hinaus können Sie ein neues Objekt über das Menü zum Erstellen von Ressourcen erstellen.