Продвинутое освещение
Энтити света
light_dynamic
Невидимый источник света, который может постоянно меняться и перемещаться. Его местоположение может определяться скриптованными двигающимися объектами. Динамическое освещение существенно нагружает процессор, потому что рассчитывается в реальном времени, и при этом оно гораздо гибче статического освещения. Используйте данный тип освещения редко, потому что он сильно нагружает графический движок.
Светящиеся текстуры
В определённых случаях можно создавать свои светящиеся или освещающие текстуры, но для этого нужно использовать файл .vmt или .rad, что выходит за рамки нашей статьи. Это поможет дизайнеру уровня сберечь усилия, когда он будет создавать световые эффекты для своей карты.
env_particlelight
Обычный свет, который освещает только частицы из env_smokestack , и больше ничего. Полезно для улучшения освещения помещений с паром и подобных, но редко используется из-за своей специфики.
env_projectedtexture
Аналогично light_dynamic - это невидимый прожектор, который может изменяться и двигаться. Он может менять свою позицию, поле зрения и диапазон, будучи привязан к двигающимся объектам. Env_projectedtextures уникальна тем, что отбрасывает динамические тени от любой геометрии (браша или модели) на все браши и модели (даже на себя), в отличие от теней RenderToTexture. Данная система используется для фонариков игроков в Half-life 2 и L4D.
Env_projectedtexture - самый тяжелый источник света, он не компилируется, и все расчёты происходят в реальном времени. Более одной или двух таких энтить резко снизят производительность на старых видеокартах. Также обратите внимание, что на Source2007 и более ранних версиях движка без исправлений тени будут сильно "зернистыми", иметь низкое разрешение и без родителя. Эти проблемы были исправлены в новых итерациях движка Source2009, тем не менее вы ограничены только одной текстурой-прожектором (ВКЛЮЧАЯ фонарики игроков).
Связанные энтити
info_lighting
Эта энтитя используется в качестве источника, от которого светится другая сущность. Иногда, при резких перепадах света на коротких расстояниях или сложных теней, модель может неправильно отсвечивать. С помощью этой энтити модель будет светить так, будто она на своём месте.
Одним из распространённых примеров являются статичные модели лестниц в HL2; в тёмных зонах они будут светиться, если в их свойствах правильно прописать info_lighting, задав последнему имя.
env_lightglow
Используется для создания ярких огней, похожих на вспышку, и затухающих на определённом расстоянии. Как правило, ставится в конце тёмных тоннелей. Является предшественником HDR -эффекта, подделывая экспозицию света. Некоторые карты Team Fortress 2 используют этот эффект, чтобы имитировать пушок от обычных источников света, но лучше использовать env_sprite .
info_no_dynamic_shadow
Заставляет конкретную брашевую поверхность не создавать динамические тени, отбрасываемые физическими сущностями или NPC. Используется редко, но может потребоваться, чтобы скрыть неправильные или кривые тени, выглядящие искусственно.
env_tonemap_controller
Управляет экспозицией световых HDR -эффектов. Если нет полностью реализованного HDR, то не оказывает влияния.
Группы сглаживания
Сглаживают освещение между гранями. Параметр находится в диалоге редактирования поверхности , сглаживает освещение группы граней, создавая эффект закруглённого света. Классическим примером является цилиндр: если сглаживание группы не задано, каждая грань браша будет получать свет и освещаться отдельно. Это создаст эффект раздельных граней. Если все они будут помещены в одну группу сглаживания, свет станет рассеиваться между гранями, создавая вид округлой колонны.
Lightmaps
Карта освещённости - это данные освещённости каждой грани. Сохранённый свет впоследствии добавляется к грани, заставляя её отсвечивать. Шкала карты освещённости - это количество пикселей текстуры на пиксель света (люксел). Чем больше значение люксел, тем выше качество, но больше размер BSP и время компиляции.
Опции компилирования
Движок Orange Box (Source 2007) добавил три новых опции, которые повышают реализм во время компиляции. Чтобы получить к ним доступ, в диалоговом окне Run Map выберите режим Expert, и затем "HDR Full compile -final (slow!)"; далее, в списке ниже, выберите строку "$light_exe". В поле Parameters введите необходимые параметры, описанные ниже.
ПРИМЕЧАНИЕ: Это значительно увеличит время компиляции, так что рекомендуется использовать на последних стадиях создания карты!
-staticproppolys
Как правило, VRAD создаёт тени под статичными пропами на основе сетки столкновений, потому что это проще, поскольку сетка столкновений близка к форме пропов. Обычно этого достаточно, но некоторые пропы могут иметь упрощенную сетку — или вообще её не иметь — вынуждая VRAD создавать неестественные тени. Данная опция позволяет обходить это для некоторых пропов, заставляя VRAD использовать полигональную сетку. Также, это необходимо, если вы используете -textureshadows (см. ниже).
Просто добавьте -staticproppolys в список параметров $light_exe (см. ниже).
-textureshadows
Не все пропы имеют геометрические "дырки". Сетчатые заборы, например, используют текстуры с альфа-каналами. Обычно они не распознаются VRAD, поэтому при их использовании отключите тени от них (что иногда приводит к приличным результатам), или добавьте эту опцию, которая заставит VRAD обрабатывать альфа-каналы также, как и браши.
Чтобы команда -textureshadows работала, вам нужно создать пользовательский файл RAD со списком пропов, к которым будет применяться данная опция. Извлеките из игры файл lights.rad с помощью GCFScape или Crafty, поместите его в папку с игрой и дайте ему новое имя. Затем, откройте его в любом текстовом редакторе, и добавьте строку forcetextureshadow [полный путь к пропу], чтобы файл применился к каждой модели. Также необходимо активировать 'staticproppolys'. Наконец, добавьте -lights [название вашего файла RAD] -textureshadows в список Parameters $light_exe (см. ниже).
-staticproplighting
В отличие от двух других, этот параметр влияет на свет, отбрасываемый пропами. Пропы, как правило, отсвечивают в зависимости от места размещения (см. info_lighting выше), что приводит к неестественному освещению, когда свет падает только на одну сторону пропа, или проп находится наполовину в тени. Эта опция заставляет VRAD рассчитывать уровень света каждой вершины независимо. Из всех трёх опций, эта, пожалуй, сильнее всего влияет на время компиляции, но, как правило, является необходимым шагом в деле создания убедительно выглядящих моделей.
Просто добавьте -staticproplighting в список $light_exe Parameters (см. выше).
Методы
Оптимизация карты освещённости
Практически всю свою информацию карты освещённости хранят в файлах Source BSP , поэтому их эффективное использование является эквивалентом хорошего освещения. Они вносят ключевой вклад в размер файла BSP: эффективное использование имеет преимущество в загрузке карты для любого желающего поиграть.
Масштаб карты освещённости - основной момент оптимизации. Он определяет, насколько детальна будет информация об освещении для данной грани (выше вы можете посмотреть эффекты). Чем больше хранится информации, тем больше размер файла. Меньший масштаб карты освещённости даёт отличную детализацию, но ценой распухшего файла (производительность останется без изменений). Больший масштаб создаёт размытое освещение, но уменьшает размер файлов. Поэтому, нуждается ли грань в детализированной карте освещенности - является определённой задачей.
В основном, это может быть сделано на глазок после компилирования карты. Посмотрите на грани с высоко-контрастными тенями или конкретными деталями, поскольку они первые кандидаты на низкий (т.е. детализированный) масштаб карты освещённости. У граней с мягкими тенями и освещением, когда они мало отличаются друг от друга, можно смело поднимать масштаб.
Пример
Рассмотрим рабочий пример коридора, который изображён справа. Одна картинка показывает вид в игре, другая отображает карты освещенности в редакторе Hammer. Карту освещённости легко посмотреть: в окне 3D-вида щелкните левой кнопкой мыши по слову Camera, и в выпавшем меню выберите 3D Lightmap Grid. И так, жёлтые грани показывают меньший масштаб относительно масштаба по-умолчанию, белые грани - масштаб по-умолчанию, и синие - большой масштаб.
В коридоре видим светильники на стенах и потолке. На снимке видно, где масштаб освещения выше, а где ниже. Передняя сторона колонны имеет повышенную карту освещённости, чтобы поймать все нюансы, т.к. на ней висит источник света. Это не такая большая проблема, ведь колонна - суть маленькая тонкая грань с малым масштабом. Пол и стены вдоль края имеют увеличенный масштаб освещённости, поскольку в игре их детализация интереса не представляет, особенно пол. У остальных граней оставлен масштаб по-умолчанию, поскольку там есть некоторая игра теней и перепады яркости. Увеличение масштаба в них приведёт к плохой освещённости и потере детализации.
Хотя, с технической точки зрения, для улучшения чёткости теней можно уменьшить масштаб на всей карте, однако затянутая компиляция и раздутый размер файла перевешивают эту плюшку. Поиск баланса между большим и малым масштабами карты освещённости может отнять у вас несколько компиляций и привести к некоторым догадкам, которые позволят найти оптимальный размер файла карты.
Создание теней
Некоторые пропы пропускают сквозь себя статичный свет, но имеют сетку столкновений , которая полностью их покрывает (большинство, если не все[подтвердить], чему хороший пример - модель забора в серии игр Half-Life 2 ). Как результат - большие, неестественные тени. Обойти это можно, создав func_brush, отключив в нём тени и покрыв текстурой block_light. Насколько это будет трудно, зависит от размеров пропа. Обычно, браши с block_light рисуются там, где свет не должен проходить сквозь браши/пропы.
Покрыв балку материалом block_light, вы создадите 'фиктивные' тени.
Создание теней: альтернативный метод
Creating Shadows with -TextureShadows (внешняя ссылка)
См. также