Jak ustawić ASW/SSW w Quest, by symulatory działały stabilnie

Cel ustawień ASW/SSW przy symulatorach na Queście

Intencja jest prosta: tak ustawić ASW/SSW w Queście, żeby kokpit nie „pływał”, obraz nie rwał się przy zerkaniu na boki, a jednocześnie sterowanie pozostało przewidywalne i bez nadmiernych opóźnień. Chodzi o stabilny, powtarzalny frame time, a nie tylko imponującą, ale skaczącą liczbę FPS w overlayu.

Symulatory VR (lotnicze i wyścigowe) są szczególnie wrażliwe na niejednolite tempo generowania klatek. Nawet jeśli średni FPS wygląda dobrze, nieprawidłowo ustawione ASW/SSW potrafi zamienić to w doświadczenie pełne juddera, ghostingu i dziwnie reagującego sterowania. Prawidłowa konfiguracja reprojection to tu nie „tweak kosmetyczny”, ale warunek bazowy.

Czym jest ASW/SSW i po co je ustawiać przy symulatorach

Reprojection w praktyce – co faktycznie robi z obrazem

ASW (Asynchronous Spacewarp) i SSW (Synchronous Spacewarp) to mechanizmy reprojection, które próbują „dosztukować” brakujące klatki, gdy GPU nie nadąża z renderowaniem natywnej liczby FPS równej odświeżaniu headsetu. Zamiast 90 fizycznie wyrenderowanych klatek na sekundę, system może wyrenderować np. 45, a co drugą klatkę „przewidzieć” na podstawie poprzedniej i ruchu głowy.

W praktyce wygląda to tak, że:

• gra renderuje mniej klatek (np. 45 FPS przy 90 Hz),
• moduł ASW/SSW analizuje ruch głowy i obraz sceny z poprzedniej klatki,
• generuje pseudo-klatki pośrednie, „przesuwając” obraz zgodnie z ruchem głowy i szacowanym ruchem obiektów,
• headset nadal odświeża się np. 90 razy na sekundę, ale co druga klatka jest przewidywana.

Jeśli reprojection działa dobrze, użytkownik widzi płynny obraz mimo niższego natywnego FPS. Jeśli jednak tryb ASW/SSW nie jest dopasowany do możliwości GPU oraz rodzaju ruchu w grze, pojawia się cała gama zakłóceń: falowanie obrazu podczas head-trackingu, rozciągnięcia obiektów, dziwne „pływanie” kokpitu przy turbo bocznym ruchu głowy.

Symulatory generują masę obliczeń CPU/GPU (fizyka, AI, avionika, dalekie zasięgi renderowania), przez co utrzymanie pełnego FPS równego odświeżaniu Questa jest trudne. Dlatego to właśnie w symulatorach rozsądnie ustawione ASW/SSW bywa kluczowe – zamiast polować na idealne 90 FPS, stabilizuje się scenariusz na 45 FPS + reprojection, by uniknąć losowych dropów.

Różnica między ASW a SSW w ekosystemie Meta/Oculus

W skrócie:

• ASW – klasyczne rozwiązanie Oculus/Meta dla PCVR (Oculus Link, Air Link), pracujące asynchronicznie względem renderingu,
• SSW – nowsza wersja, stosowana m.in. przez Virtual Desktop i w niektórych ścieżkach OpenXR, często lepiej radząca sobie z dynamicznymi scenami.

ASW w ekosystemie Meta jest zwykle kontrolowane przez aplikację Meta/Oculus i Oculus Debug Tool (Quest Debug Tool). Tryby obejmują wyłączenie, auto oraz wymuszenie określonego podziału (np. 45 FPS przy 90 Hz). ASW korzysta z informacji o ruchu głowy i przekazanych danych z gry, ale nie zawsze idealnie traktuje szybko przemieszczające się obiekty daleko w tle – stąd znane „smugi” skrzydeł czy ogon rozciągający się przy gwałtownych manewrach.

SSW (w Virtual Desktop na PCVR) może stosować bardziej zaawansowane techniki (m.in. depth-based reprojection), które lepiej rozdzielają warstwy sceny, ale i tak nie są magicznym lekarstwem: jeśli natywne FPS są zbyt niskie albo bardzo niestabilne, SSW jedynie „upiększa” judder, nie rozwiązując źródła problemu. Dla symulatorów, gdzie horyzont i kokpit stanowią kluczowy punkt odniesienia, drobne błędy predykcji stają się natychmiast widoczne.

Typowe objawy źle dobranych ustawień ASW/SSW

Reprojection źle dobrane do wydajności i odświeżania powoduje bardzo charakterystyczne artefakty. Kilka najczęściej spotykanych sygnałów ostrzegawczych:

• Judder przy panoramowaniu głową – szybkie zerknięcie na boki (np. w DCS podczas przelotu nad miastem) powoduje szarpany, „schodkowy” ruch horyzontu, mimo że overlay pokazuje akceptowalny FPS.
• „Pływający” kokpit – przy poruszaniu głową kokpit wydaje się lekko „gumowy”, przesuwa się niezależnie od otoczenia, szczególnie w Assetto Corsa/ACC w pitlane lub przy patrzeniu na słupki hamowania.
• Rozmycia i smugi przy szybko poruszających się obiektach – samoloty w formacji, auta przed nami, skrzydła samolotu – przy dynamicznym ruchu głowy ich krawędzie „rozciągają się” lub dublują.
• Niestałe poczucie prędkości – w iRacing lub MSFS przy podobnej prędkości raz czujemy płynny ruch, raz jakby środowisko skakało, szczególnie przy zbliżaniu się do gęstej zabudowy.

Jeśli takie objawy występują, mimo że mierniki FPS (np. w OpenXR Toolkit) pokazują akceptowalne wartości, głównym podejrzanym powinna być konfiguracja ASW/SSW lub konflikt kilku systemów reprojection jednocześnie.

Symulatory a wymóg stabilności zamiast „średniego FPS”

W grach akcji chwilowe dropy FPS są mniej odczuwalne – mózg wybacza krótkotrwałe fluktuacje. W symulatorach VR sytuacja jest odwrotna: kluczowy jest równy rytm klatek. Nawet 5–10 ms dodatkowego opóźnienia w niektórych momentach przekłada się na:

• rozsynchronizowanie obrazu z czuciem ruchu (szczególnie przy motion rigach),
• problemy z precyzyjnym wyczuciem punktu hamowania, flare przy lądowaniu,
• zwiększoną męczliwość wzroku i zawroty głowy po kilku dłuższych sesjach.

ASW/SSW może wyrównać ten rytm, ale tylko przy rozsądnym doborze targetu FPS. Próba „dociśnięcia” ustawień graficznych do granic możliwości, a potem ratowanie się agresywnym auto-ASW, zwykle kończy się mikroprzycięciami i feelingiem „na gumce”. Stabilne 45 FPS + ASW bywa w praktyce przyjemniejsze i bardziej spójne niż skaczące 65–85 FPS bez reprojection.

Jeśli obraz faluje przy ruchu głową mimo teoretycznie wysokiego FPS, pierwszym punktem kontrolnym powinna być konfiguracja ASW/SSW i potencjalne konflikty systemów reprojection, a dopiero później surowa moc GPU.

Podstawowe wymagania sprzętowe i systemowe – minimum, zanim dotkniesz ASW/SSW

Punkt kontrolny: stan systemu Windows i sterowników

Konfiguracja ASW/SSW ma sens dopiero wtedy, gdy system spełnia bazowe warunki techniczne. Bez tego każda zmiana reprojection będzie maskowała problemy zamiast je rozwiązywać. Krytyczne elementy:

• Sterowniki GPU – aktualna wersja NVIDIA/AMD (często lepiej trzymać się stabilnych „Game Ready” niż eksperymentalnych). Sygnał ostrzegawczy: artefakty obrazu, losowe crashe, skaczące zużycie GPU w MSI Afterburner.
• Firmware Questa – nowsze aktualizacje często poprawiają stabilność Link/Air Link i opóźnienia. Zbyt stara wersja może ograniczać dostępne odświeżania lub powodować problemy z bitrate.
• Aplikacja Meta/Oculus na PC – wymagany aktualny kanał (public), brak błędów w logach przy starcie, poprawne wykrywanie Questa jako urządzenia PCVR.

Bez tej bazy konfiguracja ASW kończy się „gaszeniem pożaru benzyną”: użytkownik widzi judder, włącza lub wyłącza ASW w panice, podczas gdy prawdziwym problemem są wysypujące się sterowniki lub niestabilny Link.

Tryb zasilania w Windows i plan zasilania GPU

Symulatory i reprojection są bardzo wrażliwe na agresywne oszczędzanie energii. Kilka zmian, które powinny być traktowane jako minimum higieniczne:

• Plan zasilania Windows – „Wysoka wydajność” lub odpowiednik producenta (np. „AMD High Performance”). Tryb zrównoważony bywa sygnałem ostrzegawczym, szczególnie na laptopach.
• Ustawienia GPU – w panelu sterowania NVIDIA/AMD wymuszenie maksymalnej wydajności dla danej aplikacji (MSFS, DCS, iRacing) oraz brak limitów FPS na poziomie sterownika, jeśli zamierza się sterować limitem z innego miejsca (OpenXR Toolkit, RTSS).
• USB i PCIe – wyłączone oszczędzanie energii dla kontrolerów USB, brak „uśpienia” portów, szczególnie przy Oculus Link po kablu.

Jeśli zasilanie jest dławione, nawet teoretycznie wydajne GPU będzie raz na kilka sekund „spuszczać z tonu”, co rozwala rytm klatek. ASW/SSW próbuje to maskować, ale efektem są mikroprzycięcia i nieprzewidywalne aktywowanie się/wyłączanie reprojection.

Spójność łańcucha VR: port USB, kabel, router Wi‑Fi

Przy Queście kluczowy jest cały łańcuch przesyłu danych:

• Oculus Link (kabel) – stabilne USB 3.x, najlepiej bez hubów i przejściówek; sygnał ostrzegawczy: test prędkości w aplikacji Meta pokazuje słaby wynik lub spadki bitrate w czasie gry.
• Air Link / Virtual Desktop – router Wi-Fi 5/6, najlepiej dedykowany kanał 5 GHz lub 6 GHz, brak innych obciążających klientów, sensowne ustawienie szerokości kanału (80 MHz zazwyczaj wystarcza, 160 MHz bywa kapryśne).
• Połączenie PC–router – zawsze przewodowe (Ethernet). PC na Wi-Fi to czerwony sygnał ostrzegawczy dla symulatorów VR.

Niestabilne łącze (USB lub Wi-Fi) objawia się nie tylko artefaktami kompresji, ale również wahaniem opóźnień. ASW/SSW bazuje na założeniu, że pipeline jest w miarę stabilny. Jeśli co pewien czas dochodzi do retransmisji pakietów lub dropów w kablu, algorytm reprojection wchodzi w nieprzewidywalne stany.

Procesy w tle: kiedy coś należy wyłączyć

Symulatory VR działają na granicy możliwości CPU i GPU. Każdy dodatkowy overlay, nakładka czy nagrywarka wprowadza dodatkowe obciążenie oraz opóźnienia w pipeline.

• Overlaye (Discord, GeForce Experience, Steam, MSI Afterburner OSD) – używać tylko jednego głównego narzędzia diagnostycznego na raz. Kilka OSD jednocześnie to prosty przepis na niestabilne czasy klatek.
• Nagrywarki/streaming (OBS, ShadowPlay) – jeśli konieczne, skonfigurować tak, by minimalizować obciążenie GPU/CPU (np. NVENC, brak zbyt agresywnego skalowania). Dla testów ASW/SSW najlepiej wyłączyć całkowicie.
• Drobne procesy (chmury, oprogramowanie RGB, aktualizatory) – każdy pojedynczo wydaje się niczym, ale razem potrafią dodać kilka ms do time frame, co przy 90 Hz robi realną różnicę.

Jeżeli system nie spełnia bazowego „minimum higienicznego” (aktualne sterowniki, stabilne zasilanie, czyste łącze, ograniczone procesy w tle), korekta ASW/SSW będzie jedynie częściowym plastrem na głębsze problemy.

Środowiska uruchomieniowe: Oculus Link, Air Link, Virtual Desktop, OpenXR

Który komponent kontroluje reprojection w danym scenariuszu

Najczęstsza przyczyna chaosu z ASW/SSW w symulatorach to niejasność, kto faktycznie kontroluje reprojection w konkretnej konfiguracji. W łańcuchu pojawia się kilka potencjalnych „szefów”:

• sterownik Meta/Oculus (Oculus Link / Air Link),
• OpenXR runtime (np. Meta OpenXR, SteamVR OpenXR, WMR OpenXR),
• SteamVR (jeśli gra używa SteamVR jako warstwy VR),
• OpenXR Toolkit (jeśli używany),
• sama gra/silnik (rzadziej, ale są silniki z własnymi trikami).

Jeśli dwa moduły próbują jednocześnie narzucać własne reprojection (np. ASW w Oculusa plus Motion Smoothing w SteamVR), efekt jest zwykle katastrofalny: nieregularny rytm klatek, „podwójne” smużenie i trudne do zdiagnozowania dropy.

Różnice między natywnym Oculusem, OpenXR, SteamVR, Virtual Desktop

W praktyce użytkownik Questa z symulatorami spotyka cztery główne scenariusze:

• Oculus Link/Air Link z natywnym Meta OpenXR – ASW kontrolowane głównie przez Oculus Debug Tool / Meta PC app; często optymalne dla MSFS (przy użyciu Meta OpenXR) i części gier z natywnym wsparciem OpenXR.
• Oculus Link/Air Link z SteamVR (OpenVR) – gra widzi SteamVR, a Quest jest „podwieszony” przez aplikację Meta; reprojection może być po części w rękach SteamVR (Motion Smoothing) i Oculusa.

Virtual Desktop jako osobna warstwa – kto wtedy rządzi ASW/SSW

Virtual Desktop dodaje do łańcucha własną warstwę strumieniowania i własne ustawienia „Smoothing”. W efekcie zarządzanie reprojection rozdziela się na dwa poziomy:

• poziom headsetu / streamera – ustawienia Virtual Desktop (Slicing, Synchronous Spacewarp, Smoothing, bitrate, odświeżanie),
• poziom API VR – OpenXR (SteamVR OpenXR, WMR OpenXR, Meta OpenXR poprzez VD „OpenXR layer”) lub starsze OpenVR.

Kluczowy punkt kontrolny: nie wolno jednocześnie forsować reprojection na obu poziomach. Jeśli VD ma włączone własne SSW/Smoothing, a jednocześnie SteamVR trzyma Motion Smoothing lub WMR ma aktywny reprojection, pojawiają się efekty „podwójnego doczepiania klatek”.

Typowy scenariusz z symulatorami na VD:

• MSFS z OpenXR przez SteamVR – głównym sterującym bywa SteamVR (Motion Smoothing), VD musi być ustawiony neutralnie (minimalne Smoothing, stabilne odświeżanie),
• DCS na SteamVR – sytuacja analogiczna, szczególnie w trybie „multiplayer low FPS”, gdzie każdy dodatkowy algorytm reprojection multiplikuje artefakty.

Jeżeli płynność w Virtual Desktop „pływa”, a overlay SteamVR pokazuje nieregularne frame time, pierwszym podejrzeniem powinno być dublowanie się SSW/Smoothing VD z Motion Smoothing po stronie runtime’u.

OpenXR Toolkit, FSR/FSR i inne nakładki – gdzie kończy się tuning, a zaczyna sabotaż

OpenXR Toolkit, narzędzia upscalingu (FSR, NIS), dodatkowe warstwy overlay (fpsVR, OpenXR overlay) kuszą precyzyjną kontrolą. W praktyce każdy moduł, który zmienia rozdzielczość, wtrąca się w pipeline lub próbuje limitować FPS, może wchodzić w konflikt z ASW/SSW.

Przy ocenie konfiguracji pomocne są trzy pytania kontrolne:

• Kto nadaje docelowy rytm klatek? – jeżeli celem jest 45 FPS przy 90 Hz headsetu, musi istnieć jedno źródło „targetu” (limit w grze, w OpenXR Toolkit lub w sterowniku). Podwójne limity prowadzą do niestabilnego time frame.
• Kto skaluje rozdzielczość? – jednoczesne użycie suwaka rozdzielczości w grze, w panelu OpenXR, w SteamVR i dodatkowego upscalingu FSR to prosty przepis na niespójny rendering.
• Kto stosuje reprojection? – ASW/SSW musi być przypisane do jednego runtime’u lub jednej warstwy. Toolboxy z własnym „frame limitingiem” nie powinny duplikować tej funkcji.

Jeśli po włączeniu OpenXR Toolkit symulator „miota się” między 30 a 45 FPS mimo stałej scenerii, zwykle winny jest źle ustawiony limit FPS lub próba jednoczesnego sterowania reprojection z kilku miejsc (Toolkit + SteamVR + Meta runtime).

ASW/SSW w praktyce – tryby pracy i kiedy który wybrać

Podstawowe tryby ASW/SSW i ich konsekwencje

W środowisku Questa przy Link/Air Link spotkasz kilka typowych trybów pracy ASW/SSW, zwykle dostępnych z poziomu Oculus Debug Tool lub Oculus Tray Tool:

• ASW Off (wyłączone) – headset renderuje każdą klatkę natywnie; wymagane utrzymanie pełnego FPS (np. 72/80/90/120) przez GPU. Każdy spadek poniżej docelowej częstotliwości oznacza judder bez „ratunku”.
• ASW Auto – runtime sam decyduje, kiedy obniżyć „realny” FPS i dociągać klatki syntetyczne. Dobre dla gier akcji, dla symulatorów bywa zbyt dynamiczne (ciągłe przełączanie trybów).
• Force 45 Hz / 30 Hz / 18 Hz (czyli 1/2, 1/3, 1/4 odświeżania) – tryb wymuszonego locka na ułamku natywnego odświeżania, reszta klatek jest syntetyczna. To kluczowe tryby dla ciężkich symulatorów.
• SSW (Synchronous SpaceWarp) – uzupełniająca technologia po stronie Questa (szczególnie w Virtual Desktop i nowszych runtime’ach), generująca dodatkowe klatki przestrzennie.

Im niższa frakcja (1/2 vs 1/3 vs 1/4), tym więcej pracy wykonuje algorytm ASW/SSW, a mniej „prawdziwego” renderingu. Po pewnym progu (1/3 i 1/4) zysk płynności bywa okupiony wyraźnym smużeniem i „galaretą” przy dynamicznym ruchu głową.

Dobór docelowego odświeżania headsetu do mocy GPU

Zanim w ogóle przełączysz tryb ASW, trzeba ustalić podstawowy parametr: odświeżanie Questa. Zasada jest prosta: im wyższe odświeżanie, tym niższa tolerancja na wahania oraz tym ostrzejsze wymagania wobec reprojection.

Przydatne punkty odniesienia:

• 72 Hz – często rozsądne minimum dla słabszych GPU i gęstych scenerii (duże lotniska, miasta w MSFS). Przy wymuszonym 1/2 ASW celujesz w 36 FPS „prawdziwych” klatek.
• 80/90 Hz – kompromis między responsywnością a wymaganiami. Przy 90 Hz i locku 45 FPS ASW ma sensowną bazę do generowania syntetycznych klatek.
• 120 Hz – tylko dla bardzo mocnych GPU i raczej lżejszych tytułów; w symulatorach rzadko osiągalne w stabilny sposób, a agresywne ASW 1/3 lub 1/4 często pogarsza feeling.

Jeżeli GPU nie utrzymuje stałych 45 FPS w typowym scenariuszu lotu/wyścigu, przechodzenie na wyższe odświeżanie (np. z 72 na 90 Hz) bez redukcji ustawień graficznych jest sygnałem ostrzegawczym. ASW będzie próbował kompensować, ale pipeline stanie się niestabilny.

Kiedy wyłączyć ASW/SSW mimo niższego FPS

Są sytuacje, w których lepiej zaakceptować niższy, ale stabilny natywny FPS bez ASW, niż agresywną interpolację:

• latanie VFR nisko nad terenem fotogrametrycznym – przy szybkim „przelocie” nad domami i drzewami ASW często wprowadza falowanie i zniekształcenia tekstur, co zaburza ocenę odległości,
• symulatory z wieloma cienkimi obiektami (linie wysokiego napięcia, ogrodzenia, maszty) – algorytmy reprojection gubią takie detale, tworząc migotanie i artefakty „duchów”,
• rigi ruchu – jeśli motion platform ma bardzo niski lag, a ASW dodaje nieregularne opóźnienie, pojawia się rozjazd między ruchem fotela a obrazem.

Jeżeli przy wyłączeniu ASW obraz jest mniej „gładki” liczbowo, ale znika uczucie gumowego ruchu i opóźnionej reakcji na drążek, to znak, że dany symulator lub sceneria lepiej znosi czysty, nawet niższy FPS niż mocno przetworzony ASW.

Lock na 45 FPS jako „złoty środek” dla większości symulatorów

W praktyce wiele konfiguracji PC + Quest kończy w punkcie kontrolnym: 90 Hz w headset + stabilny lock 45 FPS w symulatorze. W takim układzie

• GPU renderuje jedną „prawdziwą” klatkę na dwie wyświetlane,
• ASW/SSW ma przewidywalny rytm pracy,
• mikrodropy z 50 do 40 FPS nie są dramatem, bo i tak bazą jest 45.

Warunkiem jest jednak mocne „przycięcie” ustawień graficznych tak, by w najgorszym scenariuszu (deszcz, noc, duże lotnisko, multiplayer) GPU nie spadało poniżej targetu. Jeżeli w typowym locie masz 55–60 FPS, a przy dużym porcie nagle 30–35, ASW będzie cały czas zmieniał tryb i żaden lock nie pomoże.

Jeśli po ręcznym ustawieniu limitu 45 FPS (np. w OpenXR Toolkit lub w samej grze) wykres frame time przestaje ząbkować, a obraz w kabinie „uspokaja się” przy skanowaniu przyrządów, to sygnał, że udało się trafić w sensowny kompromis między natywą a syntetyką.

Scenariusze specjalne: 30 FPS i niżej (1/3, 1/4 refresh)

Przy wyjątkowo ciężkich konfiguracjach – np. MSFS z wieloma dodatkami i słabszym GPU – pojawia się pokusa zejścia z targetem aż do 30 FPS (1/3 przy 90 Hz) lub nawet 24/22,5 FPS (1/4 przy 90 Hz). Technicznie możliwe, praktycznie często problematyczne.

Konsekwencje takiego ustawienia:

• bardzo wysoki udział klatek syntetycznych – algorytm musi „wymyślać” większość ruchu na podstawie niewielu referencyjnych klatek,
• wyraźnie rosnące smużenie przy ruchu głową – efekt „galarety”, szczególnie przy szybkim obracaniu się w kokpicie,
• duże opóźnienie wejścia – sterowanie drążkiem/pedalami wydaje się „miękkie” i spóźnione.

Taki tryb nadaje się jedynie do bardzo spokojnego latania IFR, bez gwałtownych zmian kierunku i wysokości, z minimalnym ruchem głową. Jeżeli celem jest trening procedur, może być to akceptowalne. Dla VFR, akrobacji czy wyścigów samochodowych jest to zwykle poniżej sensownego minimum.

Narzędzia konfiguracji ASW/SSW dla Questa – gdzie konkretnie to ustawić

Oculus Debug Tool (ODT) – narzędzie referencyjne

Oculus Debug Tool to główne, „systemowe” narzędzie Meta do manipulowania ASW dla Link/Air Link. Działa na poziomie sterownika PC i pozwala wymusić tryby niezależnie od ustawień gier.

Kluczowe pola w ODT, które pełnią rolę punktów kontrolnych:

• Asynchronous Spacewarp – lista wyboru trybu:
  • Auto – runtime decyduje sam,
  • Disabled – ASW wyłączony,
  • 45 Hz / 30 Hz / 18 Hz – wymuszone ułamki odświeżania (konkretne nazwy mogą się różnić w zależności od wersji ODT).
• Pixels Per Display Pixel Override – współczynnik supersamplingu; zbyt wysoka wartość psuje nawet najlepiej dobrany tryb ASW, bo dobija GPU.
• Link Sharpening / Encode Resolution Width – parametry strumienia; przesadzenie z rozdzielczością kodowania szybko zjada budżet GPU i przepustowość, co przekłada się na dropy.

Przy ODT obowiązuje prosta zasada audytowa: zmieniaj jedno kluczowe ustawienie na raz. Jeśli jednocześnie ruszysz ASW, supersampling i encoding, trudno później ustalić, która zmiana wywołała efekt na frame timie.

Oculus Tray Tool (OTT) – profile per‑gra

Oculus Tray Tool jest nakładką na API Oculusa i de facto automatyzatorem ustawień z ODT, wzbogaconym o profile dla konkretnych aplikacji. Dla symulatorów to wygodna opcja, bo pozwala przypisać inne tryby ASW/SSW do różnych tytułów.

Typowy, uporządkowany scenariusz:

• tworzysz profil dla MSFS – wymuszony ASW 45 Hz, umiarkowany encoding, PPDP ~1,1–1,2,
• osobny profil dla DCS – być może ASW Off + wyższy supersampling, jeśli GPU pozwala,
• profil globalny – ustawiony neutralnie (ASW Auto lub Off, PPDP 1.0), by nie „zanieczyszczać” innych gier.

Przy użyciu OTT trzeba pilnować, by nie dublować ustawień z ODT. Jeżeli jednocześnie wymusisz ASW w ODT i w profilu OTT, debugowanie zaczyna przypominać szukanie zwarcia w instalacji z dwiema rozdzielniami.

Panel Oculus/Meta PC – odświeżanie i podstawowe parametry Link

W aplikacji Meta na PC (dawniej Oculus) ustawiasz częstotliwość odświeżania, rozdzielczość oraz tryb Link/Air Link. To fundament, którego nie nadpisze ani ODT, ani OTT, ani SteamVR.

Kontrolne kroki przed eksperymentowaniem z ASW:

• ustaw docelowe odświeżanie zgodne z mocą GPU (np. 72 lub 90 Hz),
• dostosuj rozmiar renderowania (suwak „Quality” / „Resolution”) na poziomie, który nie dobija GPU już w prostych scenach,
• wykonaj test Link (dla kabla) i sprawdź stabilność bitrate oraz opóźnienia.

Jeżeli już w prostym teście Link pojawiają się spadki bitrate lub komunikaty o zbyt słabym połączeniu, walka o idealne ASW w ciężkim symulatorze mija się z celem – problemy będą generowane przez łącze, a nie sam algorytm reprojection.

SteamVR – Motion Smoothing i jego konflikt z ASW

W scenariuszach, gdzie Quest działa przez Link/Air Link, a gra korzysta z SteamVR (OpenVR lub SteamVR OpenXR), pojawia się drugi wielki gracz: Motion Smoothing SteamVR. Domyślnie potrafi sam decydować o obniżeniu FPS i dopełnieniu syntetycznymi klatkami.

Dla przejrzystości konfiguracji potrzebne są jasne decyzje:

Wyłączanie jednego algorytmu reprojection – kto ma „rządzić”

Najczęstszy błąd przy korzystaniu z Questa przez SteamVR to podwójna reprojection: ASW/SSW po stronie Oculusa + Motion Smoothing po stronie SteamVR. Efekt to nieprzewidywalne opóźnienia i artefakty trudne do zdiagnozowania.

Minimalny plan kontroli wygląda tak:

• wariant 1 – priorytet Oculusa:
  • ASW/SSW ustawiony w ODT/OTT (np. wymuszone 45 Hz),
  • Motion Smoothing w SteamVR globalnie i per‑gra: Off,
  • w zakładce „Video” i „Per-Application” – wyłączone „Motion Smoothing” oraz „Legacy Reprojection”.
• wariant 2 – priorytet SteamVR:
  • ASW w ODT/OTT: Disabled,
  • Motion Smoothing w SteamVR: Enabled lub „Auto”,
  • monitorowanie frame time w nakładce SteamVR zamiast w Oculus Debug HUD.

Jeżeli przy włączonych obu algorytmach ruch w kokpicie „pływa”, wskaźniki smużą się przy panoramowaniu, a logi pokazują duże rozjazdy frame time między CPU a GPU, to klasyczny sygnał ostrzegawczy: dwie reprojection walczą o kontrolę pipeline’u.

Ustawienia per‑aplikacja w SteamVR dla symulatorów

Symulatory uruchamiane poprzez SteamVR (np. DCS, Assetto Corsa Competizione) korzystają z profili per‑aplikacja. Tam powinny znaleźć się parametry dopasowane do konkretnej gry, a nie do całego systemu.

Minimalny zestaw pól kontrolnych w zakładce „Per-Application Video Settings” dla danej gry:

• Resolution Per Eye – podstawowy suwak obciążenia GPU; jeśli już przy 80–100% masz dropy, dyskusja o Motion Smoothing jest przedwczesna,
• Motion Smoothing – jasno ustawione „Off” lub „Force Enabled”; tryb „Auto” bywa nieprzewidywalny w ciężkich scenach,
• Reprojection Mode (w niektórych wersjach) – upewnij się, czy nie wymusza dodatkowego „Always On”,
• Refresh Rate Override – niektóre headsets wspierają override; dla Questa przez Link zwykle pozostawiasz „Use global”.

Jeśli po obniżeniu „Resolution Per Eye” i wyłączeniu Motion Smoothing frame time nagle stabilizuje się, a objawy „szarpania” przy skręcie głową maleją, masz dowód, że wąskim gardłem było przetwarzanie w SteamVR, a nie sam Quest lub ASW.

Virtual Desktop – osobny ekosystem i własne SSW

Virtual Desktop (VD) nie korzysta z ASW Oculusa dla samego transportu obrazu – posiada własny mechanizm SSW i zestaw przełączników per‑gra. Dlatego kopiowanie ustawień z Link/Air Link 1:1 prowadzi często do mylących wniosków.

Kluczowe elementy układu VD + symulator:

• zakładka „Streaming” w aplikacji VD na PC:
  • „Sliced Encoding”, „Video Bitrate”, „Codec” (H.264/HEVC/AV1) – parametry wpływające na obciążenie GPU i stabilność strumienia,
  • „VR Graphics Quality / VR Frame Rate” – domyślna częstotliwość i jakość renderingu,
  • „Use Synchronous Spacewarp” – włączenie/wyłączenie SSW po stronie VD.
• aplikacja VD w Quest:
  • tryb połączenia (Wi‑Fi, kanał, router / AP),
  • overlay z informacją o FPS i bitrate – pierwsza linia audytu stabilności.

Przy VD priorytetem jest najpierw uzyskanie stabilnego strumienia w niskich ustawieniach jakości (mniejsza rozdzielczość, niższy bitrate), dopiero później włączanie SSW i podbijanie detali. Jeśli już przy podstawowej jakości wykres FPS w overlayu VD faluje, aktywacja SSW tylko maskuje problem i utrudnia diagnozę.

SSW w Virtual Desktop – kiedy go używać, a kiedy wyłączać

SSW w VD ma inne charakterystyki niż ASW Oculusa. W części symulatorów subiektywnie działa płynniej, w innych wprowadza specyficzne artefakty (rozciąganie skrzydeł, falowanie linii horyzontu).

Typowe scenariusze decyzyjne:

• stabilne 60–70 FPS przy odświeżaniu 72/80 Hz – SSW często zbędny; zysk płynności jest niewielki, a pojawiają się dodatkowe artefakty,
• około 40–50 FPS przy 72/80 Hz – sensowny obszar dla SSW; można wymusić niższy target w grze (np. 36–40 FPS), a SSW dopina resztę,
• poniżej 35 FPS – SSW ratuje sytuację tylko pozornie; opóźnienie wejścia i „galareta” przy ruchu głową robią się dominujące.

Jeżeli po włączeniu SSW zanikają twarde przycięcia, ale pojawia się uczucie opóźnionego ruchu przy szybkim panoramicznym „rozglądaniu się” w kokpicie, to znak, że GPU jest już zbyt obciążone. W takim układzie lepiej mocniej obniżyć ustawienia graficzne w symulatorze, niż polegać na coraz bardziej agresywnym SSW.

OpenXR Toolkit – ograniczanie FPS i audyt frame time

OpenXR Toolkit to przydatny „miernik i regulator” dla symulatorów działających na OpenXR (MSFS, DCS z OpenXR, iRacing). Nie steruje bezpośrednio ASW/SSW Questa, ale pozwala ustalić stabilny budżet FPS i obserwować, co dzieje się z frame time.

Najważniejsze moduły narzędzia pod kątem stabilności:

• FPS Limiter – twardy limit, np. 45 FPS; jeśli po jego ustawieniu krzywa frame time „wygładza się”, pipeline ma rezerwę i reprojection ma łatwiejsze zadanie,
• Upscaling/Sharpening (FSR, NIS, CAS) – możliwość renderowania w niższej rozdzielczości przy pozornej ostrości obrazu; pozwala obniżyć realne obciążenie GPU bez drastycznej utraty czytelności przyrządów,
• Overlay z frame time – szybka weryfikacja, czy skoki pochodzą z CPU (AI, fizyka, pogoda) czy z GPU (gęste chmury, duże miasto).

Jeśli po włączeniu limitu 45 FPS w OpenXR Toolkit wykres frame time nadal „ząbkuje” z dużą amplitudą, a ASW/SSW ma wrażenie „łapania zadyszki” akurat w gęstym ruchu AI lub przy wlocie w chmury, to mocny sygnał ostrzegawczy: najpierw trzeba przeprojektować ustawienia graficzne i ruchu AI w symulatorze, a dopiero później wracać do korekt ASW.

MSFS + Quest – procedura ustawiania stabilnego ASW/SSW

W przypadku Microsoft Flight Simulator pojawia się kilka warstw konfiguracji: aplikacja Meta, OpenXR (systemowy lub poprzez SteamVR), same ustawienia gry oraz ewentualny OpenXR Toolkit. Bez uporządkowania łatwo zgubić, co za co odpowiada.

Kontrolna procedura dla scenariusza: Quest przez Link/Air Link, OpenXR z aplikacji Meta:

1. W aplikacji Meta:
   • ustaw odświeżanie np. 90 Hz,
   • rozmiar renderowania na poziomie średnim (suwak w okolicach 1.0–1.1),
   • sprawdź test Link – stabilne opóźnienie i bitrate.
2. W ODT/OTT:
   • Asynchronous Spacewarp na Disabled lub Auto na czas pierwszych testów,
   • supersampling (PPDP) na 1.0–1.1, bez eksperymentów.
3. W MSFS:
   • VR Rendering Resolution: balans lub poniżej,
   • Terrain/Objects LOD – startowo w okolicach 100,
   • bez zewnętrznych limitów FPS.
4. W locie testowym:
   • monitoruj natywny FPS i frame time bez ASW,
   • upewnij się, że w typowym scenariuszu (np. dolot do średniego lotniska) FPS nie spadają drastycznie poniżej 45.
5. Dopiero potem:
   • w ODT wymuś ASW na tryb 45 Hz (1/2 refresh),
   • sprawdź stabilność przy podejściu do dużego portu, w gęstej pogodzie.

Jeżeli przy wyłączonym ASW MSFS utrzymuje stabilne 45–50 FPS, a po włączeniu wymuszonego 45 Hz obraz staje się subiektywnie płynniejszy bez dodatkowego opóźnienia na sterach, konfiguracja jest na dobrym torze. Jeśli natomiast ASW musi ciągle „gasić pożary” przy spadkach do 30 FPS i niżej, zamiast szukać magicznego trybu ASW lepiej zejść z LOD, gęstości AI i jakości chmur.

DCS + Quest – rozdzielenie ról między OpenXR a ASW

DCS World z natywnym OpenXR umożliwia ominięcie SteamVR i uproszczenie łańcucha: Quest <–> Oculus OpenXR <–> DCS. To korzystne dla stabilności, ale wymaga jasnego podziału ról między OpenXR Toolkit a ASW.

Praktyczna sekwencja konfiguracji:

• W launcherze DCS:
  • wymuś start w trybie OpenXR (parametry startowe),
  • upewnij się, że SteamVR nie jest uruchamiane pośrednio.
• W ODT/OTT:
  • ASW początkowo na Disabled,
  • PPDP w okolicach 1.0–1.2, bez skrajności.
• W DCS:
  • Pixel Density w zakładce VR – w granicach 1.0,
  • Shadows, MSAA, Clouds – startowo konserwatywnie (bez MSAA x4 i Ultra clouds).
• W OpenXR Toolkit:
  • włącz overlay i limiter FPS,
  • ustaw limit na 45 FPS przy 90 Hz w Quest,
  • opcjonalnie użyj FSR/XeSS dla zbijania rozdzielczości.

Dopiero gdy DCS stabilnie trzyma limit FPS bez interwencji ASW (brak agresywnych pików frame time w overlayu), warto przetestować włączenie ASW w ODT, aby wygładzić okazjonalne spadki. Jeśli przy włączeniu ASW pojawia się nieliniowe opóźnienie na drążkach w ciasnych manewrach, lepszym kompromisem jest utrzymanie czystego 45 FPS przez ogranicznik OpenXR Toolkit i pozostawienie ASW wyłączonego.

Symulatory wyścigowe + Quest – nacisk na input lag

W wyścigach samochodowych krytycznym parametrem jest czas reakcji między ruchem kierownicy a obrazem. ASW/SSW może poprawiać płynność, ale często kosztem precyzji czucia auta na granicy przyczepności.

Przed agresywnym korzystaniem z reprojection w simracingu warto przejść przez listę kontrolną:

• spójny FPS bez ASW – w Assetto Corsa / ACC / iRacing sprawdź, czy potrafisz utrzymać np. 72 Hz z niewielkimi wahaniami,
• profil wejścia – upewnij się, że wheelbase nie ma dodatkowego filtra opóźniającego (dodatkowe smoothing/max force filters),
• ASW/SSW test A/B – krótki test na tym samym torze i w tych samych warunkach, z i bez ASW, skupiony tylko na odczuwalnym opóźnieniu.

Jeżeli przy wyłączonym ASW FPS jest niższy, ale samochód lepiej „mówi” o granicy przyczepności w szybkich zmianach kierunku, sensowniejsze jest zejście z detali graficznych (publiczność, lustra, odbicia), niż włączanie mocno ingerującego ASW. Stabilne 72 Hz bez reprojection w wyścigach potrafi dać lepszą jakość jazdy niż 90 Hz z intensywnym SSW.

Checklist – audyt stabilności po zmianach ASW/SSW

Po każdej poważniejszej korekcie konfiguracji opłaca się przeprowadzić krótki audyt w jednym, powtarzalnym scenariuszu testowym (ta sama trasa, ta sama pogoda, ten sam samolot/auto). Pomaga to odsiać wrażenia subiektywne od realnych zysków.

Kluczowe punkty kontrolne podczas testu:

• czy frame time na GPU jest stabilny (małe wahania) przy aktywnym trybie ASW/SSW,
• czy nie ma cyklicznych skoków opóźnienia wejścia – np. co kilka sekund chwilowy „gumowy” ruch,
• czy artefakty reprojection (rozmyte śmigło, ghosting na cienkich obiektach) nie przeszkadzają w typowym użytkowaniu,

Najczęściej zadawane pytania (FAQ)

Jakie ustawienia ASW/SSW w Queście są najlepsze do symulatorów (DCS, MSFS, iRacing)?

Bezpieczny punkt startowy to wymuszenie stałego podziału klatek zamiast trybu „Auto”. Dla 90 Hz w Queście oznacza to zazwyczaj 45 FPS + ASW/SSW, a dla 72 Hz – 36 FPS + ASW/SSW. Kluczowe jest, by natywny FPS gry stabilnie utrzymywał się powyżej tego progu, inaczej reprojection zaczyna „gonić” i generuje artefakty.

Przed podjęciem decyzji sprawdź trzy rzeczy: stabilność frame time (np. w OpenXR Toolkit), zajętość GPU/CPU (MSI Afterburner) oraz to, czy nie ma gwałtownych pików opóźnień przy złożonych scenach (miasto, chmury, duży ruch AI). Jeśli gra trzyma stałe 45–50 FPS przy 90 Hz, wymuszenie ASW/SSW 45 FPS zwykle daje bardziej przewidywalne sterowanie i mniej „pływania” kokpitu niż próba utrzymania pełnych 90 FPS z okazjonalnymi dropami.

Czym dokładnie różni się ASW od SSW na Queście i co wybrać do symulatorów?

ASW w ekosystemie Meta/Oculus to klasyczny mechanizm reprojection działający po stronie aplikacji Meta/Oculus (Link, Air Link). Pracuje asynchronicznie względem renderingu, bazuje głównie na ruchu głowy i obrazie z poprzednich klatek, by sztucznie „dosztukować” brakujące. SSW, stosowane m.in. przez Virtual Desktop, wykorzystuje nowsze techniki (np. depth-based reprojection), lepiej rozdziela warstwy sceny i często czyściej radzi sobie z dynamicznym tłem.

Minimalne kryterium wyboru: jeśli grasz przez oficjalny Link/Air Link – korzystasz z ASW i kluczowe jest poprawne ustawienie jego trybu (off/auto/forced). Jeśli używasz Virtual Desktop – pracujesz głównie z SSW i to tam konfigurujesz reprojection. Sygnał ostrzegawczy: jednoczesne działanie kilku warstw reprojection (np. ASW + reprojection w OpenXR Toolkit) zwykle kończy się falowaniem obrazu, więc trzeba mieć pewność, która warstwa jest aktywna.

Jak rozpoznać, że ASW/SSW jest źle ustawione w symulatorze na Queście?

Typowe objawy to: judder przy szybkim obracaniu głowy, „pływający” kokpit (kokpit jakby na gumce względem horyzontu) oraz smugi/rozciąganie skrzydeł, aut czy samolotów lecących w formacji. Przy iRacing, ACC czy DCS często widać to szczególnie mocno przy szybkim zerkaniu na boki w pitlane lub nad gęstą zabudową.

Punkt kontrolny: jeśli overlay (np. OpenXR Toolkit, Oculus Debug Tool) pokazuje sensowny średni FPS, ale ruch horyzontu podczas panoramowania jest schodkowy lub niestabilny, głównym podejrzanym jest konfiguracja ASW/SSW, a nie sama moc GPU. Jeśli po wyłączeniu reprojection judder zmienia się w „czysty” spadek FPS, to znak, że trzeba dobrać inny target FPS (np. zejść z 90 Hz na 72 Hz albo zredukować ustawienia graficzne pod stabilne 45 FPS + ASW/SSW).

Czy lepiej mieć 90 FPS bez ASW, czy 45 FPS z ASW/SSW w symulatorach VR?

Dla symulatorów kryterium nadrzędne to stabilność frame time, nie sama liczba FPS w overlayu. Stabilne 45 FPS z dobrze działającym ASW/SSW i równym rytmem klatek często daje bardziej przewidywalne sterowanie i mniej zmęczenia niż skaczące 65–90 FPS bez reprojection. Przy ruchu po łuku, lądowaniach czy precyzyjnym hamowaniu mózg szybciej wyłapuje nierówny rytm klatek niż niższy, ale stały FPS.

Jeśli jesteś w stanie utrzymać absolutnie stabilne, pełne odświeżanie (np. 90 FPS przy 90 Hz) w każdej sytuacji – można grać bez ASW/SSW. Jeśli jednak przy ciężkich scenach (gęste chmury, duże lotnisko, deszcz, dużo AI) masz dropy, lepszym wyborem jest świadome zablokowanie się na pół odświeżania (45 FPS + ASW) i lekkie zbicie detali niż tolerowanie przypadkowych spadków do 60–70 FPS.

Jak ustawić ASW/SSW w Oculus Debug Tool / Quest Debug Tool pod symulatory?

Minimalny schemat działania jest zawsze podobny. Najpierw: włącz overlay z pomiarem FPS i frame time (OpenXR Toolkit, ODT Performance HUD), odpal typowy scenariusz w symulatorze (np. podejście do dużego lotniska, gęsta zabudowa, pełna sesja wyścigowa) i sprawdź, ile realnie trzyma gra bez wymuszonego ASW. Następnie w Oculus/Quest Debug Tool wybierz tryb ASW: wyłączony, auto albo wymuszone 45 FPS (przy 90 Hz) czy 36 FPS (przy 72 Hz) – i obserwuj, jak zmienia się stabilność frame time.

Punkt kontrolny: jeśli w trybie „Auto” ASW stale przełącza się między pełnym FPS a podziałem (skaczące odczucie płynności), lepsze jest wymuszenie konkretnego targetu (np. 45 FPS). Jeśli natomiast nawet przy wymuszonym 45 FPS widzisz duże piki frame time i kapnięcia poniżej 45, to znak, że trzeba obniżyć ustawienia graficzne, zmniejszyć rozdzielczość renderowania lub odświeżanie Questa (np. z 90 na 72 Hz).

Dlaczego mam judder i „pływający” kokpit mimo wysokiego FPS w overlayu?

Najczęstsza przyczyna to nierówny frame time i/lub konflikt kilku systemów reprojection. Overlay może pokazywać średnio 70–80 FPS, ale jeśli poszczególne klatki generują się w bardzo różnym czasie (np. raz 9 ms, raz 18 ms), mózg odbiera to jako szarpanie horyzontu. Dodatkowo, jeśli jednocześnie działa ASW/SSW i niezależne ograniczenie FPS (np. w sterowniku GPU albo RTSS), powstają dziwne interakcje skutkujące falowaniem obrazu.

Lista kontrolna: wyłącz wszystkie dodatkowe limity FPS w sterowniku GPU, wyłącz inne reprojection (np. w OpenXR Toolkit), zostaw tylko jedną warstwę (ASW lub SSW) i dopiero wtedy oceniaj zachowanie obrazu. Jeśli po tej operacji judder ustępuje lub wyraźnie się zmniejsza, przyczyną była „walka” kilku mechanizmów kontroli klatek, a nie same możliwości sprzętu.

Jak przygotować system Windows i sterowniki, zanim zacznę bawić się ASW/SSW?

Absolutne minimum techniczne przed tuningiem reprojection obejmuje: aktualne i stabilne sterowniki GPU (Game Ready, nie beta), aktualny firmware Questa oraz działającą bez błędów aplikację Meta/Oculus na PC. Dodatkowo tryb zasilania Windows ustawiony na „Wysoka wydajność” (lub odpowiednik producenta) oraz wyłączone agresywne oszczędzanie energii dla USB i PCIe, żeby Link/Air Link nie „przytykał się” losowo.

Najważniejsze wnioski

• Kluczowym celem konfiguracji ASW/SSW w symulatorach na Queście jest stabilny, powtarzalny frame time, a nie jak najwyższy, ale skaczący FPS – jeśli licznik FPS wygląda dobrze, a kokpit „pływa”, ustawienia reprojection są pierwszym podejrzanym.
• ASW/SSW zastępuje część fizycznie renderowanych klatek przewidywanymi (np. 45 FPS + syntetyczne klatki przy 90 Hz), co pozwala utrzymać płynność, ale przy złej konfiguracji generuje judder, ghosting i opóźnione sterowanie zamiast realnej poprawy komfortu.
• ASW (Meta/Oculus) i SSW (np. w Virtual Desktop) różnią się sposobem działania – SSW bywa lepsze w dynamicznych scenach dzięki bardziej zaawansowanej reprojekcji, lecz żaden z tych trybów nie „naprawi” skrajnie niestabilnych lub zbyt niskich natywnych FPS, jedynie zamaskuje problem.
• Typowe sygnały ostrzegawcze źle dobranego ASW/SSW to: szarpanie horyzontu przy szybkim zerkaniu na boki, „gumowy” kokpit przesuwający się względem otoczenia, smugi i rozciąganie szybko poruszających się obiektów oraz niestabilne poczucie prędkości mimo akceptowalnego FPS w overlayu.
• W symulatorach priorytetem jest równe tempo generowania klatek – nawet niewielkie fluktuacje (5–10 ms) przekładają się na gorsze czucie ruchu, problemy z precyzją (hamowanie, flare) i szybsze zmęczenie; jeśli obraz faluje przy ruchu głową, konfiguracja reprojection powinna być pierwszym punktem kontrolnym.