Interakciós architektúra – MRTK3

Az MRTK a Unity XR Interaction Toolkit által kínált interakciók készletére épül. A vegyes valóság olyan funkciói, mint a csuklós kézkövetés, a tekintet és a csippentés, összetettebb interakciókat igényelnek, mint az XRI által alapértelmezés szerint biztosított készlet. Az MRTK új kezelőfelületeket határoz meg, amelyeket általában a bemeneti modalitás és a megfelelő implementációk kategorizálnak.

Összegzés és áttekintés

Az XRI-t kezdő fejlesztőknek javasoljuk, hogy először tekintse át a Unity XRI-architektúrájának dokumentációját. Az MRTK-interakciók a meglévő XRI-interakciók vagy az XRI-kezelőfelületek implementációinak alosztályai. Lásd a Unity dokumentációját az interakciós architektúrájukról, amely az MRTK-ra is vonatkozik.

Az XRI jó polgárai

Az egyéni MRTK-kezelők jól viselkednek az alapértelmezett XRI-kezelőfelületek tekintetében; Az XRI-rendszerek szempontjából megkülönböztethetetlenek a "vanília" interakcióktól. Az inverz is igaz; Ha speciális interakciókat hoz létre az MRTK-ban, az alapértelmezett XRI-interakciók továbbra is működnek az alapszintű rámutatáshoz, és kiválasztják azt. Ez az MRTK azon törekvésének része, hogy teljes mértékben kompatibilis legyen a meglévő XRI-projektekkel. Ha XRI-alkalmazással rendelkezik, az MRTK-interakciók és a felhasználói felület vezérlői együttműködnek a meglévő "vanília" XRI-beállítással.

A bemeneti modalitás absztrakciója

A bemeneti eszköz, az interakciót végrehajtó kezelő és az általuk létrehozott interakciós események mindegyike architekturálisan el van különítve az XRI-ben. Ez az elkülönítés kritikus fontosságú az MRTK3 bemeneti absztrakciós stratégiája szempontjából, és lehetővé teszi, hogy platformfüggetlen és eszközközi interakciókat írjunk, amelyek minden környezetben jól működnek.

Az MRTK 2-es verziójában gyakori ösztön, hogy egy adott bemeneti típusra vagy eszközre jellemző interakciókat kódozzanak. Sok fejlesztő megszokta, hogy olyan interakciókat ír, amelyek kifejezetten egy közeli megragadásra, egy távoli sugárra vagy valamilyen más konkrét bemeneti típusra reagálnak.

Bár az MRTK3 továbbra is lehetővé teszi az egyes bemeneti módok egyértelműsítését és észlelését, az egyes bemeneti típusokkal való kemény kódolású interakciók mesterségesen korlátozzák és csökkentik az interakciók rugalmasságát. Erről bővebben az interakciós architektúra dokumentációjában olvashat, de az interakciósok kulcsa az, hogy általában nem kell 1:1-et leképezniük bemeneti eszközökkel.

AttachTransform és Inversion of Control

Az MRTK v2 a "mozgáslogikákban" a – Sliderés így tovább – részeként ObjectManipulatortett műveletek nagy része már maga az interakciós felhasználó felelőssége. Az interakciós vezérlő mostantól szabályozza az attachTransformot, hogy meghatározza, hogyan viselkedik egy adott típusú manipuláció. Többé nem kell összetett interakciós logikát írnia az interakcióra, amely különbözik a bemeneti modalitások között; ehelyett az egyesített manipulációs logika a bemeneti modalitástól vagy az attachTransformazt vezető eszköztől függetlenül figyelheti a "pózt".

Egy 's attachTransform például GrabInteractora kéz/vezérlő megragadási pontján található. A XRRayInteractor"s"-ek attachTransform a sugár végén található találati ponton találhatók. A CanvasProxyInteractor's attachTransform található, ahol az egér kattintott. Az összes ilyen különböző interakciós, az interakciós nem kell törődnie a típus az interakciós annak érdekében, hogy megfelelően reagáljon a manipulációkra.

Az interakcióba lépő lekérdezi a lekérdezéseket attachTransform , és az interakciós típustól függetlenül minden attachTransform egyes műveletet képes kezelni.

Ez a megközelítés kritikus fontosságú a meglévő XRI-interakciókkal való kompatibilitáshoz, valamint a még nem fejlesztett bemeneti modalitások jövőbeni ellenőrzéséhez. Ha új beviteli módszert vezet be, nem kell módosítania a meglévő interakciókat, ha az új kezelő érvényes és jól viselkedő viselkedést attachTransformhoz létre.

Így filozófiailag ez az attachTransform interakciós logika. Minden egyéni interakció esetén mindig előnyben kell részesítenie egy új kezelő új attachTransform logikával való írását ahelyett, hogy újraírna vagy kibővítené az új interakcióhoz testre szabandó interakciókat. Ily módon minden meglévő interakció élvezheti az új interakció előnyeit, és nem csak azokat, amelyeket átírt vagy kiterjesztett.

XRControllers és bemeneti kötés

A legtöbb interakciós felhasználó nem kapcsolódik közvetlenül a bemeneti műveletekhez. A legtöbb származik XRBaseControllerInteractor, amely megköveteli XRController a felett az interakciós a hierarchiában. A XRController kötések bemeneti műveletekhez kötődnek, majd propagálja a vonatkozó műveleteket (kiválasztás és így tovább) az összes csatlakoztatott interakciós felhasználónak.

Ennek ellenére előfordulhat, hogy egyes interakciókhoz speciális bemeneti kötések vagy további bemenetek szükségesek, amelyeket a XRController rendszer nem ad meg. Ezekben az esetekben az interakciós felhasználók közvetlenül a saját egyedi bemeneti műveleteikhez kötődnek, vagy más, nem bemeneti rendszerbeli forrásokat is használhatnak az interakciós logikához. Az XRI alaposztályok szívesebben figyelik a XRControllerkötéseket, de ezek a viselkedések felülírhatók külső vagy alternatív bemeneti források használata esetén.

Interfészek

Az XRI az alapszintű IXRInteractor, IXRHoverInteractorés IXRSelectInteractorIXRActivateInteractora . Az MRTK további interfészeket határoz meg az interakciókhoz. Néhány további információt tesz közzé az MRTK-specifikus interakciókról, míg mások egyszerűen kategorizálásra és azonosításra szolgálnak. Ezek az interfészek mind a Core-csomagban találhatók, míg az implementációk más csomagokban találhatók, beleértve az Inputot is.

Fontos

Bár ezek az interfészek hasznosak, ha egy adott típusú interakcióra kell szűrnie, javasoljuk, hogy ne kódozza le az interakciókat, hogy kifejezetten ezeket az interfészeket figyelje. Minden helyzetben mindig előnyben kell részesítenie az általános XRI-t , amelyet a rendszer kiválaszt és átvesz, nem pedig interakcióspecifikus felületet.

Hacsak nem szükséges, akkor ne hivatkozzon az interfészek konkrét MRTK-implementációira interakciókban, kivéve, ha feltétlenül szükséges. Minden esetben jobb, ha az interfészekre hivatkozunk. A konkrét típusokra való explicit hivatkozás korlátozza az interakciókat, hogy csak a jelenlegi, meglévő típusokkal működjenek. Ha csak az interfészekre hivatkozik, biztosíthatja a kompatibilitást olyan jövőbeli implementációkkal, amelyek esetleg nem osztják alá a meglévő implementációkat.

IVariableSelectInteractor

Az interfészt implementáló interakciók változók (azaz analóg) kiválasztását okozhatják az interakciókhoz. A változó kiválasztásának összege lekérdezhető a SelectProgress tulajdonsággal. Az interfészt megvalósító MRTK-interakciók közé tartoznak a MRTKRayInteractor GazePinchInteractor. Az alapműveleteket (az alapértelmezett XRI-interakciókat és MRTKBaseInteractable) a változókijelölés mennyisége nem befolyásolja; StatefulInteractableazonban figyeli ezt az értéket, és az max() összes részt vevő változó és nem változó interakciós elem alapján kiszámítja aztSelectedness.

IGazeInteractor

Az interfészt megvalósító interakciók a felhasználó passzív tekintetét képviselik, függetlenül minden manipulációtól vagy szándéktól. Az MRTK-implementáció , FuzzyGazeInteractoramely az XRI-től XRRayInteractoröröklődik, és homályos cone-casting logikát ad hozzá. XRBaseInteractable jelölőt fog jelölni IsGazeHovered , amikor egy IGazeInteractor rámutatás történik.

IGrabInteractor

Az interfészt implementáló interakciók fizikai, közel mezőhöz közeli interakciót jelentenek. A attachTransform definíció szerint a megragadási pont. Az MRTK implementációja az GrabInteractorXRI alosztálya XRDirectInteractor.

IPokeInteractor

Az interfészt megvalósító interakciók poking interakciót jelentenek. Vegye figyelembe, hogy ez nem feltétlenül jelenti az ujját! Tetszőleges interakciók implementálhatják ezt az interfészt, és nem ujjból származó poking interakciókat kínálnak. Azon kevés esetek egyike, ahol az interakciós felületek ellenőrzése jó ötlet, az olyan interakciós műveletek, mint például PressableButton az s figyelése IPokeInteractor, kifejezetten a hangerősség-vezérléshez. Minden kezelő, amely implementálja IPokeInteractor , 3D-s lenyomást indukál a gombokon.

IPokeInteractor elérhetővé teszi a PokeRadius tulajdonságot, amely meghatározza a poking objektum jellemzőit. A poke úgy tekinthető, hogy középre van attachTransform kapcsolva, és kifelé terjed ki a attachTransform .PokeRadius Az olyan interakciók, mint például PressableButton a 3D leküldési távolság eltolása ezzel a sugárral, amelyet a felhasználó fizikai ujjvastagsága vezérelhet ujjalapú prések esetén.

Ennek a felületnek az MRTK-implementációja a .PokeInteractor A sablonprojektben egy másik példát IPokeInteractor is bemutatunk, amely nem ujjal vezérelhető; PenInteractor a virtuális 3D-s toll csúcsán gyökerező poke interakciókat biztosít.

IRayInteractor

Az interfészt implementáló interakciók sugáralapú rámutatási interakciót jelentenek. Ez attachTransform a sugár találati helyét jelöli a megcélzott objektum felületén a kijelölés során.

Ennek a felületnek az MRTK-implementációja MRTKRayInteractorközvetlenül az XRI-től XRRayInteractoröröklődik .

Feljegyzés

Az XRI XRRayInteractor nem implementálja ezt az MRTK-felületet.

ISpeechInteractor

Az interfészt megvalósító interakciók beszédvezérelt interakciókat képviselnek. Az MRTK megvalósítása a következő SpeechInteractor: .

Az MRTK SpeechInteractorbelsőleg használja PhraseRecognitionSubsystem és előfizet az XRI-ből XRInteractionManagerszármazó, kezelhető regisztrációs eseményekre . Az interakcióba lépőknek azonban nem kell aggódniuk amiatt, hogy melyik alrendszer végzi a beszédfeldolgozást; ISpeechInteractorS hozza létre ugyanazokat az XRI-eseményeket (kiválasztás és így tovább), mint bármely más interakciós felhasználó.

IGazePinchInteractor

Ez az interfész egyszerűen a IVariableSelectInteractor felület specializációja. Az interfészt megvalósító interakciók implicit módon változóválasztású interakciók. IGazePinchInteractorközvetetten célzott távoli manipulációt jelentenek. Egy különálló tekintetalapú interakció vezérli az interakció célját, a manipuláció pedig egy kézzel vagy vezérlővel történik. attachTransform ugyanúgy viselkedik, mint IRayInteractora "s attachTransform "; a kiválasztás indításakor a cél találati pontjához illeszkedik.

Ha több IGazePinchInteractors vesz részt egyetlen interakcióban, az s-eket eltűri attachTransformaz összes részt vevő csippentőpont közötti mediánpontról való elmozdulásuk. Így az interakciók ugyanúgy értelmezhetik ezeket az s-eket attachTransform, mint bármely más többkezes interakció esetén, például a attachTransforms megragadásos interakciók vagy a sugár interakciók esetében.

Az MRTK megvalósítása a GazePinchInteractor.

IHandedInteractor

Egyes kezelők úgy is dönthetnek, hogy implementálják IHandedInteractor az interfészt, hogy explicit módon megadják, hogy egy adott kézhez vannak társítva egy felhasználóhoz. Egyes interakciók nincsenek társítva a kéztartással, ezért nem valósítják meg ezt. A legnyilvánvalóbb példák azok, mint SpeechInteractor vagy FuzzyGazeInteractor.

Az ezen interfészt megvalósító MRTK-interakciók az HandJointInteractor, egy általános, absztrakcióXRDirectInteractor, amelyet egy tetszőleges kézi ízület, a GazePinchInteractor.MRTKRayInteractor

Az interakciós eszközök jelenleg ezt az interfészt használják bizonyos hatások kilövésére, ha kiválasztják, amelyeknek egyértelműnek kell lenniük a bal vagy a jobb kéz között. Erre a legfontosabb példa az UX-összetevők kódtárában található impulzuseffektus.