The Engine of Path of Exile

Lead: W technicznym wykładzie na ExileCon 2026 Alex Sannikov z zespołu silnika GGG pokazał rozwiązania, które dają artystom narzędzia do budowania wyglądu obu gier. Mówił o dziurach w terenie, grafach materiałów, cząsteczkach na GPU, cieniach i kryształach, a także o tym, co stało się z Radiance Cascades od ExileCon 2023. Na koniec odpowiadał na pytania widzów.

W skrócie

• Obie gry działają na dokładnie tym samym silniku. Każda zmiana pod PoE 2 kompiluje się też dla PoE 1, więc zespół pilnuje, by nie zepsuć drugiej gry.
• Zespół silnika liczy sześć osób, mało jak na standardy branży. Zamiast dopisywać kod, stale dopracowuje istniejący, żeby silnik był mały i łatwy w utrzymaniu.
• Oświetlenie globalne w PoE 2 (Radiance Cascades) liczy się w jednej klatce, w ok. 1–2 ms, niezależnie od tego, co dzieje się na ekranie.
• Wersja na Maca jest „prawie gotowa”. Gra działa też na Linuksie z obsługą Steama, bez potrzeby SteamOS.
• Kolejna generacja Radiance Cascades jest „prawie gotowa do produkcji”, ale wymaga sprzętowego ray tracingu, z którego studio chce zrezygnować.

Cutout: dziury w czymkolwiek

• Zagadka na start: urządzenie map w Kingsmarch, częściowo pod ziemią, choć poziom nie ma tam dziury. Ten sam trik widać przy otchłaniach z Abyss, które pojawiają się wszędzie i „wchodzą” w ziemię, poprawnie reagując na światło i cienie. Taką dziurę można nawet przyczepić do postaci i biegać z nią.
• Wyłączenie testu głębi dawało nienaturalny efekt. Zamiast tego niewidzialna geometria „cutout” zaznacza piksele w buforze stencil, osobny przebieg ustawia im nieskończoną głębię, a potem rysowana jest część podziemna.
• Bez tego każda otchłań wymagałaby osobnej wersji kafla terenu bez ziemi. Większość gier tego nie potrzebuje, ale w PoE wszystko łączy się ze wszystkim w dowolnej kolejności. Tą samą techniką zrobiono przejście z holodeku do cytadeli: jeden poziom się rozpuszcza, a drugi wyłania.

Grafy materiałów bez łączenia

• Grafy materiałów ma każdy nowoczesny silnik, ale w silniku GGG nie trzeba ich ze sobą łączyć. Artysta wrzuca do materiału np. graf cutout i graf parallax, a ich działanie łączy się samo. Kolejność ustala system „etapów” (stages): jeden graf zapisuje np. pozycję wierzchołka na danym etapie, a inny odczytuje ją na późniejszym.
• Prośba artystów o opisywanie grup węzłów zamieniła się w „funkcje” dla artystów. Grupa pola (field group) liczy np. poprawne normalne z samej mapy wysokości, wyliczając wyrażenie w kilku punktach. Artysta rysuje tylko splajn wysokości, a pęknięcia w ziemi poprawnie reagują na światło i mieszają się z normalnymi terenu.
• Zamiast stosów smoothstepów i potęg artyści używają splajnów. Każdy splajn w grze jest w czasie działania wypiekany do jednowymiarowej tekstury, a wszystkie razem do jednej tekstury 2D. Odczyt kosztuje tyle samo bez względu na złożoność splajnu.
• Grupy interpolacji to pole sześciokątów, w którym artysta podaje tylko kolor albo teksturę dla każdego, a węzeł płynnie je łączy. Losowe przesunięcia tekstur łamią powtarzalność kafli, a przewijanie według mapy przepływu daje płynącą wodę czy ogień bez widocznych sześciokątów.
• Węzeł deformacji siatki przelicza normalne po deformacji. Artysta nie musi rozumieć matematyki, a oświetlenie mocno zdeformowanych modeli wciąż jest poprawne.

Cząsteczki, cienie i mapy aktów

• Większość efektów w grze to cząsteczki. Ich zachowanie artyści opisują tymi samymi grafami co shadery, a symulacja jest fizyczna: grawitacja, opór powietrza, masa. Przykładami były ściana składana z odłamków i pojawienie się potwora z rojem motyli. Wszystko liczy GPU w ok. 1 ms, podczas gdy na CPU zajęłoby to dziesiątki milisekund.
• „Snapshot capture” zapisuje bieżącą klatkę do bufora, z którego czytają cząsteczki. Tak powstał efekt pękającego ekranu w walce z pinnacle bossem Delirium.
• Ostrość cieni zależy od rozdzielczości shadow mapy. Bryłę światła trzeba więc ciasno dopasować do widocznej sceny, co w grze 2,5D jest trudne. Rozwiązaniem jest „box light”: pochylona projekcja sześcianu, która na ziemię zawsze rzuca kwadrat. Daje to ostrzejsze cienie przy tym samym zużyciu VRAM. Alex dziwi się, że inne gry tego nie robią.
• Mapy aktów są w rzeczywistości obiektami 3D, zbudowanymi tym samym systemem generowania terenu co reszta gry. Jest nawet obszar, w którym da się po takiej mapie biegać. Alex przyznał, że na początku nie wierzył, że artystom uda się uzyskać tak płaski wygląd.
• Instancing: jeden obiekt nadrzędny i dowolnie dużo kopii istniejących tylko na GPU. Na pokazanej scenie CPU liczyło kilka postaci, a GPU mogło rysować setki. Więcej takich tłumów ma być w nowych aktach.

Kryształy i parallax

• Uczciwe renderowanie kryształu jest bardzo wolne, więc gra używa przybliżenia, które wygląda tak samo, a jest dużo szybsze. Wewnętrzny rdzeń dostaje oświetlenie i odbicia, a zewnętrzna warstwa zniekształcenie w przestrzeni ekranu, które mózg odczytuje jako załamanie światła. Do tego losowe przesunięcia dla „mgiełki” i druga warstwa odbić. Tej techniki używa wiele efektów lodu.
• Parallax z płynnym przejściem do terenu („contact fade”, pokazany już na ExileCon 2023) pozwala artystom nałożyć mapę wysokości z Substance Paintera i uzyskać nierówną powierzchnię, która naturalnie wtapia się w ziemię. Często wystarcza sam contact fade bez parallaxu, co daje prawie ten sam efekt dużo taniej. Do tego „outer parallax” z poprawniejszymi konturami.

Narzędzia zespołu silnika

• „Multi-layer picking” pozwala najechać kursorem na błąd lub wolny efekt i zobaczyć wszystkie zasoby pod kursorem razem ze statystykami ich wywołań rysowania. Pomaga też artystom znaleźć problematyczne zasoby, np. drzewo nie wiadomo skąd.
• Do problemów z wielowątkowością zespół używa profilera Tracy.
• „Pułapki” (traps) zastępują ręczne breakpointy. W kodzie są z góry rozmieszczone, wyłączone punkty przerwania dla wszystkich obiektów, które włącza się z interfejsu w grze. Nie trzeba niczego przekompilowywać, a Alex polecał to rozwiązanie twórcom własnych silników.
• Linux: gra działa na każdej dystrybucji z obsługą Steama, bez potrzeby SteamOS. Według Alexa Linux nie miał też problemów z zawieszaniem się Windows 11 24H2 czy błędami sterowników. On sam gra w domu na Linuksie.

Radiance Cascades: co dalej

• Alex od ok. 15 lat bada oświetlenie globalne. Większość gier polega na odszumianiu i akumulacji w czasie, stąd „smugi” i opóźnione światło, zwłaszcza przy niskim FPS. W PoE światło reaguje natychmiast, bo liczy się w jednej klatce, w ok. 1–2 ms. Koszt jest stały, niezależnie od tego, czy na ekranie jest jedna kula ognia, czy sto, a każda świecąca powierzchnia oświetla otoczenie bez dodatkowego kosztu.
• Algorytm dzieli oświetlenie na kaskady: bliskie ma wysoką częstotliwość, dalsze coraz niższą i jest coraz tańsze. Potem kaskady łączy się z powrotem w finalny obraz.
• Kolejny etap to „sparse radiance cascades” w przestrzeni świata: sondy przyklejone do powierzchni o stałym rozmiarze na ekranie, stała pamięć i koszt ok. 5 ms na klatkę. Działa nawet bez reprojekcji w czasie i nie ma artefaktów przestrzeni ekranu. Na przeszkodzie stoją wydajność i sprzętowy ray tracing, bo utrzymywanie jego struktury akceleracji (cząsteczki, animowane siatki) mocno ograniczałoby grę.
• Lustrzane odbicia z ray tracingiem są według Alexa banalne: demo napisał w ok. 40 minut. Za kilka lat staną się standardem; już teraz widać „syndrom mokrego asfaltu”. Prawdziwie trudne jest światło rozproszone, a ray tracing go nie rozwiązuje.
• Nowy kierunek to śledzenie samych sond zamiast geometrii (cone tracing), bez ray tracingu. Pierwsze wyniki zbliżają się do wersji z ray tracingiem. Na pytanie, kiedy trafi to do gry, Alex odpowiedział: gdy uda się pozbyć sprzętowego ray tracingu. Poza tym technika jest prawie gotowa do produkcji.
• Wokół techniki powstała społeczność na Discordzie licząca tysiące entuzjastów grafiki. Razem wydali kilka prac naukowych, w tym ulepszoną wersję 2D, wersję 3D, oświetlenie wolumetryczne, a nawet pracę w czasopiśmie astrofizycznym, bo propagacja promieniowania gwiazd to ten sam proces co widzenie. Alex podziękował streamerowi PoE 2, który wyjaśnił to swoim widzom.
• Radiance Cascades używa już kilka gier na Steamie, m.in. Core Keeper. Społeczność stosuje je też do równania ciepła, wyszukiwania ścieżek czy symulacji grawitacji. Według Alexa w społeczności krąży mem: każdy błąd w implementacji daje fraktal. Do rozwiązania zostały m.in. jednopikselowe światła i osiągnięcie teoretycznej wydajności w praktyce.

Q&A

• Jak nie psuć gry, dodając funkcje? Mały zespół (sześć osób) i mało kodu: zamiast dopisywać, dopracowuje się istniejący, żeby był szybszy i łatwiejszy w debugowaniu.
• Wersja na Maca? W drodze, „prawie gotowa”, potrzebuje jeszcze trochę czasu.
• Nowsze FSR? Alexowi nie podoba się, że nowsze wersje FSR są zamknięte i wymagają wektorów ruchu. Gra obsługuje DLSS, który zwykle wygląda lepiej, a konsole mają własne skalowanie.
• Funkcje z innych silników? Jeśli coś jest ciekawe, zespół po prostu to implementuje, „to nasza praca”.
• Złożoność geometrii? Wersja w przestrzeni ekranu nie zależy od sceny (korzysta z bufora głębi). Celem dla wersji bez ray tracingu jest koszt zależny tylko od rozmiaru sceny w wokselach, a nie od liczby wielokątów.
• Wpływ generowania proceduralnego? Duży: cutout nie byłby potrzebny w grze bez proceduralnych poziomów, a takie potrzeby rozszerzają możliwości silnika.
• Czemu nie ma motion bluru? Zmniejsza czytelność. Artyści VFX mają smugi ruchu, ale używają ich ostrożnie, a rozmycia przy ruchu postaci nie będzie.
• Konsole i PC? Warstwa abstrakcji obejmuje wszystkie platformy, więc prawie cały kod silnika pisze się raz. Różni się tylko backend.
• Ile silnika jest wspólne? Całość. Zmiana pod ligę PoE 1 musi być sprawdzona pod kątem PoE 2 i odwrotnie, ale kod jest na tyle ogólny, że zwykle nie stanowi to problemu.

Relacja KaruiPolska przygotowana na podstawie transmisji ExileCon 2026 (segment: The Engine of Path of Exile, 22:30–23:20 czasu polskiego). Część nazw własnych (streamer, gry i prace naukowe) była w transkrypcji niewyraźna, więc podajemy je ogólnie.