Interactables – MRTK3

MRTK bygger på det XRBaseInteractable som tillhandahålls av Unitys XR Interaction Toolkit. Det befintliga interaktionsbara beteendet och API:et stöds fullt ut i MRTK, och alla våra anpassade interaktionsbara objekt följer det befintliga XRI-interaktionsbara API:et.

För utvecklare som är nybörjare på XRI rekommenderar vi starkt att du först läser Unitys XRI-arkitekturdokumentation.

För att utöka de interaktionsbara mekanismer som ingår i XRI erbjuder MRTK två basklasser där avancerade interaktioner kan byggas, den ena utökar den andra.

• MRTKBaseInteractable : XRBaseInteractable
  • Den här klassen erbjuder filtrering och flaggning för olika typer av interaktionsfaktorer. Även om bas-XRI XRBaseInteractable inte diskriminerar mellan interaktionstyper, MRTKBaseInteractable tillhandahåller bekvämlighetsfunktioner för att kontrollera om vanliga typer av interaktioner förekommer. Bekvämlighetsegenskaper som IsGazeHovered eller IsGrabSelected är genvägar för att fråga om en deltagande interagerare implementerar ett visst gränssnitt (motsvarande IGazeInteractor eller IGrabInteractor). Dessa flaggor är mer högpresterande än att iterera genom listan med interactorsHovering eller interactorsSelecting. Dessutom MRTKBaseInteractable kan filtrera/avvisa vissa typer av interaktionsfaktorer om utvecklaren vill undanta vissa indatavillkor.
• StatefulInteractable : MRTKBaseInteractable
  • Samtidigt MRTKBaseInteractable som flaggor och filter läggs till, och du undviker att lägga till ytterligare tillstånd i det interaktionsbara objektet, StatefulInteractable introduceras användbara tillståndskänsliga funktioner som att växla och välja variabler.

Strikt uppdelning av tillstånd och visuella objekt

I MRTK 2.x var interaktionsbara objekt ofta ansvariga för att driva sina egna visuella effekter, oavsett om det var komprimering av en 3D-knapp, en hovringseffekt eller till och med bara ändra färg på ett klick. Begränsningen för den här metoden är att interaktionslogik är nära kopplad till de visuella objekten. Om du skulle göra om de visuella objekten eller använda en annan storlek/form/deplacement/etc. av knappen skulle interaktionsskriptet i sig behöva ändras.

I MRTK3 är interaktionsbara objekt rent tillstånd och interaktion. Den interaktionsbara återger inga visuella ändringar eller effekter baserat på dess interna tillstånd. Det är bara en samling tillstånds- och interaktionslogik som är mycket portabel mellan konfigurationer av visuella presentationer.

Samma PressableButton skript kan användas för att skapa en vågig boll, ett pressbart "styrplatta"-liknande plan eller ett abstrakt pressbart som utfärdar nätverkshändelser vid press. Skriptet PressableButton bryr sig inte ens om "var" det är, det kan vara inuti en arbetsyta eller på en styv kropp.

För att driva visuella objekt används en separat "visuell drivrutin" för att avsöka tillståndet från det interaktionsbara objektet och återge lämplig feedback. StateVisualizer är den rekommenderade lågkodsmetoden för att driva vanliga visuella feedbackeffekter från interaktionsbart tillstånd, men utvecklare kan skriva egna anpassade visuella drivrutiner. Våra knappkomponenter använder StateVisualizer till exempel vanligtvis för sina avancerade 3D - och skuggningsbaserade feedbackeffekter, men vi ger också ett exempel BasicPressableButtonVisuals som visar hur en enkel visuell drivrutin kan redigeras i kod.

Variabelval

StatefulInteractableden mest användbara ytterligare funktionen i XRI-basfunktionerna är stöd för variabeln Selectedness. Även om bas-XRI-interaktionsbara objekt antingen är markerade eller inte valda, kan MRTK:erna StatefulInteractablevara valfri flyttalsfraktion av valda.

Det här konceptet är användbart när du arbetar i XR, eftersom nästan alla former av indata inte längre är binära tillstånd. Rörelsestyrenheter har ofta analoga utlösare (eller analoga grepp!), handinteraktioner kan ge en variabel "pinchedness" och volumetric press interaktioner kan trycka på en knapp eller pushbar yta med en varierande mängd. Du ser dessa variabler, analoga interaktioner överallt i XR och MRTK är utrustade för att hjälpa utvecklare att skapa härliga interaktioner ovanpå dessa analoga indata.

Ett brett spektrum av olika interaktionsfaktorer och typer av interaktioner kan alla bidra tillsammans till den övergripande urvalsheten hos en interaktionsbar. I synnerhet bidrar alla interagerare som implementerar IVariableSelectInteractor sin analoga urvalsmängd, vanligtvis via en max() av alla deltagande interaktionsfaktorer. Den här variabelmängden kombineras med de binära, icke-variabelval som kommer från vaniljliknande interaktionsfaktorer.

För härledda klasser som PressableButton, Selectedness() åsidosättas funktionen för att lägga till ytterligare en "ingrediens" i urvalsberäkningen. Interagerare som implementerar IPokeInteractor kan bidra med urval baserat på deras fysiska plats och hur de fysiskt trycker ned på det interagerande objektet. Andra härledda klasser kan introducera andra, godtyckliga urvalsformer.

För de interaktionsbara MRTK:erna tillhandahåller Selectedness() och isSelected kommer alltid att "godkänna", med andra ord, kommer du aldrig att observera ett Selectedness() större än SelectThreshold utan motsvarande XRI isSelected och en tillhörande interaktionsfaktor i interactorsSelecting.

Viktigt

Dina anpassade underklasser som kan interagera kan naturligtvis åsidosättas Selectedness till något annat värde som är helt frånkopplat från XRI isSelected. Men våra interaktionsbara objekt gör inte detta, och vi avråder starkt från det. Skriv i allmänhet aldrig interaktioner som inte har någon motsvarande interaktionsfaktor. XRI-valet är i de allra flesta fall tillräckligt, och alla anpassade interaktioner som du skapar bör skrivas som interaktionsappar.

När du skapar en anpassad interaktionsbar metod som stöder en ny metod för att Selectedness()fastställa åsidosätter du helt enkelt metoden och kombinerar den nya markeringsmängden med den befintliga urvalsmängden. Om du använder StateVisualizer eller något annat visuellt lager som lyssnar på variabelval svarar det därefter på den nya urvalstypen.

Mappa UGUI-händelser till XRI

I vissa fall är det önskvärt att ha interaktionsbara objekt som svarar på UGUI-händelser, till exempel mus, spelplatta eller pekskärmsindata. UGUIInputAdapter, som är en UGUI Selectable, tar emot UGUI-händelser och vidarebefordrar dem till en CanvasProxyInteractor, om en finns.

CanvasProxyInteractor När meddelas om UGUI-händelserna av UGUIInputAdapterutfärdar den motsvarande XRI-åtgärder på relevant interaktionsbar. Mappningen mellan UGUI-indata och XRI-åtgärder är något förlustig och är ett område med aktiv utveckling.

Med det här systemet kan befintliga XRI-interaktionsbara objekt som är byggda för uppslukande plattformar, händer, rörelsestyrenheter och 3D-indata reagera lika bra på tillgängliga 2D-kontroller som mus och spelplatta.