Freigeben über


Subsysteme — MRTK3

MRTK3 nutzt die Unity XR Subsystem Management-Infrastruktur zum Schreiben erweiterbarer Module, die dazu beitragen können, plattformübergreifende Unterstützung für Features wie Sprach- und Handverfolgung bereitzustellen. Diese Subsysteme werden von Unity zusammen mit den vorhandenen nativen Unity-Subsystemen wie XRMeshSubsystem und initialisiert und XRInputSubsystemgeladen. Informationen zur Funktionsweise von Unity-Subsystemen finden Sie in der Dokumentation.

Philosophie

In MRTK v2 stellten "Dienste" einen Großteil der Funktionalität in der Szene selbst bereit. Sie instanziieren Objekte, verschieben Objekte, aktualisieren die Szenenhierarchie usw. In MRTK3 ändern die Subsysteme die Szene nicht explizit. Die MRTK3-Subsysteme sind modulare Anbieter von Daten, Informationen oder Ereignissen oder führen Berechnungen für Endbenutzer durch. Wenn sich etwas in der Szene ändern oder basierend auf der Dateneingabe ausgeführt werden soll, muss eine separate szenenbasierte Schnellansichtskomponente vorhanden sein, um auf die Daten zu reagieren. Diese Aufteilung stellt sicher, 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 großzügig verwendet, verwendet MRTK3 im Allgemeinen OpenXR und das Unity-Eingabesystem für plattformübergreifende Eingaben. Einige Datentypen werden jedoch noch nicht vom Eingabesystem umschlossen. In diesen Fällen stellen wir plattformübergreifende Schnittstellen über unsere Subsysteme bereit.

MRTK-Subsystemlebenszyklus

Die Subsystemdefinitionen, die in der Unity-Infrastruktur enthalten sind, bieten einfache Lebenszyklusmethoden wie Start, Stopund Destroy. Wir erweitern diese Definition um hilfreiche "Tick"-Methoden wie Update, LateUpdateund FixedUpdate. Unsere MRTKLifecycleManager verwaltet Subsysteme, die unsere Lebenszyklusschnittstelle implementieren. Dieser Lebenszyklus-Manager ist der einzige MonoBehaviour, der an der Subsystemarchitektur beteiligt ist. dies kann überall in der Szene platziert werden, aber wir neigen dazu, es irgendwo auf dem Rig zu lassen.

Befragend

Abfragen für eine Subsystemimplementierung sind einfach und leistungsfähig.

// 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

Verschiedene Implementierungen eines Subsystems können unterschiedliche Funktionen aufweisen. Beispielsweise können die verschiedenen Implementierungen von ihre HandsSubsystem Fähigkeit zum Melden physischer 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;
}

Profile

MRTK3-Subsystemprofile sind nicht mit den Profilen von MRTK 2.x zu verwechseln, und es handelt sich um eine Plattformressource pro Bereitstellung, die definiert, welche Subsysteme erstellt und gestartet werden.

Subsystemprofile, wie in der Ansicht MRTK-Projekteinstellungen gezeigt.

Subsysteme, für die das entsprechende Kontrollkästchen aktiviert ist, werden von MRTKLifecycleManager erstellt und gestartet, und ihre Lebenszyklusmethoden werden aufgerufen. Verschiedenen Bereitstellungszielen können unterschiedliche Profile zugewiesen werden.

Die hier gezeigten Subsysteme werden anhand der installierten Pakete bestimmt. Wenn kein Paket installiert ist, werden die diesem Paket zugeordneten Subsysteme hier nicht angezeigt, und die Liste wird automatisch aktualisiert.

Als Teil des MRTK v3-Pakets MRTKProfile ist ein vorgefertigtes Paket enthalten. Es handelt sich um eine unveränderliche Ressource. Wenn Sie jedoch eine benutzerdefinierte Auswahl von Subsystemen erstellen möchten, die ausgeführt werden sollen, sollten Sie Ihre MRTKProfile Ressource in Ihrem Projekt erstellen.

Erstellen eigener MRTK-Subsysteme

Konfiguration

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

Konfigurieren eines Subsystems

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

XRSubsystemHelpers.GetConfiguration<TConfig, TSubsystem>()

Subsysteme definieren, welcher Konfigurationstyp für sie in ihrer MRTKSubsystemAttributerelevant ist. Darüber hinaus definiert das Attribut auch mehrere Metadatenelemente sowie die konkreten Typen des implementierten Anbieters. Dies ist beispielsweise das Attribut, das vom MRTK Hands Aggregator Subsystem verwendet wird.

[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 Standardmäßige Konfigurationsressourcen bereitgestellt. Sie sind unveränderlich und müssen in Ihrem Projekt dupliziert werden, damit sie bearbeitet werden können. Sie können ein neues Medienobjekt auch über das Menü zum Erstellen von Medienobjekten erstellen.

Menü zum Erstellen neuer Ressourcen