Налаштування освітлення ігрових сцен для графіки

Налаштування освітлення ігрових сцен для графіки

Сцена без роботи освітлення—це моделі у сірій кімнаті. Добре налаштоване світло може піднести навіть середні ассети до рівня, при якому гравець не помічає технічних компромісів. Погане освітлення убиває дорогі моделі. Це не про художницький смак—це про розуміння того, як рушій рахує світло.

Де конкретно все ламається

У URP-проектах стандартна помилка—змішування Forward та Deferred Rendering Path без урахування того, що Deferred не підтримує MSAA і працює інакше з Normal Maps на деяких платформах. Частина джерел світла починає вести себе неочікувано, особливо Point Light з малим Intensity але великим Range—у Forward він потрапляє в per-object light limit (за замовчуванням 8 додаткових світ), а на мобільних платформах цей ліміт жорсткіший.

Другий класичний провал: освітлення виглядає нормально в сцені, але після запікання Lightmap всі тені зміщуються. Це наслідок неправильного Shadow Bias на Source Light—коли Directional Light має Normal Bias вище 0.4, статичні тені від запікання не збігаються з динамічними тенями в Mixed режимі. Результат—«подвійна тінь» на стику запеченого та реалтаймового.

Архітектура світла сцени: від крупного до дрібного

Розпочинати надо з ключового джерела—Sun/Moon для зовнішніх сцен, основного потолочного світла або вікна для інтер'єрів. Directional Light з правильно встановленими Color Temperature та Intensity задає тональність всієї сцени. У HDRP це зручніше робити через Physically Based Sky + HDRI Sky для отримання коректного ambient.

Далі—контровий світ (rim/back light) для читаємості персонажів на фоні оточення. Окремий Source Light з невеликим Intensity, спрямований проти основного—персонаж не сливається з фоном навіть у темних зонах. У більшості проектів цей світ роблять невидимим для оточення через Light Layers (HDRP) або Culling Mask.

Акцентне освітлення—Point Lights та Spot Lights для створення інтересу в кадрі, підсвітки інтерактивних об'єктів, атмосферних ефектів. Тут важливо контролювати кількість: кожен додатковий источник у Forward Rendering додає pass для кожного освітлюваного об'єкту. На мобільних пристроях 4 додаткові источники—вже багато.

Робота з Color Temperature замість колірних пресетів

Інженери часто задають колір источника прямо через Color picker. Коректніше—через Color Temperature (Kelvin). 2700K дає теплий вечірній світ лампи розжарювання, 5600K—нейтральний денний, 8000K—холодний синій відтінок хмурого неба. При зміні часу доби через Timeline або Shader достатньо анімувати значення Kelvin, і вся сцена змінює тональність органічно, без ручної правки кожного источника.

У URP Color Temperature включається через Additional Light Data → Use Color Temperature. У HDRP це стандартний параметр HD Additional Light Data.

Кейс: horror-гра, занадто яскраві темні зони

На одному проекті жанру horror скаржились, що темні коридори виглядають «мильно»—м'які тені, немає контрасту. Проблема виявилась у Ambient Light: він був встановлений через Environment Lighting → Source: Color з Intensity 0.8—фактично Fill Light на всю сцену. Після переходу на Source: Gradient з Sky Intensity 0.05, Ground Intensity 0.02 та прибранням Equator темні зони стали по-справжньому темними, а Light Probes почали коректно передавати різницю між освітленими та неосвітленими зонами персонажу.

Освітлення та LOD: проблема, яку помічають пізно

При використанні LOD Groups є нюанс, який регулярно спливає в середині проекту: источники світла з Culling Mask та Light Layers ведуть себе по-різному на різних LOD-рівнях тільки якщо Renderer'и на цих рівнях мають різні Layer налаштування. Але частіше проблема в іншому—на LOD2 та LOD3 нерідко стоять спрощені Mesh без Normal Map, а шейдер той же, що й на LOD0. У результаті при переключенні LOD освітлення різко змінюється: нормальна модель гарно блищить, а спрощена лоповка виглядає пласкою.

Коректний підхід: для LOD2+ використовувати спрощені шейдери (Lit → Simple Lit або Custom Unlit з запеченим AO), а не повний PBR стек. Це не тільки візуально коректніше, а й знижує навантаження на GPU при рендері далеких об'єктів.

Ще один момент з Emissive матеріалами у Baked GI: об'єкт з Emissive може «запекти» своє світіння в оточуючі лайтмапи, але тільки якщо у нього включений Contribute GI та параметр Emission у шейдері проброшен в Lightmap Emissive. У URP/Lit це Emission → Baked Emission. Якщо цей прапор не включений, об'єкт світить сам по собі, але нічого не освітлює в запеченому лайтмапі—поширена причина того, чому «світячий» екран або вікно не дає світла на підлогу навколо.

Інструменти для діагностики освітлення

Frame Debugger (Window → Analysis → Frame Debugger) дозволяє пройтись по кожному draw call та подивитись, який Pass відповідає за конкретний об'єкт. Незамінний, коли потрібно зрозуміти, чому об'єкт освітлюється не так, як очікується.

Rendering Debugger у режимі Lighting → Albedo / Specular / Normal / Direct Diffuse розбирає освітлення на компоненти. Якщо Normal карта не впливає на освітлення так, як повинна—це одразу видно в режимі перегляду Normal.

GPU Usage Profiler показує, скільки GPU-часу йде на Shadow Caster Pass для кожного источника. Якщо один Spot Light з увімкненим Shadow Casting з'їдає 3 мс—це повід або знизити Shadow Resolution для цього источника, або перевести його в non-shadow режим та імітувати тінь через Blob Shadow текстуру.

Для HDRP-проектів є окремий інструмент—Light Explorer (Window → Rendering → Light Explorer). Показує всі источники світла у сцені у вигляді таблиці з режимами, інтенсивністю та типом тіней. Зручно для аудиту сцен, де источників більше 20: не потрібно кликати по кожному в Hierarchy.

Процес та строки

Робота починається з художнього брифу: референси, час доби, атмосфера, цільова платформа. Далі—технічний аудит сцени (кількість источників, поточні Render Path, версія рушія). Потім налаштування базового освітлення з ітераційним узгодженням. Фінальний етап—оптимізація та перевірка на цільових пристроях.

Вартість розраховується індивідуально після аналізу вимог та поточного стану проекту.