Interaktionsfähige Objekte – MRTK3

MRTK baut auf dem XRBaseInteractable auf, das vom XR Interaction Toolkit von Unity zur Verfügung gestellt wird. Das bestehende Verhalten interaktionsfähiger Objekte und die API werden in MRTK vollständig unterstützt, und alle unsere benutzerdefinierten interaktionsfähigen Objekte gehorchen der vorhandenen XRI interactable-API.

Wir empfehlen eindringlich für Entwickler, die XRI noch nicht kennen, dass Sie zunächst die Dokumentation zur XRI-Architektur von Unity lesen.

Um die in XRI enthaltenen interaktionsfähigen Mechanismen zu erweitern, bietet MRTK zwei Basisklassen, auf denen erweiterte Interaktionen aufgebaut werden können, wobei eine die andere erweitert.

• MRTKBaseInteractable : XRBaseInteractable
  • Diese Klasse bietet Filterung und Kennzeichnung für verschiedene Interaktortypen. Während die Basis-XRI XRBaseInteractable nicht zwischen Interaktortypen unterscheidet, bietet MRTKBaseInteractable Komfortfunktionen zur Prüfung, ob gängige Interaktionstypen stattfinden. Komforteigenschaften wie IsGazeHovered oder IsGrabSelected stellen Abkürzungen für das Abfragen dar, ob ein teilnehmender Interaktor eine bestimmte Schnittstelle implementiert (entsprechend IGazeInteractor oder IGrabInteractor). Diese Flags bieten eine bessere Leistung als das Durchlaufen der Liste von interactorsHovering oder interactorsSelecting. Darüber hinaus kann MRTKBaseInteractable bestimmte Interaktortypen filtern/ablehnen, für den Fall dass der Entwickler bestimmte Eingabemodalitäten ausschließen möchte.
• StatefulInteractable : MRTKBaseInteractable
  • Während MRTKBaseInteractable Flags und Filter hinzufügt und es vermeidet, dem interaktiven Objekt zusätzliche Zustände hinzuzufügen, führt StatefulInteractable nützliche zustandsbehaftete Funktionen wie Umschalten und Variablenauswahl ein.

Strenge Trennung von Zustand und visuellem Element

In MRTK 2.x waren interaktionsfähige Elemente oftmals für das Steuern ihrer eigenen visuellen Effekte zuständig, sei es das Drücken einer 3D-Schaltfläche, ein Drauf-Zeigen-Effekt oder einfach nur das Ändern der Farbe bei einem Klick. Die Begrenzung dieser Herangehensweise ist, dass die Interaktionslogik eng mit den visuellen Objekten zusammenhängt. Wenn Sie die visuellen Objekte umgestalten oder eine andere Größe/Form/Verschiebung/usw. der Schaltfläche nutzen würden, müsste sich das Interaktionsskript selbst verändern.

interaktive Objekte sind in MRTK3 nur Zustand und Interaktion. Das interaktive Objekt rendert basierend auf seinem internen Zustand keine visuellen Veränderungen oder Effekte. Es ist nur eine Sammlung von Zustands- und Interaktionslogik, die zwischen visuellen Präsentationssetups sehr portabel ist.

Das gleiche PressableButton-Skript kann verwendet werden, um einen schwammigen Ball, eine drückbare, Trackpad-artige Fläche oder ein abstraktes drückbares Objekt zu erstellen, dass auf Druck Netzwerkereignisse ausgibt. Dem PressableButton-Skript ist es sogar egal, „wo“ es sich befindet – es kann sich in einem Zeichenbereich oder auf einem starren Körper befinden.

Zum Steuern von visuellen Elementen wird ein separater „visueller Treiber“ verwendet, um den Zustand aus dem interaktionsfähigen Objekt abzufragen und das entsprechende Feedback zu rendern. StateVisualizer ist die empfohlene Low-Code-Methode zum Steuern gängiger visueller Feedbackeffekte aus dem Zustand des interaktionsfähigen Objekts, aber es bleibt Entwicklern unbenommen, ihre eigenen benutzerdefinierten visuellen Treiber zu schreiben. Beispielsweise verwenden unsere Schaltflächenkomponenten im Allgemeinen StateVisualizer für ihre erweiterten 3D- und Shader-basierten Feedbackeffekte, wir stellen als Beispiel aber auch BasicPressableButtonVisuals zur Verfügung, das aufzeigt, wie einfach ein visueller Treiber in Code erstellt werden kann.

Variablenauswahl

Die nützlichste zusätzliche Funktion von StatefulInteractable gegenüber der XRI-Basisfunktionalität ist die Unterstützung für Selectedness von Variablen. Während interaktionsfähige XRI-Basisobjekte entweder ausgewählt oder nicht ausgewählt sind, bieten StatefulInteractables aus dem MRTK jeden mit Gleitkommazahlen darstellbaren Bruchteil von „ausgewählt“.

Dieses Konzept ist bei der Arbeit in XR nützlich, da fast alle Eingabeformen keine binären Zustände mehr sind. Motion-Controller weisen oftmals Auslöser (oder analoge Griffe!) auf, Handinteraktionen können ein variables Maß an „Gedrücktsein“ darstellen, und volumetrische Drückinteraktionen können eine Taste oder eine drückbare Fläche um einen variablen Betrag herabdrücken. Sie finden diese variablen, analogen Interaktionen überall in XR, und MRTK ist dafür ausgestattet, Entwickler beim Erstellen ansprechender Interaktionen auf der Grundlage dieser analogen Eingaben zu unterstützen.

Eine breite Palette verschiedener Interaktoren und Interaktionstypen können alle gemeinsam zum Gesamtmaß der Ausgewähltheit eines interaktionsfähigen Objekts beitragen. Insbesondere tragen alle Interaktoren, die IVariableSelectInteractor implementieren, ihren analogen Auswahlbetrag bei, in der Regel durch ein max() aller teilnehmenden Interaktoren. Dieser Variablenbetrag wird mit den binären, nicht variablen Auswahlen kombiniert, die von konventionellen Interaktoren stammen.

Für abgeleitete Klassen wie PressableButton wird die Funktion Selectedness() außer Kraft gesetzt, um der Auswahlberechnung einen zusätzlichen „Bestandteil“ hinzuzufügen. Interaktoren, die IPokeInteractor implementieren, können das Ausgewähltsein auf der Grundlage ihrer physischen Position und der Weise beitragen, in der sie physisch auf das interaktive Objekt drücken. Andere abgeleitete Klassen können andere, beliebige Formen der Auswahl einführen.

Für alle von MRTK zur Verfügung gestellten interaktiven Objekte stimmen Selectedness() und isSelected immer überein, d. h. es wird sich nie die Situation ergeben, dass eine Selectedness() größer als SelectThreshold ist, ohne dass ein entsprechendes XRI-isSelected und ein begleitender Interaktor in interactorsSelecting vorhanden sind.

Wichtig

Ihre benutzerdefinierten interaktiven Unterklassen können offensichtlich Selectedness außer Kraft setzen und auf einen anderen Wert festlegen, der vollständig vom XRI-isSelected losgelöst ist; jedoch tun unsere interaktiven Objekte dies nicht, und wir raten dringend davon ab. Schreiben Sie ganz allgemein niemals Interaktionen, zu denen kein entsprechender Interaktionsgeber vorhanden ist. Die XRI-Auswahl ist in den allermeisten Fällen ausreichend, und alle benutzerdefinierten Interaktionen, die Sie erstellen, sollten als Interaktionsgeber geschrieben werden.

Wenn Sie eine benutzerdefiniertes interaktives Objekt erstellen, das eine neue Methode zur Bestimmung von Selectedness() unterstützt, setzen Sie einfach die Methode außer Kraft, und kombinieren Sie Ihr neues Ausgewähltsein mit dem vorhandenen Auswahlbetrag. Wenn Sie StateVisualizer oder eine andere visuelle Ebene verwenden, welche die Variablenauswahl abhört, wird sie entsprechend auf Ihren neuen Auswahltyp reagieren.

Zuordnen von UGUI-Ereignissen zu XRI

In einigen Fällen ist es wünschenswert, dass interaktive Objekte auf UGUI-Ereignisse reagieren, wie Maus, Gamepad oder Touchscreeneingaben. Der UGUIInputAdapter, bei dem es sich um ein UGUI-Selectable handelt, empfängt UGUI-Ereignisse und leitet sie an einen CanvasProxyInteractor weiter, wenn einer vorhanden ist.

Wenn der CanvasProxyInteractor durch den UGUIInputAdapter von den UGUI-Ereignissen in Kenntnis gesetzt wird, gibt er äquivalente XRI-Aktionen auf dem relevanten interaktionsfähigen Objekt aus. Die Zuordnung zwischen UGUI-Eingabe- und XRI-Aktionen ist etwas verlustbehaftet und stellt einen Bereich aktiver Entwicklung dar.

Mit diesem System können vorhandene interaktionsfähige XRI-Objekte, die für immersive Plattformen, Hände, Motion-Controller und 3D-Eingaben ausgelegt sind, gleichermaßen gut auf barrierefreie 2D-Steuerelemente wie Maus und Gamepad reagieren.