Volumetric UI med Canvas – MRTK3

Anteckning

Det här är en konceptuell översikt över hur hybridgränssnittet för arbetsytor skapas. Dokumentation om de enskilda UX-prefaberna finns i dokumentationen om UX-komponenter.

MRTK3 introducerar volymtriskt användargränssnitt som är integrerat med Unitys RectTransform- och Canvas-system. Även om det här systemet historiskt sett främst har använts för 2D flat UI, kan det återge och lägga ut volymtriskt 3D-användargränssnitt. Detta kan påskynda design iteration och öka återgivningen av de mönster som kan skapas med volymtriskt användargränssnitt.

Anteckning

Det Arbetsytebaserade komponentbiblioteket är under aktiv utveckling och ändras snabbt med nya funktioner, utseende, layout och arkitektur.

MRTK 2.xs icke-Canvas UI-system var mycket svåra att utforma för eftersom de saknade många av de grundläggande funktioner som förväntades från ett gränssnittsdesignsystem.

• ✘ Brist på icke-fysiska designenheter
• ✘ Ingen justering
• ✘ Ingen marginal/utfyllnad
• ✘ Inga flexibla eller dynamiska layouter
• ✘ Distinkta prefabs för varje enskild permutation av layout, storlek och konfiguration
• ✘ Mycket begränsat stöd för samlingslayout (vågräta/lodräta layouter)
• ✘ Brist på grundläggande designfunktioner som absolut stora rundade hörnradier eller linjebredder
• ✘ Behöver använda skala för att justera UI-elementstorlekar, destruktivt förändra underordnade
• ✘ Begränsat stöd för mus och tangentbord
• ✘ Inget stöd för gamepad

Som ett resultat av dessa begränsningar har volymtriskt användargränssnitt historiskt sett varit mer primitivt i sin design och krävt en hel del manuellt arbete från tekniska designers för att skapa vackra layouter.

MRTK3 introducerar en enhetlig metod. Vackra volymtriska UI-kontroller som stöder alla XR-interaktioner (till exempel ledade handspårningspressar och blick-nypa) kan redigeras i en Canvas-RectTransform kontext. Kontroller kan automatiskt utformas med rätt marginal, utfyllnad, responsiv flex och alla funktioner som designers förväntar sig. Dessutom kan vi dirigera UGUI-händelser till XRI så att exakt samma gränssnittsprefabs fungerar lika bra i 2D-kontexter och 3D, inklusive tillgängliga indata som gamepad.

Fördelarna innefattar:

• ✔ Flexibla designenheter som mappar till en mängd olika fysiska kontexter (3D-verklighet, 2D-skärmar, TV/Desktop/Mobile/Web)
• ✔ Stöd för fullständig RektTransform-justering för dynamisk layout med sammanhängande överordnade/underordnade relationer
• ✔ Stöd för fullständig RectTransform-marginal och utfyllnad via UnityUI AutoLayout-grupper
• ✔ Stöd för flexlayouter med prioritet och marginaler via UnityUI AutoLayout-grupper
• ✔ En enda prefab för varje typ av kontroll, som kan ändras och justeras så att den passar valfritt innehåll eller kontext
• ✔ Vågräta layouter, lodräta layouter och rutnätslayouter från UnityUI AutoLayout-grupper. Anpassade layouter är möjliga via tillägg av Unity-layoutgränssnitt.
• ✔ Många olika avancerade designfunktioner som helt stora rundade hörnradier, linjebredder och marginaler, som aktiveras av avancerade UI-skuggningsfunktioner i paketet Mixed Reality Grafikverktyg.
• ✔ Ingen skalning: all storlek och layout uppnås genom RektTransform-storlek och förskjutningsmått. Föräldrar skalar inte barn.
• ✔ Fullständigt stöd för mus + tangentbord, internt via UGUI-händelser och UGUIInputAdapter och CanvasProxyInteractor (se dokumentationen för interaktionsbar arkitektur för mer information)
• ✔ Stöd för gamepad och riktad/relativ navigering

Den här kraften och flexibiliteten kan komma till en kostnad, och arbetsytebaserat användargränssnitt kräver noggrann hantering för att undvika vanliga prestandagropar.

• Varje "flyttande del" av användargränssnittet bör vara en distinkt arbetsytenod. Det finns O(tree_height) kostnader som är kopplade till mutationen av arbetsytehierarkier. Användning av flera arbetsytor för flera rörliga delar/återanvändbara komponenter rekommenderas starkt.
• Undvik att använda en enda global arbetsyta för hela scenen.
• Att flytta och rotera arbetsytor och RectTransforms kan få prestandakonsekvenser. Vi rekommenderar starkt att du kapslade arbetsytan under en icke-RectTransform-transformering av "hölster" som kommer att flyttas, i stället för att flytta arbetsytan direkt.
• Vår berättelse om maskering och urklipp av colliderbaserade UIs är fortfarande under utveckling. Överväg att undvika rullningsvyer som innehåller klickbart innehåll.
• Standardinställningen unity directional navigation system kan i vissa 3D-kontexter bete sig konstigt. Vi undersöker anpassade navigeringssystem som fungerar mer robust i ovanliga 3D-layouter.

Vi kommer att ge mer specifik vägledning för att optimera dina arbetsytebaserade layouter när vi utför mer detaljerade prestandatester på en rad olika enheter.

Installation

Våra komponenter är författade med en designenhet: 1mm förhållande för fysiska kontexter. När du konfigurerar en arbetsyta för användning med volymtriskt användargränssnitt avsett för visning i uppslukande 3D-program:

• Se till att arbetsytan är världsrymd
• Kontrollera att arbetsytans skala är globalt 0,001 på alla axlar

För program som återger till en 2D-skärm kan skalan justeras fritt så att den matchar dina angivna användbarhetsmått och minsta pekmålstorlekar.

När du använder interaktionsbara objekt med UGUIInputAdapter (till exempel vår Canvas-baserade UX) ska du se till att du har en CanvasProxyInteractor på en (helst tom) GameObject i din scen. Detta vidarebefordrar UGUI-händelser via XRI, vilket säkerställer att dina interaktionsbara objekt fungerar korrekt.

Om du vill experimentera med UGUI-indata på icke-UX-komponenter lägger du till UGUIInputAdapter i din interaktionsbara XRI. UGUI-indata på icke-UX-relaterade interaktionsbara objekt är experimentella och utsätts för flera öppna buggar.

Pågående utveckling

Vi formar fortfarande utvecklingsberättelsen för att skapa ett vackert användargränssnitt på våra olika plattformar som stöds. För närvarande levererar vi fortfarande två versioner av de flesta UX-komponenter: en som inte använder Canvas, med statisk layout som inte svarar (som vi tidigare har angett i MRTK 2.x) och en annan version som har skapats med vår enhetliga arbetsytebaserad metod. När vi skapar fler komponenter och fyller ut vår implementering av designbiblioteket förväntar vi oss att vi kommer att föråldrade komponenter som inte är canvas för konsekvens och underhåll.

Enhetlig tillståndshantering

På grund av den strikta uppdelningen av tillstånd/interaktion och visuella objekt ser du att samma tillstånds- och interaktionsskript delas mellan arbetsyte- och icke-arbetsytekontexter. Detta är avsiktligt; samma interaktionsskript kan återanvändas i alla visuella objekt eller layoutkontexter, vilket minskar API-ytan och förbättrar konsekvensen i våra interaktioner. Är till exempel Slider interaktionskomponenten för skjutreglaget för både arbetsytor och icke-arbetsytereglage och PressableButton är samma skript mellan knapparna Arbetsyta och icke-Arbetsytor. I framtiden, om ett nytt layout- eller presentationsramverk antas, kan vi överföra samma interaktionslogik och system för att säkerställa konsekvens och underhåll.

Arkitekturdiagrammet nedan beskriver hur de olika indatahändelserna och typerna av interaktionsbara objekt fungerar tillsammans för att ge ett enhetligt interaktionstillstånd. Klicka på diagrammet för att se en större version.