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

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

Ми — сертифіковані спеціалісти Unity та Unreal Engine. Налаштовуємо освітлення ігрових сцен під ключ: працюємо з URP/HDRP, забезпечуємо консистентність від редактора до цільових платформ. За 5 років реалізували світлові схеми для понад 20 проєктів — від мобільних казуалок до PC-хорорів. Гарантуємо результат, який пройде Frame Debugger та RenderDoc без сюрпризів.

Чому освітлення ламається на мобільних платформах?

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

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

Як правильно налаштувати Color Temperature?

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

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

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

Починати треба з ключового джерела — 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 додаткових джерела — вже багато.

Порівняння Forward та Deferred для освітлення

З нашої практики: 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.

Що входить в нашу роботу

• Аудит поточного освітлення та рендер-пайплайну
• Налаштування Key, Fill, Back Light з урахуванням художнього брифу
• Оптимізація під цільові платформи (включно з mobile, console)
• Запікання Lightmap та Light Probes
• Документація щодо світлової схеми та рекомендації для команди
• Підтримка протягом двох тижнів після здачі

Процес та терміни

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

Вартість розраховується індивідуально після аналізу вимог та поточного стану проєкту. Отримайте консультацію з вашого проєкту — зв'яжіться з нами.