Nie zaczynaj od pytania „które oświetlenie jest lepsze?”
Dwa podejścia, dwa zestawy kompromisów
Wybór między oświetleniem wypalanym a dynamicznym nie jest konkursem, w którym jedno rozwiązanie zawsze wygrywa. To decyzja o tym, co w świecie gry ma się zmieniać, jak często i jaką cenę projekt jest w stanie za to zapłacić: w wydajności, czasie produkcji, pamięci urządzenia oraz swobodzie późniejszych poprawek. [2]
Oświetlenie wypalane, nazywane też baked lighting, polega na wcześniejszym obliczeniu światła i cieni. Wynik zostaje zapisany zwykle w lightmapach, czyli teksturach zawierających informacje o oświetleniu powierzchni, czasem w kolorach wierzchołków albo danych przypisanych do obiektów sceny. W czasie gry silnik nie musi od nowa liczyć pełnego wpływu każdego światła na każdą ścianę. Dzięki temu można uzyskać ładne miękkie cienie, odbicia światła między powierzchniami i przyjemną atmosferę przy relatywnie niskim koszcie renderowania. [1]
Oświetlenie dynamiczne w grze jest liczone w czasie rzeczywistym. Lampa może zostać zniszczona, słońce przesuwa się po niebie, gracz włącza latarkę, eksplozja na moment rozjaśnia korytarz, a przeciwnik rzuca cień na ścianę. Taka elastyczność jest bardzo cenna, ale każda zmiana wymaga pracy GPU i często CPU. Im więcej świateł, cieni, przezroczystości, cząsteczek oraz post-processingu, tym trudniej utrzymać stabilną wydajność gry 3D.
W praktyce wiele niezależnych projektów korzysta z modelu pośredniego. Hybrydowe oświetlenie gry pozwala wypalić światło na nieruchomych ścianach, podłogach i dekoracjach, a jednocześnie zostawić dynamiczne źródła dla bohatera, interaktywnych obiektów oraz efektów specjalnych. Jest to podobne do przygotowania scenografii teatralnej: dekoracje dostają precyzyjnie ustawione światło, lecz aktor nadal może wejść z lampą, pochodnią albo błyskawicą.
Pierwszy błąd: wybór technologii przed określeniem potrzeb gry
Najbardziej kosztowna pomyłka nie polega na użyciu złej opcji w Unity czy Unreal Engine. Polega na wybraniu technologii dlatego, że wygląda efektownie w krótkim demie lub pasuje do aktualnej mody. Dynamiczny cykl dnia i nocy może robić wrażenie na zwiastunie, ale nie poprawi gry, której akcja przez całość toczy się w zamkniętej krypcie. Z kolei pięknie wypalone wnętrze nie spełni oczekiwań, jeśli podstawową mechaniką jest gaszenie świateł i obserwowanie zachowania przeciwników w ciemności.
Zanim powstanie pierwszy komplet lightmap, dobrze jest odpowiedzieć sobie na kilka pytań: Czy światło zmienia reguły gry? Czy gracz ma możliwość niszczenia lamp, otwierania okien, zapalania ognia albo manipulowania porą dnia? Czy poziomy są jednorazowo skomponowanymi przestrzeniami, czy powstają proceduralnie? Czy kamera pokazuje mały fragment wnętrza, czy ogromny otwarty krajobraz? Te odpowiedzi mówią więcej niż sama lista funkcji silnika.
Gra eksploracyjna z pełnym cyklem dnia i nocy ma inne wymagania niż izometryczna gra logiczna składająca się z kilkunastu ręcznie zaprojektowanych komnat. W pierwszym przypadku dynamic lighting może być fundamentem nastroju i mechaniki. W drugim stałe, wypalane światło pozwoli dopracować kompozycję każdego kadru, zaoszczędzić klatki na animacje i ograniczyć ryzyko problemów technicznych.
Krótka mapa decyzji przed rozpoczęciem produkcji
Jeżeli większość odpowiedzi brzmi „nic istotnego w świetle się nie zmienia”, oświetlenie wypalane powinno być punktem wyjścia. Jeżeli światło zmienia się często, wpływa na zagrożenia albo stanowi narzędzie gracza, system dynamiczny staje się bardziej uzasadniony. Nie oznacza to jednak, że każdy obiekt musi być oświetlany i cieniowany w czasie rzeczywistym.
| Cecha projektu | Rozwiązanie zwykle korzystniejsze | Praktyczne uzasadnienie |
|---|---|---|
| Ręcznie przygotowane wnętrza | Oświetlenie wypalane lub hybrydowe | Łatwiej kontrolować klimat, jakość cieni i koszt renderowania. |
| Cykl dnia i nocy wpływający na grę | Oświetlenie dynamiczne lub hybrydowe | Zmiana kierunku, barwy i intensywności światła musi być widoczna w czasie rzeczywistym. |
| Gra na telefonach lub słabszych komputerach | Głównie baked lighting | Zmniejsza obciążenie GPU podczas rozgrywki. |
| Dużo ruchomych lamp, eksplozji i zniszczeń | Dynamiczne światła punktowe z restrykcyjnym budżetem | Interakcje wymagają reakcji obrazu, ale nie każde światło musi rzucać cień. |
| Proceduralnie generowane poziomy | Dynamiczne światło, vertex lighting lub bake w etapach | Stałe lightmapy dla każdej możliwej konfiguracji mogą być niepraktyczne. |
Nieruchoma krypta w grze przygodowej nie potrzebuje kosztownego systemu dynamicznego słońca tylko dlatego, że taki system dobrze wygląda na materiałach promocyjnych. Znacznie lepiej przeznaczyć dostępny budżet na czytelne pochodnie, delikatną mgłę, światło wpadające przez szczeliny i jeden dynamiczny błysk podczas ważnej interakcji.
Błąd nr 1 — ignorowanie wydajności docelowego sprzętu
Dlaczego dynamiczne światło potrafi szybko zjadać budżet klatek
Dynamiczne światło nie ma jednego stałego kosztu. Jego obciążenie zależy od typu renderera, rozdzielczości ekranu, liczby obiektów w zasięgu, materiałów, jakości cieni, liczby pikseli objętych światłem i ustawień post-processingu. Dlatego scena z trzema dynamicznymi lampami może działać znakomicie w małym pokoju, a ten sam zestaw świateł może powodować spadki płynności w szerokim hallu z odbiciami, cząsteczkami i półprzezroczystą mgłą.
Najdroższe bywają zwykle światła rzucające cienie w czasie rzeczywistym. Silnik musi stworzyć dodatkowe dane opisujące widok sceny z perspektywy źródła światła, a następnie wykorzystać je podczas renderowania obrazu. W przypadku światła kierunkowego, takiego jak słońce, koszt rośnie wraz z zakresem widocznej przestrzeni. Przy lampach punktowych i reflektorach problemem staje się duża liczba nakładających się stożków lub kul światła.
Trudność narasta, gdy twórca dokłada efekt po efekcie. Dynamiczne cienie, wolumetryczna mgła, rozbłyski, screen space reflections, miękkie cząsteczki, mokre materiały i animowane neony potrafią stworzyć atrakcyjny obraz. Jednak GPU nie ocenia, czy scena ma klimat; wykonuje kolejne operacje. Gra indie nie musi rezygnować z efektów, ale powinna zdecydować, które z nich naprawdę budują doświadczenie, a które są tylko dekoracją widoczną przez kilka sekund.
Jak rozpoznać problem zanim będzie za późno
Testowanie wyłącznie na komputerze używanym do tworzenia gry daje fałszywe poczucie bezpieczeństwa. Stacja robocza może bez wysiłku obsłużyć scenę, która na słabszym laptopie, Steam Decku, konsoli przenośnej albo telefonie zacznie gubić płynność. Szczególnie zdradliwe są poziomy, które w edytorze wyglądają prosto, ale po dodaniu pełnego HUD-u, efektów walki, dźwięku przestrzennego i systemów AI przestają mieścić się w budżecie klatek.
Niepokojącym sygnałem są spadki wydajności po obrocie kamery, wejściu do nowego pomieszczenia albo rozpoczęciu walki. Równie ważne są nierówne czasy klatek. Gra może chwilowo pokazywać wysoki licznik FPS, ale krótkie przycięcia podczas ładowania cieni lub aktywowania światła gracza będą wyraźnie odczuwalne. W dynamicznej grze akcji pojedyncze szarpnięcie obrazu potrafi wyglądać jak utrata kontroli.
Sam licznik FPS nie wystarczy. Potrzebny jest profiler renderowania, który pokaże koszt świateł, cieni, draw calli, przezroczystości i post-processingu. W Unity przydadzą się między innymi Frame Debugger oraz Profiler, a w Unreal Engine narzędzia takie jak GPU Visualizer i statystyki renderowania. Nie chodzi o obsesyjne analizowanie każdej milisekundy od pierwszego dnia. Chodzi o to, aby nie zgadywać, co jest problemem, gdy scena zaczyna działać zbyt wolno. [4]
Lepsze rozwiązania niż „wyłączmy połowę świateł”
Chaotyczne wycinanie efektów pod koniec produkcji zwykle kończy się pogorszeniem wyglądu bez odzyskania wystarczającej wydajności. Skuteczniejsze jest stworzenie prostego budżetu. Trzeba ustalić, ile świateł z cieniami może jednocześnie pojawić się w kadrze, jak daleko mogą sięgać oraz które obiekty faktycznie muszą przyjmować ich cień.
- Ogranicz zasięg światła, zamiast oświetlać nim całe pomieszczenie „na wszelki wypadek”.
- Wyłącz cienie dla świateł drugoplanowych, na przykład lamp dekoracyjnych i drobnych efektów magicznych.
- Stosuj warstwy renderowania, aby światło latarki nie obliczało wpływu na elementy, których gracz nigdy nie zauważy.
- Używaj cullingu, dzięki któremu światła poza kadrem lub za zamkniętymi drzwiami nie obciążają sceny bez potrzeby.
- Przygotuj uproszczone warianty jakości dla słabszego sprzętu, zwłaszcza dla cieni, zasięgu świateł i efektów wolumetrycznych.
Dobry układ hybrydowy często wygląda tak: ściany i meble korzystają z bake’u, postać gracza otrzymuje światło z probe’ów, a latarka, pociski i interaktywne lampy są dynamiczne. W rezultacie scena zachowuje reakcję na działanie gracza, ale nie zmusza sprzętu do liczenia pełnego oświetlenia całej mapy w każdej klatce.
Najcięższa scena powinna powstać wcześnie
Nie testuj tylko pustego korytarza z jedną lampą. Przygotuj fragment reprezentujący najtrudniejszy przypadek: maksymalną liczbę przeciwników, cząsteczki, źródła światła, złożone materiały, mgłę i pełny interfejs. Taka scena jest jak próbny most obciążony ciężarówką, zanim dopuści się go do ruchu. Jeśli wytrzyma wcześnie, późniejsze decyzje będą znacznie spokojniejsze.
Wydajność należy mierzyć na docelowej rozdzielczości oraz urządzeniach zbliżonych do minimalnej konfiguracji. Gra projektowana na monitorze 1440p, ale uruchamiana później w 4K, może wymagać zupełnie innego budżetu pikseli. Analogicznie, tytuł mobilny testowany wyłącznie na nowym telefonie nie powie nic o zachowaniu na popularnych urządzeniach ze średniej półki.
Błąd nr 2 — traktowanie oświetlenia wypalanego jako rozwiązania bez ograniczeń
Co naprawdę kosztuje bake
Oświetlenie wypalane w grach przenosi dużą część kosztu z czasu działania gry do etapu produkcji i przygotowania zasobów. To korzystne, ale nie darmowe. Generowanie lightmap może trwać długo, szczególnie przy wysokiej jakości, dużych scenach oraz rozbudowanym global illumination. Każda większa zmiana geometrii, położenia