Kontrolery rąk i ruchu w trybie DirectX

Artykuł
03/21/2023

Uwaga

Ten artykuł dotyczy starszych natywnych interfejsów API winRT. W przypadku nowych projektów aplikacji natywnych zalecamy użycie interfejsu API OpenXR.

W Windows Mixed Reality dane wejściowe zarówno ręczne, jak i wejściowe kontrolera ruchu są obsługiwane za pośrednictwem interfejsów API danych wejściowych przestrzennych znajdujących się w przestrzeni nazw Windows.UI.Input.Spatial. Dzięki temu można łatwo obsługiwać typowe akcje, takie jak Select , naciska to samo w obu rękach i kontrolerach ruchu.

Wprowadzenie

Aby uzyskać dostęp do danych wejściowych przestrzennych w Windows Mixed Reality, zacznij od interfejsu SpatialInteractionManager. Dostęp do tego interfejsu można uzyskać, wywołując polecenie SpatialInteractionManager::GetForCurrentView, zazwyczaj czasami podczas uruchamiania aplikacji.

using namespace winrt::Windows::UI::Input::Spatial;

SpatialInteractionManager interactionManager = SpatialInteractionManager::GetForCurrentView();

Zadaniem spatialInteractionManager jest zapewnienie dostępu do usługi SpatialInteractionSources, która reprezentuje źródło danych wejściowych. W systemie są dostępne trzy rodzaje zasobów SpatialInteractionSources.

Ręka reprezentuje wykrytą rękę użytkownika. Źródła ręczne oferują różne funkcje oparte na urządzeniu, począwszy od podstawowych gestów na urządzeniu HoloLens do pełnego śledzenia rąk na HoloLens 2.
Kontroler reprezentuje sparowany kontroler ruchu. Kontrolery ruchu mogą oferować różne możliwości, na przykład Wybierz wyzwalacze, Przyciski menu, Przyciski chwytania, touchpady i szminki.
Głos reprezentuje słowa kluczowe wykryte przez system głosowy użytkownika. Na przykład to źródło wstrzykuje naciśnięcie klawisza Select i wydanie za każdym razem, gdy użytkownik powie "Wybierz".

Dane dla ramki dla źródła są reprezentowane przez interfejs SpatialInteractionSourceState . Istnieją dwa różne sposoby uzyskiwania dostępu do tych danych, w zależności od tego, czy chcesz użyć modelu opartego na zdarzeniach, czy sondowania w aplikacji.

Dane wejściowe sterowane zdarzeniami

Funkcja SpatialInteractionManager udostępnia wiele zdarzeń, dla których aplikacja może nasłuchiwać. Oto kilka przykładów: SourcePressed, [SourceReleased i SourceUpdated.

Na przykład poniższy kod podłącza procedurę obsługi zdarzeń o nazwie MyApp::OnSourcePressed do zdarzenia SourcePressed. Dzięki temu aplikacja może wykrywać naciśnięcia na dowolnym typie źródła interakcji.

using namespace winrt::Windows::UI::Input::Spatial;

auto interactionManager = SpatialInteractionManager::GetForCurrentView();
interactionManager.SourcePressed({ this, &MyApp::OnSourcePressed });

To zdarzenie naciśnięcia jest wysyłane do aplikacji asynchronicznie wraz z odpowiednim elementem SpatialInteractionSourceState w momencie wystąpienia naciśnięcia. Aparat aplikacji lub gier może chcieć rozpocząć przetwarzanie od razu lub w kolejce dane zdarzenia w procedurze przetwarzania danych wejściowych. Oto funkcja obsługi zdarzeń dla zdarzenia SourcePressed, która sprawdza, czy przycisk wyboru został naciśnięty.

using namespace winrt::Windows::UI::Input::Spatial;

void MyApp::OnSourcePressed(SpatialInteractionManager const& sender, SpatialInteractionSourceEventArgs const& args)
{
	if (args.PressKind() == SpatialInteractionPressKind::Select)
	{
		// Select button was pressed, update app state
	}
}

Powyższy kod sprawdza tylko naciśnięcie klawisza "Select", które odpowiada akcji podstawowej na urządzeniu. Przykłady obejmują wykonywanie funkcji AirTap na urządzeniu HoloLens lub ściąganie wyzwalacza na kontrolerze ruchu. Naciśnięcia "Select" reprezentują zamiar użytkownika aktywowania hologramu, którego dotyczy. Zdarzenie SourcePressed zostanie wyzwolone dla wielu różnych przycisków i gestów, a w tych przypadkach można sprawdzić inne właściwości w usłudze SpatialInteractionSource.

Dane wejściowe oparte na sondowaniu

Możesz również użyć funkcji SpatialInteractionManager do sondowania bieżącego stanu danych wejściowych każdej ramki. W tym celu wywołaj metodę GetDetectedSourcesAtTimestamp dla każdej ramki. Ta funkcja zwraca tablicę zawierającą jeden element SpatialInteractionSourceState dla każdego aktywnego elementu SpatialInteractionSource. Oznacza to, że jeden dla każdego aktywnego kontrolera ruchu, jeden dla każdej śledzonej ręki, a drugi dla mowy, jeśli polecenie "select" zostało ostatnio wypowiedziane. Następnie możesz sprawdzić właściwości w każdej usłudze SpatialInteractionSourceState, aby wprowadzić dane wejściowe do aplikacji.

Oto przykład sposobu sprawdzania akcji "select" przy użyciu metody sondowania. Zmienna przewidywania reprezentuje obiekt HolographicFramePrediction , który można uzyskać z elementu HolographicFrame.

using namespace winrt::Windows::UI::Input::Spatial;

auto interactionManager = SpatialInteractionManager::GetForCurrentView();
auto sourceStates = m_spatialInteractionManager.GetDetectedSourcesAtTimestamp(prediction.Timestamp());

for (auto& sourceState : sourceStates)
{
	if (sourceState.IsSelectPressed())
	{
		// Select button is down, update app state
	}
}

Każdy element SpatialInteractionSource ma identyfikator, którego można użyć do identyfikowania nowych źródeł i korelowania istniejących źródeł z ramki do ramki. Ręce otrzymują nowy identyfikator za każdym razem, gdy opuszczają i wprowadzają FOV, ale identyfikatory kontrolera pozostają statyczne przez czas trwania sesji. Zdarzenia można używać w usłudze SpatialInteractionManager, takich jak SourceDetected i SourceLost, aby reagować podczas wprowadzania lub opuszczania widoku urządzenia lub gdy kontrolery ruchu są włączone/wyłączone lub są sparowane/niespłacone.

Przewidywane a historyczne pozy

Parametr GetDetectedSourcesAtTimestamp ma parametr sygnatury czasowej. Dzięki temu można zażądać stanu i postawić dane, które są przewidywane lub historyczne, umożliwiając skorelowanie interakcji przestrzennych z innymi źródłami danych wejściowych. Na przykład podczas renderowania pozycji ręki w bieżącej ramce można przekazać przewidywaną sygnaturę czasową dostarczoną przez element HolographicFrame. Umożliwia to systemowi przewidywanie pozycji ręki w celu ścisłego dopasowania do renderowanych danych wyjściowych ramek, minimalizując zauważalne opóźnienie.

Jednak taka przewidywana postawa nie generuje idealnego promienia wskazującego na cel ze źródłem interakcji. Na przykład po naciśnięciu przycisku kontrolera ruchu do systemu operacyjnego może upłynąć do 20 ms dla tego zdarzenia. Podobnie po wykonaniu gestu dłoni przez użytkownika może upłynąć pewien czas, zanim system wykryje gest, a aplikacja następnie sonduje go. Do czasu sondowania aplikacji pod kątem zmiany stanu głowa i ręka stanowią używane do kierowania tej interakcji rzeczywiście miało miejsce w przeszłości. Jeśli celem jest przekazanie bieżącej znacznika czasowego elementu HolographicFrame do elementu GetDetectedSourcesAtTimestamp, zamiast tego pozycja zostanie przewidana do promienia docelowego w momencie wyświetlenia ramki, co może wynosić więcej niż 20 ms w przyszłości. Ta przyszła postawa jest dobra do renderowania źródła interakcji, ale stanowi związek z naszym problemem czasowym w celu kierowania interakcji, ponieważ cel użytkownika wystąpił w przeszłości.

Na szczęście zdarzenia SourcePressed, [SourceReleased i SourceUpdated zapewniają stan historyczny skojarzony z każdym zdarzeniem wejściowym. Obejmuje to bezpośrednio historyczną głowę i rękę, które są dostępne za pośrednictwem narzędzia TryGetPointerPose, wraz z historycznym znacznikiem czasu , który można przekazać do innych interfejsów API w celu skorelowania z tym zdarzeniem.

Prowadzi to do następujących najlepszych rozwiązań podczas renderowania i określania wartości docelowych za pomocą rąk i kontrolerów każdej ramki:

W przypadku renderowania każdej ramki/kontrolera aplikacja powinna sondowaćprzewidywaną do przodu postawę każdego źródła interakcji w czasie fotonu bieżącej ramki. Możesz sondować wszystkie źródła interakcji, wywołując metodę GetDetectedSourcesAtTimestamp każdą ramkę, przekazując przewidywaną sygnaturę czasową dostarczoną przez HolographicFrame::CurrentPrediction.
W przypadku celów ręcznych/kontrolerów przeznaczonych dla prasy lub wydania aplikacja powinna obsługiwać zdarzenia naciśnięcia/ wydania, raycasting w oparciu o historyczną głowę lub rękę pozować do tego zdarzenia. Ten element docelowy jest pobierany przez obsługę zdarzenia SourcePressed lub SourceReleased , pobierania właściwości State z argumentów zdarzeń, a następnie wywoływania metody TryGetPointerPose .

Właściwości wejściowe między urządzeniami

Interfejs API SpatialInteractionSource obsługuje kontrolery i systemy śledzenia rąk z szeroką gamą możliwości. Wiele z tych możliwości jest powszechnych między typami urządzeń. Na przykład śledzenie rąk i kontrolery ruchu zapewniają akcję "select" i pozycję 3D. Jeśli to możliwe, interfejs API mapuje te typowe możliwości na te same właściwości w usłudze SpatialInteractionSource. Dzięki temu aplikacje mogą łatwiej obsługiwać szeroką gamę typów danych wejściowych. W poniższej tabeli opisano obsługiwane właściwości oraz sposób ich porównywania między typami wejściowymi.

Właściwość	Opis	Gesty holoLens (1. generacji)	Kontrolery ruchu	Przegubowe ręce
SpatialInteractionSource::Handedness	Prawa lub lewa ręka / kontroler.	Nieobsługiwane	Obsługiwane	Obsługiwane
SpatialInteractionSourceState::IsSelectPressed	Bieżący stan przycisku podstawowego.	Naciśnij powietrze	Wyzwalacz	Zrelaksowany air tap (wyprostowany szczypta)
SpatialInteractionSourceState::IsGrasped	Bieżący stan przycisku grab.	Nieobsługiwane	Przycisk Chwytaj	Szczypta lub zamknięta ręka
SpatialInteractionSourceState::IsMenuPressed	Bieżący stan przycisku menu.	Nieobsługiwane	Przycisk menu	Nieobsługiwane
SpatialInteractionSourceLocation::Position	Położenie XYZ ręki lub uchwytu na kontrolerze.	Lokalizacja palmowa	Położenie uścisku	Lokalizacja palmowa
SpatialInteractionSourceLocation::Orientation	Quaternion reprezentujący orientację ręki lub uchwytu na kontrolerze.	Nieobsługiwane	Orientacja uścisku	Orientacja dłoni
SpatialPointerInteractionSourcePose::Position	Pochodzenie promienia wskazującego.	Nieobsługiwane	Obsługiwane	Obsługiwane
SpatialPointerInteractionSourcePose::ForwardDirection	Kierunek promienia wskazującego.	Nieobsługiwane	Obsługiwane	Obsługiwane

Niektóre z powyższych właściwości nie są dostępne na wszystkich urządzeniach, a interfejs API zapewnia środki do przetestowania. Na przykład możesz sprawdzić właściwość SpatialInteractionSource::IsGraspSupported , aby określić, czy źródło zapewnia akcję uchwycenia.

Pozy uchwytu a punktowanie pozy

Windows Mixed Reality obsługuje kontrolery ruchu w różnych czynnikach form. Obsługuje również systemy śledzenia rąk artykułowanych. Wszystkie te systemy mają różne relacje między położeniem ręki a naturalnym "przodu" kierunku, którego aplikacje powinny używać do wskazywania lub renderowania obiektów w ręku użytkownika. Aby zapewnić obsługę wszystkich tych elementów, istnieją dwa typy pozy 3D dostępne dla zarówno śledzenia rąk, jak i kontrolerów ruchu. Pierwszy to uścisk, który reprezentuje położenie ręki użytkownika. Drugim jest wskazywanie pozycji, która reprezentuje promienie wskazujące pochodzące z ręki lub kontrolera użytkownika. Jeśli więc chcesz renderować rękę użytkownika lub obiekt trzymany w ręku użytkownika, na przykład miecz lub broń, użyj pozy uchwytu. Jeśli chcesz raycast z kontrolera lub ręki, na przykład gdy użytkownik **wskazuje interfejs użytkownika, użyj pozycji wskazującej.

Dostęp do uścisku można uzyskać za pośrednictwem funkcji SpatialInteractionSourceState::P roperties::TryGetLocation(...). Jest on zdefiniowany w następujący sposób:

Położenie uchwytu: centroid palmowy podczas trzymania kontrolera naturalnie, wyrównany w lewo lub w prawo, aby wyśrodkować położenie w uścisku.
Oś prawej orientacji uchwytu: Kiedy całkowicie otworzysz rękę, aby utworzyć płaską pozę 5-palcem, promienie, które są normalne dla dłoni (do przodu z lewej dłoni, do tyłu z prawej dłoni)
Oś przodu orientacji uchwytu: Po zamknięciu ręki częściowo (jakby trzymał kontroler), promieni, który wskazuje "do przodu" przez rurkę utworzoną przez palce nie-kciuka.
Oś uścisku w górę: oś w górę dorozumiana przez definicje Prawa i Przodu.

Dostęp do wskaźnika można uzyskać za pośrednictwem elementu SpatialInteractionSourceState::P roperties::TryGetLocation(...)::SourcePointerPose lub SpatialInteractionSourceState ::TryGetPointerPose(...)::TryGetInteractionSourcePosePose.

Właściwości wejściowe specyficzne dla kontrolera

W przypadku kontrolerów właściwość SpatialInteractionSource ma właściwość Controller z dodatkowymi możliwościami.

HasThumbstick: Jeśli prawda, kontroler ma szminkę. Sprawdź właściwość ControllerProperties obiektu SpatialInteractionSourceState, aby uzyskać wartości kciuka x i y (ThumbstickX i ThumbstickY), a także stan naciśnięty (IsThumbstickPressed).
HasTouchpad: Jeśli ma wartość true, kontroler ma touchpad. Sprawdź właściwość ControllerProperties obiektu SpatialInteractionSourceState, aby uzyskać wartości touchpad x i y (TouchpadX i TouchpadY), a następnie sprawdź, czy użytkownik dotyka okienka (IsTouchpadTouchpadTouched), a jeśli naciskają w dół touchpad (IsTouchpadPressed).
SimpleHapticsController: Interfejs API SimpleHapticsController dla kontrolera umożliwia inspekcję możliwości haptycznych kontrolera, a także pozwala kontrolować opinie haptyczne.

Zakres dla touchpad i kciuka wynosi od -1 do 1 dla obu osi (od dołu do góry i od lewej do prawej). Zakres wyzwalacza analogowego, do którego uzyskuje się dostęp przy użyciu właściwości SpatialInteractionSourceState::SelectPressedValue, ma zakres od 0 do 1. Wartość 1 jest skorelowana z isSelectPressed jest równa true; każda inna wartość jest skorelowana z isSelectPressed jest równa false.

Śledzenie rąk przegubowych

Interfejs API Windows Mixed Reality zapewnia pełną obsługę śledzenia rąk artykułowanych, na przykład w HoloLens 2. Śledzenie rąk artykułowanych może służyć do implementowania modeli bezpośrednich manipulowania i wprowadzania punktów i zatwierdzania w aplikacjach. Może być również używany do tworzenia w pełni niestandardowych interakcji.

Szkielet ręki

Śledzenie rąk przegubowych zapewnia 25-stawowy szkielet, który umożliwia wiele różnych typów interakcji. Szkielet zapewnia pięć stawów dla indeksu/środkowego/pierścienia/ małych palców, czterech stawów dla kciuka i jednego stawu nadgarstka. Staw nadgarstka służy jako podstawa hierarchii. Na poniższej ilustracji przedstawiono układ szkieletu.

Szkielet dłoni

W większości przypadków każdy staw jest nazwany na podstawie kości, którą reprezentuje. Ponieważ istnieją dwie kości na każdym stawie, używamy konwencji nazewnictwa każdego stawu na podstawie kości podrzędnej w tej lokalizacji. Kość dziecka jest definiowana jako kość dalej od nadgarstka. Na przykład staw "Proximal indeksu" zawiera pozycję początkową kości proximalnej indeksu oraz orientację tej kości. Nie zawiera położenia końcowego kości. Jeśli tego potrzebujesz, otrzymasz go od następnego wspólnego w hierarchii, wspólnego "Pośrednie indeksowanie".

Oprócz 25 stawów hierarchicznych, system zapewnia staw palmowy. Palma nie jest zwykle uważana za część struktury szkieletowej. Jest on dostarczany tylko jako wygodny sposób, aby uzyskać ogólną pozycję i orientację ręki.

Dla każdego wspólnego podano następujące informacje:

Nazwa	Opis
Position	Położenie 3D stawu dostępne w dowolnym żądanym układzie współrzędnych.
Orientacja	Orientacja 3D kości, dostępna w dowolnym żądanym układzie współrzędnych.
Radius	Odległość do powierzchni skóry na pozycji stawu. Przydatne do dostrajania bezpośrednich interakcji lub wizualizacji, które opierają się na szerokości palca.
Dokładność	Zawiera wskazówkę na temat tego, jak pewny siebie system czuje się o informacjach tego wspólnego.

Dostęp do danych szkieletu ręki można uzyskać za pośrednictwem funkcji spatialInteractionSourceState. Funkcja jest nazywana TryGetHandPose i zwraca obiekt o nazwie HandPose. Jeśli źródło nie obsługuje wyartykułowanych rąk, ta funkcja zwróci wartość null. Gdy masz repozytorium HandPose, możesz uzyskać bieżące wspólne dane, wywołując metodę TryGetJoint z nazwą wspólnego, w którym cię interesuje. Dane są zwracane jako struktura JointPose . Poniższy kod pobiera położenie palca indeksu. Zmienna currentState reprezentuje wystąpienie obiektu SpatialInteractionSourceState.

using namespace winrt::Windows::Perception::People;
using namespace winrt::Windows::Foundation::Numerics;

auto handPose = currentState.TryGetHandPose();
if (handPose)
{
	JointPose joint;
	if (handPose.TryGetJoint(desiredCoordinateSystem, HandJointKind::IndexTip, joint))
	{
		float3 indexTipPosition = joint.Position;

		// Do something with the index tip position
	}
}

Siatka ręczna

Interfejs API śledzenia rąk artykułowanych umożliwia w pełni deformowalne siatki ręczne trójkąta. Ta siatka może deformować się w czasie rzeczywistym wraz ze szkieletem dłoni i przydaje się do wizualizacji i zaawansowanych technik fizyki. Aby uzyskać dostęp do siatki ręcznej, należy najpierw utworzyć obiekt HandMeshObserver przez wywołanie polecenia TryCreateHandMeshObserverAsync w usłudze SpatialInteractionSource. Należy to zrobić tylko raz w każdym źródle, zazwyczaj przy pierwszym wyświetleniu. Oznacza to, że wywołasz tę funkcję, aby utworzyć obiekt HandMeshObserver za każdym razem, gdy ręka wchodzi do FOV. Jest to funkcja asynchronicznie, więc musisz radzić sobie z odrobiną współbieżności tutaj. Po udostępnieniu możesz poprosić obiekt HandMeshObserver o bufor indeksu trójkąta, wywołując polecenie GetTriangleIn index. Indeksy nie zmieniają ramki na ramce, więc można je pobrać raz i buforować je przez cały okres istnienia źródła. Indeksy są dostarczane w kolejności uzwojenia w kierunku zegara.

Poniższy kod uruchamia odłączony element std::thread w celu utworzenia obserwatora siatki i wyodrębnia bufor indeksu po udostępnieniu obserwatora siatki. Rozpoczyna się od zmiennej o nazwie currentState, która jest wystąpieniem spatialInteractionSourceState reprezentującym śledzonej ręki.

using namespace Windows::Perception::People;

std::thread createObserverThread([this, currentState]()
{
    HandMeshObserver newHandMeshObserver = currentState.Source().TryCreateHandMeshObserverAsync().get();
    if (newHandMeshObserver)
    {
		unsigned indexCount = newHandMeshObserver.TriangleIndexCount();
		vector<unsigned short> indices(indexCount);
		newHandMeshObserver.GetTriangleIndices(indices);

        // Save the indices and handMeshObserver for later use - and use a mutex to synchronize access if needed!
     }
});
createObserverThread.detach();

Uruchamianie odłączonego wątku jest tylko jedną z opcji obsługi wywołań asynchronicznych. Alternatywnie możesz użyć nowej funkcji co_await obsługiwanej przez język C++/WinRT.

Po utworzeniu obiektu HandMeshObserver należy go trzymać przez czas, w którym jest aktywny odpowiedni obiekt SpatialInteractionSource. Następnie każda ramka może poprosić o najnowszy bufor wierzchołka, który reprezentuje rękę, wywołując polecenie GetVertexStateForPose i przekazując wystąpienie HandPose , które reprezentuje pozę, dla której mają być wierzchołki. Każdy wierzchołek w buforze ma położenie i normalne. Oto przykład sposobu pobierania bieżącego zestawu wierzchołków dla siatki ręcznej. Tak jak wcześniej, zmienna currentState reprezentuje wystąpienie spatialInteractionSourceState.

using namespace winrt::Windows::Perception::People;

auto handPose = currentState.TryGetHandPose();
if (handPose)
{
    std::vector<HandMeshVertex> vertices(handMeshObserver.VertexCount());
    auto vertexState = handMeshObserver.GetVertexStateForPose(handPose);
    vertexState.GetVertices(vertices);

    auto meshTransform = vertexState.CoordinateSystem().TryGetTransformTo(desiredCoordinateSystem);
    if (meshTransform != nullptr)
    {
    	// Do something with the vertices and mesh transform, along with the indices that you saved earlier
    }
}

W przeciwieństwie do stawów szkieletowych interfejs API siatki dłoni nie pozwala określić układu współrzędnych dla wierzchołków. Zamiast tego handMeshVertexState określa układ współrzędnych, w których znajdują się wierzchołki. Następnie możesz uzyskać przekształcenie siatki, wywołując polecenie TryGetTransformTo i określając odpowiedni układ współrzędnych. Za każdym razem, gdy pracujesz z wierzchołkami, musisz użyć tej transformacji siatki. Takie podejście zmniejsza obciążenie procesora CPU, zwłaszcza jeśli używasz tylko siatki do celów renderowania.

Spojrzenie i zatwierdzanie gestów złożonych

W przypadku aplikacji korzystających z modelu wejściowego spojrzenie i zatwierdzenie, szczególnie w przypadku urządzenia HoloLens (pierwsza generacja), interfejs API danych wejściowych przestrzennych udostępnia opcjonalny element SpatialGestureRecognizer , który może służyć do włączania złożonych gestów opartych na zdarzeniu "select". Rozsyłając interakcje z obiektu SpatialInteractionManager do urządzenia SpatialGestureRecognizer hologramu, aplikacje mogą wykrywać zdarzenia Tap, Hold, Manipulation i Navigation jednolicie między rękami, głosem i urządzeniami wejściowymi przestrzennymi bez konieczności ręcznego obsługi nacisków i wydań.

SpatialGestureRecognizer wykonuje tylko minimalne uściślanie między zestawem żądanych gestów. Jeśli na przykład zażądasz tylko naciśnięcia, użytkownik może trzymać palec w dół tak długo, jak lubią, a naciśnięcie będzie nadal występować. Jeśli zażądasz zarówno naciśnięcia, jak i blokady, po około sekundzie przytrzymywania palca gest podwyższa poziom do blokady, a naciśnięcie nie będzie już występować.

Aby użyć klasy SpatialGestureRecognizer, obsłuż zdarzenie InteractionDetected spatialInteractionManager i pobierz uwidocznione tam zdarzenie SpatialPointerPose. Użyj promienia wzroku głowy użytkownika z tej pozy, aby przeciąć się hologramami i siatkami powierzchniowymi w otoczeniu użytkownika, aby określić, z czym użytkownik zamierza korzystać. Następnie należy kierować element SpatialInteraction w argumentach zdarzeń do obiektu docelowego SpatialGestureRecognizer przy użyciu metody CaptureInteraction . Rozpoczyna się interpretowanie tej interakcji zgodnie z parametrem SpatialGestureSettings ustawionym na tym rozpoznawaniu w czasie tworzenia — lub za pomocą polecenia TrySetGestureSettings.

Na urządzeniu HoloLens (pierwsza generacja) interakcje i gesty powinny pochodzić od wzroku głowy użytkownika, a nie renderowania lub interakcji z lokalizacją strony. Po rozpoczęciu interakcji względne ruchy dłoni mogą służyć do sterowania gestem, tak jak w przypadku gestu Manipulowanie lub Nawigacja.