Vývojáři z SCS Software se po dlouhé době rozhodli sepsat další podrobný článek ze zákulisí vývoje, tentokrát na téma SSAO, ambientní okluze (zastínění okolím) generované v obraze, která byla přidána v rámci aktualizací 1.38 pro ATS i ETS2. Následující část je tedy kompletním překladem původního článku z blogu SCS Software.
Dnes bychom chtěli vysvětlit novou grafickou funkci, kterou představujeme v našich hrách s aktualizací 1.38. Tento článek je velmi technický – požádali jsme naše programátory, aby nám pomohli, a vysvětlení je poměrně složité. Cítili jsme však, že alespoň pro některé z vás může být tento materiál velmi zajímavý – abyste mohli vidět, že to, co se děje pod pokličkou herního enginu, vyžaduje hodně zkoumání a tvrdé práce našeho týmu programátorů. Mimo samotné technické podrobnosti si myslíme, že vysvětlení kontextu a výkonových kompromisů může být pro většinu hráčů užitečné a důležité.
Jaroslav, známý jako Cim(jeden ze statečných a zkušených programátorů pracujících na grafických vylepšeních)
Shrnutí níže uvedeného textu by bylo, že ambientní okluze generovaná v obraze je skvělá, nová, ale výkonově náročná technika obohacující vykreslování našeho herního světa. Nemusíte ji používat, pokud máte pocit, že vám příliš snižuje výkon, nebo naopak se vám může líbit a můžete si dovolit obětovat několik snímků za sekundu za lepší vnímání stínů a hloubky. Celý efekt může být mizivý, většinou funguje na úrovni podvědomí, ale jakmile si na něj zvyknete, pravděpodobně se těžko budete vracet. Jedná se o další milník v našem plánu vylepšit nasvícení/stínování, na kterém aktuálně pracujeme, a po kterém bude následovat nové zpracování světla s využitím HDR i širší zavedení normálově mapovaných povrchů v nadcházejících aktualizacích.
Tato technika má svá omezení a úskalí. V posledních letech ji používalo několik AAA her, a přestože není dokonalá, pomáhá lidskému vnímání lépe porozumět scéně, takže doufáme, že její přidání do naší technologické směsi pro truckové simulátory bude prospěšné. Do budoucna určitě chceme představit další způsoby vypočítávání stínů, které ji vylepší nebo dokonce nahradí.
Jsme pod neustálým tlakem vokální části fanouškovské základny, abychom vylepšili vzhled našich her, zároveň je tu ale stále touha po rychlejším běhu našich her. Kromě těchto někdy protichůdných požadavků přicházejících z hráčské základny máme také vlastní oddělení grafiků, kteří vždy touží po nějaké nové grafické vymoženosti, aby naše hry byly bohatší a lepší. Kdykoliv do hry zavedeme novou grafickou funkci, snažíme se to udělat způsobem, který neublíží výkonu hráčům se staršími počítači – nechceme, aby se hra stala pro naše stávající zákazníky nekompatibilní. Proto existuje možnost SSAO zcela vypnout a několik nastavení pro jeho kvalitu/výkon.
Práce programátorů na nových technikách SSAO/HBAO vyžadovala rovněž změny v našich postupech při tvorbě modelů. Všechny 3D modely v našich hrách musely být přepracovány výtvarným oddělením a ve všech případech, kdy falešné stíny či zatmavení již byly aplikovány přímo na modelu, došlo k jejich změně. V případě některých komplexnějších herních modelů to znamenalo zjednodušení, které snížilo jejich počet trojúhelníků natolik, aby se to projevilo na vylepšení výkonu vykreslování. Do určité míry jsme tak vyměnili část nezbytného budoucího manuálního úsilí, které bylo potřeba pro vytvoření jednotlivých dobře vypadajících 3D modelů, za algoritmický proces vykreslování, který sjednocuje vzhled stínů v rámci celé scény a pomáhá „zakořenit“ objekty jako jsou budovy, sloupy lamp či vegetace do terénu.
Co znamená SSAO a jak funguje
Než začneme – povšimněte si, že SSAO je obecná zkratka pro „screen space ambient occlusion“ (ambientní okluze generovaná v obraze). Název zahrnuje všechny různé techniky ambientní okluze (AO) a jejich varianty, které fungují v prostoru obrazovky (to znamená, že získávají veškeré informace za běhu z dat, která jsou vykreslována na obrazovce monitoru a do příslušných vyrovnávacích pamětí). Existuje SSAO (technologie studia Crytek z roku 2007, která v podstatě dala jméno všem těmto technikám), MSSAO, HBAO, HDAO, GTAO a mnoho dalších technik, z nichž každá používá odlišné postupy vyladění, přičemž každá má své výhody i nevýhody. Náš přístup jsme založili na horizontální technice nazvané GTAO, která byla představena společností Activision v roce 2016.
Část ambientní okluze (AO) v názvu znamená, že vyhodnocujeme, kolik dopadajícího světla (převážně z oblohy, ale někdy se vypočítaná okluze aplikuje i na jiná světla) se zakryje na konkrétním místě v herním světě. Představte si, že stojíte na rovné půdě – nad sebou byste viděli celou oblohu, tzn. 0% okluze, země je plně osvětlena oblohou. Teď si představte, že jste na dně studny – viděli byste jen malou skvrnu oblohy, tzn. že obloha je téměř 100% zakryta a jen nepatrně přispívá k okolnímu osvětlení v této studni, a samozřejmě samotné dno je také dost tmavé. Konkrétní úroveň okolní okluze na konkrétním místě ovlivňuje výpočty osvětlení a vytváří zastíněné oblasti v záhybech, dírách a dalších „složitějších“ místech. Podle svého okolí se tak může pohybovat mezi 0 % až 100 %.
Výpočet okluze ve velkém detailu a s velkou přesností je velmi náročná na výkon; v podstatě byste museli vysílat paprsky z jakékoliv počítané pozice ve všech směrech a vyzkoušet, zda dopadly na oblohu nebo ne, a pak průměrovat výsledek. Čím více paprsků vysíláte, tím lepší informaci získáte, ovšem za cenu vyšších výpočetních nákladů. Tento proces by mohl být zpracováván offline, např. když je mapa ukládána jeho designérem. Některé hry a enginy tento způsob používají, tímto způsobem však budete moci zapéct informace o ambientní okluzi pouze pro nepohyblivé objekty, protože v té době nejsou přítomna žádná vozidla ani animované objekty.
Takže namísto zapékání statických informací (což by zároveň vyžadovalo hodně času a prostoru na disku, vzhledem k měřítku naší mapy světa), ji chceme vypočítat přímo za chodu hry. Tímto způsobem ji můžeme počítat i pro interakci s vozidly, otevírání mostů, animované objekty apod. Přesto to má háček – pro takový výpočetní přístup máme k dispozici pouze data, která jsou viditelná na obrazovce (vzpomeňte si na „generování v obraze“), takže jakmile se některá část herního světa dostane z viditelného rámce, nemůže být použita pro výpočet okluze. Toto omezení vytváří různé artefakty jako je mizející okluze na zdi, která byla původně způsobena objektem, který se právě dostal za okraj obrazovky, a stal se tak neviditelný nejen pro vás, ale také pro algoritmus, takže přestal mít vliv na výpočet okluze.
Dobře, nyní víme, co vypočítat (ambientní okluzi) a víme, se kterými daty můžeme počítat (to, co vidíme na obrazovce). Co s tím uděláme? No, pro každý pixel na obrazovce (tj. 2 miliony pixelů v HD rozlišení, krát 4 při 400% škálování!) náš kód shaderu musí dotazovat hodnotu okolních pixelů z-bufferu a pokusit se získat představu o geometrickém tvaru oblasti, která ji obklopuje. Máme pouze omezený počet těchto „doteků“, protože s rostoucím počtem doteků dochází k prudkému vzrůstu náročnosti na výkon – tahle operace je tou skutečnou zátěží na 3D grafické karty. Mezní hodnota počtu doteků zase ovlivňuje přesnost ambientní okluze (a v určitých situacích může způsobit nepřesnosti a pruhy). Představte si, že chcete vypočítat své okolí na dvoumetrové přímce, a jste ochotni utratit 8 doteků pro přesnější odhad. Dotazovat se budete každých 25 cm na přímce, takže každý menší detail mezi těmito body může zůstat zcela bez povšimnutí, pokud nebudete mít štěstí a netrefíte na něj přímo na daném místě (nebo naopak budete mít smůlu, protože ho můžete ztratit v dalším snímku, takže okolí se najednou bude zdát jakoby se během snímků změnilo a způsobí blikání). Čím dále váš algoritmus sonduje, tím méně je přesný. Musíte tedy omezit velikost oblasti, kterou analyzujete kolem každého herního pixelu, což zase omezuje, jak daleko ambientní okluze „vidí“ – proto tato metoda není vhodná pro výpočet okluzí ve velkých prostorech, jako např. pod mostními oblouky.
Zmínili jsme se, že námi vybraná technika je založena na horizontu. To znamená, že nezkoumáme prostředí vysíláním paprsků ve 3D světě, místo toho analyzujeme polokouli nad/kolem každého pixelu, abychom viděli, jak daleko se otevírá, dokud není zastíněna, kolik světla je vpuštěno okolní geometrií s použitím z-bufferu jako našeho vyslance. Polokoule je ve skutečnosti aproximována několika běhy podél čáry natočené kolem daného pixelu. Pokud budeme moci sledovat celou tuto polokouli v plném rozsahu, nedojde k žádnému zastínění. Pokud se algoritmus dotkne hodnoty v z-bufferu, která by blokovala příchozí světlo, definuje úroveň zastínění. Algoritmus je optimalizován pro výkon, ale jeho omezení spočívá v tom, že jakmile se čehokoliv dotkne, třeba jen pravděpodobně malého objektu, přestane sondovat dále. To může způsobit problém „přestínění“ a může být spatřen jako vizuální artefakt, kdy nějaký relativně tenký předmět, jako např. sloupek dopravního značení, způsobí silnou okluzi na blízké zdi. Můžete se pokusit odhalit takovéto malé objekty a přeskočit je, což ovšem naopak může způsobit „nedostatečné zastínění“. Rozhodli jsme se pro první variantu.
Existuje také další zajímavá a užitečná vlastnost technik založených na horizontu. V závislosti na tom, jak velká část polokoule nad daným pixelem je zastíněna, můžete vypočítat směr, který je nejméně zastíněný. Rozsah okluze si lze představit jako kornout zmrzliny s proměnlivým vrcholovým úhlem orientovaným v daném směru. Tento směr se nazývá „ohnutá normála“ a my ji používáme pro různé světelné výpočty, např. pro zastínění odrazu na lesklých površích. Myšlenka je taková, že když se podíváte na povrch a zrcadlově odražené směry se dostanou pryč z tohoto kužele, považujeme to za (alespoň částečnou) okluzi, čímž se sníží intenzita odrazu. Nejlepším způsobem, jak můžete tento efekt vidět, je podívat se na větší a kulaté chromované části, např. palivové nádrže, s vypnutým a zapnutým SSAO.
Takže jak vidíte, samotná myšlenka není tak náročná, alespoň pro profesionálního grafického programátora, ale je zde spousta výpočtů, které 3D grafickou kartu dosti zatěžují. Vytvořili jsme tedy několik výkonových profilů, každý s pomocí různých optimalizačních technik:
- Použití méně doteků pro každý směr – je to rychlejší, ale umožňuje ambientní okluzi vynechat větší objekty než s jemnějším vzorkováním.
- Znovuprojektování výsledků ambientní okluze z předchozího snímku – umožňuje nám skrýt artefakty před podvzorkováním, ale může docházet k „duchům“, pokud znovuprojektování selže (když to, co vidíte mezi jednotlivými snímky, se často mění).
- Vykreslování v nižším rozlišení – snižuje počet výpočtů na čtvrtinu, ale vytváří méně přesnou ambientní okluzi, výsledkem může být mírně rozmazané stínování
Pokud jste článek dočetli až sem, jsme rádi, že jeho překlad našel využití i mezi našimi čtenáři. Nezapomeňte se s námi podělit v komentářích o vaše postřehy, případně připomínky a dotazy.
Už nějakou dobu jsem si říkal, že v ETS2/ATS něco chybí. Stíny tam sice jsou, ale všechno je to takové umělé, osvětlení příliš uniformní. Říkal jsem si, že by to mohlo být SSAO, ale zas tak jistý jsem si nebyl.
Výsledný dojem je ale skvělý. Přesně to tomu chybělo. 🙂
Přečetla jsem to celé, ale pochopila jen po „funguje“ v nadpise. 😀
Co říkají?
Sultáne, odborný … pindy ….
Hlavně že to dobře vypadá. 😉
Mně by taky stačili první tři odstavce nebo i jen ta věta: „…lepší vnímání stínů a hloubky“.
Kdo to přečte do konce, dostane odměnu od Jaroslava, známý jako Cim
(jeden ze statečných a zkušených programátorů pracujících na grafických vylepšeních).
Sultán Solimán: „No vidíš, když se díváš pořádně, tak jedou!” 🙂
Clanek jsem si precetl az do konce, ale jelikoz s grafikou nepracuji, tak mi to stejne moc nereklo. Aspon tedka vime, ze nas do budoucna cekaji dalsi graficka vylepseni napr. zpracovani svetla s vyuzitim HDR, nebo sirsi zavedeni normalove mapovanych povrchu. A dnes bych prosil blog o Idahu, diky 😀
Tak já bych ani o ten blog (myslím tím nějaké „nesmyslné plácání“) o Idahu moc nestál,spíše bych uvítal datum.To čekání mě už nebaví,a to si nedělám srandu.
To Hellforce: To nejsi sam, me uz to cekani taky nebavi. 😀 Navic dnes uz vysel blog o DAF XF Unity Edition.
Johnyprosnb: Mohl bys mi prosim poradit co mam presne delat abych ziskal ty potisky?
Ja nejsem tech odkazech vubec registrovany.
To akvarista1: Vsechny klice jsou rozdany.
Johnyprosnb: A kde klic najdu pro edemceni potisku novyho potisku.
Johnyprosnb: https://blog.scssoft.com/
Jde jde ten odkaz nejakym spusobem obnovit? Protoze me se nic nestahuje.
Johnyprosnb: Zrejme jsem aktivoval balicek pro tahac DAF XF E6, ale nic s toho se
mi nic nestahlo s automatickou aktualizaci. Jinak mam balicek DAF XF TUNING PACK.
Je to nejaky potisk, nebo nejaky vylepseni pro DAF XF.
Este viac by potesil ray tracing… Inak okrem toho ze ssao mi zozere asi 20fps som volajako zmenu nepocitil. Taka bonusova otazka preco moderi dokazu spravit rocne obdobia a scs nie…
To RosTDor: Moderi dokazi vytvorit mod, ktery napr. imituje zimu, ale nedokazi vytvorit mod, ktery umi stridat rocni obdobi. Co se tyce funkce ray tracing, napr. World of Tanks ma funkci ray tracing, ktera bezi na API DirectX 11 a k vypoctu ji postaci jen normalni shadery v GPU. Tato technologie je ve World of Tanks omezena jenom na tanky a to ty, ktere jsou v pohybu, nikoliv ty sestrelene. A take se nepocita pro vozidla, ktera nejsou ozarena primym slunecnim svetlem. Nejak si nedokazu predstavit, jaky vyznam by tohle melo v ETS2/ATS, jedine vyuziti ktere me momentalne napada jsou kvalitnejsi stiny v kabine. Navic si myslim, ze tenhle efekt bude zdimat vykon karty daleko vic, nez SSAO.