Delen via


Volumetrische gebruikersinterface met canvas — MRTK3

Flexibele en responsieve indeling

Het formaat van een container met schuifregelaars wijzigen

Volledige scharnierende handondersteuning

Notitie

Dit is een conceptueel overzicht van hoe de op canvas gebaseerde gebruikersinterface wordt gebouwd. Zie de documentatie voor UX-onderdelen voor documentatie over de afzonderlijke UX-prefabs.

MRTK3 introduceert een volumetrische gebruikersinterface die is geïntegreerd met het RectTransform- en Canvas-systeem van Unity. Hoewel dit systeem in het verleden voornamelijk werd gebruikt voor de 2D-platte gebruikersinterface, is het in staat om volumetrische 3D-gebruikersinterfaces weer te geven en in te delen. Dit kan de ontwerp-iteratie versnellen en de betrouwbaarheid van de ontwerpen verhogen die kunnen worden gemaakt met de volumetrische gebruikersinterface.

Notitie

De op Canvas gebaseerde onderdelenbibliotheek is in ontwikkeling en verandert snel met nieuwe functies, uiterlijk, indeling en architectuur.

De niet-Canvas UI-systemen van MRTK 2.x waren erg moeilijk te ontwerpen omdat ze veel van de basisfuncties misten die van een interfaceontwerpsysteem werden verwacht.

  • ✘ Gebrek aan niet-fysieke ontwerpeenheden
  • ✘ Geen uitlijning
  • ✘ Geen marge/opvulling
  • ✘ Geen flexibele of responsieve indelingen
  • ✘ Afzonderlijke prefabs voor elke afzonderlijke permutatie van indeling, grootte en configuratie
  • ✘ Zeer beperkte ondersteuning voor verzamelingsindelingen (horizontale/verticale samenstelbare indelingen)
  • ✘ Gebrek aan basisfuncties zoals afgeronde hoekradii of streekbreedten van absoluut formaat
  • ✘ De schaal moet worden gebruikt om de grootte van UI-elementen aan te passen, waardoor onderliggende elementen destructief worden gewijzigd
  • ✘ Beperkte ondersteuning voor muis en toetsenbord
  • ✘ Geen ondersteuning voor gamepad

Als gevolg van deze beperkingen is de volumetrische gebruikersinterface van oudsher primitiever geweest in het ontwerp en veel handmatig werk van technische ontwerpers vereist om prachtige lay-outs te maken.

MRTK3 introduceert een uniforme aanpak. Prachtige volumetrische ui-besturingselementen die ondersteuning bieden voor alle XR-interacties (zoals gearticuleerde handtraceringspersen en staren-knijpen) kunnen worden geschreven in een Canvas-RectTransform context. Besturingselementen kunnen automatisch worden ingedeeld met de juiste marge, opvulling, responsieve flex en alle functies die ontwerpers verwachten. Bovendien kunnen we UGUI-gebeurtenissen naar beneden routeren naar XRI, zodat exact dezelfde ui-prefabs even goed werken in 2D-contexten als in 3D, inclusief toegankelijke invoer zoals gamepad.

Enkele voordelen:

  • ✔ Flexibele ontwerpeenheden die zijn toegewezen aan verschillende fysieke contexten (3D-realiteit, 2D-schermen, tv/desktop/mobiel/web)
  • ✔ Volledige uitlijningsondersteuning voor RectTransform voor responsieve indeling met samenhangende bovenliggende/onderliggende relaties
  • ✔ Volledige ondersteuning voor marges en opvulling van RectTransform via UnityUI AutoLayout-groepen
  • ✔ Ondersteuning voor flex-indelingen met prioriteit en marges via UnityUI AutoLayout-groepen
  • ✔ Eén prefab voor elk type besturingselement, die kan worden aangepast aan elke inhoud of context
  • ✔ Horizontale, verticale en rasterindelingen van UnityUI AutoLayout-groepen. Aangepaste indelingen zijn mogelijk via uitbreiding van Unity-indelingsinterfaces.
  • ✔ Grote verscheidenheid aan geavanceerde ontwerpfuncties, zoals afgeronde hoekradii van absoluut formaat, streekbreedten en marges, mogelijk gemaakt door de geavanceerde ui-arceringsfuncties in het pakket Mixed Reality Graphics Tools.
  • ✔ Geen schaalaanpassing: alle grootte en indeling worden bereikt met behulp van metrische gegevens van De Grootte en Offset van RectTransform. Ouders schalen kinderen niet.
  • ✔ Volledige ondersteuning voor muis + toetsenbord, systeemeigen via UGUI-gebeurtenissen en de UGUIInputAdapter en CanvasProxyInteractor (zie de documentatie voor interactiebare architectuur voor meer informatie)
  • ✔ Ondersteuning voor gamepad en directionele/relatieve navigatie

Deze kracht en flexibiliteit kunnen kosten met zich mee brengt, en de op Canvas gebaseerde gebruikersinterface vereist zorgvuldig beheer om veelvoorkomende prestatiekuilen te voorkomen.

  • Elk 'bewegend deel' van uw gebruikersinterface moet een afzonderlijk Canvas-knooppunt zijn. Er zijn O(tree_height) kosten verbonden aan de mutatie van canvashiërarchieën. Het gebruik van meerdere canvassen voor meerdere bewegende onderdelen/herbruikbare onderdelen wordt sterk aanbevolen.
  • Vermijd het gebruik van één globaal canvas voor uw hele scène.
  • Het verplaatsen en draaien van canvassen en RectTransforms kan gevolgen hebben voor de prestaties. We raden u ten zeerste aan uw canvas te nesten onder een niet-RectTransform holstertransformatie die wordt verplaatst, in plaats van het canvas rechtstreeks te verplaatsen.
  • Ons verhaal voor het maskeren en knippen van gebruikersinterfaces op basis van colliers is nog in ontwikkeling. Overweeg schuifweergaven met klikbare inhoud te vermijden.
  • Het standaard directionele navigatiesysteem van Unity kan zich in sommige 3D-contexten vreemd gedragen. We onderzoeken aangepaste navigatiesystemen die zich krachtiger gedragen in ongebruikelijke 3D-indelingen.

We geven specifiekere richtlijnen voor het optimaliseren van uw op canvas gebaseerde indelingen naarmate we meer gedetailleerde prestatietests uitvoeren op verschillende apparaten.

Instellen

Onze onderdelen zijn geschreven met een 1 ontwerpeenheid: 1mm verhouding voor fysieke contexten. Wanneer u een canvas instelt voor gebruik met een volumetrische gebruikersinterface die is bedoeld voor weergave in insluitende 3D-toepassingen:

  • Zorg ervoor dat uw canvas een wereldruimte is
  • Zorg ervoor dat de schaal van het canvas globaal 0,001 is op alle assen

Voor toepassingen die worden weergegeven naar een 2D-beeldscherm, kan de schaal vrij worden aangepast aan uw opgegeven bruikbaarheidsgegevens en minimale aanraakdoelgrootten.

Wanneer u interactieables gebruikt met UGUIInputAdapter (zoals onze op canvas gebaseerde UX), moet u ervoor zorgen dat u een CanvasProxyInteractor op een (bij voorkeur leeg) GameObject in uw scène hebt. Hiermee worden UGUI-gebeurtenissen doorgestuurd via XRI, zodat uw interactie goed werkt.

Als u wilt experimenteren met UGUI-invoer op niet-UX-onderdelen, voegt u toe UGUIInputAdapter aan uw XRI-interactie. UGUI-invoer voor niet-UX-gerelateerde interactables is experimenteel en is onderhevig aan verschillende open bugs.

Doorlopende ontwikkeling

We geven nog steeds vorm aan het ontwikkelingsverhaal voor het bouwen van een prachtige gebruikersinterface op onze verschillende ondersteunde platforms. Momenteel verzenden we nog steeds twee versies van de meeste UX-onderdelen: een versie die geen canvas gebruikt, met statische indeling die niet reageert (zoals we in het verleden hebben geleverd in MRTK 2.x), en een andere versie die is gebouwd met onze geïntegreerde canvas-benadering. Naarmate we meer onderdelen bouwen en de implementatie van onze ontwerpbibliotheek verder uitbouwen, verwachten we dat we de niet-Canvas-onderdelen zullen afschappen in het belang van consistentie en onderhoud.

Uniform statusbeheer

Vanwege de strikte scheiding van status/interactie en visuals, zult u merken dat dezelfde status- en interactiescripts worden gedeeld in canvas- en niet-Canvas-contexten. Dit is standaard; dezelfde interactiescripts kunnen opnieuw worden gebruikt in elke visuele of lay-outcontext, waardoor het API-oppervlak wordt verkleind en de consistentie van onze interacties wordt verbeterd. Is bijvoorbeeld Slider het interactieonderdeel schuifregelaars voor zowel canvas- als niet-canvasschuifregelaars en PressableButton is hetzelfde script voor canvasknoppen en niet-canvasknoppen. Als er in de toekomst een nieuw indelings- of presentatieframework wordt gebruikt, kunnen we dezelfde interactielogica en -systemen overdragen om consistentie en onderhoudbaarheid te garanderen.

In het onderstaande architectuurdiagram wordt beschreven hoe de verschillende invoerevenementen en typen interactie-elementen samenwerken om een uniforme interactiestatus te bieden. Klik op het diagram om een grotere versie weer te geven.

Een architectuurdiagram dat laat zien hoe verschillende invoerevenementen en typen interactie-items samenwerken.