урок 13.3 улучшенная компиляция. ускорение компиляции.
Улучшенная версия ZHLT Custom Build
Наряду с официальными компиляторами от Sean Cavanaugh aka «Zoner» существует их улучшенная версия, так называемый Custom Build от Энтони Мура (Anthony Moore) aka «Merl». Версия утилит от Энтони Мура обладает рядом преимуществ, о которых и пойдет речь в данной статье. Все параметры, описанные в данной статье, применимы ТОЛЬКО к ZHLT Custom Build и не применимы к простым ZHLT.
Последней версией ZHLT Custom Build является 1.7. Также можно встретить обозначение 2.5.3-1.7, но т.к. при выходе новых версий Custom Build меняется только вторая часть цифр, то 2.5.3 принято опускать
Новое в версии 1.7
Поддержка переключаемых светящихся текстур
Поддержка полупрозрачных и цветных теней для энтитей
Возможное значение параметра «-subdivide» увеличено до 512
Обновлена информация об объекте «info_compile_parmeters»
Null-текстура
Null-текстура предназначена для уменьшения количества отрисовываемых игрой полигонов, т.е. для снижения r_speeds и, соответственно, повышения количества кадров в секунду. Эту текстуру необходимо наносить на те стороны объектов, которые игрок никогда не увидит в нормальной ситуации в игре.
При компиляции null-текстуры просто удаляются, таким образом в игре движок Half-Life не отрисовывает поверхности, окрашенные null-текстурой. Применять null-текстуру можно как к обычным брашам, так и к брашевым энтити-объектам.
Пример использования. Допустим у нас на карте есть ящик (func_wall). В игре он будет расходовать 6 epoly по количеству сторон. Нижнюю часть ящика (дно) в нормальных условиях игрок увидеть не может. Окрасив ее null-текстурой, мы снизим показатель epoly на 1 полигон. Если ящик стоит около стены (как на рисунке), то также можно окрасить прислоненную грань.

Второй пример. У нас есть оконный проем со стеклом, сделанным из func_breakable или из того же func_wall. В игре стекло также занимает 6 epoly. Но игрок видит только 2 стороны стекла — другие 4 мы можем спокойно окрасить null-текстурой, таким образом сбережем 4 epoly.

Но это все меры, сберегающие epoly, в то время, как более главным для нас является сбережение wpoly. Поэтому null-текстуру нужно наносить на крыши домов, верхние грани заборов, стен, высоких ящиков — в общем, на те стороны, которые игрок увидеть не сможет. Кстати, вместо null-текстуры с тем же успехом можно использовать обычную SKY-текстуру. В обоих случаях происходит снижение r_speeds.
Если Вы будете использовать null-текстуру, не забудьте скопировать zhlt.wad (идет вместе с компиляторами) в какую-нибудь папку и подключить к редактору через меню «Tools\Options\Textures».
Автоматическое определение wad-файлов
Эта простая функция дает возможность подключать к редактору любое количество текстурных WAD-файлов, и при этом, только действительно используемые WAD-файлы будут включены в готовый BSP-файл карты.
Чтобы задействовать эту функцию, необходимо в строчку запуска компилятора HLCSG добавить параметр -wadautodetect.
Режим экономии clipnode
Данный режим включен по умолчанию в компиляторе HLCSG, поэтому нет необходимости включать его дополнительными параметрами.
Clipnode — поверхности, определяемые игровым движком, как непроходимые для игрока. Каждый браш на карте (будь-то стена, пол или ящик) «окутывается» clipnode-поверхностями. Благодаря clipnode'ам игрок не проваливается сквозь землю и не может проходить сквозь стены. Помните старый халфовский чит «noclip» (хождение сквозь стены) — вот это оно и есть :)
Количество таких плоскостей, как и многое другое в Half-Life, ограничено. Если число clipnode-плоскостей превышает максимально допустимое значение, то при компиляции возникнут ошибки.
В этой версии компиляторов, CSG анализирует использование clip-плоскостей на карте. Если в каких-то случаях возможно избежать их использования (например, func_illusionary не нуждается в использовании таких плоскостей), то такие clipnode-плоскости удаляются. Однако режим экономии clipnode не исключает появления ошибки MAX_MAP_CLIPNODES при компиляции, а просто уменьшает вероятность ее появления.
Рассеянный свет
Эта функция позволяет создавать более реалистичное освещение с использованием объекта light_environment. При этом компилятор HLRAD использует информацию о цвете и интенсивности освещения не из стандартного параметра «_light», а из параметра «_diffuse_light» (Вы указываете цвет и яркость света, как обычно, но только в параметре «_diffuse_light»). В этом случае свет будет проецироваться не от солнца, а со всего неба, что должно сделать освещение более реалистичным.
Изменение теней объектов
Это новая функция в ZHLT Custom Build 1.7, позволяющая мапперу изменять прозрачность и цвет отбрасываемой брашевыми энтити-объектами тени.
Чтобы задействовать эту функцию необходимо выставить флаг «Opaque» в свойствах энтити-объекта, в параметре «zhlt_lightflags».
Далее необходимо отжать кнопку «Smart Edit» и добавить новый параметр по имени zhlt_customshadow. Данный параметр определяет прозрачность энтити-объекта, значения от 1.0 до 0.0 (где 1.0 непрозрачный объект (нормальная, полная тень), а 0.0 — абсолютно прозрачный объект (нет теней)).
Чтобы изменить цвет отбрасываемой тени (например, если Вы делаете эффект тени от цветного стекла), необходимо прописать не 1 параметр, а 3, которые определят цвет тени в формате RGB (Красный, Зеленый, Синий). Например, чтобы придать тени красный оттенок, необходимо прописать в свойствах 0.5 0.0 0.0. При указании значений более 1.0, компилятор HLRAD создасть что-то вроде люминисцентной тени.
Чтобы все это заработало вместе с отраженным светом (а по умолчанию с отраженным светом эти эффекты не работают), необходимо в строку запуска компилятора HLRAD добавить следующий параметр -customshadowwithbounce.
Если вместе с параметром -customshadowwithbounce Вы также используете параметр -sparse, то процесс компиляции может сильно затянуться. Рекомендуется вместе с параметром -customshadowwithbounce использовать параметр -nomatrix;
Параметр -customshadowwithbounce работает только с обычными (greyscale) тенями, т.е. с цветными не работает.
Конфигурационный WAD-файл
А вот и существенное нововведение по сравнению с обычными компиляторами ZHLT — конфигурационный WAD-файл.
Конфигурационный WAD-файл используется для хранения различных конфигураций текстурных файлов. Например, Вы можете создать конфигурацию текстур для одной Вашей карты и другую конфигурацию (записать другие текстуры) для другой.
Конфигурационный WAD-файл с именем WAD.CFG должен находиться в одной директории с компиляторами ZHLT Custom Build.
Предположим, что одновременно Вы создаете несколько карт, которые используют различные текстурные WAD-файлы. Что Вы вынуждены делать? Поработав над одной картой, Вы открываете параметры редактора и отключаете неиспользуемые другой картой текстуры и наоборот подключаете используемые. Поработав какое-то время со второй картой, Вы решаете вернуться и доделать первую карту, и опять открываете параметры редактора, отключаете-подключаете текстуры... — в общем очень неудобно.
Справиться с этой проблемой помогает конфигурационный WAD-файл.
Ниже мы приводим синтаксис этого файла.
имя_конфигурации
{
c:\путь\wad1.wad
c:\путь\wad2.wad
...
include c:\путь\wad3.wad
}
где:
Имя_конфигурации — любое имя (удобно называть конфигурацию по названию карты).
c:\путь\wad1.wad — полный путь к первому WAD-файлу
c:\путь\wad2.wad — полный путь ко второму WAD-файлу
include c:\путь\wad3.wad — параметр «include» означает, что текстуры из данного WAD-файла будут включены в BSP-файл карты.
Вы можете использовать любое количество конфигураций и записей о WAD-файлах.
Рассмотрим небольшой пример:
Предположим, что на нашей карте DE_MAP используются 3 стандартных WAD-файла (halflife.wad, liquids.wad и decals.wad) и один нестандартный (MAP.WAD), который мы изготовили самостоятельно. Тогда наша запись в файле WAD.CFG будет выглядеть следующим образом:
MAP
{
c:\Games\Half-Life\valve\halflife.wad
c:\Games\Half-Life\valve\liquids.wad
c:\Games\Half-Life\valve\decals.wad
include c:\Wads\map.wad
}
Перед компиляцией необходимо добавить следующий параметр к компилятору HLCSG: -wadconfig MAP.
Таким образом, получается, что во время компиляции, HLCSG увидит, что надо использовать конфигурацию по имени MAP, считает информацию из файла WAD.CFG и затем уже будет использовать текстуры из стандартных WAD-файлов, и включит текстуры из нашего WAD-файла (MAP.WAD).
Путь к файлу wad.cfg
Параметр -wadcfgfile позволяет вручную указать путь к файлу WAD.CFG (по умолчанию компиляторы ищут этот файл в своей директории или в директории с Half-Life). Если WAD.CFG находится у Вас в какой-то другой директории, то необходимо добавить параметр -wadcfgfile путь_к_файлу в строку запуска компилятора HLCSG.
Поддержка объекта info_compile_parameters
Данная версия утилит поддерживает использование на карте объекта info_compile_parameters. В свойсвах этого объекта можно указать параметры компиляции, вместо их указания в командной строке. Если у Вас нет данного объекта, информацию о нем необходимо дописать в FGD-файл. О том, как это сделать и вообще более подробно об объекте Вы можете узнать из раздела «Энтити».
Поддержка объекта info_texlights
Данная версия утилит поддерживает использование на карте объекта info_texlights. Данный объект используется вместо RAD-файла, в который записывается информация о светящихся текстурах на карте. Подробнее об этом объекте Вы можете прочитать в разделе «Энтити».
Переключаемые светящиеся текстуры
Отличное нововведение в версии ZHLT Custom Build 1.7 — переключаемые светящиеся текстуры. Теперь любая светящаяся текстура может мигать, пульсировать или просто быть включена/выключена, как обычная лампочка. Раньше это было не возможно, но сейчас с выходом Сustom Build 1.7, это стало реально.
Секрет заключается в следующем, в FGD-файл, в свойства брашевых энтити-объектов (например, func_wall, как самый распространенный) необходимо добавить следующий код:
style(choices) : "Texlight style" : 0 =
[
0 : "Normal"
-3: "Grouped"
10: "Fluorescent flicker"
2 : "Slow, strong pulse"
11: "Slow pulse, noblack"
5 : "Gentle pulse"
1 : "Flicker A"
6 : "Flicker B"
3 : "Candle A"
7 : "Candle B"
8 : "Candle C"
4 : "Fast strobe"
9 : "Slow strobe"
12: "Underwater"
]
Добавив этот код к объекту func_wall, в редакторе можно будет выбрать стиль для данного объекта.
Стиль Grouped предназначен для создания светящихся текстур, которые можно включить/выключить, как лампочку.
Итак, создаем func_wall, окрашиваем его светящейся текстурой (светящейся текстура станет только, если ее прописать в специальном RAD-файле, который затем подключить при компиляции), даем func_wall имя (например, WALL-1), ставим стиль «Grouped» и (ВНИМАНИЕ!) создаем около func_wall обычную лампочку light с таким же именем (WALL-1). Ставим яркость лампочки в 0.01.
В итоге компилятор, просчитывающий освещение, а это HLRAD будет думать, что свет излучает лампочка (light), а не светящаяся текстура. Чтобы выключить или включить освещение от текстуры необходимо активировать лампочку (light). Всего этого можно было бы не делать, если бы CS поддерживал переключаемые светящиеся текстуры, как это сделано, например, в Spirit of Half-Life.
Параметр -subdivide
Данный параметр компилятора HLBSP позволяет изменить шаг, с которым поверхность карты делится на полигоны. По умолчанию через каждые 240 текстурных пикселей делается разрез, это означает, что сторона объекта с наложенной текстурой 256х256 пикселей будет разбита на 4 полигона (1 большой полигон с размером 240х240 пикселей и 3 маленьких), что в итоге может привести к существенному увеличению общего количества полигонов на карте.
Установив значение параметра -subdivide 256 мы значительно уменьшим количество полигонов на карте, при условии, что мы используем текстуры 256х256 пикселей. Это происходит потому, что теперь поверхность карты будет разрезаться через каждые 256 пикселей текстуры, а значит сторона объекта будет создавать не 4, а всего лишь 1 полигон.
Если мы будем использовать текстуры более 256 пикселей, то стоит попробовать еще увеличить параметр «-subdivide». Однако, как сообщает разработчик ZHLT Custom Build, при увеличении этого параметра, могут возникнуть проблемы с запуском карты в режиме Software. Но, учитывая, что Software режим используется крайне редко (и вообще mustdie :), то можно смело использовать этот прекрасный параметр.
Но здесь существует одно очень большое «НО» — параметр не работает :) Точнее, в некоторых случаях карта компилируется нормально, в других же компиляция прекращается, и выдается сообщение об ошибке на стадии просчета освещения (HLRAD). Так было по крайней мере с ZHLT Custom Build 1.7. Ждем улучшений.
Максимальное vis-расстояние
Максимальное визуальное расстояние (Maximum Distance Visibility — MDV) это новая функция, которая помогает справиться с проблемой отрисовки объектов на дальних расстояниях на Вашей карте. Ведь нет никаких гарантий, что все участки карты будут отрисованы в игре (некоторые дальные участки могут начать скрываться). Используя данный параметр, Вы будете уверены, что карта будет точно отрисована в пределах максимального визуального расстояния (MDV).
Чтобы использовать эту функцию необходимо вписать параметр -maxdistance # в строку запуска HLVIS, где # — максимальное расстояние в юнитах.
Однако существует один побочный эффект при использовании MDV. Работа компилятора HLRAD по оптимизации освещения сильно зависит от размера visibility matrix (размера визуальной матрицы). В итоге обычный RAD-компилятор может как бы «обрезать» свет. Но нам волноваться нечего и вот почему.
Данную проблему решает использование вместо стандартного RAD-компилятора, компилятора HLRAD специальной версии от Адама Фостера (Adam Foster). А в состав утилит ZHLT Custom Build включен компилятор HLRAD как раз от Адама Фостера.
Если параметр -maxdistance у компилятора HLVIS установлен, то будет создан дополнительный файл *.VDT с информацией о размере реальной визуальной матрицы (без использования MDV). Затем этот файл используется компилятором HLRAD для создания правильного освещения карты.
Новые параметры компиляторов ZHLT Custom Build
Данные параметры применимы лишь к улучшенной версии компиляторов ZHLT Custom Build и не будут работать с обычными ZHLT. Естественно, что к улучшенным компиляторам можно применять и все остальные параметры, которые работают в официальных утилитах. Об этих парметрах Вы можете прочитать в соответствующей статье из данной Главы.
HLCSG
-nonulltex
Отключает использование NULL-текстур;
-noclipeconomy
Отключает режим экономии clipnode-плоскостей;
-wadconfig имя_конфигурации
Указывает имя конфигурации wad-файлов в файле wad.cfg;
-wadautodetect
Включает режим автообнаружения wad-файлов;
-wadcfgfile путь_к_файлу_wad.cfg
Позволяет вручную указать путь к файлу wad.cfg, по умолчанию компиляторы ищут этот файл в своей директории и в директории с Half-Life;
HLBSP
-nonulltex
Отключает использование NULL-текстур;
-subdivide х, где х — значение от 240 до 512;
Изменяет шаг, с которым карта разрезается на полигоны (по умолчанию 240);
HLVIS
-maxdistance х, где х — расстояние в юнитах;
Устанавливает максимальное vis-расстояние;
HLRAD
-colourgamma r g b
Устанавливает значение гаммы (gamma) в формате r, g, b (красный, зеленый, синий);
-colourscale r g b
Устанавливает значение lightscale в формате r, g, b (красный, зеленый, синий);
-colourjitter r g b
Добавляет шум (помехи) различных цветов, используется для размытия (dithering);
-jitter r g b
Добавляет шум (помехи) монохромного (одного) цвета, используется для размытия (dithering);
-nodiffuse
Выключает diffuse hack для объекта light_environment;
-nospotpoints
Выключает точечный режим отображения объекта light_spot;
-softlight r g b d
Устанавливает значения для backwards-light hack (хака для отраженного света);
-customshadowwithbounce
Позволяет использовать полупрозрачные тени для энтити-объектов при отраженном свете;
NETVIS
Нет изменений
Как ускорить компиляцию?
Один из наиболее частых вопросов, которые задают мапперы, вынесен в заголовок нашей статьи. Действительно, далеко не у всех еще мощные компьютеры, и порой приходится ждать, пока откомпилируется карта, несколько часов. В этой статье мы постараемся рассказать о всех возможных способах ускорения компиляции карты.
Мощность компьютера
Конечно же, в первую очередь, время компиляции зависит от мощности компьютера. Если быть точнее, то от частоты процессора и количества оперативной памяти. Чем больше и того, и другого, тем лучше. Если оперативной памяти мало, то здесь время компиляции начинает зависеть и от скоростных характеристих винчестера. Действительно, если при компиляции свободная оперативная память закончилась, то начинает использоваться SWAP-файл (файл виртуальной памяти). И чем быстрее винчестер передает данные из него, тем быстрее пройдет компиляция.
Что касается конкретных цифр, то, по опыту, для компиляции средней карты (средней как по размерам, так и по сложности внутреннего строения) необходимо порядка 256 Мб оперативной памяти. Лучше 384 Мб. Под словом «средней» следует понимать карту типа De_Inferno. Для более крупных карт памяти может понадобится еще больше. В общем, чем больше памяти у Вас установлено, тем быстрее пройдет компиляция.
Замедление компиляции из-за нехватки памяти
Если Вы наблюдали такую картину: компиляция идет довольно быстро, доходит до 90%, а затем каждый процент преодолевается чуть ли не часами, то это верный признак нехватки оперативной памяти. При этом Вы можете заметить мигание лампочки винчестера, указывающее на использование SWAP-файла.
Часто такая ситуация начинается на операции MakeScales и SwapTransfers компилятора HLRAD. Исправить данную ситуацию можно резким упрощением карты (уменьшением ее размеров, изменением внутреннего строения) или установкой дополнительной оперативной памяти. Выбирайте из этих двух вариантов по своим возможностям. Или же, как третий вариант, попросите откомпилировать свою карту друга :)
Остановка компиляции из-за нехватки памяти
Бывает и так, что компиляция завершается раньше времени из-за полного исчерпания всех видов памяти (и оперативной, и виртуальной). При этом компиляторы ZHLT выдадут примерно такой текст ошибки: «HLRAD.EXE failed to allocate a block of memory». Выходом из ситуации может быть увеличение SWAP-файла или установка дополнительной оперативной памяти.
Программа для компиляции
Скажите НЕТ компиляции через Hammer или Worldcraft. Если у Вас слабый компьютер, используйте для компиляции только пакетный BAT-файл. Дополнительно перед компиляцией уберите все программы из автозагрузки, увеличьте размер SWAP-файла, перезагрузитесь и начинайте компиляцию.
Комплексность карты
Под словом «комплексность» карты следует понимать совокупность размеров карты и сложность ее внутреннего строения. Прекрасными примерами комплексных карт служат довольно известные карты: De_Volare, De_Laguna, Cs_Shogun и др. На каком-нибудь PII-400 при 64 Мб памяти эти карты могут компилировать днями!
Обширные открытые пространства, изобилие наклонных поверхностей различной формы (например, горы), большое количество источников света — все это заметно (!) увеличивает время компиляции. К тому же без должной оптимизации, карты, подобные перечисленным выше, будут несщядно тормозить на любой машине просто потому, что старый движок Half-Life не способен обрабатывать уровни таких размеров и такой сложности.
Чтобы хоть как-то ускорить компиляцию больших карт необходимо, во-первых, закрашивать все невидимые игроком поверхности (крыши домов, обратные стороны стен карты, дно карты) SKY-текстурами, во-вторых, стараться делать дно и внешние стены карты плоскими, без впадин и ям, идеально, чтобы стены и дно образовывали непрерывную плоскость. Первый совет поможет ускорить просчет освещения (одну из основных операций), т.к. при компиляции SKY-текстуры не просчитываются на освещение; второй совет пригодится, если Вы строите небо карты одной большой коробкой, в этом случае между небом и картой не останется «пустот», что ускорит оптимизацию карты компилятором HLVIS.
Источники света
Замедление компиляции может вызвать большое количество источников света, собранных в одном месте. А если они еще будут мигающими или выключающимися, то время компиляции возрастет еще значительнее.
Очень сильно на скорость компиляции влияет количество светящихся текстур, т.е. текстур, излучающих свет. Если Вы используете светящиеся текстуры, то при компиляции программой HLRAD, можно будет заметить существенное увеличение количества источников света (Direct Lights). Например, может быть так, что у Вас на карте используется всего 20 лампочек и несколько светящихся текстур, тем не менее количесво Direct Lights будет около 1000 или даже больше. Конечно же, это существенно замедлит компиляцию на компьютерах с малым количеством оперативной памяти, так как светящие текстуры используют в несколько раз больше памяти, нежели обычные иточники света (light, light_spot и light_environment).
Вывод: не увлекайтесь светящимися текстурами и не размещайте очень много разнообразных (как по цвету и мощности света, так и по состоянию: мигающая, обыная, выключаемая) лампочек в одном месте карты.
Ускорение просчета освещения
Как Вы должно быть уже знаете из предыдущих статей Учебника, компиляцию можно проводить двумя способами: быструю с щадящими параметрами и полную с настройками на максимальное качество. Повторяться не будем. Напомним только, что при тестовой компиляции можно указать для компилятора HLRAD параметр -chop 128 и при этом убрать параметр -extra. Это заметно ускорит компиляцию на обширных картах. Так же можно вообще отказаться от просчета освещения (HLRAD) и оптимизации карты (HLVIS), если компиляция действительно тестовая и служит только для проверки работоспособности энтити-объектов и таймингов карты, т.е. проверки времени встречи команд в разных местах.
Очень полезным может оказаться параметр -incremental для все того же компилятора HLRAD. Этот параметр при первой компиляции и, соответственно, при первом просчете освещения создает файл с информацией об освещении карты. Размер файла будет зависеть от размеров карты, но обычно он занимает нескольких десятков мегабайт (до 100-150). При повторной компиляции с этим же параметром, утилиты ZHLT найдут ранее созданный файл и пропустят некоторые требовательные к ресурсам операции освещения. Данный метод позволяет существенно уменьшить время полной (самой качественной) компиляции больших карт.
NetVIS: или компилируем с другом
Еще несколько ускорить компиляцию поможет проведение операции по оптимизации карты вместе с другом. Если Вы хотите использовать эту возможность, то вместо компилятора HLVIS следует запускать NetVIS. Тогда один из компьютеров (допустим, Ваш) будет сервером, а компьютер друга — клиентом. При наличии очень большой (комплексной) карты время компиляции может быть существенно уменьшено.
Еще не все используют ZHLT!
К великому сожалению, это так... Не все мапперы знают про компиляторы Zoner's Half-Life Tools и продолжают использовать стандартные устаревшие компиляторы. Это тем более удивительно, что в интернете и у нас на сайте постоянно упоминаются именно ZHLT, как самые лучшие компиляторы.
В качестве заключения
Конечно же, время компиляции карты очень сильно зависит от мощности компьютера, но и на слабых компьютерах вполне возможно создавать очень качественные карты. Вспомните, какие компьютеры были осенью 1999 года, когда был создан De_Dust или весной 2001 года, когда появился De_Dust2. Разве обязательно делать огромную карту, ждать часами ее компиляции, а потом разочароваться из-за того, что в эту карту никто не играет? :)