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

На первом этапе мы подготовим текстуры — из формата Targa переведем их в VTF , напишем для них VMT-скрипт , который будет управлять визуализацией и физикой материалов. Затем нужно будет написать qc-скрипт , согласно которому компилятор соберет модель. Потом мы подготовим модель, физическую оболочку, анимации и… откомпилируем то, что у нас получилось.

Текстуры — в материалы

Формат VTF ( Valve Texture Format ) был специально разработан для хранения всех необходимых движку данных о материалах. Кроме самой текстуры с альфа-каналами там располагается карта нормалей, mip-уровни текстуры, являющиеся ее уменьшенными копиями, которые накладываются на объект при большом удалении от камеры (для экономии ресурсов).

Для начала напишем для нашей текстуры VMT-файл. Не будем усложнять себе жизнь и сделаем материал достаточно простым.

“VertexLitGeneric”

{

“$baseTexture” “Models/Combine_soldier/Combine_elite”

“$envmap” “env_cubemap”

“$bumpmap” “models/combine_soldier/combine_elite_normal”

“$normalmapalphaenvmapmask” 1

“$model” 1

“$selfillum” 1

}

Этот скрипт находится в одном из примеров к официальному SDK. Рассмотрим его, а потом вы сами решите, что убрать, а что добавить.

Ключевое слово VertexLitGeneric определяет тип освещения поверхности. Здесь используются вершинные шейдеры. Если бы вы делали материал для своей карты, на который могли воздействовать карты освещенности (то самое, из-за чего на карте появляется свет и из-за чего он так долго компилируется), то на его месте находилось бы слово LightmappedGeneric.

Описатель $BaseTexture указывает, где располагается ваша текстура в формате Targa. $envmap определяет тип взаимодействия освещения карты и окружения вообще с материалом. Здесь использована константа env_cubemap , определяющая, что поверхность будет блестеть и при этом на нее будут накладываться кьюбмэпы (cubemap) — особый вид текстур, состоящий из шести элементов. Эти элементы являются квадратными текстурами, и на них изображены все стороны света, верх и низ соответственно. В первой части HL так делались небеса.

Параметр $bumpmap показывает, что на вашу текстуру будет применен бампмеппинг, а путь после этого слова указывает, где находится карта высот. Затем идет идентификация карты нормалей. Единица указывает на то, что для этого материала определена карта нормалей и только часть модели, определенная альфа-каналом, будет отражать кьюбмэпы.

Далее следует описатель $model , единица после которого означает, что эта текстура будет накладываться на полигональную модель. $selfillum определяет, что часть текстуры, выделенная альфа-каналом, будет “самосветящейся” (как глаза у комбайнов).

Разумеется, все приведенные элементы вам не понадобятся, поскольку все разом они не могут быть отображены. Например, самосвечение перекроет кьюбмэпы и карты нормалей, и их не будет видно.

После того как вы прописали в VMT-файле нужные элементы, приступим к созданию текстового файла, описывающего процесс компиляции через инструмент vtex.exe , обитающий в недрах официального SDK. Вот пример такого файла:

_ $nolod //Не использовать функцию level of detail_

$nomip //Не разделять текстуру на mip-уровни

$clamps //Не повторять текстуру по S-координате

_ $clampt // Не повторять текстуру по S-координате — используется для текстур вроде спрайтов, не требующих повторения (тайлинга)_

_ $skybox // Текстура будет использована как один из шести элементов неба_

_ $startframe (integer) //Для анимированных текстур — начальный кадр_

$endframe (integer) //Для анимированных текстур — конечный кадр. Имя текстуры при этом должно быть mytex001.tga ; mytex.002.tga ; mytex003.tga и т.д.

_ $nocompress //Не использовать сжатие текстур_

_ $nonice //Не использовать NICE-фильтр для низших mip-уровней_

_ $dxt5 //Использовать сжатие dxt5 вместо полного по умолчанию_

Как говорится — лишнее зачеркнуть. После того как файл будет создан, вам нужно будет выделить файлы tga, vmt и только что созданный txt и перетащить их на значок файла vtex.exe. Он скомпилирует файл материала и выдаст сообщение об успешности операции (или ошибке — если вы сделали что-то не так). Откомпилируйте все текстуры.

Переходим к следующему этапу.

Компиляция модели

Для начала нам следует экспортировать модель в smd-файл. В XSI или в 3D Studio — не важно, экспортируется одинаково, только в последнем случае нужен плагин-экспортер, который можно взять с наших дисков. При нажатии Export вам будет задан вопрос, в каком виде сохранить модель.

Сначала сохраните ее как reference — это основная геометрия модели с координатами текстур. Затем очередь анимаций. Если у вас их много — экспортируйте каждую. Возможно, анимации у вас хранятся в отдельных файлах — тогда откройте их поочередно и сохраните как sequence.

Настало время создания физической оболочки. Это условная модель, по которой работает физика столкновений. Физическая оболочка должна быть выпуклым телом, то есть сложные элементы не подойдут, иначе движок доведет их до выпуклых. Как же быть? Выход есть — нужно разбить сложную модель столкновений на несколько простых, выпуклых, и после этого каждой из них присвоить свою группу сглаживания ( smoothing groups ), тогда все будет нормально.

Рекомендую сначала сделать вокруг модели ее физическую оболочку и только потом удалить модель (скелет не трогайте), а оболочку привяжите к соответствующим костям, чтобы физическая оболочка двигалась так же, как и видимая модель. Теперь можно и ее экспортировать.

Все, что нужно, подготовлено — осталось лишь собрать все воедино. Это делается в специальном скриптовом файле с расширением qc.

Вот пример простейшего скрипта:

$modelname MyModel.mdl

_ $scale 1.0_

_ $body “Body” MyModelReference.smd_

_ $cd “C:/mypath”_

_ $staticprop_

_ $sequence SeqNameMyModel “MyModel_idle” fps 30_

_ $collisionmodel “mymodel_phys.smd”_

_ {_

_ $mass 132_

_ }_

Первая строка задает имя модели. Так будет называться файл, содержащий модель. Вторая строка отвечает за масштаб модели по сравнению с оригиналом. Параметр $body определяет название геометрии модели и название файла, содержащего эту геометрию. $cd задает путь к директории компилируемой модели. Если путь не задан, то модель выбирается из директории, где лежит файл qc.

Параметр $staticprop объявляет, что модель статична и не содержит анимации, кроме необходимой для компиляции (обычно там делают всего один кадр). Эта команда позволяет движку игнорировать движение костей внутри модели, в результате модель быстрее рендерится. Подходит только для статичных моделей вроде бочек, вывесок и похожих.

$sequence определяет анимацию, сразу после этого описателя идет название анимации и затем в кавычках — имя файла анимации. Слово fps задает скорость проигрывания анимации. Если у вас в редакторе анимация получилась длинной, например 30 кадров, и скорость проигрывания анимации вы поставите тоже 30 кадров, то анимация будет проиграна за 1 секунду, если же поставить скорость 15, то анимация проиграется за 2 секунды.

Параметр $collisionmodel задает имя файла с физической оболочкой. После идет блок команд в фигурных скобках. Команда всего одна — масса объекта, задается вами в килограммах. Например, бутылка водки будет иметь значение 0,5; а бронетранспортер БТР-80 — 13600.

Когда файл компиляции закончен, можно собрать модель. Делается это так же, как и в случае с текстурами. Перенесите значок qc-файла на значок studiomdl.exe , после чего начнется компиляция. Когда все будет закончено, модель появится в определенной вами директории.

Финальные аккорды

Вот мы и научились основам создания моделей для Half-Life 2. Многое осталось за кадром, но самые главные моменты мы рассмотрели. На базе полученных знаний вы можете самостоятельно творить и экспериментировать.

В описании компиляции нет ничего сложного, но иногда объемы текста просто поражают. Например, при создании ragdoll’а нужно описать каждый сустав и индивидуально задать ему диапазон подвижности. При создании техники нужно также описать очень много параметров, таких как точки соприкосновения с поверхностью, амортизация, анимация поворота и радиус поворота колес и много чего еще.

Пока поддерживается только четырехколесная техника, но, используя исходный код, предоставляемый Valve, это можно исправить. При создании моделей оружия важно помнить, что отображаемая на экране модель подгоняется под положение камеры — игрока. Камера всегда располагается в начале координат и смотрит вдоль оси X. Поэтому располагайте модель чуть ниже нулевой горизонтальной плоскости. Тогда ее будет хорошо видно на экране при тестировании.

Ошибки разные бывают

Коротко о возможных ошибках. Самые типичные из них — не найден файл материала, не привязаны кости к модели (если в модели остался хоть один свободный вертекс, модель не удастся экспортировать).

Не ставьте физическую оболочку копией файла reference — это, в зависимости от сложности модели, сильно нагружает процессор расчетом физики. Если расположение костей и их количество в файле геометрии не совпадает с количеством в файле анимации, то в лучшем случае компилятор выдаст ошибку, в худшем — компиляция произойдет, но при этом вся анимация изменится до неузнаваемости.

Если вы меняете скелет, то нужно создавать новую анимацию. Если ваши текстуры имеют размерность, не кратную двум, то результат также будет плачевным. Внимательно следите за вышеописанными вещами — и все будет нормально.

* * *

На этом вводный курс в моделирование завершен. Ждем ваших писем с отзывами и конкретными вопросами, ответы на которые мы напечатаем в игростроевской “Горячей линии”.

Также обратите внимание, что все статьи цикла “Моделлинг Half-Life 2” мы выкладываем на диск в разделе “ ИнфоБлок ”. Если что-то пропустили, то вам туда — прямой наводкой.