Hinweis
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, sich anzumelden oder das Verzeichnis zu wechseln.
Für den Zugriff auf diese Seite ist eine Autorisierung erforderlich. Sie können versuchen, das Verzeichnis zu wechseln.
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 XRInputSubsystem
geladen. 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
, Stop
und Destroy
. Wir erweitern diese Definition um hilfreiche "Tick"-Methoden wie Update
, LateUpdate
und 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.
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.
Konfiguration
Subsystemen können Konfigurationsobjekte zugewiesen werden, um ihr Verhalten anzupassen.
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 MRTKSubsystemAttribute
relevant 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.