Volumetrische Benutzeroberfläche mit Zeichenbereich — MRTK3

Flexibles und reaktionsfähiges Layout

Ändern der Größe eines Containers mit darin Schiebereglern

Vollständige Handunterstützung

Hinweis

Dies ist eine konzeptionelle Übersicht zum Aufbau der hybriden, zeichenbereichbasierten Benutzeroberfläche. Dokumentation zu den einzelnen UX-Prefabs finden Sie in der Dokumentation zu UX-Komponenten.

MRTK3 führt eine volumetrische Benutzeroberfläche ein, die in das RectTransform- und Zeichenbereich-System von Unity integriert ist. Obwohl dieses System bisher in erster Linie für flache 2D Benutzeroberfläche verwendet wurde, ist es in der Lage, volumetrische 3D-Benutzeroberfläche zu rendern und Layouts zu erstellen. Dies kann die Entwurfsiteration beschleunigen und die Genauigkeit der Designs erhöhen, die mit volumetrischer Benutzeroberfläche erstellt werden können.

Hinweis

Die zeichenbereichbasierte Komponentenbibliothek befindet sich in der aktiven Entwicklung und ändert sich schnell, mit neuen Features, Aussehen und Verhalten, Layout und Architektur.

Entwürfe für das nicht zeichenbereichbasierte Benutzeroberflächensystem von MRTK 2.x waren sehr schwierig zu erstellen, weil ihm viele der Grundfunktionen fehlten, die man von einem Designsystem für Benutzeroberflächen erwartet.

  • ✘ Mangel an nicht physischen Designeinheiten
  • ✘ Keine Ausrichtung
  • ✘ Kein Rand/Abstand
  • ✘ Keine flexiblen oder dynamischen Layouts
  • ✘ Einzelne Prefabs für jede einzelne Permutation von Layout, Größe und Konfiguration
  • ✘ Sehr eingeschränkte Unterstützung für das Sammlungslayout (horizontal/vertikale zusammensetzbare Layouts)
  • ✘ Mangel an grundlegenden Designfeatures wie abgerundeten Eckradien oder Strichbreiten mit absoluten Größen
  • ✘ Es sollte Skalierung verwendet werden, um die Größe von Elementen der Benutzeroberfläche anzupassen, wodurch untergeordnete Elemente destruktiv verändert werden
  • ✘ Eingeschränkte Unterstützung für Maus und Tastatur
  • ✘ Keine Unterstützung für Gamepad

Aufgrund dieser Einschränkungen waren volumetrische Benutzeroberflächen in der Vergangenheit einfacher im Design und erforderten viel manuelle Arbeit von technischen Designern, um schöne Layouts zu erstellen.

MRTK3 führt einen einheitlichen Ansatz ein. Schöne volumetrische Benutzeroberflächen-Steuerelemente, die alle XR-Interaktionen unterstützen (z. B. artikulierte Handverfolgungsdrücke und anvisieren-kneifen), können in einem Canvas-RectTransform Kontext erstellt werden. Steuerelemente können automatisch mit dem richtigen Rand, Abstand, reaktionsfähigen Flex und allen Features, die Designer erwarten, angelegt werden. Darüber hinaus können wir UGUI-Ereignisse in XRI herabführen, sodass die exakt gleichen Benutzeroberflächen-Prefabs gleichermaßen gut in 2D- wie 3D-Kontexten funktionieren, einschließlich barrierefreier Eingaben wie Gamepad.

Es ergeben sich folgende Vorteile:

  • ✔ Flexible Entwurfseinheiten, die einer Vielzahl von physischen Kontexten zugeordnet sind (3D-Realität, 2D-Bildschirme, TV/Desktop/mobile Geräte/Web)
  • ✔ Vollständige Unterstützung der RectTransform-Ausrichtung für dynamisches Layout mit zusammenhängenden Überordnungs-/Unterordnungsbeziehungen
  • ✔ Vollständige RectTransform Rand- und Abstandsunterstützung über UnityUI AutoLayout-Gruppen
  • ✔ Unterstützung von Flex-Layouts mit Priorität und Rändern über UnityUI AutoLayout-Gruppen
  • ✔ Ein einzelner Prefab für jeden Steuerelementtyp, dessen Größe geändert und der an jede Art von Inhalt oder Kontext angepasst werden kann
  • ✔ Horizontale, vertikale und Rasterlayouts aus UnityUI AutoLayout-Gruppen. Benutzerdefinierte Layouts sind durch Erweiterung von Unity-Layoutschnittstellen möglich.
  • ✔ Eine Vielzahl von erweiterten Designfeatures wie abgerundete Eckradien, Strichbreiten und Ränder mit absoluter Größe, was durch die erweiterten Benutzeroberflächen-Shaderfeatures im Mixed Reality-Grafiktools-Paket ermöglicht wird.
  • ✔ Keine Skalierung: Alle Größen und Layouts werden mithilfe von RectTransform-Größen- und Offsetmetriken realisiert. Übergeordnete Elemente bewirken keine Skalierung untergeordneter Elemente.
  • ✔ Vollständige Unterstützung für Maus + Tastatur, nativ über UGUI-Ereignisse sowie den UGUIInputAdapter und CanvasProxyInteractor (weitere Informationen dazu finden Sie in der Dokumentation zur Architektur interaktionsfähiger Elemente)
  • ✔ Unterstützung für Gamepad und direktionale/relative Navigation

Diese Leistungsfähigkeit und Flexibilität können mit einem hohen Preis einhergehen, und die zeichenbereichbasierte Benutzeroberfläche erfordert sorgfältige Verwaltung, um gängige Fallstricke im Hinblick auf die Leistung zu meiden.

  • Jedes „bewegliche Teil“ Ihrer Benutzeroberfläche sollte einen separaten Zeichenbereichsknoten darstellen. Mit der Mutation von Zeichenbereichshierarchien gehen O(tree_height)-Kosten einher; die Verwendung mehrerer Zeichenbereiche für mehrere bewegliche Teile/wiederverwendbare Komponenten ist dringend empfohlen.
  • Vermeiden Sie die Verwendung eines einzelnen globalen Zeichenbereichs für ihre gesamte Szene.
  • Das Verschieben und Drehen von Zeichenbereichen und RectTransforms kann die Leistung beeinträchtigen. Wir empfehlen dringend, Ihren Zeichenbereich unterhalb einer nicht zu RectTransform gehörenden „Holstertransformation“ zu verschachteln, auf die die Verschiebung angewendet wird, statt den Zeichenbereich direkt zu verschieben.
  • Unsere Geschichte bezüglich Maskierung und Freistellen in Collider-basierten Benutzeroberflächen ist noch in der Entwicklung. Erwägen Sie, Bildlaufansichten zu vermeiden, die klickbare Inhalte enthalten.
  • Das standardmäßige Richtungsnavigationssystem von Unity kann sich in manchen 3D-Kontexten seltsam verhalten. Wir untersuchen benutzerdefinierte Navigationssysteme, die sich in ungewöhnlichen 3D-Layouts stabiler verhalten.

Wir werden spezifischere Anleitungen zur Optimierung Ihrer zeichenbereichbasierten Layouts veröffentlichen, wenn wir detailliertere Leistungstests für eine Reihe von Geräten durchführen.

Einrichten

Unsere Komponenten werden für physische Kontexte mit einem Verhältnis von 1 Entwurfseinheit : 1 mm erstellt. Wenn Sie einen Zeichenbereich für die Nutzung mit einer volumetrischen Benutzeroberfläche einrichten, die für die Anzeige in immersiven 3D-Anwendungen vorgesehen ist:

  • Legen Sie Ihren Zeichenbereich auf „worldspace“ fest
  • Vergewissern Sie sich, dass der Maßstab des Zeichenbereichs global 0,001 für alle Achsen beträgt

Für Anwendungen, die auf einer 2D-Anzeige gerendert werden, kann die Skalierung frei angepasst werden, um Ihren angegebenen Nutzbarkeitsmetriken und den Minimalgrößen für Berührungsziele zu entsprechen.

Wenn Sie interaktionsfähige Objekte mit UGUIInputAdapter (wie unserer zeichenbereichbasierten UX) verwenden, stellen Sie sicher, dass Sie einen CanvasProxyInteractor in einem (vorzugsweise leeren) GameObject in Ihrer Szene verwenden. Dadurch werden UGUI-Ereignisse über XRI weitergeleitet, was sicherstellt, dass Ihre interaktionsfähigen Objekte ordnungsgemäß funktionieren.

Wenn Sie mit UGUI-Eingaben für Nicht-UX-Komponenten experimentieren möchten, fügen Sie Ihrem interaktionsfähigen XRI-Objekt UGUIInputAdapter hinzu. UGUI-Eingaben für nicht UX-bezogene interaktionsfähige Objekte sind experimentell und unterliegen mehreren nicht behobenen Fehlern.

Laufende Entwicklung

Wir sind noch im Prozess, die Entwicklungsgeschichte für das Erstellen schöner Benutzeroberflächen auf der Vielzahl der von uns unterstützten Plattformen zu schreiben. Derzeit liefern wir weiterhin zwei Versionen der meisten UX-Komponenten: eine, die den Zeichenbereich nicht verwendet, mit statischem, nicht-dynamischem Layout (wie wir das in der Vergangenheit in MRTK 2.x bereitgestellt haben) und eine andere Version, die mit unserem einheitlichen zeichenbereichbasierten Ansatz erstellt wird. In dem Maß, da wir mehr Komponenten erstellen und die Implementierung unserer Designbibliothek ausgestalten, haben wir die Erwartung, dass wir die nicht zeichenbereichbasierten Komponenten als veraltet erklären, im Sinne von Konsistenz und einfacher Wartung.

Einheitliche Zustandsverwaltung

Aufgrund der strikten Trennung von Zustand/Interaktion und visuellen Elementen werden Sie feststellen, dass die gleichen Status- und Interaktionsskripts gemeinsam in zeichenbereichbasierten und nicht zeichenbereichbasierten Kontexten verwendet werden. Dies ist konzeptionell bedingt. Die gleichen Interaktionsskripts können in beliebigen visuellen oder Layoutkontexten wiederverwendet werden, was die API-Oberfläche verringert und die Konsistenz Ihrer Interaktionen steigert. Beispielsweise ist Slider die Schieberegler-Interaktionskomponente sowohl für zeichenbereichbasierte als auch nicht zeichenbereichbasierte Schieberegler, und PressableButton ist das gleiche Skript für Zeichenbereichs- und Nicht-Zeichenbereichs-Schaltflächen. Wenn in Zukunft ein neues Layout oder Präsentationsframework eingeführt wird, können wir die gleiche Interaktionslogik und die gleichen Systeme übernehmen, um Konsistenz und Wartungsfreundlichkeit zu gewährleisten.

Das folgende Architekturdiagramm enthält Details dazu, wie die verschiedenen Eingabeereignisse und Typen von interaktionsfähigen Objekten zusammenarbeiten, um einen einheitlichen Interaktionszustand bereitzustellen. Klicken Sie auf das Diagramm, um es zu vergrößern.

Ein Architekturdiagramm, das zeigt, wie verschiedene Eingabeereignisse und Typen von interagierbaren Funktionen zusammenarbeiten.