Запікання статичного світла (Lightmaps) у іграх
Лайтмапи—це спосіб купити якісне освітлення ціною CPU/GPU-часу на етапі розробки, а не під час гри. Для мобільних платформ та проектів з обмеженим бюджетом продуктивності це не просто зручний варіант—це єдиний реальний шлях до гарного освітлення без просадок FPS.
Але конвеєр запікання ламається легко. І частіше за все—не через налаштування освітлення, а через геометрію.
Важливий момент, який часто пропускають: лайтмапи статичні за визначенням. Будь-який об'єкт без позначки Static не бере участі у запіканні як источник або отримувач запеченого світла. Це означає, що динамічні персонажі, двері, ліфти та все інше, що рухається, повинні працювати з Light Probes для отримання непрямого освітлення. Коректна взаємодія статичних лайтмап та динамічних Light Probes—окрема частина архітектури освітлення, яку закладають до початку робіт, а не вирішують постфактум.
UV1-розгортка: тут живе 80% всіх проблем
Progressive Lightmapper запікає освітлення в окремий UV-канал—UV Channel 1 (Lightmap UV). Якщо цей канал не налаштований правильно, жодні параметри запікання не рятуватимуть.
Три жорсткі вимоги до Lightmap UV: острови не повинні перекриватися, острови повинні мати відступ від краю атласу (мінімум 2 пікселя при стандартній роздільності), поверхні однакового розміру в світовому просторі повинні мати пропорційний розмір острова. Останнє порушується найчастіше при імпорту ассетів з сторонніх джерел—художник робить розгортку для дифузної текстури, а Lightmap UV залишається як попало.
У Unity можна включити автоматичну генерацію Lightmap UV при імпорті (Model → Generate Lightmap UVs), але це не панацея. Автогенерація погано працює з архітектурними об'єктами з гострими кутами—алгоритм розбиває поверхню на занадто дрібні острови, і при запіканні на стиках з'являються темні смуги через padding artifacts. Для таких об'єктів краще робити UV1 вручну в Blender або Maya з явним контролем швів та padding.
Перевіряти розгортку перед запіканням обов'язково—через Lightmap UV Preview в Scene View (кнопка UV Charts у режимі Baked Lightmap).
Налаштування Progressive Lightmapper
Progressive Lightmapper—CPU або GPU, залежно від заліза. GPU-версія на сучасних картах працює в 5–15 разів швидше, але потребує NVIDIA з підтримкою CUDA або AMD з Metal/OpenCL. На машинах без дискретної GPU або при роботі з дуже великими сценами (більше 4K об'єктів) CPU-версія стабільніша.
Ключові параметри, які реально впливають на результат:
Lightmap Resolution—texels на одиницю світового простору. Стандарт 10–20 для близьких поверхонь, 2–5 для далеких. Єдине значення для всієї сцени—помилка. Коректний шлях: Lightmap Parameters Assets різних класів якості, призначені через Mesh Renderer → Lightmap Parameters.
Direct Samples / Indirect Samples—кількість променів для прямого та непрямого освітлення. Для продакшн-білду Direct 64, Indirect 512—розумна база. При шумі на темних ділянках збільшуємо Indirect до 1024. Збільшення вище 2048 рідко дає видимий результат при звичайних дифузних матеріалах.
Max Bounces—кількість відбиттів непрямого світла. 2 bounce достатньо для більшості сцен. 4+—для скляних або дзеркальних інтер'єрів, де світло багаторазово переотражується.
Denoising—обов'язково включати для фінального запікання. Optix (NVIDIA) дає найкращий результат, але недоступний без сумісної карти. OpenImageDenoise (Intel) працює на будь-якому CPU.
Кейс: лайтмапи для мобільної стратегії
Проект—мобільна стратегія з ізометричним виглядом, 20+ сцен рівнів. Вимога: лайтмапи не повинні займати більше 4 MB на сцену (обмеження бюджету памяті). При стандартних налаштуваннях кожна сцена генерувала 3–5 текстур 1024×1024, що давало 6–8 MB навіть в ETC2.
Рішення через Lightmap Packing: перейшли на один атлас 2048×2048 замість кількох 1024×1024 (щільніша упаковка через кращий bin-packing алгоритм). Для всіх об'єктів дальнього плану та дахових поверхонь, невидимих камерою, Contribute GI відключили повністю. Результат—1 текстура 2048×2048 на сцену, 2 MB в ETC2 при збереженні візуальної якості на близькому плані.
Lightmap Compression та формати
Після запікання Unity зберігає лайтмапи в Lightmap-dir як float32 EXR. При білді вони конвертуються згідно налаштувань платформи. Для Android рекомендую явно задати Lightmap Encoding у Project Settings → Player → Lightmap Encoding: Normal Quality використовує RGBM-кодування (8 бітів), High Quality—BC6H на десктопі або RGBA Half Float на мобільних, що дає кращу збереженість HDR-даних.
На iOS з Metal переважніший ASTC 6×6—він дає краще співвідношення якість/розмір, ніж ETC2. Налаштовується через Texture Importer для папки з лайтмапами (Select All → Override for iOS).
Поетапна робота над запіканням
Спочатку аудит UV-розгорток та виправлення проблемних об'єктів. Паралельно—налаштування Lightmap Parameters Assets під різні класи об'єктів. Потім тестове запікання з низькою якістю (Direct 8, Indirect 32) для перевірки структури освітлення—на цьому етапі видні проблеми з UV та розстановкою источників. Після узгодження—фінальне запікання з продакшн-параметрами, деноізинг, перевірка розміру атласів. Фінал—тест у білді на цільовій платформі.
| Масштаб | Строки |
|---|---|
| 1–3 невеликі сцени (до 100 об'єктів кожна) | 2–4 дні |
| 10–20 сцен середнього розміру | 1–3 тижні |
| Великий рівень з відкритим простором | 1–2 тижні |
| Повний конвеєр з UV-правками та оптимізацією | 3–6 тижнів |
Вартість визначається індивідуально після аудиту UV-розгорток та аналізу поточного стану проекту.