Architektura interakcji — MRTK3

Zestaw narzędzi MRTK opiera się na zestawie interakcji oferowanych przez zestaw narzędzi interakcji XR aparatu Unity. Funkcje rzeczywistości mieszanej, takie jak przegubowe śledzenie rąk, spojrzenie i szczypta, wymagają bardziej rozbudowanych interakcji niż zestaw dostarczany z XRI domyślnie. Zestaw narzędzi MRTK definiuje nowe interfejsy interakcji, kategoryzowane na ogół przez modalność wejściową i odpowiadające im implementacje.

Podsumowanie i przegląd

W przypadku deweloperów, którzy dopiero zaczyna korzystać z architektury XRI, zalecamy zapoznanie się z dokumentacją architektury XRI aparatu Unity. Interakcje mrTK to podklasy istniejących interakcji XRI lub implementacji interfejsów interakcji XRI. Zapoznaj się z dokumentacją aparatu Unity dotyczącą architektury interakcji, która ma również zastosowanie do zestawu narzędzi MRTK.

Dobrzy obywatele XRI

Niestandardowe interakcje zestawu narzędzi MRTK są dobrze zachowywane w odniesieniu do domyślnych interfejsów interakcji XRI; z perspektywy systemów XRI są one nie do odróżnienia od "waniliowych" interakcji. Odwrotność jest również prawdziwa; podczas tworzenia zaawansowanych funkcji interakcji w zestawie narzędzi MRTK domyślne interakcje XRI będą nadal działać dla podstawowego wskaźnika myszy i wybrania. Jest to część wysiłku mrTK, aby była w pełni zgodna z istniejącymi projektami XRI. Jeśli masz aplikację XRI, kontrolki MRTK współdziałają i kontrolki interfejsu użytkownika będą działać z istniejącą konfiguracją XRI "vanilla".

Abstrakcja modalności danych wejściowych

Urządzenie wejściowe, interakcja wykonująca interakcję i generowane przez nie zdarzenia interakcji są izolowane architektonicznie w usłudze XRI. Ta izolacja ma kluczowe znaczenie dla strategii abstrakcji danych wejściowych w narzędziu MRTK3 i umożliwia pisanie interakcji międzyplatformowych i między urządzeniami, które dobrze działają we wszystkich kontekstach.

Z zestawu NARZĘDZI MRTK w wersji 2 istnieje typowy instynkt interakcji kodu specyficznych dla określonego typu danych wejściowych lub urządzenia. Wielu deweloperów jest przyzwyczajonych do pisania interakcji, które reagują specjalnie na zbliżenie chwytania, dalekiego promienia lub innego określonego typu danych wejściowych.

Chociaż funkcja MRTK3 nadal umożliwia uściślanie i wykrywanie poszczególnych trybów wejściowych, stałe kodowanie interakcji z określonymi typami danych wejściowych jest sztucznie ograniczane i zmniejsza elastyczność interakcji. Więcej informacji na ten temat można znaleźć w dokumentacji architektury umożliwiającej interakcję, ale kluczem dla interakcji jest to, że zazwyczaj nie muszą mapować 1:1 z urządzeniami wejściowymi.

AttachTransform i Inversion of Control

Wiele z tego, co mrTK v2 zrobił w "logiki przenoszenia" w ramach ObjectManipulator, Slideri tak dalej, jest teraz obowiązkiem samego interakcji. Interakcja steruje teraz jego attachTransform, aby zdefiniować zachowanie określonego typu manipulacji. Nie trzeba już pisać złożonej logiki interakcji na temat interakcji, która różni się między modalnościami wejściowymi; Zamiast tego ujednolicona logika manipulowania może nasłuchiwać attachTransformpozy niezależnie od modalności danych wejściowych lub urządzenia, które go napędza.

Na przykład GrabInteractorelement "s attachTransform " znajduje się w punkcie chwytania na rękę/kontrolerze. " XRRayInteractorS attachTransform znajduje się w punkcie trafienia na końcu promienia. Element CanvasProxyInteractor"s attachTransform " znajduje się wszędzie tam, gdzie kliknęła mysz. W przypadku wszystkich tych różnych interakcji interakcja nie musi dbać o typ interakcji w celu odpowiedniego reagowania na manipulacje.

Możliwe do interakcji zapytania attachTransform i mogą traktować wszystkie attachTransform te same niezależnie od typu interakcji.

Takie podejście ma kluczowe znaczenie dla zgodności z istniejącymi interakcjami XRI, a także weryfikacją przyszłych interakcji dotyczących modalności wejściowych, które nie zostały jeszcze opracowane. Jeśli zostanie wprowadzona nowa metoda wejściowa, nie musisz zmieniać istniejących możliwości interakcji, jeśli nowy interakcja generuje prawidłowy i dobrze zachowywany attachTransformelement .

Tak więc, filozoficznie, attachTransform jest logiką interakcji. W przypadku wszelkich interakcji niestandardowych zawsze należy wyrazić preferencje dotyczące pisania nowej interakcji z nową attachTransform logiką, a nie ponownego pisania lub rozszerzania interakcji, które mają być dostosowane do nowej interakcji. W ten sposób wszystkie istniejące możliwości interakcji mogą korzystać z zalet nowej interakcji zamiast tylko tych, które zostały przepisane lub rozszerzone.

XRControllers i powiązanie wejściowe

Większość interakcji nie wiąże się bezpośrednio z akcjami wejściowymi. Większość pochodzi z XRBaseControllerInteractorklasy , która wymaga XRController elementu powyżej interakcji w hierarchii. Powiązanie XRController z akcjami wejściowymi, a następnie propaguje odpowiednie akcje (wybierz i tak dalej) do wszystkich dołączonych interakcji.

Niemniej jednak niektóre interakcje mogą wymagać specjalnych powiązań wejściowych lub dodatkowych danych wejściowych, które XRController nie zapewniają. W takich przypadkach interakcje mają możliwość powiązania bezpośrednio z własnymi unikatowymi akcjami wejściowymi, a nawet używania innych źródeł innych niż Input-System logiki interakcji. Klasy podstawowe XRI wolą nasłuchiwać XRControllerpowiązań, ale te zachowania mogą być zastępowane do używania zewnętrznych lub alternatywnych źródeł wejściowych.

Interfejsy

XRI definiuje podstawowe IXRInteractor, , IXRHoverInteractorIXRSelectInteractori IXRActivateInteractor. Zestaw narzędzi MRTK definiuje dodatkowe interfejsy dla interakcji. Niektóre uwidaczniają dodatkowe informacje o interakcjach specyficznych dla zestawu narzędzi MRTK, a inne są po prostu przeznaczone do kategoryzacji i identyfikacji. Wszystkie te interfejsy znajdują się w pakiecie Core , podczas gdy implementacje znajdują się w innych pakietach, w tym w danych wejściowych.

Ważne

Chociaż te interfejsy są przydatne, jeśli trzeba filtrować pod kątem określonego typu interakcji, zalecamy, aby nie kodować twoich interakcji w celu nasłuchiwania tych interfejsów specjalnie. W każdej sytuacji zawsze należy przyznać preferencje ogólne XRI jest wybierane i isHovered, a nie jakikolwiek interfejs specyficzny dla interakcji.

Jeśli nie jest to konieczne, nie należy odwoływać się do konkretnych implementacji zestawu narzędzi MRTK tych interfejsów w interakcjach, chyba że jest to absolutnie konieczne. We wszystkich przypadkach lepiej odwoływać się do interfejsów. Jawne odwoływanie się do konkretnych typów spowoduje ograniczenie interakcji tylko do pracy z bieżącymi, istniejącymi typami. Odwołując się tylko do interfejsów, należy zapewnić zgodność z przyszłymi implementacjami, które mogą nie klasyfikować istniejących implementacji.

IVariableSelectInteractor

Interakcje implementujące ten interfejs mogą wystawiać zmienną (czyli analogową) wybór do interakcji. Zmienna wybrana kwota może być odpytywane za SelectProgress pomocą właściwości . Interakcje zestawu narzędzi MRTK, które implementują ten interfejs, obejmują element MRTKRayInteractor i GazePinchInteractor. Podstawowe możliwości interakcji (domyślne możliwości interakcji XRI i MRTKBaseInteractable) nie będą miały wpływu na zmienną ilość wyboru; StatefulInteractablejednak nasłuchuje tej wartości i oblicza jej Selectedness na max() podstawie wszystkich uczestniczących zmiennych i interakcji innych niż zmienne.

IGazeInteractor

Interakcje, które implementują ten interfejs, reprezentują pasywne spojrzenie użytkownika, niezależnie od jakiejkolwiek manipulacji lub intencji. Implementacja zestawu narzędzi MRTK to FuzzyGazeInteractor, która dziedziczy z architektury XRI XRRayInteractori dodaje logikę rzutu rozmytego. XRBaseInteractable będzie flagą IsGazeHovered po umieszczeniu IGazeInteractor wskaźnika myszy.

IGrabInteractor

Interakcje implementujące ten interfejs reprezentują fizyczną interakcję w pobliżu pola. Element attachTransform jest definiowany jako punkt chwytania. Implementacja zestawu narzędzi MRTK to GrabInteractor, która podklasuje wartości XRDirectInteractorXRI .

IPokeInteractor

Interakcje implementujące ten interfejs reprezentują interakcję pokingu. Należy pamiętać, że niekoniecznie oznacza to palec! Dowolne interakcje mogą implementować ten interfejs i oferować interakcje z źródłami innych niż palce. W jednym z niewielu wystąpień, w których sprawdzanie interfejsów interakcji jest dobrym pomysłem, interakcje takie jak PressableButton nasłuchiwanie IPokeInteractors, w szczególności, do napędu prasy woluminowej. Każda interakcja, która implementuje IPokeInteractor , wywoła naciśnięcia 3D na przyciskach.

IPokeInteractor uwidacznia PokeRadius właściwość , która definiuje cechy obiektu kłusowania. Poke jest uważany za wyśrodkowany na attachTransform i rozciąga się na zewnątrz od attachTransform PokeRadiusobiektu . Interakcje, takie jak PressableButton przesunięcie ich odległości wypychania 3D przez ten promień, który może być napędzany przez fizyczną grubość palca użytkownika w przypadku naciśnięcia na palcach.

Implementacja zestawu narzędzi MRTK tego interfejsu to PokeInteractor. W naszym projekcie szablonu udostępniamy również inny przykład IPokeInteractor , który nie jest oparty na palcach; PenInteractor zapewnia interakcje z poke zakorzenione na wierzchołku wirtualnego stylu 3D.

IRayInteractor

Interakcje implementujące ten interfejs reprezentują interakcję wskazującą na promienie. Obiekt attachTransform reprezentuje lokalizację trafienia promienia na powierzchni obiektu docelowego podczas zaznaczenia.

Implementacja zestawu narzędzi MRTK tego interfejsu jest MRTKRayInteractordziedziczona bezpośrednio z XRI XRRayInteractor.

Uwaga

XRI XRRayInteractor nie implementuje tego interfejsu zestawu narzędzi MRTK.

ISpeechInteractor

Interakcje implementujące ten interfejs reprezentują interakcje oparte na mowie. Implementacja zestawu narzędzi MRTK to SpeechInteractor.

Zestaw narzędzi MRTK SpeechInteractor, wewnętrznie, używa PhraseRecognitionSubsystem i subskrybuje zdarzenia rejestracji z możliwością interakcji z XRI XRInteractionManager. Jednak interakcje nie muszą być zaniepokojone tym, jaki podsystem wykonuje przetwarzanie mowy; ISpeechInteractors wygeneruj te same zdarzenia XRI (wybierz i tak dalej), które wykonuje każda inna interakcja.

IGazePinchInteractor

Ten interfejs jest po prostu specjalizacją interfejsu IVariableSelectInteractor . Interakcje implementujące ten interfejs są niejawnie interakcjami selektorów zmiennych. IGazePinchInteractors wyraźnie reprezentują pośrednio ukierunkowaną zdalną manipulację. Oddzielny interakcja oparta na spojrzeniu napędza cel interakcji, a manipulacja jest ręcznie lub kontrolerem. attachTransform zachowuje się w taki sam sposób, jak IRayInteractorw attachTransform przypadku, gdy zostanie zainicjowany wybór, zostanie przyciągnięty do punktu trafienia w miejscu docelowym.

Gdy wiele IGazePinchInteractorosób uczestniczy w jednej interakcji, ich attachTransforms są przesunięte przez ich przemieszczenie z punktu mediany między wszystkimi uczestniczącymi punktami szczyptowania. W związku z tym interakcje mogą interpretować te attachTransformelementy w taki sam sposób, jak w przypadku każdej innej interakcji wieloręcznych, takich jak attachTransforms interakcja z zgarnięcia lub interakcje promieni.

Implementacja zestawu GazePinchInteractornarzędzi MRTK to .

IHandedInteractor

Niektóre interakcje mogą zdecydować się na zaimplementowanie IHandedInteractor interfejsu w celu jawnego określenia, że są one skojarzone z określoną ręką dla użytkownika. Niektóre interakcje nie są związane z wręcznością i w związku z tym nie implementują tego. Najbardziej oczywiste przykłady to takie jak SpeechInteractor lub FuzzyGazeInteractor.

Interakcje zestawu narzędzi MRTK implementujące ten interfejs to HandJointInteractor, ogólny, abstrakcyjny XRDirectInteractor sterowany przez dowolne połączenie ręczne, GazePinchInteractori MRTKRayInteractor.

Obecnie można korzystać z tego interfejsu do uruchamiania niektórych efektów po wybraniu, które muszą uściślać między lewą lub prawą ręką. Najbardziej godnym uwagi przykładem jest efekt impulsu w bibliotece składników środowiska użytkownika.