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.
MRTK baut auf dem XRBaseInteractable XR Interaction Toolkit von Unity auf. Das vorhandene interaktionsfähige Verhalten und die API werden im MRTK vollständig unterstützt, und alle unsere benutzerdefinierten interaktionsfähigen Funktionen folgen der vorhandenen interagierbaren XRI-API.
Entwicklern, die noch nicht mit XRI vertraut sind, wird dringend empfohlen, zuerst die Dokumentation zur XRI-Architektur von Unity zu lesen.
Um die in XRI enthaltenen interagierbaren Mechanismen zu erweitern, bietet MRTK zwei Basisklassen, auf denen erweiterte Interaktionen erstellt werden können, eine erweiterung die andere.
MRTKBaseInteractable : XRBaseInteractable- Diese Klasse bietet Filterung und Kennzeichnung für verschiedene Arten von Interaktoren. Während die Basis-XRI
XRBaseInteractablenicht zwischen Interaktortypen unterscheidet,MRTKBaseInteractablebietet praktische Funktionen zur Überprüfung, ob gängige Arten von Interaktionen auftreten. Komforteigenschaften wieIsGazeHoveredoderIsGrabSelectedsind Verknüpfungen zum Abfragen, ob ein teilnehmender Interaktor eine bestimmte Schnittstelle implementiert (entsprechendIGazeInteractoroderIGrabInteractor). Diese Flags sind leistungsfähiger als das Durchlaufen der Liste voninteractorsHoveringoderinteractorsSelecting. Darüber hinausMRTKBaseInteractablekann bestimmte Typen von Interaktoren gefiltert/abgelehnt werden, wenn der Entwickler bestimmte Eingabemodalitäten ausschließen möchte.
- Diese Klasse bietet Filterung und Kennzeichnung für verschiedene Arten von Interaktoren. Während die Basis-XRI
StatefulInteractable : MRTKBaseInteractable- Fügt zwar
MRTKBaseInteractableFlags und Filter hinzu und vermeidet das Hinzufügen von zusätzlichem Zustand zum interagierbaren Objekt,StatefulInteractableführt jedoch nützliche zustandsbehaftete Features wie Umschalten und Variablenauswahl ein.
- Fügt zwar
Strikte Trennung von Zustand und Visuals
In MRTK 2.x waren interaktionsfähige Elemente oft dafür verantwortlich, ihre eigenen visuellen Effekte zu steuern, sei es das Komprimieren einer 3D-Schaltfläche, ein Hover-Effekt oder sogar das Ändern der Farbe bei einem Klick. Die Einschränkung dieses Ansatzes besteht darin, dass die Interaktionslogik eng an die Visuellen gebunden ist. Wenn Sie die Visuals neu entwerfen oder eine andere Größe/Form/Verschiebung/etc. der Schaltfläche verwenden würden, müsste sich das Interaktionsskript selbst ändern.
In MRTK3 sind interaktionsfähige Komponenten reine Zustände und Interaktionen. Der interagierbare rendert keine visuellen Änderungen oder Effekte basierend auf seinem internen Zustand. Es handelt sich lediglich um eine Sammlung von Zustands- und Interaktionslogik, die zwischen visuellen Präsentationssetups sehr portabel ist.
Dasselbe PressableButton Skript kann verwendet werden, um einen wellenförmigen Ball, eine drückebare "Trackpad"-ähnliche Ebene oder eine abstrakte druckbare Ebene zu erstellen, die Netzwerkereignisse beim Drücken ausgibt. Dem PressableButton Skript ist es nicht einmal egal, wo es sich befindet; es könnte sich innerhalb einer Canvas oder auf einem starren Körper befinden.
Zum Steuern von Visuals wird ein separater "visueller Treiber" verwendet, um den Zustand aus dem interagierbaren abzufragen und das entsprechende Feedback zu rendern.
StateVisualizer ist die empfohlene Low-Code-Methode zum Steuern allgemeiner visueller Feedbackeffekte aus dem interagierbaren Zustand, aber Entwickler können ihre eigenen benutzerdefinierten visuellen Treiber schreiben. Beispielsweise verwenden StateVisualizer unsere Schaltflächenkomponenten im Allgemeinen für ihre erweiterten 3D- und Shader-basierten Feedbackeffekte, aber wir bieten auch ein Beispiel BasicPressableButtonVisuals , das zeigt, wie ein einfacher visueller Treiber im Code erstellt werden kann.
Variablenauswahl
StatefulInteractableDas nützlichste zusätzliche Feature gegenüber der XRI-Basisfunktionalität ist die Unterstützung der Variablen Selectedness. Während basisbasierte XRI-Interaktionsfunktionen entweder ausgewählt oder nicht ausgewählt sind, kann es sich bei MRTK um einen beliebigen Gleitkommabruchteil des ausgewählten Typs StatefulInteractablehandelt.
Dieses Konzept ist bei der Arbeit in XR nützlich, da fast alle Eingabeformen keine binären Zustände mehr sind. Motion-Controller verfügen häufig über analoge Trigger (oder analoge Griffe!), Handinteraktionen können eine variable "Zusammendrückung" liefern, und volumetrische Druckinteraktionen können eine Taste oder eine druckbare Oberfläche um einen variierenden Betrag drücken. Sie sehen diese variablen, analogen Interaktionen überall in XR, und MRTK ist so ausgestattet, dass Entwickler ansprechende Interaktionen auf diesen analogen Eingaben aufbauen können.
Eine Vielzahl unterschiedlicher Interaktoren und Arten von Interaktionen kann zusammen zur Gesamtauswahl eines interagierbaren Beitragen. Insbesondere tragen alle Interaktoren, die implementieren IVariableSelectInteractor , ihre analoge Auswahlmenge bei, in der Regel über einen max() aller beteiligten Interaktoren. Dieser Variablenbetrag wird mit der binären, nicht variablen Auswahl kombiniert, die von Interaktoren im Vanilla-Stil stammt.
Bei abgeleiteten Klassen wie PressableButtonwird die Selectedness() Funktion überschrieben, um der Auswahlberechnung einen zusätzlichen "Inhaltsstoff" hinzuzufügen. Interaktoren, die implementieren IPokeInteractor , können die Auswahl basierend auf ihrem physischen Standort und ihrer physischen Drucktaste auf das interaktionsfähige Element beitragen. Andere abgeleitete Klassen können andere, beliebige Formen der Auswahl einführen.
Für die interaktionsfähigen Funktionen stellt MRTK bereit und Selectedness()isSelected wird immer "zustimmen" - mit anderen Worten, Sie werden niemals ein Selectedness() größeres beobachten als ohne SelectThreshold einen entsprechenden XRI isSelected und einen begleitenden Interaktor in interactorsSelecting.
Wichtig
Ihre benutzerdefinierten interagierbaren Unterklassen können offensichtlich einen anderen Wert außer Kraft setzen Selectedness , der vollständig vom XRI isSelectedgetrennt ist. Unsere interaktionsfähigen Komponenten tun dies jedoch nicht, und wir raten dringend davon ab. Im Allgemeinen schreiben Sie niemals Interaktionen , die nicht über einen entsprechenden Interaktor verfügen. Die XRI-Auswahl ist in den meisten Fällen ausreichend, und alle benutzerdefinierten Interaktionen, die Sie erstellen, sollten als Interaktoren geschrieben werden.
Wenn Sie eine benutzerdefinierte Interaktionsfunktion erstellen, die eine neue Methode zur Bestimmung Selectedness()unterstützt, überschreiben Sie einfach die Methode, und kombinieren Sie Ihre neue Auswahl mit dem vorhandenen Auswahlumfang. Wenn Sie oder eine andere visuelle Ebene verwenden StateVisualizer , die auf die Auswahl von Variablen lauscht, reagiert diese entsprechend auf Ihren neuen Auswahltyp.
Zuordnen von UGUI-Ereignissen zu XRI
In einigen Fällen ist es wünschenswert, dass interaktionsfähige Elemente auf UGUI-Ereignisse wie Maus-, Gamepad- oder Touchscreeneingaben reagieren. Der UGUIInputAdapter, bei dem es sich um eine UGUI Selectablehandelt, empfängt UGUI-Ereignisse und leitet sie an eine CanvasProxyInteractorweiter, sofern vorhanden.
Wenn der CanvasProxyInteractor von UGUIInputAdapterüber die UGUI-Ereignisse benachrichtigt wird, gibt es entsprechende XRI-Aktionen für das relevante interaktionsfähige Objekt aus. Die Zuordnung zwischen UGUI-Eingaben und XRI-Aktionen ist etwas verlustbehaftet und ist ein Bereich der aktiven Entwicklung.
Mit diesem System können vorhandene XRI-Interaktionsfunktionen, die für immersive Plattformen, Hände, Motion-Controller und 3D-Eingaben entwickelt wurden, genauso gut auf zugängliche 2D-Steuerelemente wie Maus und Gamepad reagieren.