Запекание статического света (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 бounce достаточно для большинства сцен. 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-развёрток и анализа текущего состояния проекта.