Mody VR do symulatorów: co poprawia ostrość i stabilność obrazu

Dlaczego ostrość i stabilność obrazu w VR są tak trudne do pogodzenia

Specyfika VR w symulatorach ciężarówek

Symulatory ciężarówek w VR (ETS2, ATS i podobne tytuły) są wyjątkowo wymagające, bo łączą cechy symulatora jazdy i sandboxa z ogromną mapą. Silnik gry musi jednocześnie renderować duży obszar, z dalekim zasięgiem widzenia, dużą liczbą obiektów i źródeł światła. W goglach VR ten sam obraz trzeba wygenerować podwójnie – osobno dla lewego i prawego oka, często w wysokiej częstotliwości odświeżania. To oznacza wielokrotnie wyższe obciążenie GPU niż na monitorze.

Do tego dochodzi kwestia input-lagu i komfortu. W zwykłej grze spadek do 40–50 FPS jest irytujący, ale akceptowalny. W VR przy takim framerate zaczyna się bujanie obrazu, pojawia się dyskomfort, a niektóre osoby odczuwają wręcz chorobę symulatorową. Mody VR, które poprawiają ostrość obrazu, często podnoszą wymagania sprzętowe – a to z kolei uderza właśnie w stabilność klatek.

Symulatory ciężarówek są dodatkowo czułe na doczytywanie świata. Streaming mapy w tle (wczytywanie kolejnych segmentów drogi, miast, modeli AI) potrafi powodować krótkie przycięcia. Na monitorze bywa to ledwo zauważalne, w VR każde takie „szarpnięcie” wybija z immersji. Dlatego sama poprawa jakości wizualnej modami nie wystarczy – równie ważne są zmiany, które odchudzają scenę, redukują liczbę obiektów i usprawniają LOD.

Napięcie między jakością a wydajnością

Ostrość obrazu w VR jest zwykle podbijana przez supersampling, zwiększanie rozdzielczości renderowania oraz filtry wyostrzające. Każda z tych metod ma swoją cenę. Supersampling liniowo zwiększa liczbę renderowanych pikseli, co bardzo obciąża układ graficzny. Filtry typu sharpen poprawiają mikrodetale, ale łatwo wprowadzają migotanie krawędzi i szumy, które w goglach są często bardziej irytujące niż lekko miękki obraz.

Stabilny obraz oznacza zaś trzymanie się stałego progu FPS (np. 72, 80, 90 Hz w zależności od gogli) lub przynajmniej stabilną pracę reprojection. To oznacza konieczność konsekwentnego obniżania detali tam, gdzie są najmniej bolesne wizualnie: cienie, gęstość trawy, odbicia, gęstość ruchu AI, szczegółowość odbiorców w miastach. Każdy „ładny” mod graficzny, który podnosi detale, działa przeciwko temu celowi – jeśli nie jest użyty z głową.

Napięcie polega na tym, że ostrość i stabilność trzeba wypośrodkować. Próg komfortu w VR jest często niższy niż oczekiwania graficzne gracza. Lepiej mieć odrobinę mniej efektowną scenerię, ale wyraźne znaki drogowe i tablice, niż super fotorealistyczne niebo, które powoduje dropy przy wjeździe do większego miasta. Dobrze dobrane mody VR mają wspierać tę równowagę, a nie ją niszczyć.

Supersampling, rozdzielczość i punkt malejących korzyści

Supersampling i zwiększanie rozdzielczości renderowania (w SteamVR, OpenXR, narzędziach producenta gogli) świetnie wpływa na ostrość, ale tylko do pewnego momentu. Po przekroczeniu określonego progu (zależnie od headsetu i mocy PC) czas renderowania jednej klatki zaczyna przekraczać to, co akceptuje panel gogli. W praktyce pojawia się pływający framerate, reprojection pracuje na pełnych obrotach, a modyfikacje graficzne zaczynają się „dusić”.

Granica opłacalności jest inna dla każdego zestawu: RTX 4070 + Quest 3 w trybie Link będzie miało inny „słodki punkt” niż RX 6700 XT + Reverb G2 w natywnym WMR. Najczęściej jednak ustawianie supersamplingu znacznie powyżej 100–120% w menedżerze VR przy jednoczesnym stosowaniu ciężkich modów pogodowych kończy się katastrofą dla stabilności. Z punktu widzenia ostrości w goglach powyżej pewnego progu różnice są trudno zauważalne, za to w logach widać rosnące czasy renderowania.

Wiele osób instaluje kolejny mod wyostrzający czy paczkę tekstur „4K”, licząc na wyraźniejszy obraz, a tymczasem osiąga efekt odwrotny: reprojection maskuje część detali, pojawiają się mikroprzycięcia, a cyfry na desce rozdzielczej „pływają” przy ruchu głowy. To klasyczny moment, w którym dodatkowy mod graficzny nie daje realnego zysku czytelności, a jedynie dobija GPU.

Stabilny framerate, reprojection i wrażenie płynności

W VR liczy się nie tylko surowa liczba FPS, ale regularność. Stabilne 45 FPS z dobrze skonfigurowaną reprojection potrafi być bardziej komfortowe niż skaczące 60–80 FPS bez reprojection. Symulatory ciężarówek często nie są w stanie utrzymać nativnej częstotliwości paneli VR w ciężkich scenach (duże skrzyżowania, wieczór, deszcz). Wtedy kluczowe jest, aby modami i ustawieniami utrzymać spójne minimum, które pozwoli reprojection działać w przewidywalny sposób.

Mody poprawiające stabilność obrazu w VR często nie są spektakularne wizualnie: to mody redukujące zagęszczenie obiektów, optymalizujące LOD, ograniczające źródła światła lub wydłużające czas doczytywania zasobów, żeby uniknąć gwałtownych skoków. Tego typu dodatki rzadko robią wrażenie na screenshotach, ale efekt w goglach jest dramatyczny: mniej nagłych spadków, mniejsza szansa na crash przy ładowaniu mapy VR, płynniejszy ruch otoczenia.

Podstawy techniczne: jak VR działa w ETS2/ATS i podobnych symulatorach

OpenVR, OpenXR, SteamVR i inne warstwy pośrednie

VR w symulatorach ciężarówek opiera się najczęściej na OpenVR (SteamVR) albo OpenXR. ETS2 i ATS pierwotnie korzystają głównie z integracji przez SteamVR, ale coraz częściej gracze omijają SteamVR, korzystając z warstwy OpenXR i dodatkowych narzędzi (np. OpenComposite, OpenXR Toolkit). Każda z tych dróg ma wpływ na to, jakie mody i narzędzia można zastosować.

W ujęciu praktycznym tor wygląda zwykle tak:

• gra (ETS2/ATS z trybem VR)
• API VR: OpenVR (SteamVR) lub OpenXR (czasem z OpenComposite jako tłumaczem)
• platforma VR gogli (Oculus, WMR, Varjo, Pimax itd.)
• sterowniki GPU (NVIDIA/AMD) i ich własne optymalizacje

Każdy dodatkowy „adapter” (np. OpenComposite) to potencjalne miejsce konfliktów z modami, overlayami czy injectorami. Niektóre narzędzia – jak reshade pod VR – działają tylko przy konkretnej kombinacji API i sposobu uruchomienia gry. Dlatego zanim doinstaluje się jakikolwiek mod, trzeba ustalić jak dokładnie uruchamiany jest VR: natywne SteamVR, OpenXR przez Steam, czy może sterownik producenta gogli jako runtime OpenXR.

Rola sterowników GPU i paneli konfiguracyjnych

Sterowniki graficzne to kolejny element, przez który przechodzi każdy obraz. NVIDIA Control Panel oraz AMD Software mogą dodawać funkcje typu skalowanie, optymalizacje opóźnień, pre-rendered frames, limitowanie FPS, a nawet własne filtry wyostrzające. Dla VR w symulatorach część tych opcji jest albo mało skuteczna, albo wręcz przeszkadza.

Nietrudno doprowadzić do sytuacji, w której:

• gra stosuje swoje AA i skalowanie,
• SteamVR/OpenXR używa własnego supersamplingu,
• panel GPU dokłada resampling lub filtry sharpening,
• a do tego reshade dorzuca kolejne wyostrzenie.

To klasyczny przepis na nadmiernie ostrą, zaszumioną, męczącą oczy scenę oraz zupełnie niepotrzebne obciążenie GPU. Sterownik powinien w VR pełnić rolę raczej „przezroczystą”: bez zbędnych globalnych override’ów dla skalowania czy wygładzania krawędzi. Mody VR bazują na przewidywalnym pipeline; globalne sztuczki sterownika często to zaburzają i utrudniają debugowanie.

Pipeline renderowania i miejsca, gdzie działają mody

Renderowanie sceny VR w symulatorze wygląda w uproszczeniu tak:

• silnik gry buduje scenę 3D (geometria, tekstury, światła, efekty pogodowe),
• tworzone są osobne obrazy dla każdego oka (uwzględniające pozycję i ruch głowy),
• silnik nakłada swoje postprocesy (anti-aliasing, bloom, cienie kontaktowe),
• API VR (OpenVR/OpenXR) odbiera gotowe klatki i wysyła dalej,
• runtime gogli stosuje ewentualne własne tricki (reprojection, czasem foveated rendering),
• panel VR wyświetla obraz.

Mody i narzędzia mogą ingerować na różnych etapach:

• W silniku gry – mody LOD, tekstur, pogodowe, mody odchudzające modele, pluginy manipulujące config.cfg i ustawieniami.
• Jako injectory postprocessów – reshade, FSR/NIS injectors, filtry wyostrzające podpinają się do wyjściowego obrazu gry przed przekazaniem go do API VR.
• Na poziomie runtime VR – OpenXR Toolkit dodaje własne skalowanie, foveated rendering, overlay diagnostyczny; SteamVR potrafi zmieniać rozdzielczość i filtry.
• Po stronie gogli – np. aplikacje do zarządzania Questem, WMR, Pimax, które mogą modyfikować docelową rozdzielczość lub przepływ danych (np. kompresja obrazu po USB/Wi‑Fi).

Część elementów jest poza zasięgiem modów. Przykładowo:

• architektura cieni (shadow maps) i sposób ich filtrowania leży po stronie silnika gry,
• system LOD dla modeli AI ma określone limity, które trudno przekroczyć bez ryzyka błędów,
• streaming mapy i sposób ładowania zasobów mają twarde ograniczenia związane z pamięcią i jednordzeniowymi fragmentami silnika.

Nie każdy problem ostrości/stabilności da się zatem obejść modami. Jeśli silnik gry ma agresywne doczytywanie modeli przy wjeździe do dużego miasta, nawet najlepiej skonfigurowany OpenXR nie wyeliminuje wszystkich przycięć – może jedynie je złagodzić.

Wpływ API na dostępność modów i overlayów

Wybór API VR (OpenVR vs OpenXR) wpływa bezpośrednio na to, jakie narzędzia można zastosować. Przykładowo:

• część starszych overlayów i pluginów monitorujących FPS działa tylko z OpenVR/SteamVR,
• OpenXR Toolkit wymaga oczywiście środowiska OpenXR,
• niektóre reshade/injectory działają poprawnie tylko, gdy gra startuje jako „zwykła” aplikacja 3D i pipeline nie jest zbyt skomplikowany przez dodatkowe translatory.

Częstym scenariuszem jest migracja z SteamVR na OpenXR (np. przez OpenComposite) w celu zyskania kilku dodatkowych FPS i mniejszego opóźnienia. Zyski bywają zauważalne, ale po drodze tracone są niektóre overlaye czy narzędzia debugujące. W kontekście modów VR do symulatorów warto rozważyć, czy korzyść z lepszej wydajności równoważy utratę części narzędzi diagnostycznych. Bez rzetelnych pomiarów FPS i frametime’ów trudno ocenić, które mody faktycznie poprawiają stabilność obrazu.

Rodzaje modów i narzędzi VR, które realnie wpływają na ostrość i stabilność

Mody graficzne i konfiguracyjne w samym symulatorze

Mody VR do symulatorów ciężarówek można pogrupować według tego, co zmieniają w pipeline. Pierwsza grupa to mody działające wewnątrz gry, czyli klasyczne mody graficzne, konfiguracyjne i „silnikowe”. Wśród nich można wyróżnić:

• Mody shaderowe/kolorystyczne – zmieniają tonację, kontrast, często symulują bardziej realistyczne światło. Z punktu widzenia VR mogą poprawić subiektywną ostrość (przez lokalne zwiększenie kontrastu), ale przy przesadzie potrafią zalać obraz czernią lub przejaskrawić jasne elementy. Dla czytelności znaków drogowych i zegarów często lepsze są umiarkowane, neutralne presety.
• Mody LOD i zasięgu rysowania – manipulują odległością, z jakiej widać różne obiekty (drzewa, budynki, pojazdy). W VR rozsądną praktyką jest redukcja zasięgu tam, gdzie nie ma to krytycznego wpływu na jazdę, co znacząco stabilizuje FPS w gęstych obszarach miejskich.
• Mody odchudzające tekstury – kompresują lub redukują rozdzielczość wybranych tekstur (np. roślinność, obiekty tła). Zwykle mały koszt wizualny za sporą oszczędność VRAM i mniej stutterów przy doczytywaniu.
• Paczki pogodowe i oświetleniowe – poprawiają niebo, chmury, słońce, deszcz. Niektóre z nich są bardzo ciężkie wydajnościowo (gęste volumetric clouds, złożone efekty deszczu). Trzeba wybierać te, które oferują czystszą scenę (lepsza widoczność, czytelniejsze kontrasty) bez ekstremalnego narzutu na GPU.
• Mody „silnikowe” i pluginy konfiguracji – np. skrypty modyfikujące wartości w pliku config.cfg, włączające ukryte parametry pod VR (jak określone AA, cienie, LOD). Dobrze przygotowany mod tego typu może dać wyraźny zysk w stabilności bez ingerencji w same zasoby gry.

Narzędzia po stronie runtime VR i gogli

Druga duża grupa to narzędzia działające już po tym, jak gra wyrenderuje swoją klatkę. Tu najczęściej pojawia się realna poprawa ostrości przy zachowaniu względnej stabilności, ale też więcej pułapek konfiguracji.

Typowe przykłady:

• OpenXR Toolkit – dodaje skalowanie (NIS/FSR), wyostrzanie, foveated rendering, overlay z frametime’ami. Dobrze skonfigurowany potrafi zastąpić większość kombinacji supersamplingu w SteamVR i filtrów w sterowniku GPU.
• Panele producenta gogli (Oculus/Meta, WMR Portal, Pimax, Varjo Base) – pozwalają wymusić docelową rozdzielczość, częstotliwość odświeżania, poziom kompresji (przy graniu po kablu/Wi‑Fi) i rodzaj reprojekcji.
• Narzędzia typu OpenComposite/OpenXR-Toolkit Companion – same w sobie nie poprawiają jakości, ale umożliwiają przesiadkę na inne API, które daje dostęp do lepszych metod skalowania.

Największy zysk z tej warstwy pojawia się, gdy zastępuje ona kilka nachodzących na siebie systemów skalowania. Jeden dobrze ustawiony supersampling + sensowny sharpening zwykle bije kombinację „AA gry + scaling SteamVR + sharpening sterownika + reshade”.

Injectory postprocessów i zewnętrzne filtry

Osobną kategorią są narzędzia typu reshade, różne injectory FSR/NIS i filtry wyostrzające działające jak „nakładka” na obraz gry. Z VR radzą sobie w różnym stopniu – zależy od API i sposobu uruchomienia symulatora.

Najczęstsze zastosowania:

• lokalne podbicie ostrości krawędzi (sharpening),
• delikatne poprawienie czytelności znaków i interfejsu,
• korekta kolorów/kontrastu bardziej subtelna niż w ciężkich paczkach graficznych.

Problem polega na tym, że te narzędzia zwykle „nie wiedzą”, że obraz jest podwójny (dla lewego i prawego oka). Zastosowane agresywnie potrafią wyciągnąć szum, aliasing i kompresję, przez co zyskuje się pozorną ostrość kosztem komfortu i stabilności w szybkim ruchu głowy. Rozsądny scenariusz to użycie jednego lekkiego filtra sharpening + ewentualnie niewielka korekta gamma/kontrastu, bez wchodzenia w HDR‑owe eksperymenty.

Narzędzia diagnostyczne i overlaye pomiarowe

Ostatnia z praktycznych grup to wszystko, co nie zmienia obrazu, ale pozwala ocenić, czy dany mod lub ustawienie faktycznie pomaga. Bez tego łatwo pomylić „efekt placebo” z realną poprawą stabilności.

Najbardziej przydatne są:

• overlaye z FPS i frametime (np. z OpenXR Toolkit, SteamVR, narzędzi producenta gogli),
• monitoring wykorzystania GPU/CPU (RTSS, MSI Afterburner, narzędzia NVIDII/AMD),
• proste logowanie temperatur i taktowań – zwłaszcza przy długich sesjach VR, gdzie thermal throttling może psuć ostrość przez nagłe dropy FPS.

Różnica między „60–90 FPS skaczącymi jak szalone” a stabilnymi 45 FPS z reprojekcją bywa trudna do wyczucia, jeśli patrzy się tylko na licznik FPS. Dopiero frametime (czas renderowania pojedynczej klatki) ujawnia, czy pipeline jest stabilny. Mody VR, które „na papierze” podnoszą FPS, ale generują szarpane frametime’y, w praktyce obniżają komfort jazdy.

Konfiguracja bazowa bez modów – punkt wyjścia przed kombinowaniem

Dlaczego najpierw należy „odmodować” symulator

Większość problemów z VR w ETS2/ATS pojawia się nie dlatego, że sprzęt jest zbyt słaby, tylko przez chaos w konfiguracji. Gra, sterownik GPU, SteamVR/OpenXR, reshade, paczki graficzne – wszystko na raz coś skaluje, filtruje i wyostrza. Zanim zacznie się szukać „cudownego moda VR”, sensownie jest wrócić do możliwie czystej bazy.

W praktyce chodzi o kilka kroków:

• wyłączenie wszystkich opcjonalnych modów graficznych i shaderowych,
• przywrócenie domyślnych ustawień w panelu NVIDII/AMD dla ETS2/ATS (bez globalnych override’ów),
• ustawienie neutralnych wartości supersamplingu w SteamVR/OpenXR (np. 100%),
• tymczasowe usunięcie reshade/injectorów.

Dopiero na takim „gołym” profilu można wiarygodnie ocenić, co naprawdę zmienia pojedynczy mod czy narzędzie. W przeciwnym wypadku każde pogorszenie ostrości lub szarpanie da się zwalić na cokolwiek – i kończy się to godzinami ślepego grzebania.

Podstawowe ustawienia w ETS2/ATS pod VR

Sam symulator daje kilka dźwigni, które przesądzają o tym, czy VR będzie grywalne:

• Skalowanie obrazu w grze – w konfiguracji VR sensownie jest trzymać je w okolicach 100% i zamiast tego bawić się rozdzielczością w runtime VR (SteamVR/OpenXR). Podwójne skalowanie to klasyczny sposób na zajechanie GPU bez realnego zysku.
• Anti-aliasing – natywne rozwiązania w ETS2/ATS są przeciętne. Często lepszy efekt daje umiarkowany AA w grze + wyższa rozdzielczość na poziomie VR, niż próby ratowania wszystkiego agresywnym AA w silniku.
• Cienie – bardzo kosztowny element. Pod VR lepiej mieć stabilne średnie cienie niż ultra‑wysokie z dropami przy każdej zmianie pory dnia czy wjeździe do miasta.
• Odbicia i SSAO – bajery typu wyszukane odbicia w szybach czy mocne ambient occlusion wyglądają ładnie na monitorze, ale w goglach przynoszą więcej szumu niż realizmu. Umiarkowane poziomy zmniejszają migotanie i „brud” obrazu.
• Gęstość ruchu i detale otoczenia – w VR więcej znaczy często mniej. Lepiej mieć nieco mniej pojazdów AI i detali ulicy niż wywalczone na siłę „żywe miasto”, które powoduje stutter przy każdej zmianie skrzyżowania.

Typowy scenariusz z praktyki: gracz przerzuca wszystkie suwaki na „Ultra”, bo GPU na monitorze dawało radę. W VR ten sam zestaw zabija płynność, a potem zaczyna się dogęszczanie modami. Odchudzenie kilku najcięższych opcji w samej grze potrafi dać większy efekt niż trzy paczki „optimizera”.

Ustawienia sterownika GPU jako baza

Kolejny etap to porządek w panelu NVIDII/AMD. Globalne „tweaki” pod gry 2D potrafią kompletnie rozjechać VR:

• Sharpening / Image Sharpening – najlepiej wyłączyć na poziomie sterownika dla profilu ETS2/ATS. Wyostrzanie w runtime VR (OpenXR Toolkit) daje zwykle więcej kontroli i lepszą jakość.
• Skalowanie rozdzielczości (DLDSR, VSR itp.) – funkcje typu „super rozdzielczość” dobrze wyglądają na monitorze, ale dublują rolę supersamplingu w VR. W większości przypadków powinny być wyłączone dla profilu gry.
• Optymalizacje typu Low Latency, Max Pre-Rendered Frames – w symulatorach możemy mieć odwrotną sytuację niż w FPS-ach. Zbyt agresywne przycinanie kolejki klatek bywa źródłem niestabilnych frametime’ów. Najbezpieczniej zaczynać od wartości domyślnych i zmieniać je pojedynczo.
• V‑Sync i ograniczniki FPS – źle dobrany limit potrafi wejść w konflikt z reprojekcją w runtime VR. Jeśli już ograniczać, lepiej robić to w jednym miejscu (np. w samym runtime lub RTSS), nie w trzech naraz.

Konfiguracja „bazowa” w sterowniku to w praktyce profil możliwie zbliżony do domyślnego, z ewentualnym ręcznym ustawieniem trybu zasilania (preferuj wydajność) i dopasowaniem zarządzania energią tak, aby GPU nie schodziło zbyt agresywnie z taktowań przy wolniejszych scenach.

Neutralny profil runtime VR (SteamVR/OpenXR)

Trzecia noga tej układanki to runtime gogli. Tu również łatwo przesadzić:

• ustawiona zbyt wysoka rozdzielczość renderowania (np. 200–300% w SteamVR) zabija FPS w symulatorze, który i tak jest mocno jednowątkowy,
• wymuszona reprojekcja 1:3 lub dziwne tryby motion smoothing powodują nienaturalne rozmycie ruchu i smugi na znakach,
• dynamiczne skalowanie rozdzielczości może w teorii pomagać, ale u niektórych użytkowników daje „oddychający” obraz – raz ostry, raz miękki.

Bezpieczny start to:

• skalowanie bazowe w okolicach 80–110% (zależnie od gogli),
• reprojekcja automatyczna lub standardowa 1:2, jeśli GPU jest słabe,
• wyłączone dodatki typu motion smoothing w eksperymentalnych trybach, dopóki baza nie jest stabilna.

Dopiero na takim profilu warto podłączać OpenXR Toolkit czy inne narzędzia modyfikujące obraz. W przeciwnym wypadku trudno odróżnić, czy dziwne artefakty wynikają z moda, czy z niestandardowej funkcji runtime’u.

Mody zwiększające ostrość obrazu w VR – co faktycznie działa

Supersampling i rozdzielczość – „mod” numer zero

Zanim pojawi się jakikolwiek mod zewnętrzny, największy wpływ na ostrość ma zwykła rozdzielczość renderowania. W VR to głównie suwaki w SteamVR/OpenXR i ewentualnie wewnętrzne skalowanie gry. Nominalna rozdzielczość paneli gogli bywa po prostu za mała, by znaki drogowe czy napisy na deskach rozdzielczych były czytelne bez podbijania render scale.

Ogólna zasada jest prosta: lepiej lekko podbić rozdzielczość renderowania i zredukować kilka cięższych efektów graficznych, niż na siłę trzymać „Ultra” przy niskim render scale. Modów, które „magicznie” poprawią czytelność liter przy bardzo niskiej rozdzielczości, po prostu nie ma.

OpenXR Toolkit – praktyczny „zestaw” pod VR w symulatorach

W środowisku OpenXR jednym z najskuteczniejszych narzędzi poprawy ostrości przy rozsądnej cenie wydajności jest OpenXR Toolkit. Kluczowe funkcje z punktu widzenia ETS2/ATS:

• Skalowanie przestrzenne (FSR/NIS) – umożliwia renderowanie gry w niższej rozdzielczości i podbicie jej przez algorytm skalujący. Gdy GPU jest blisko limitu, można obniżyć skalowanie w runtime i włączyć FSR/NIS, zachowując zbliżoną ostrość do wyższej natywnej rozdzielczości.
• Sharpening z regulacją – kontrola poziomu wyostrzania bez wchodzenia w sterownik GPU lub reshade. Delikatne wartości często wystarczą, aby poprawić czytelność znaków i tekstur asfaltu bez „kłującego” szumu.
• Fixed/Foveated Rendering – jeśli gogle i gra to tolerują, można obniżyć rozdzielczość w peryferiach pola widzenia. Największa ostrość pozostaje w centrum, a GPU dostaje trochę oddechu. W symulatorach, gdzie wzrok koncentruje się głównie na drodze przed ciężarówką, ma to realny sens.

Trzeba przy tym brać pod uwagę, że FSR/NIS nie są cudownym lekiem. Przy zbyt dużej redukcji rozdzielczości zaczynają pojawiać się artefakty i „miękkość” drobnych detali. Realny zakres „bezpieczny” to często okolice 80–90% render scale + umiarkowane skalowanie FSR, zamiast spadku do 60% z agresywnym sharpeningiem.

Minimalistyczne reshade pod VR – kiedy ma sens

Reshade w VR to temat drażliwy. Działa nie zawsze, bywa kapryśny z OpenXR i potrafi powodować crashe przy aktualizacjach gry lub runtime’u. Jeśli jednak pipeline pozwala na jego użycie, można z niego wycisnąć trochę dodatkowej ostrości i czytelności sceny.

Najbliżej rozsądku są presety, które:

• używają jednego, lekkiego filtra sharpening zamiast zestawu „HDR + bloom + sharpen x2”,
• delikatnie korygują kontrast i gamma, tak aby znaki i interfejs nie ginęły w zbyt ciemnej scenie,
• nie wprowadzają ekstremalnych efektów światła, flar i intensywnego DOF.

Przykładowy scenariusz z praktyki: gracz ma już względnie stabilną konfigurację OpenXR Toolkit, ale nadal ma problem z czytelnością znaków na tle jasnego nieba. Dodanie lekkiego reshade z delikatnym podbiciem lokalnego kontrastu potrafi zauważalnie pomóc, o ile nie dubluje się ostrości z toolkit i sterownika. Warunek: dokładne testy stabilności po każdej większej aktualizacji gry lub runtime’u VR.

Mody tekstur i retekstury interfejsu

Ostrość to nie tylko rozdzielczość renderowania, ale też jakość samych tekstur. Część paczek graficznych pod VR skupia się na:

• podmianie tekstur znaków drogowych na wyraźniejsze, z lepszym kontrastem liter i obramowań,
• zmianie tekstur interfejsu kabiny (prędkościomierze, wyświetlacze) na bardziej czytelne w goglach,
• uprośceniu lub wyczyszczeniu z szumu niektórych elementów UI.

Mody na oświetlenie i pogodę a czytelność w VR

Mody graficzne zmieniające światło i pogodę są jednymi z najpopularniejszych w ETS2/ATS, ale pod VR ich działanie bywa odwrotne od zamierzonego. To, co na monitorze wygląda „filmowo”, w goglach bardzo szybko zamienia się w utratę czytelności i migotanie.

Najczęstsze problemy pojawiają się przy:

• zbyt agresywnym kontrastowaniu sceny – ciemne cienie w kabinie i jasne niebo utrudniają odczyt zegarów i znaków, szczególnie przy dynamicznej ekspozycji,
• przepalonym bloomie i lens flarach – efektowna poświata świateł reflektorów na monitorze, w VR może przykrywać detale drogi i znaki,
• przesadnym HDR – gwałtowne zmiany jasności przy wyjeździe z tunelu lub wjazdach do miast powodują wrażenie „pulsującego” obrazu.

Jeśli celem jest ostrość i spokój obrazu, bardziej przydatne są paczki, które:

• łagodzą skrajności jasności i cieni, zamiast je podbijać,
• zmniejszają intensywność bloom i rozmytych efektów świetlnych,
• czyszczą „mgiełki” i nadmiar post-processingu wokół świateł miejskich.

Przykład z praktyki: użytkownik instaluje popularny mod pogody z bardzo mocnym HDR. Na monitorze zachód słońca wygląda świetnie, w VR znaki drogowe zlewają się z niebem. Po przejściu na bardziej stonowany preset bez agresywnego bloom, ostrość subiektywnie „wraca”, choć nominalna rozdzielczość się nie zmienia.

Pakiety „VR graphics/realism” – czego oczekiwać, a czego nie

W warsztatach i na forach regularnie pojawiają się paczki „VR graphics” czy „VR realism”. Niektóre są uczciwie opisane, inne obiecują cudowne „4K w goglach typu entry level”. Trzeba je filtrować z chłodną głową.

Typowe składniki takich paczek to:

• zmodyfikowane pliki konfiguracyjne gry (np. komenda r_scale, mipmapy, odległości rysowania),
• preset post-processingu – wyostrzanie, zmiana koloru i kontrastu,
• mody uproszczające niektóre efekty (mgły, cienie dalekie, odbicia), aby odciążyć GPU.

Rzeczy, które faktycznie mogą pomóc:

• rozsądne zwiększenie rozdzielczości tekstur krytycznych (znaki, UI),
• uproszczenie lub wyłączenie dalekich efektów, które i tak w VR słabo widać, a kosztują sporo mocy,
• korekta gamma/koloru tak, by napisy i oznaczenia dróg odcinały się od tła.

Z kolei obietnice w stylu „podwaja FPS i ostrość” zwykle opierają się na jednym z paru trików:

• drastyczne obniżenie realnej rozdzielczości (np. przez polecenia konsoli),
• wyłączenie połowy efektów graficznych, co można zrobić samodzielnie w menu,
• agresywne wyostrzanie, które na statycznym screenie wygląda ostro, a w ruchu zamienia się w szum.

Bezpieczne podejście: traktować takie paczki jako źródło pomysłów. Rozbić je na elementy, porównać z własną konfiguracją, włączyć pojedyncze funkcje zamiast ładować „all-in-one” z nadzieją na cud.

Mody optymalizujące geometrię i detale pod VR

ETS2/ATS potrafią zasypać silnik masą drobnych obiektów – słupkami, krzakami, detali w zabudowie. Na monitorze dodają klimatu, w VR część z nich jest ledwo widoczna, za to każda dodatkowa instancja geometrii obciąża CPU i czasem GPU.

Mody tnące detale i geometrię mają kilka praktycznych zastosowań:

• redukcja gęstości roślinności przy drogach szybkiego ruchu – zmniejsza migotanie w peryferiach FOV i poprawia płynność,
• ograniczenie liczby drobnych obiektów miejskich (kosze, słupki, małe reklamy), które w VR są tłem i rzadko przyciągają wzrok,
• łagodniejsze LOD – przełączanie modeli na niższe szczegóły w większych odległościach, aby zredukować „popping” w ruchu.

Efekt uboczny bywa pozytywny: mniej „śmieci” w scenie to mniejsza szansa na szarpnięcia frametime’ów w miastach. Obraz wydaje się spokojniejszy, a mózg przestaje śledzić ciągłe pojawianie się i znikanie drobnych elementów na obrzeżach pola widzenia.

Narzędzia do blokowania FPS i wygładzania frametime’u

Chociaż nie są to „mody graficzne” w klasycznym sensie, z punktu widzenia stabilności VR pełnią podobną rolę. RTSS czy inne zewnętrzne limitery FPS mogą pomóc, o ile są używane świadomie.

Symulatory SCS działają najstabilniej, gdy:

• FPS jest powyżej celu reprojekcji (np. 45 przy docelowych 90 Hz) i nie skacze co chwilę między dwoma poziomami,
• frametime utrzymuje się w możliwie wąskim przedziale, bez pojedynczych „kolców”.

Takie narzędzia umożliwiają:

• ustawienie twardego limitu FPS poniżej maksymalnej wartości, jaką osiąga gra – w zamian dostaje się mniej wahań,
• monitorowanie frametime’u w czasie rzeczywistym i szybkie wyłapanie, czy to mod mapy, czy pogody powoduje skoki,
• dość precyzyjne dobranie limitu tak, aby dobrze współgrał z wybranym trybem reprojekcji w runtime VR.

Ryzyko pojawia się, gdy limit ustawi się zbyt blisko granicy możliwości sprzętu. Przykład: gra bez limitu „lata” między 55–75 FPS, gracz ustawia sztywne 72, licząc na płynność – w efektach końcowych pojawia się ciągłe doganianie limitu, mikroprzycięcia i rozjazd z reprojekcją. Bezpieczniej czasem celowo zejść do niższego, ale osiągalnego stałego poziomu, co paradoksalnie poprawia wrażenie płynności i ostrość ruchu znaków czy barier.

Mody mapowe i ruchu AI a komfort w goglach

Rozszerzenia map i mody na ruch AI kojarzą się głównie z zawartością, ale w VR bardzo łatwo potrafią zepsuć stabilność obrazu. Sytuacja jest prosta: więcej skrzyżowań, więcej skomplikowanych prefabów i większy ruch oznacza cięższe sceny dla CPU, a pośrednio także dla GPU.

Typowe objawy „przeładowanej” mapy pod VR to:

• regularne przycinki przy każdym większym węźle lub wjeździe do miasta,
• skoki czasów doczytywania sektorów, widoczne jako krótkie pauzy przy szybszej jeździe,
• migotanie lub gubienie ostrości przy gwałtownych spadkach FPS i agresywnej reprojekcji.

Przy konfiguracjach na granicy możliwości sprzętu sensowniejsze bywa używanie mniejszych, dobrze zoptymalizowanych map i umiarkowanych modów ruchu AI niż „pakietu wszystkiego”. Dodatkowe drogi nie przydadzą się, jeśli każda jazda przez większe miasto kończy się uczuciem „chwiania obrazu” w goglach.

Specjalistyczne mody dla wybranych gogli i platform

Co jakiś czas pojawiają się dodatki twierdzące, że są „pod konkretne gogle” (np. WMR, Quest przez Link, Pico). Zazwyczaj nie są to prawdziwe mody gry, tylko zbiory ustawień lub skrypty konfigurujące runtime, sterownik lub pliki konfiguracyjne.

Takie paczki bywają pomocne, gdy:

• opisują jasno, jakie parametry zmieniają (np. FOV w configu, rozdzielczość i tryb reprojekcji),
• są przygotowane pod konkretną ścieżkę uruchamiania (np. OpenXR zamiast SteamVR),
• mają aktualne instrukcje pod obecną wersję sterowników i runtime’u.

Ryzykowne są natomiast zestawy „uniwersalne dla wszystkich gogli VR” z narzuconymi wartościami FOV, rozdzielczości i LOD. Zbyt wąskie FOV może poprawić wydajność kosztem nienaturalnego tunelowego widzenia, a przesadne kadrowanie sceny w configu wywoła artefakty na krawędziach obrazu.

Bezpieczniejsza droga to traktowanie takich paczek jako źródła referencyjnych liczb dla konkretnych modeli gogli, ale ręczne wprowadzanie zmian i testowanie ich krok po kroku. Szczególnie istotne jest to przy goglach podłączanych przez strumieniowanie (Link/AirLink, Virtual Desktop), gdzie dochodzi opóźnienie sieciowe i dodatkowa kompresja obrazu.

Zarządzanie kolejnością modów a stabilność obrazu

Sama obecność modów to połowa problemu, druga to sposób ich ułożenia. Konflikty między paczkami graficznymi, pogodą i mapami mogą nie tyle „crashować” grę, ile generować nieprzewidywalne spadki wydajności i artefakty.

Przy układaniu listy modów pod VR dobrze sprawdza się kilka praktyk:

• ograniczenie liczby paczek graficznych do jednej „bazy” – jeden mod na pogodę/światło, jeden na roślinność; unikanie nakładających się reshade/post-processów,
• sprawdzenie, co nadpisuje co – jeśli dwa mody ruszają te same pliki tekstur lub definicji oświetlenia, nierzadko efektem jest dziwne zachowanie HDR lub cieni,
• testowanie po kilku modach naraz, a nie po całej 30‑elementowej paczce – łatwiej wtedy znaleźć winnego nagłych stutterów w VR.

Same priorytety modów (kolejność ładowania) nie poprawią FPS magicznie, ale bałagan na liście ułatwia powstawanie konfliktów, a te często objawiają się właśnie niestabilnością obrazu – migającymi teksturami, dziwnymi przejściami jasności, czy powtarzającymi się „przykucnięciami” frametime’u w tych samych miejscach trasy.

Kompromisy, których nie da się obejść żadnym modem

W tle wszystkich powyższych zabiegów zostaje kilka ograniczeń, których żaden mod nie przeskoczy. Symulatory SCS mają stary, mocno jednowątkowy silnik, a VR do tego wymaga wysokiej stabilności i dużej liczby próbek na oko.

Kilka twardych realiów:

• na słabszych CPU nawet najlepszy mod graficzny nie usunie przycięć w gęstym ruchu miejskim – można je co najwyżej złagodzić, redukując obciążenie,
• zbyt niska bazowa rozdzielczość gogli nie zamieni się w „ostre 4K” od samego sharpening – pojawią się artefakty, a drobne litery pozostaną ograniczeniem sprzętu,
• reprojekcja zawsze wprowadza pewną „płynność inaczej”; można ją wygładzić stabilnym FPS i rozsądnymi modami, ale nie da się w pełni ukryć jej charakteru.

Dlatego większość skutecznych konfiguracji VR pod ETS2/ATS składa się z kilku umiarkowanych zmian: lekkie podbicie rozdzielczości, rozsądny sharpening, prostsze efekty wizualne, mądrze dobrane mody tekstur i światła oraz ostrożne użycie narzędzi typu OpenXR Toolkit i RTSS. Agresywne „pakiety cudów” niemal zawsze kończą się gorzej niż cierpliwe składanie własnego, przewidywalnego zestawu.

Najczęściej zadawane pytania (FAQ)

Jakie mody VR najbardziej poprawiają ostrość obrazu w ETS2/ATS?

Największy wpływ na ostrość mają mody i narzędzia ingerujące w skalowanie rozdzielczości oraz wyostrzanie: supersampling w SteamVR/OpenXR, narzędzia pokroju OpenXR Toolkit, czasem reshade z ostrożnie ustawionym sharpeningiem. Część modów ogranicza też rozmycie i wygładzanie krawędzi w samym silniku gry, co poprawia czytelność znaków i deski rozdzielczej.

Efekt zależy jednak od konfiguracji. Ten sam poziom supersamplingu na Reverb G2 i na Queście 2 da zupełnie inny „realny” zysk, a przy słabszym GPU szybko pojawi się przeciążenie i niestabilny framerate. Dlatego punkt startowy to raczej umiarkowane podbicie rozdzielczości (np. 110–120%) i dopiero później testowanie dodatkowego wyostrzania.

Jakie ustawienia i mody VR najbardziej stabilizują FPS w symulatorach ciężarówek?

Najwięcej robią mody „odchudzające” scenę: redukcja liczby obiektów w miastach, uproszczone LOD, mniejsza gęstość trawy, ograniczenie świateł i efektów pogodowych. Równolegle trzeba zjechać z ciężkimi opcjami w samej grze (cienie, odbicia, gęstość ruchu AI), zwłaszcza jeśli używane są rozbudowane mody pogodowe i graficzne.

Dobrym sygnałem jest sytuacja, gdy gra trzyma stabilnie np. 45 FPS i reprojection pracuje przewidywalnie, zamiast „skakać” między wartościami. Jeśli mod wygląda świetnie na screenach, ale w goglach powoduje nagłe dropy przy wjeździe do miasta, zwykle lepiej z niego zrezygnować lub mocno ograniczyć jego ustawienia.

Jaki poziom supersamplingu w VR do ETS2/ATS jest optymalny?

Nie ma uniwersalnej wartości, bo wiele zależy od headsetu, łącza (dla gogli bezprzewodowych) i GPU. W praktyce dla większości konfiguracji rozsądny przedział to okolice 100–120% w menedżerze VR, pod warunkiem że nie są jednocześnie ładowane ciężkie mody graficzne 4K i agresywne filtry sharpen.

Jeżeli po podniesieniu supersamplingu powyżej tego progu zysku wizualnego prawie nie widać, a zaczynają się skoki FPS, to znaczy, że został przekroczony „punkt malejących korzyści”. Wtedy lepiej utrzymać niższą rozdzielczość i zainwestować w stabilność (mniej cieni, mniejszy ruch AI) niż dalej „pchać” piksele.

Czy reshade i filtry wyostrzające są bezpieczne do VR w symulatorach?

Technicznie dużo zależy od kombinacji API (OpenVR/OpenXR), sposobu uruchamiania gry i użytych injectorów. Reshade bywa kapryśny w VR: potrafi gryźć się z OpenComposite, overlayami lub innymi modami, a bywa też źródłem crashy przy zmianie sceny lub ładowaniu mapy. Trzeba testować na „czystej” konfiguracji i po jednym narzędziu naraz.

Od strony komfortu nadmierny sharpening w VR szybko prowadzi do zaszumienia obrazu i migotania krawędzi. Efekt „ostry jak brzytwa” na statycznym screenie, w goglach przy ruchu głowy zamienia się często w męczące oczy „mrówki”. Rozsądna praktyka to bardzo delikatne wyostrzanie i tylko wtedy, gdy supersampling nie może już iść wyżej bez zabicia FPS.

Czy lepiej używać SteamVR czy OpenXR/OpenComposite do ETS2/ATS w VR?

Coraz częściej lepszą wydajność i mniejsze opóźnienia daje przejście na OpenXR z pominięciem pełnego SteamVR (np. przez OpenComposite). Mniej warstw pośrednich to zwykle mniejszy narzut na CPU/GPU, a tym samym większa szansa na utrzymanie stabilnego framerate przy tych samych modach i ustawieniach.

To jednak nie jest reguła bez wyjątków. Niektóre narzędzia (np. konkretne wersje reshade czy overlaye) działają tylko z OpenVR/SteamVR. Jeśli dany mod VR wymaga określonego API, trzeba się dostosować, a zamiast „przeskakiwać” między runtime’ami na oślep – najpierw ustalić docelową ścieżkę: SteamVR natywnie albo OpenXR jako główny runtime gogli.

Jak uniknąć konfliktów między modami VR, sterownikiem GPU i ustawieniami gry?

Podstawowa zasada: jedno miejsce odpowiada za konkretny typ obróbki obrazu. Jeśli gra ma własne AA i skalowanie, menedżer VR ma supersampling, a sterownik GPU oraz reshade dorzucają własne ostrości i filtry, powstaje trudny do opanowania „koktajl”. Zanim szuka się winnego stutterów, trzeba wyłączyć globalne override’y w sterowniku i ograniczyć nakładanie się efektów.

Praktyczne minimum to:

• skalowanie i rozdzielczość – ustawione w jednym miejscu (najczęściej SteamVR/OpenXR),
• AA – albo z gry, albo z narzędzia VR, nie oba naraz na agresywnych profilach,
• wyostrzanie – jedna, delikatna warstwa, zamiast trzech konkurujących filtrów.

Dopiero na tak „oczyszczonym” pipeline da się rzetelnie ocenić, który mod realnie pomaga, a który tylko obciąża GPU.

Co jest ważniejsze w VR do ETS2/ATS: wysoka rozdzielczość czy stabilne FPS?

Dla komfortu VR wygrywa stabilność. Lekko miękki, ale równy obraz przy 45 FPS z przewidywalną reprojection jest mniej męczący niż superostry, ale szarpiący przy każdym doczytywaniu miasta. Szczególnie odczuwalne jest to w długich trasach – po godzinie jazdy drobne mikrolagi robią większą różnicę niż dodatkowe piksele na krawędziach znaków.

Rozsądne podejście to najpierw „zabetonować” stabilne minimum FPS poprzez redukcję detali, modów obciążających GPU i ruchu AI, a dopiero potem stopniowo podnosić rozdzielczość lub wyostrzanie. Jeśli przy każdym kolejnym kroku ustawienia FPS zaczynają „pływać”, to znak, że osiągnięto granicę sensownego kompromisu dla danej konfiguracji.

Najważniejsze wnioski

• Symulatory ciężarówek w VR są wyjątkowo wymagające wydajnościowo, bo łączą dużą, streamowaną mapę, daleki zasięg widzenia i podwójne renderowanie dla każdego oka, więc każdy „ciężki” mod szybciej niż w innych grach dobija GPU.
• Ostrość i stabilność obrazu są w stałym konflikcie: większość modów poprawiających wyrazistość (supersampling, filtry wyostrzające, tekstury 4K) zwiększa obciążenie i pogarsza płynność, co w VR bezpośrednio odbija się na komforcie i może nasilać objawy choroby symulatorowej.
• Realny zysk z podbijania rozdzielczości i supersamplingu kończy się w okolicach określonego „słodkiego punktu” (często ~100–120% dla typowych zestawów), a dalsze podbijanie zwykle daje znikomy wzrost ostrości przy wyraźnym spadku stabilności klatek.
• W praktyce lepszą czytelność daje lekkie obniżenie ogólnej „fajerwerkowości” grafiki (cienie, trawa, odbicia, ruch AI) przy zachowaniu wyraźnych znaków, tablic i deski rozdzielczej, niż maksowanie jakości nieba czy oświetlenia kosztem dropów FPS przy wjeździe do miasta.
• Stabilne, przewidywalne FPS (np. „sztywne” 45 z dobrze działającą reprojection) są w VR bardziej komfortowe niż teoretycznie wyższy, ale skaczący framerate; gwałtowne spadki i mikroprzycięcia potrafią zniszczyć wrażenie płynności mimo wysokich średnich FPS.

Opracowano na podstawie

• Virtual Reality – A Short Introduction. Springer (2018) – Podstawy techniczne VR, wymagania wydajnościowe i komfort użytkownika
• Virtual Reality and the GPU: A Natural Fit. NVIDIA (2016) – Wpływ podwójnego renderingu, latency i FPS na komfort w VR
• SteamVR Performance Guidelines. Valve – Wytyczne dot. FPS, reprojection i ustawień rozdzielczości w SteamVR
• OpenXR Specification. Khronos Group (2023) – Standard API OpenXR, warstwy pośrednie i integracja z aplikacjami VR
• Euro Truck Simulator 2 – VR Support FAQ. SCS Software – Oficjalne informacje o trybie VR, integracji ze SteamVR i wymaganiach
• Asynchronous Reprojection in Virtual Reality. Oculus – Zasady działania reprojection i wpływ stabilnego FPS na płynność