Skip to content
tech-deep-dive · 23 kwietnia 2026

Jak zbudowaliśmy eye tracking i semi-fizyczną wspinaczkę w Reach The Clouds

Notatki inżynierskie z Reach The Clouds, naszego VR demo na Meta Quest Pro: OVREyeGaze + raycast, własny system Eye Interactable, semi-fizyczna wspinaczka.

Autor: Aleksander Caban · Co-founder, Carbon Studio

Reach The Clouds — demo VR z eye-trackingiem od Carbon Studio, key art: wspinacz sięgający po gałąź w chmurach

Dwa pomysły, które warto połączyć

W Carbon Studio lubimy eksplorować rzeczy, które sprawiają że VR jest bardziej miejscem niż gadżetem. Przy Reach The Clouds — naszym demo na Meta Quest Pro, które ogłosiliśmy wiosną tego roku — dwa pomysły, wokół których krążyliśmy od dłuższego czasu, trafiły w końcu do tego samego prototypu: eye tracking jako realna metoda interakcji oraz semi-fizyczny system wspinaczki, który zamienia przemieszczanie się w gameplay, a nie tylko traversal.

Na papierze obie rzeczy brzmią jak feature’y, które odhacza się z listy. W praktyce obie otworzyły sporo pytań projektowych — i garść technicznych, których niekoniecznie się spodziewaliśmy.

Eye tracking w praktyce — OVREyeGaze + raycast

Użyliśmy Meta OVREyeGaze do czytania kierunku spojrzenia gracza. To łatwa część — SDK daje ci Unity Transform zgodny z tym, gdzie patrzą oczy. Czego nie daje: informacji o tym, na co konkretnie w scenie patrzy gracz. Spojrzenie jest kierunkiem, nie referencją do obiektu.

Dodaliśmy więc drugą warstwę: z forward-vectora spojrzenia wysyłamy raycast w świat i sprawdzamy, czy trafił w coś interaktywnego. Jeśli tak — obiekt po drugiej stronie przejmuje obsługę.

Taki flow pokrywa się z tym, jak dokumentacja Mety sugeruje podpinanie eye trackingu w scenach Unity — OVREyeGaze jako źródło kierunku, raycast jako sposób zamiany tego kierunku na konkretny cel. Decyzja, którą musieliśmy podjąć, dotyczyła rozłożenia logiki: ile siedzi w raycasterze, a ile w każdym obiekcie.

Eye Interactable — oddzielamy detekcję od reakcji

Skończyło się podziałem na dwa systemy:

  • Gaze detection — jeden komponent, odpowiedzialny za czytanie OVREyeGaze, wysyłanie raycastu i decydowanie, na co gracz patrzy.
  • Eye Interactable — nasz własny komponent, który żyje na każdym celowalnym obiekcie w scenie i definiuje, co ma się stać, kiedy obiekt jest obserwowany.

Ta separacja brzmi oczywisto z perspektywy czasu, ale dała nam dużo. Detektor nie musiał wiedzieć nic o gałęziach, przełącznikach czy warstwach chmur — po prostu emitował eventy „ten obiekt został obserwowany”. Każdy Eye Interactable mógł dowolnie zareagować: zacząć wzrost gałęzi, zaświecić się, odegrać dźwięk, podpiąć się pod dowolną mechanikę — bez dotykania kodu od eye trackingu.

Kod gameplay’owy zostawał blisko gameplay’u. Kod wejścia blisko wejścia.

Raycast i LineRenderer — detekcja i debugowanie

Dwa narzędzia zrobiły większość roboty wewnątrz gaze detectora.

Raycast był kręgosłupem detekcji — to samo API Unity, którego użyłbyś do standardowej selekcji pointerem, tylko zasilane oczami zamiast kontrolera.

LineRenderer był naszym przyjacielem w debugowaniu. Eye tracking trudno debugować na wyczucie — nie widzisz łatwo, co robią twoje własne oczy. Więc rysowaliśmy promień w scenie w czasie developmentu i patrzyliśmy jak się rusza, kiedy przesuwaliśmy spojrzenie. To pozwoliło nam wyłapać dryfy, przesunięcia i edge case’y, które inaczej byłyby prawie niemożliwe do złapania.

Pod koniec prototypu LineRenderer był wyłączony w buildzie produkcyjnym — ale długo zostawał w dev buildach.

Najtrudniejsze — interpretacja tego, gdzie ktoś naprawdę patrzy

Tu jest problem, o którym z góry nikt ci nie mówi: naiwny raycast ze spojrzenia nie trafia w to, na co patrzysz.

W pierwszej implementacji wzięliśmy forward-vector z transforma oka i wystrzeliliśmy prosty promień w scenę. Działało. Tylko nie czuło się dobrze. Promień „przechodził” za obiekt, na który patrzyliśmy, trafiał w coś daleko z tyłu — i gra reagowała na niewłaściwą rzecz.

Problem leżał w przepaści między surowym wejściem (kierunek) a intencją za nim (punkt skupienia). Oczy nie wpatrują się w idealnie prostej linii w nieskończoność — zbiegają się na czymś, i to „coś” jest tym, o czym gracz myśli. Nasz prostacki promień ignorował konwergencję w całości.

Spędziliśmy nad tym sporą część prototypu. Bez schodzenia w detal: poprawka polegała na tym, żeby przestać traktować kierunek oka jako pojedynczy wektor w pustkę, a zacząć traktować go jako sposób przybliżenia realnego punktu skupienia gracza w przestrzeni 3D. Kiedy to zaskoczyło, wszystko po drodze — triggery Eye Interactable, wizualizacje LineRenderer, feedback z play-testów — zaczęło wyglądać uczciwie.

Wyzwania produkcyjne — nowa biblioteka na custom player controllerze

Dwie rzeczy sprawiły, że implementacja była trudniejsza, niż sugerowałaby czysta integracja.

Po pierwsze, Meta OVREyeGaze był relatywnie nowy, kiedy z nim pracowaliśmy. Oficjalna dokumentacja istniała, ale przykładów było mało, a wiedzy społecznościowej jeszcze mniej. Za każdym razem, kiedy trafialiśmy na dziwny edge case, budowaliśmy też narzędzia, żeby go w ogóle zrozumieć.

Po drugie i bardziej boleśnie: byliśmy na custom player controllerze, nie na defaultcie Mety. Dokumentacja — i szczerze większość tutoriali o eye trackingu — zakłada, że używasz OVRCameraRig z OVRManagerem, włączasz Eye Tracking Support w rigu, i prosisz o Eye Tracking permissions na starcie aplikacji przez standardowy boilerplate. To jest rozsądny default. Tylko tak się składa, że to był właśnie ten, który zastąpiliśmy własnym rozwiązaniem.

Trzeba było więc zrobić to wszystko ręcznie: podpiąć eye-tracking support do naszego riga, poprosić o permissions w naszym własnym flow startowym aplikacji, upewnić się, że dane o spojrzeniu lądują w odpowiednim transformie w odpowiednim momencie. Nic z tego nie było technicznie trudne. To była po prostu seria małych decyzji, które każdą musieliśmy podjąć na nowo na warstwie naszej architektury gracza.

Semi-fizyczna wspinaczka — ruch, który ma ciężar

Drugim filarem Reach The Clouds był system semi-fizycznej wspinaczki. Nazwa brzydka, pomysł prosty.

Chcieliśmy, żeby wspinaczka w VR zachowała fizyczne czucie ruchu — sięgasz, chwytasz, twój ciężar gdzieś jest — bez tego, żeby stać się na tyle fizyczną, że wejdzie sobie w drogę. Pełna fizyka wspinaczki jest wyczerpująca i nieczytelna. Czysto animowana wspinaczka jest martwa. Chcieliśmy środka.

Mechanika opiera się na tym, że gracz fizycznie chwyta rękami elementy otoczenia — gałęzie, wypustki, uchwyty. Ten chwyt jest tym, co wzmacnia obecność: kontakt jest prawdziwy, puszczenie jest świadome, a przestrzeń między chwytami ma ciężar.

Ważniejsze od samego chwytu było to, jak gracz wyrzuca się w stronę następnego uchwytu. Łatwo pozwolić, żeby wspinaczka w VR zamieniła się w bezwładny dryf z punktu do punktu. Sporo czasu spędziliśmy na tuningu wyrzutu: ile momentum daje wahnięcie, jak odpowiada ciało, co znaczy „za daleko” i „w sam raz”. Celem był rytm — ruch, który ma beat, a nie tylko trajektorię.

Łamiące się gałęzie i mechanika upadku

Żeby przepchnąć mechanikę z przemieszczania się w gameplay, dodaliśmy dwie rzeczy.

Gałęzie się łamią. Nie wszystkie, nie losowo — ale gałąź, którą gracz chwyci, może pęknąć pod ciężarem, po za długim czasie, albo pod złym kątem. Nagle to, po którą gałąź sięgasz, ma znaczenie.

Można spaść. Upadek nie jest tylko utratą postępu; jest konsekwencją, która kształtuje każdą kolejną decyzję. Wspinaczka w naszym systemie nigdy nie jest tylko spacerem po ścianie. Jest sekwencją małych zakładów: utrzymam to? sięgnę stąd? czy tamta gałąź puści?

Razem te dwa dodatki zamieniły system ruchu w sytuację gameplay’ową. To był cel od początku.

Technologia w służbie immersji

To, że postawiliśmy eye tracking i semi-fizyczną wspinaczkę obok siebie, nie było przypadkiem. Patrząc wstecz — oba wzmacniają tę samą ideę z dwóch stron.

Eye tracking zrobił z uwagi gracza pełnoprawne wejście. To, gdzie patrzysz, jest teraz czymś, o czym świat wie.

Wspinaczka zrobiła z ciała gracza pełnoprawne wejście. Jak się ruszasz, jak chwytasz, jak się commitujesz — świat też o tym wie.

Żaden z tych feature’ów z osobna nie zrobiłby doświadczenia immersyjnym. Razem podniosły podłogę tego, o co demo mogło poprosić gracza i czego gracz mógł oczekiwać z powrotem.

Tu właśnie, jak sądzimy, leży najciekawsza praca w VR: na styku precyzyjnego wejścia i fizycznego zaangażowania.

Co dalej

Prototypy takie jak Reach The Clouds nie są tylko o konkretnym demo. Są o budowaniu muscle memory dla bardziej zaawansowanego designu interakcji VR — tego rodzaju, którego nie nauczysz się z whitepapera, tylko próbując.

Eye tracking tanieje, robi się dokładniejszy i szerzej dostępny. Semi-fizyczny input (ręce, ciało, haptyka) jest dojrzały na tyle, żeby go shipować. Połączenie tych dwóch rzeczy wciąż jest szybko zmieniającym się obszarem — i dokładnie dlatego warto z nim eksperymentować dzisiaj, zanim konwencje się ustalą.

Jeśli chcesz zobaczyć, jak to wszystko składa się w realnym gameplay’u, zapowiedź Reach The Clouds opisuje czym jest demo i jak ma się ono czuć. Ten post jest dla osób ciekawych przewodów pod spodem.

Kluczowe wnioski

  • Zbudowane dla Meta Quest Pro. Użyliśmy Meta OVREyeGaze do kierunku spojrzenia i dodaliśmy warstwę raycast żeby zamienić spojrzenie w selekcję obiektów — OVREyeGaze mówi *gdzie* oczy patrzą, nie *na co* gracz patrzy.
  • Podzieliliśmy system na dwie rzeczy: wykrywanie spojrzenia (gdzie gracz patrzy) i własny komponent Eye Interactable (co ma się stać z konkretnym obiektem). Ta separacja sprawiła, że system jest skalowalny na różne mechaniki.
  • Semi-fizyczna wspinaczka: gracz fizycznie chwyta elementy otoczenia. Dodanie łamiących się gałęzi i mechaniki upadku zamieniło przemieszczanie się w gameplay — ruch z rytmem, ciężarem i ryzykiem.
  • Największe wyzwanie techniczne: naiwny raycast z forward-vectora oczu strzelał „za daleko prosto” i mijał prawdziwy punkt skupienia wzroku. Poprawienie tej interpretacji było kluczem do naturalnie działającej interakcji.
  • Dokumentacja Mety zakłada standardowy setup gracza na OVRCameraRig + OVRManager. Nasz custom player controller oznaczał ręczne przepięcie permissions, inicjalizacji riga i włączenia eye trackingu.

Najczęstsze pytania

+ Czym jest Meta OVREyeGaze?

OVREyeGaze to komponent Meta Horizon SDK do eye trackingu na wspieranych urządzeniach Meta Quest. Udostępnia kierunek spojrzenia gracza jako Unity Transform, który używasz do sterowania interakcją — zwykle przez raycast z forward-vectora spojrzenia i sprawdzenie, co trafi w scenie.

+ Które urządzenia Meta Quest wspierają eye tracking?

Kiedy budowaliśmy Reach The Clouds, eye tracking był dostępny na Meta Quest Pro. API (OVREyeGaze) jest takie samo na nowszych headsetach Meta Quest, które mają sprzętowy eye tracking — różnią się tylko warstwy permissions i capability checks.

+ Jak w praktyce działa raycast ze spojrzenia?

OVREyeGaze daje kierunek zgodny z tym, gdzie patrzy gracz. Wysyłasz raycast z pozycji oczu wzdłuż tego kierunku i sprawdzasz kolizje z interaktywnymi obiektami w scenie. Kiedy promień trafi w cel, odpalasz jego zachowanie — u nas to zachowanie żyje w osobnym komponencie Eye Interactable, nie w detektorze spojrzenia.

+ Czym jest Reach The Clouds?

Reach The Clouds to nasze demo VR na Meta Quest Pro, które używa eye trackingu jako głównego wejścia. Ogłosiliśmy je w marcu 2026 — pełne omówienie demo i zawartości jest w [zapowiedzi Reach The Clouds](https://carbonstudio.pl/2026/03/16/reach-the-clouds-gra-vr-eye-tracking/). Ten post schodzi poziom niżej — jak faktycznie działają leżące pod tym systemy.

Źródła i dalsza lektura

  1. [01] Meta OVREyeGaze — Eye Tracking w Unity — Meta Horizon Developers
  2. [02] Reach The Clouds - Nasze nowe demo VR z eye-trackingiem na Meta Quest Pro — Carbon Studio (2026-03-16)
#eye-tracking#reach-the-clouds#meta-quest-pro#vr#xr#unity#ovreye-gaze#case-study
AC

Aleksander Caban

Co-founder, Carbon Studio

Co-founder of Carbon Studio, a Polish VR game studio behind The Wizards, Hunt Together, and Warhammer Age of Sigmar: Tempestfall. Writes about XR, AI, and the craft of immersive software.