Błąd Lumen Reflections w Unreal Engine 5.8: Naprawa cichego fallbacku do Screen-Space

Cichy fallback: Dlaczego odbicia przestały działać w UE 5.8

Aktualizacja do Unreal Engine 5.8 miała być standardowym krokiem w pipeline, ale inżynierowie grafiki zauważają, że ich błyszczące materiały metaliczne wyglądają płasko i mętnie. Powierzchnie, które wcześniej wyświetlały ostre detale ray-traced, teraz powracają do rozmytych odbić screen-space (SSR), gdy tylko odbijany obiekt znika z ekranu. Ta cicha degradacja renderowania jest spowodowana przez unreal engine 5.8 lumen reflections bug, w którym silnik nie generuje odbić, chyba że Lumen Global Illumination (GI) jest w pełni aktywny. W przypadku gier opierających się na baked lighting lub alternatywnych rozwiązaniach GI, wymusza to wybór między ogromnym narzutem na GPU a zniszczoną jakością oprawy wizualnej.

Główny problem wynika z tego, jak Unreal Engine 5.8 inicjalizuje swój rendering pipeline. We wcześniejszych wersjach deweloperzy mogli wyłączyć Lumen Global Illumination w celu zaoszczędzenia zasobów GPU, zachowując jednocześnie aktywną funkcję Lumen Reflections, aby utrzymać wysokiej jakości specular highlights na metalu i szkle. Ten autonomiczny tryb odbić (standalone reflections) jest podstawą w przypadku sprzętu średniej klasy oraz profili optymalizacyjnych, w których indirect lighting jest wypiekane w lightmapach. Jednak w UE 5.8 wyłączenie Lumen GI po cichu dezaktywuje całą reprezentację Lumen Scene, co powoduje natychmiastowy fallback odbić do metod screen-space bez żadnych ostrzeżeń czy błędów w logach.

Ta regresja jest szczególnie dotkliwa dla wydań wieloplatformowych. Gra zoptymalizowana pod kątem stabilnych 60 FPS na konsolach może stracić cały swój budżet wydajnościowy GPU, jeśli deweloperzy zostaną zmuszeni do ponownego włączenia Lumen GI tylko po to, by ich błyszczące materiały wyglądały prawidłowo. Zrozumienie, dlaczego dochodzi do tego fallbacku i jak go załatać, jest kluczowe dla każdego, kto wydaje lub aktualizuje projekt w Unreal Engine w 2026 roku.

Zrozumienie architektury: Lumen Reflections vs. Global Illumination

Aby zrozumieć, dlaczego ten błąd występuje, należy przyjrzeć się temu, jak Lumen generuje odbicia i indirect lighting pod maską. Lumen nie wykonuje testów ray tracingu bezpośrednio na statycznych siatkach (static meshes) o pełnej szczegółowości na poziomie, ponieważ byłoby to zbyt kosztowne obliczeniowo dla aplikacji działających w czasie rzeczywistym. Zamiast tego buduje uproszczoną reprezentację sceny o nazwie Lumen Scene, która składa się z niskorozdzielczych struktur wokselowych oraz dwuwymiarowych kart (2D cards) zawierających atrybuty powierzchni, takie jak base color, roughness i opacity. Ten zbiór danych jest znany jako Surface Cache.

W prawidłowym stanie silnika Surface Cache jest aktualizowany w sposób ciągły, gdy kamera porusza się w otoczeniu. Kiedy odbijająca powierzchnia wymaga ray-trace'a, silnik wysyła promienie do tej Lumen Scene, aby określić, jakie obiekty są widoczne i jakie światło emitują. Taka architektura pozwala przebiegowi odbić (reflection pass) na ewaluację złożonych, błyszczących odbić przy ułamku kosztów pełnego path tracingu. Co kluczowe, Lumen Scene i jej Surface Cache mogą być inicjalizowane niezależnie od tego, czy silnik używa technologii Lumen do obliczania globalnego indirect lighting.

Gdy uruchomisz standardowy profil wydajnościowy na nowoczesnej konsoli, takiej jak PlayStation 5, podział kosztów wydajnościowych wyraźnie pokazuje, dlaczego rozdzielenie tych funkcji jest niezbędne:

• Lumen GI + Lumen Reflections: Obliczanie indirect lighting dla całej sceny, aktualizowanie Surface Cache i śledzenie błyszczących odbić zajmuje około 6,5 ms czasu ramki GPU w rozdzielczości 1440p.
• Standalone Lumen Reflections: Śledzenie odbić względem Surface Cache przy użyciu baked lightmaps dla GI zajmuje tylko 1,8 ms czasu ramki GPU.
• Screen-Space Reflections (SSR): Śledzenie odbić przy użyciu wyłącznie bufora ekranu (screen buffer) zajmuje 0,5 ms czasu ramki GPU, ale cierpi na poważne ucinanie obrazu (clipping) na krawędziach viewportu.

Poprzez wymuszenie fallbacku do SSR, silnik pozbawia nas efektu paralaksy oraz możliwości generowania odbić obiektów spoza ekranu (off-screen reflections), które sprawiają, że współczesne sceny wyglądają realistycznie. I odwrotnie, zmuszanie deweloperów do włączenia Lumen GI w celu odzyskania tych odbić nakłada ogromny narzut rzędu 4,7 ms na budżet ramki GPU. To dodatkowe opóźnienie jest niedopuszczalne w przypadku dynamicznych gier rywalizacyjnych lub gier akcji celujących w wysokie liczby klatek na sekundę.

Diagnozowanie błędu Lumen Reflections w Unreal Engine 5.8

Wykrycie tego błędu podczas produkcji wymaga wyjścia poza domyślne zachowanie viewportu w Unreal Editor, które czasami może maskować problem z powodu ścieżek renderowania przeznaczonych wyłącznie dla edytora (editor-only rendering paths). Błąd objawia się szczególnie wtedy, gdy włączony jest Hardware Ray Tracing (HWRT), ale metoda dynamicznego globalnego oświetlenia (dynamic global illumination method) jest wyłączona. Aby potwierdzić, czy ten problem dotyczy Twojego projektu, musisz odtworzyć dokładnie takie same ustawienia konfiguracyjne, w których dochodzi do fallbacku.

Zacznij od sprawdzenia konfiguracji renderowania swojego projektu. W Project Settings > Engine > Rendering przejdź do sekcji Global Illumination i ustaw Dynamic Global Illumination Method na None (lub na inną metodę niekorzystającą z technologii Lumen, np. Screen Space). Następnie przejdź do sekcji Reflections i ustaw Reflection Method na Lumen. W sekcji Hardware Ray Tracing upewnij się, że opcje Support Hardware Ray Tracing oraz Use Hardware Ray Tracing When Available są ustawione na true.

+-------------------------------------------------------------------+
| Project Settings -> Engine -> Rendering                           |
+-------------------------------------------------------------------+
| Dynamic Global Illumination Method:  [ None / Screen Space ]      |
| Reflection Method:                   [ Lumen ]                    |
| Support Hardware Ray Tracing:        [ True ]                     |
| Use Hardware Ray Tracing:            [ True ]                     |
+-------------------------------------------------------------------+

Po zastosowaniu tych ustawień uruchom swoją scenę w instancji standalone gry lub w aktywnym oknie PIE. Uruchom polecenie konsoli r.Lumen.Visualize.CardPlacement 1, aby zbadać Lumen Scene. W Unreal Engine 5.8 zobaczysz całkowicie pusty ekran, co potwierdza, że Surface Cache jest nieaktywny. Oznacza to, że silnik wyłączył card update pipeline, zmuszając odbicia do fallbacku do screen-space reflections.

Sprofiluj scenę za pomocą narzędzia Unreal Insights lub standardowego polecenia konsoli stat GPU. Zobaczysz, że LumenReflections znika z przebiegu profilowania (profile pass), a w jego miejsce pojawia się wyłącznie ScreenSpaceReflections, co zajmuje około ~0,4 ms do ~0,8 ms w zależności od pokrycia ekranu.

Rozwiązania programistyczne: Wykrywanie i naprawianie fallbacku w C++

W oczekiwaniu na oficjalny hotfix możesz programowo wykryć ten stan po stronie klienta i wymusić niezbędne konfiguracje silnika. Zapobiegnie to wpływowi tej cichej degradacji na graczy na systemach wspierających sprzętowy ray tracing. Poniżej znajduje się implementacja komponentu aktora (actor component) w C++, która odpytuje menedżera konsoli, sprawdza bieżącą konfigurację renderowania i dynamicznie rozwiązuje ten konflikt.

#include "CoreMinimal.h"
#include "Components/ActorComponent.h"
#include "HAL/IConsoleManager.h"
#include "Engine/World.h"
#include "LumenReflectionsChecker.generated.h"

UCLASS(ClassGroup=(Custom), meta=(BlueprintSpawnableComponent))
class MYGAME_API ULumenReflectionsChecker : public UActorComponent

{
    GENERATED_BODY()

public:
    ULumenReflectionsChecker();

protected:
    virtual void BeginPlay() override;

private:
    void ValidateLumenConfiguration();
};

ULumenReflectionsChecker::ULumenReflectionsChecker()
{
    PrimaryComponentTick.bCanEverTick = false;
}

void ULumenReflectionsChecker::BeginPlay()
{
    Super::BeginPlay();
    ValidateLumenConfiguration();
}

void ULumenReflectionsChecker::ValidateLumenConfiguration()
{
    // Retrieve critical engine console variables for Lumen setup
    IConsoleVariable* GiMethodVar = IConsoleManager::Get().FindConsoleVariable(TEXT("r.DynamicGlobalIlluminationMethod"));
    IConsoleVariable* ReflectionMethodVar = IConsoleManager::Get().FindConsoleVariable(TEXT("r.ReflectionMethod"));
    IConsoleVariable* ForceLumenSceneVar = IConsoleManager::Get().FindConsoleVariable(TEXT("r.Lumen.ForceLumenScene"));

    if (GiMethodVar && ReflectionMethodVar)
    { 
        int32 GiMethod = GiMethodVar->GetInt();
        int32 ReflectionMethod = ReflectionMethodVar->GetInt();

        // In UE 5.8, if GI is 0 (None) and Reflection is 1 (Lumen), reflections fall back to SSR.
        if (GiMethod == 0 && ReflectionMethod == 1)
        { 
            UE_LOG(LogTemp, Warning, TEXT("[LumenChecker] Warning: Lumen GI is disabled, but Lumen Reflections are active. UE 5.8 forces SSR fallback in this state."));

            if (ForceLumenSceneVar)
            {
                // Mitigate the fallback by forcing the Lumen Scene to update
                ForceLumenSceneVar->Set(1, ECVF_SetByCode);
                UE_LOG(LogTemp, Log, TEXT("[LumenChecker] Applied CVar workaround: r.Lumen.ForceLumenScene set to 1."));
            }
        }
    }
}

Ten komponent można dołączyć do głównego stanu gry (game state) lub aktora inicjalizacyjnego (initialization actor). Po uruchomieniu gry skrypt sprawdza, czy ustawienia projektu odpowiadają wadliwej konfiguracji. Jeśli tak, programowo ustawia on r.Lumen.ForceLumenScene na 1. Instruuje to renderer, aby utrzymywał Surface Cache, mimo że system globalnego oświetlenia go nie żąda, dzięki czemu Twoje odbicia pozostają w pełni operacyjne.

Ręczne obejścia i poprawki w kodzie źródłowym silnika

Dla deweloperów, którzy nie chcą wykonywać skryptów C++ w runtime w celu modyfikacji zmiennych konsolowych, istnieją dwie główne metody rozwiązania problemu fallbacku: bezpośrednia modyfikacja plików konfiguracyjnych lub załatanie kodu źródłowego silnika. Oba podejścia są odpowiednie w zależności od tego, czy używasz wersji Unreal Engine z launchera, czy też własnej kompilacji ze źródła.

Obejście 1: Nadpisanie konfiguracji za pomocą zmiennych konsolowych

Jeśli używasz wersji Unreal Engine 5.8 z Epic Games Launcher, nie możesz bezpośrednio modyfikować kodu silnika. Zamiast tego musisz wymusić na silniku utrzymanie Lumen Scene przy użyciu plików konfiguracyjnych. Otwórz katalog swojego projektu i przejdź do Config/DefaultEngine.ini.

W sekcji [/Script/Engine.RendererSettings] dodaj następujące linie:

r.DynamicGlobalIlluminationMethod=0
r.ReflectionMethod=1
r.Lumen.ForceLumenScene=1.Lumen.Reflections.AllowWithoutGI=1

Ustawienie r.Lumen.ForceLumenScene na 1 nadpisuje przebieg optymalizacyjny (optimization pass) rendering pipeline, który oznacza Lumen Scene jako nieużywaną, gdy GI jest wyłączone. Wymusza to na silniku alokację niezbędnej pamięci GPU i przebiegów obliczeniowych (compute passes) w celu zbudowania i aktualizacji kart Surface Cache. Chociaż przywraca to odbicia, należy pamiętać, że nieznacznie zwiększy to koszt GPU base pass w porównaniu do UE 5.7, ponieważ silnik wykonuje teraz te aktualizacje bez kontekstu optymalizacyjnego, który posiadał w poprzednich wersjach.

Obejście 2: Modyfikacja kodu źródłowego silnika

Jeśli kompilujesz Unreal Engine 5.8 ze źródeł, możesz załatać ten błąd u samego źródła. Główna przyczyna regresji leży wewnątrz funkcji FDeferredShadingSceneRenderer::InitLumenScene, zlokalizowanej w prywatnych plikach renderowania silnika (Private/Lumen/LumenScene.cpp). W UE 5.8 warunki sprawdzające, czy Lumen Scene jest wymagana, zostały zoptymalizowane, ale niechcący pominięto w nich weryfikację ustawień odbić.

Aby to naprawić, otwórz LumenScene.cpp i znajdź miejsce, w którym zdefiniowano bNeedLumenScene. Wadliwy kod i jego poprawiona wersja wyglądają następująco:

- // Faulty check in UE 5.8 that ignores reflection settings
- const bool bNeedLumenScene = Scene->DynamicGIProjectSetting == EEDynamicGlobalIlluminationMethod::Lumen;
+ // Corrected check restoring reflections-only compatibility
+ const bool bNeedLumenScene = Scene->DynamicGIProjectSetting == EEDynamicGlobalIlluminationMethod::Lumen || Scene->ReflectionProjectSetting == EEReflectionMethod::Lumen;

Po zmodyfikowaniu tej linii przebuduj silnik. Zmiana ta przywraca dokładnie tę samą logikę pipeline, która była używana w UE 5.7, umożliwiając rendererowi inicjalizację Lumen Scene za każdym razem, gdy wybrane są odbicia Lumen, niezależnie od metody Global Illumination. Jest to najczystszy sposób na rozwiązanie tego problemu, ponieważ pozwala uniknąć stosowania nadpisań CVars, które mogą dezorientować członków zespołu lub zaśmiecać pliki konfiguracyjne.

Dalsze konsekwencje: Skoki czasu ramki u klienta i multiplayer desync

Choć błędy graficzne są często traktowane jako odizolowane problemy wizualne, ich wtórne skutki mogą rzutować na całą architekturę gry. Gdy deweloperzy napotykają ten błąd, ich pierwszą reakcją jest często po prostu ponowne włączenie Lumen GI w celu przywrócenia odbić. Jednak dodanie od 4 ms do 6 ms obciążenia GPU po stronie klienta może spowodować poważne spadki płynności (frame rate drops), co może wywołać problemy z multiplayer desync.

W grach typu multiplayer symulacja fizyki oraz przetwarzanie danych wejściowych gracza (player input) są ściśle powiązane z częstotliwością taktowania klatek klienta (client's frame tick rate). Gdy klient doświadcza nagłego przestoju w renderowaniu (rendering stall) – na przykład gdy przebieg odbić (reflection pass) przeciąża GPU podczas obrotu kamery – czas ramki symulacji klienta gwałtownie rośnie. Opóźnienie to może prowadzić do opóźnionego wysyłania pakietów sieciowych lub ich przetwarzania niezgodnie z kolejnością, co skutkuje widocznymi lagami i korektami serwera (server corrections). Aby zapobiec wpływowi tych skoków wydajności na wrażenia z rozgrywki multiplayer, zapoznaj się z naszym przewodnikiem jak naprawić desynchronizację pozycji gracza (player location desync) w UEFN i multiplayerze Unreal Engine.

Co więcej, te problemy z renderowaniem podkreślają znaczenie oddzielenia ustawień graficznych po stronie klienta od logiki serwera. Bezgłowe serwery dedykowane (headless dedicated servers) nigdy nie powinny kompilować ani ładować pipeline'ów renderowania, materiałów ani wolumenów postprocessingu (post-processing volumes). Brak wycięcia tych zasobów (asset stripping) podczas kompilacji pliku wykonywalnego serwera skutkuje rozdętym zużyciem pamięci (memory footprint) oraz długim czasem uruchamiania, co może obniżyć czas reakcji matchmakera. Aby uzyskać szczegółowy przewodnik dotyczący optymalizacji buildów serwerowych, przeczytaj nasz artykuł jak opanować usuwanie zbędnych zasobów (asset stripping) na serwerze dedykowanym Unreal Engine.

Rozwiązywanie problemu zarządzania konfiguracją z horizOn

Naprawienie błędów renderowania, takich jak unreal engine 5.8 lumen reflections bug, na lokalnej maszynie to dopiero połowa sukcesu. Gdy Twoja gra trafi na rynek, musisz zarządzać profilami graficznymi, nadpisaniami zmiennych konsolowych (CVars) oraz ustawieniami silnika na tysiącach różnych konfiguracji komputerów graczy. Hardkodowanie zmiennych CVars w lokalnych plikach konfiguracyjnych oznacza, że jeśli w drobnym updejcie silnika zostanie wykryta kolejna regresja renderowania, musisz skompilować, spakować i dostarczyć graczom całkowicie nowy patch.

Właśnie w tym obszarze zarządzania konfiguracją horizOn staje się nieocenionym narzędziem dla twórców gier. Zamiast zmuszać Cię do wydawania dużych aktualizacji klienta gry w celu usunięcia problemów z renderowaniem, nasza platforma pozwala dynamicznie zarządzać ustawieniami gry z poziomu scentralizowanego backendu. Korzystając z usługi zdalnej konfiguracji (remote configuration) horizOn, możesz definiować docelowe profile dla różnych konfiguracji sprzętowych i aktualizować je w czasie rzeczywistym.

Na przykład, gdy gracz uruchamia grę, klient może odpytać backend, przekazując szczegóły dotyczące wykrytej karty GPU oraz wersji silnika. Serwer porównuje te dane z aktualnymi regułami konfiguracji i zwraca zoptymalizowaną listę CVars. Jeśli gracz korzysta z UE 5.8 na karcie średniej klasy, backend dynamicznie przesyła ustawienie r.Lumen.ForceLumenScene=1. Pozwala to na idealne działanie odbić bez konieczności pisania i utrzymywania skomplikowanych profili po stronie klienta czy wydawania awaryjnych patchy.

Najlepsze praktyki konfigurowania technologii Lumen w środowisku produkcyjnym

Podczas wydawania gry, która korzysta z odbić Lumen lub globalnego oświetlenia, przestrzeganie ustrukturyzowanego procesu QA zapobiega dotarciu regresji wizualnych do graczy. Poniżej znajdują się cztery najlepsze praktyki, które możesz zintegrować ze swoim pipeline'em deweloperskim:

1. Automatyzacja testów GBuffer: Zbuduj testy automatyczne w swoim pipeline CI/CD, które przechwytują obrazy z viewportu przy użyciu określonych flag renderowania. Użyj tych testów, aby zweryfikować, czy kanał odbić zawiera poprawne dane ray-traced zamiast wykonywać fallback do pustej przestrzeni ekranu.
2. Rozdzielanie GI i odbić podczas optymalizacji: Przetestuj grę z wyłączonym GI i włączonymi odbiciami Lumen. Pozwala to ocenić przyrosty wydajności z zastosowania baked lighting na słabszych konfiguracjach, przy jednoczesnym zachowaniu błyszczących specular highlights.
3. Wykonywanie walidacji CVars przy starcie: Zaimplementuj skrypty walidacyjne w runtime, które sprawdzają status zmiennych konsolowych, takich jak r.DynamicGlobalIlluminationMethod i r.ReflectionMethod podczas początkowej fazy ładowania gry, upewniając się, że nie wywołują one fallbacków.
4. Stosowanie dynamicznych profili klienta: Unikaj hardkodowania ustawień graficznych (graphics presets) w plikach binarnych projektu. Używaj narzędzi do dynamicznej konfiguracji, aby dostosowywać zmienne renderowania w locie, co pozwoli Ci natychmiast reagować na regresje silnika bez konieczności wydawania pełnej aktualizacji klienta.

Chcesz uprościć zarządzanie konfiguracją swojej gry i wdrażać stabilne serwery dedykowane (dedicated servers)? Zarejestruj się w horizOn już dziś lub przeczytaj naszą dokumentację dla deweloperów, aby dowiedzieć się, jak zintegrować dynamiczne aktualizacje ustawień ze swoim pipeline'em Unreal Engine.

---

Source: UE 5.8 Release - Lumen Reflections not working unless Lumen GI enabled