Настройка освещения игровых сцен для графики

Настройка освещения игровых сцен для графики

Сцена без работающего освещения — это модели в серой комнате. Хорошо настроенный свет может поднять даже средние ассеты до уровня, при котором игрок не замечает технических компромиссов. Плохое освещение убивает дорогие модели. Это не про художественный вкус — это про понимание того, как движок считает свет.

Где конкретно всё ломается

В 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 режиме. Результат — «двойная тень» на стыке запечённого и реалтаймового.

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

Начинать надо с ключевого источника — 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, версия движка). Затем настройка базового освещения с итерационным согласованием. Финальный этап — оптимизация и проверка на целевых устройствах.

Стоимость рассчитывается индивидуально после анализа требований и текущего состояния проекта.