Oświetlenie wypalane czy dynamiczne? Wybór dla gry indie

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.

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 lamp, materiałów lub ustawień bake’u może wymusić ponowne przeliczenie danych.

Zmiana „drobnego” elementu może uruchomić dużą pracę

Najbardziej uciążliwe nie są zwykle wielkie przebudowy poziomu, lecz seria pozornie niewinnych poprawek. Artysta przesuwa okno o metr, projektant dodaje skrzynię blokującą światło, ktoś zmienia kolor ściany, a programista chce mocniejszy kontrast w jednym korytarzu. Każda z tych zmian może wpłynąć na wynik bake’u i wymagać sprawdzenia sceny ponownie.

Problem rośnie, gdy zespół traktuje oświetlenie jak ostatnią warstwę dekoracyjną. Jeśli układ pomieszczeń, materiały i obiekty interaktywne nadal często się zmieniają, finalne wypalanie wysokiej jakości jest przedwczesne. Twórcy tracą wtedy czas na czekanie na przeliczenia, a później podejmują złe decyzje projektowe tylko dlatego, że „nie chcą już uruchamiać bake’u jeszcze raz”.

Dobrym rozwiązaniem jest praca w dwóch trybach. Podczas prototypowania używaj szybkiego bake’u o niższej jakości albo uproszczonego podglądu światła. Pełne ustawienia, wysoką liczbę próbek i docelową rozdzielczość lightmap zostaw na etap, w którym geometria poziomu jest względnie stabilna. Dzięki temu poprawki nie zamieniają się w wielogodzinne przestoje.

Lightmapy mogą stać się problemem pamięci

Wypalone światło zmniejsza koszt obliczeń w trakcie gry, ale dane oświetlenia trzeba gdzieś przechować. Duże tekstury lightmap zajmują pamięć dysku, pamięć RAM i pamięć GPU. Na pojedynczej małej planszy nie musi to mieć znaczenia. W grze z wieloma wnętrzami, wysoką rozdzielczością tekstur i dużą liczbą unikalnych obiektów rozmiar danych może jednak szybko wzrosnąć.

Szczególnie niebezpieczne jest ustawianie wysokiej gęstości texeli dla całej sceny. Twórca widzi lekko rozmyty cień na jednej ważnej ścianie, podnosi jakość globalnie i nagle generuje kilka razy większe lightmapy. Tymczasem problem mógł dotyczyć tylko jednego fragmentu poziomu albo źle przygotowanego UV.

Objawami są dłuższe ładowanie lokacji, nagłe zużycie pamięci na słabszych urządzeniach, zbyt duże paczki instalacyjne albo agresywne doczytywanie tekstur. W projektach mobilnych i na konsolach przenośnych taki koszt może być równie istotny jak czas renderowania klatki.

Zamiast podnosić jakość wszędzie, lepiej kontrolować ją lokalnie:

• Ustal różną gęstość lightmap dla elementów ważnych wizualnie i dla tła.
• Nie przydzielaj dużych fragmentów lightmap drobnym dekoracjom, których gracz ogląda z daleka.
• Dziel poziomy na logiczne części, aby dane oświetlenia nie musiały być stale obecne dla całej mapy.
• Sprawdzaj rozmiar wygenerowanych plików po każdym większym zwiększeniu jakości.
• Testuj scenę po kompresji, ponieważ artefakty mogą być widoczne dopiero w docelowym buildzie.

Źle przygotowane UV psuje nawet dobry bake

Oświetlenie wypalane wymaga odpowiednio przygotowanych współrzędnych UV dla lightmap. Jeżeli wyspy UV nachodzą na siebie, są zbyt małe, mają za mały odstęp albo są ułożone nieefektywnie, wynik może zawierać plamy, szwy, przecieki światła i nierówne cienie. ^[3]

Typowy przykład to ciemna ściana przy jasnej podłodze. Po bake’u w narożniku pojawia się jasna linia, mimo że w scenie nie ma żadnego źródła światła. Czasem winne są ustawienia próbek lub filtracji, ale równie często problem wynika z UV, zbyt małego marginesu między wyspami albo niedokładnej geometrii.

Nie należy maskować takich błędów dodatkowymi lampami. To często pogarsza czytelność sceny i zwiększa liczbę wyjątków w ustawieniach. Lepiej najpierw sprawdzić geometrię, normalne, UV dla lightmap oraz skalę obiektów. Jeden poprawnie przygotowany moduł ściany jest cenniejszy niż dziesięć ręcznych poprawek dla każdej kolejnej komnaty.

Wypalone światło nie zareaguje samo na zmianę stanu gry

Stały cień wygląda przekonująco tylko tak długo, jak długo świat zachowuje się zgodnie z założeniami bake’u. Jeśli gracz zniszczy lampę, przesunie dużą przeszkodę albo otworzy przejście, wcześniej zapisane oświetlenie nie dostosuje się automatycznie. W rezultacie można zobaczyć jasne odbicie po nieistniejącej lampie albo cień obiektu, który został już usunięty.

Nie oznacza to, że każda interakcja wyklucza lightmapy. Trzeba tylko projektować takie sytuacje świadomie. Zniszczalna lampa może być dynamiczna, podczas gdy reszta oświetlenia pomieszczenia pozostaje stała. Drzwi mogą otwierać się w miejscu, gdzie zmiana światła nie wpływa istotnie na odbiór sceny. Można też przygotować dwa warianty wizualne pomieszczenia, jeśli dana zmiana jest rzadka i fabularnie ważna.

Najgorszym rozwiązaniem jest obiecanie mechaniki opartej na świetle, a następnie ograniczenie jej dlatego, że dekoracyjne cienie nie mogą się zmienić. Technologia powinna wspierać projekt poziomu, a nie wymuszać nielogiczne reguły świata.

Błąd nr 3 — projektowanie światła bez związku z rozgrywką i kamerą

Ładne światło nie zawsze jest czytelnym światłem

Oświetlenie może budować klimat, ale jego podstawowym zadaniem w grze jest także przekazywanie informacji. Gracz musi szybko rozpoznać ścieżkę, zagrożenie, przedmiot interaktywny, granicę przestrzeni i pozycję własnej postaci. Scena, która wygląda efektownie na nieruchomym screenie, może być męcząca podczas ruchu.

Przykładowo: ciemny korytarz z pojedynczymi jasnymi plamami może tworzyć napięcie w grze horrorowej. Jeśli jednak przeciwnik, pułapka i przedmiot potrzebny do postępu mają podobny kolor oraz jasność co tło, gracz nie odczuje napięcia. Prawdopodobnie uzna, że gra ukrywa przed nim informacje w nieuczciwy sposób.

Rozpoznasz ten problem podczas testów bez komentarza. Jeśli nowe osoby pytają, gdzie mają iść, nie widzą drabiny albo regularnie wpadają na elementy otoczenia, przyczyną nie musi być zły level design. Często winne są zbyt niskie kontrasty, nadmiar wizualnego hałasu lub światło skierowane na niewłaściwe elementy.

Kamera zmienia zasady kompozycji

Światło należy oceniać z perspektywy kamery gracza, a nie z widoku swobodnego w edytorze. W grze izometrycznej górne powierzchnie, ściany i podłoga mogą zajmować kadr w zupełnie innych proporcjach niż w grze FPP. W platformówce kamera boczna wymaga czytelnego oddzielenia postaci od tła, natomiast w grze TPP ważne jest, aby silny kontrast nie zasłaniał sylwetki bohatera.

Częsty błąd pojawia się wtedy, gdy autor ustawia dramatyczne światło pod atrakcyjnym kątem, ale kamera prawie nigdy go nie pokazuje. Promień wpadający przez okno może świetnie wyglądać w podglądzie sceny, lecz z właściwego kadru być zasłonięty przez meble albo wypadać poza ekran. W takiej sytuacji kosztowny efekt nie wzmacnia ani nastroju, ani orientacji.

Lepsza metoda jest prosta: przechodź poziom tak, jak przejdzie go gracz. Zatrzymuj kamerę w typowych miejscach, przy szybkich zwrotach, podczas walki i w momentach interakcji. Sprawdzaj, czy bohater odcina się od tła, czy cel jest widoczny oraz czy jasne obszary prowadzą wzrok tam, gdzie powinny.

Nie używaj ciemności jako zamiennika napięcia

Obniżenie ekspozycji całej sceny jest szybkim sposobem na uzyskanie nastroju, ale rzadko rozwiązuje problem projektu. Gdy wszystko jest równie ciemne, gracz nie wie, co jest tajemnicą, co przeszkodą, a co po prostu słabo widoczną teksturą. Dotyczy to zwłaszcza ekranów o słabszej jasności, grania w dzień oraz monitorów z odmiennymi ustawieniami gamma.

Zamiast zaciemniać wszystko, buduj hierarchię. Tło może pozostać stonowane, ścieżka otrzymać subtelne światło prowadzące, a ważny przedmiot wyraźniejszy kontrast lub odmienną temperaturę barwową. Ciepłe światło pochodni przy chłodnym otoczeniu może wskazywać bezpieczne miejsce bez używania strzałek i migających znaczników.

Jeśli gra celowo ogranicza widoczność, daj graczowi narzędzia do odczytania sytuacji: kontur interaktywnych obiektów, dźwięk kierunkowy, krótkie rozbłyski, mapę, tryb skupienia albo źródło światła kontrolowane przez użytkownika. Nie odbiera to klimatu. Pozwala odróżnić świadome napięcie od frustracji.

Efekty świetlne powinny mieć znaczenie

Dynamiczny błysk, migotanie lampy czy zmiana koloru światła są najbardziej skuteczne wtedy, gdy komunikują stan świata. Migająca lampa może zapowiadać awarię, czerwone światło — alarm, a nagłe zgaśnięcie — pojawienie się zagrożenia. Jeżeli podobne efekty występują bez przerwy i bez znaczenia, przestają być zauważalne.

To ważne również dla komfortu. Zbyt intensywne stroboskopy, gwałtowne zmiany ekspozycji i częste błyski mogą męczyć wzrok, a dla części odbiorców stanowić realny problem dostępności. Dobrą praktyką jest przygotowanie opcji ograniczenia błysków, zmniejszenia intensywności efektów oraz wyłączenia agresywnych zmian obrazu.

Krótki test sceny przed zatwierdzeniem oświetlenia

• Czy gracz widzi swoją postać i najważniejszy cel z typowej pozycji kamery?
• Czy wejścia, krawędzie, przeszkody i interaktywne obiekty odróżniają się od tła?
• Czy ciemność tworzy zamierzone napięcie, a nie ukrywa informacji potrzebnych do działania?
• Czy jasne miejsca kierują wzrok świadomie, zamiast przypadkowo przyciągać uwagę dekoracją?
• Czy zmiany światła informują o stanie gry lub wspierają atmosferę, a nie są wyłącznie efektem?
• Czy scena pozostaje czytelna na docelowym ekranie, przy różnych ustawieniach jasności?
• Czy po zmianie lampy, geometrii lub materiału wiadomo, jakie dane bake’u trzeba przeliczyć?
• Czy rozmiar lightmap i czas ich generowania mieszczą się w realnym planie produkcji?

Źródła

• [1] Android Developers – Lighting for mobile games with Unity ↑
• [2] Unity Technologies – Lighting strategy – Unity Manual ↑
• [3] Unity Technologies – Optimizing lighting for a healthy frame rate ↑
• [4] Epic Games – Global Illumination in Unreal Engine ↑