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

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

Ми — сертифіковані спеціалісти 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, версія двигуна). Потім налаштування базового освітлення з ітераційним узгодженням. Фінальний етап — оптимізація та перевірка на цільових пристроях.

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

Які проблеми вирішує налаштування освітлення?

Художник запікає лайтмапи годину, знаходить артефакт на стику UV, виправляє розгортку і запікає ще годину. Цикл повторюється 3–5 разів на день. У масштабі проекту з десятком сцен втрачаються тижні. Неправильна стратегія на старті (усі джерела в Realtime) на релізі дає 30–50% просадки FPS на мобільних пристроях і консолях. Послуги з налаштування освітлення та рендерингу під ключ вирішують дві головні болі: час запікання і продуктивність рантайм. За 5 років ми реалізували понад 30 проектів — від інді до AA-тайтлів. Свяжіться з нами для отримання консультації: розберемо вашу сцену та запропонуємо рішення.

Динамічне, статичне та змішане освітлення: як обрати?

В Unity три режими для джерела світла — ось як вони впливають на продуктивність:

Помилка: студія виставляє все освітлення в Realtime і отримує сцену з 12 джерелами тіней на екрані. На мобільних платформах це гарантований провал. Mixed Lighting з підрежимами Subtractive або Shadowmask — робочий компроміс. Статичні об'єкти отримують запечені тіні, динамічні — реалтаймові від тих самих джерел.

Як оптимізувати запечене освітлення без втрати якості?

Саме тут втрачається найбільше часу. Ось як ми це робимо.

Вибір між Enlighten та Progressive Lightmapper

Unity підтримує два бекенди. Enlighten — старий двигун для реального часу, дає менш точний GI (в 2–3 рази поступається Progressive за якістю). Progressive Lightmapper (GPU) на хорошій карті працює в 5–10 разів швидше за CPU. За замовчуванням ми використовуємо Progressive Lightmapper для PC та консолей. Ключові параметри:

Lightmap Resolution:    10–20 texels/unit для більшості сцен
Max Bounces:            2–4 (не 8, як стоїть за замовчуванням)
Samples (Direct):       32–64
Samples (Indirect):     512–1024
Denoiser:               OIDN (Intel) або OptiX (NVIDIA)

Деноізер обов'язковий. Без нього для чистого результату потрібні тисячі семплів; з деноізером вистачає 256–512, і ітерація займає хвилини, а не години.

Чому виникають артефакти на лайтмапах та як їх прибрати?

Часті артефакти та рішення зведено в таблицю:

Організація сцени для швидкого запікання

Великий масштаб сцени — головний ворог швидкості. Покроковий процес:

1. Виключаємо дрібні об'єкти (менше 0.5 unit) — вони отримують освітлення через Light Probes.
2. Використовуємо Instanced Meshes для повторюваних об'єктів — дерева, каміння, паркани шарять один UV-атлас.
3. Terrain запікаємо окремо зі зниженою роздільною здатністю (2–5 texels/unit).
4. Перевіряємо Backface Tolerance на складній геометрії.

Дотримання цих правил скорочує час запікання на 50–70% без втрати якості. Wikipedia описує техніку запеченого освітлення як Lightmap.

Light Probes та Reflection Probes: навіщо та як налаштовувати?

Light Probes дають динамічним об'єктам ілюзію запеченого освітлення. Проби потрібно розставляти кожні 2–4 метри в зонах з перепадом освітлення. Занадто рідкісна розстановка дає різкі стрибки при переміщенні персонажа. Probe Volumes (HDRP) замінюють ручну розстановку на об'ємну сітку — для великих відкритих сцен це суттєва економія часу.

Reflection Probes — коректні відбиття на PBR-матеріалах. Без них метал і дзеркала відбивають скайбокс замість оточення. Налаштування: Baked для статичних приміщень, Realtime для зон зі змінним оточенням (телевізор, екрани), Box Projection для коректного відбиття геометрії.

Пост-обробка: SSAO та SSR

SSAO додає затемнення в щілинах і кутах. Типова помилка — занадто високі Radius та Intensity. Робочі значення: Radius 0.5–1.5, Intensity 1.0–2.0. SSR дає динамічні відбиття на горизонтальних поверхнях, працює лише з видимим на екрані.

Що входить до роботи з налаштування освітлення

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

1. Аудит поточної системи — профілювання через Frame Debugger та RenderDoc, виявлення вузьких місць.
2. Стратегія освітлення — документація з вибором режимів (Mixed/Baked/Realtime) під вашу платформу.
3. Оптимізація запікання — налаштування Progressive Lightmapper, UV-розгортки, Light Probes.
4. Налаштування Reflection Probes та пост-обробки (SSAO, SSR, Bloom) під стилістику.
5. Фінальний звіт з результатами вимірювань продуктивності (FPS budget, draw calls).
6. Онлайн-консультацію — розбір вашої сцени в прямому ефірі.

Приклад економії: проект на Unity з відкритим світом. Вихідний час запікання однієї сцени — 4 години. Після оптимізації знижено до 1 години 20 хвилин. Економія часу за місяць — понад 40 годин розробки.

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

Працюємо за чітким регламентом:

• Аналітика (1–2 дні) — розбір сцени, скріншоти, профілювання.
• Проектування (1 день) — вибір стратегії, план оптимізації.
• Реалізація (3–7 днів залежно від складності) — правки UV, налаштування Lightmapper, Light Probes, пост-обробка.
• Тестування (1–2 дні) — вимірювання продуктивності, усунення артефактів.
• Деплой — передача файлів сцени, документація, чек-лист.

Терміни орієнтовно: від 5 до 15 робочих днів. Вартість розраховується індивідуально — зв'яжіться з нами для оцінки вашого проекту. Замовте послугу налаштування динамічного освітлення — отримайте стабільний FPS без артефактів. Отримайте безкоштовну консультацію з налаштування освітлення під ключ: від аналізу до фінальної оптимізації.