Urbi et Orbi

Глава седьмая
Предисловие
Глава №7 - это учебное пособие посвящённое расширенному пояснению механики
и всем аспектам введения нового объекта архитектуры из шестой главы.
Учебное пособие публикуется с сохранением стилистики подачи материала от автора.

How to bring custom buildings in-game
Как ввести пользовательские здания в игру
Источник

Spoiler (expand)

Автор Mr.Jox
Перевод и адаптация vadim

Вступление.
Ранее было создано довольно подробное руководство по введению нового здания в игру, и теперь настало время дополнить и пояснить отдельные его элементы и понятия. В этой серии уроков я собираюсь предоставить вам самую свежую информацию о том, как ввести в игру ваш пользовательский объект и заставить его адекватно находится и функционировать в самой Игре.

Оглавление
1. Перечисление элементов объекта для его введение в Ted
2. создание элементов объекта
3. Применение атрибутов
4. Экспорт в .cs2
5. Настройка rules.bob и конвертирование
6. Как заставить ваш объект отображаться в TEd

Перечисление элементов объекта для его введения в Ted
Объект, который вводится в конструктор Ted состоит из технических элементов необходимых для точного ввода всего объекта /со всеми его параметрами/
Итак, разберём все элементы всё по пунктам
1) Geometry файл геометрии объекта (3d модели, состоящие из различных уровней LOD);
2) Collision файл коллизии (коллизии 3d модели, которые не должны быть показаны в игре, однако они служат технической характеристикой вашего объекта в игре);
3) Animation файл прописи анимации объекта (как правило это несколько анимационных кусков модели, то есть в принципе это несколько роликов с вашей вводимой модели);
4) Geometry reference описание примитива геометрии объекта (произвольная примитивная геометрия, которую вы используете для ссылки на уже существующею вашу модель);
5) Hard файл (примитивная фигура, состоящая из замкнутой серии линий, которые определяют форму вашего объекта);
6) Ground_ad (примитивная линия с 2 вершинами, определяющая в некотором роде линию подсказки AI на уровне земли);
7) Platform (плоская 3d модель, которая используется для определения стоячей позиции (позиций) для юнитов);
8) Platform ground (примитивная плоскость на уровне земли, которая определяет, как и где юнит будет проходить через ваш разрушенный объект);
9) EFline (примитивная линия, которая используется для определения поведения юнита в определенном месте на платформе в соответствии с геометрией вашего актива);
10) Docking line линия стыковки (примитивная линия, определяющая местоположение осадного инвентаря/башни или лестницы/, который будет использоваться для прохождения через ваш объект);
11) Region zone зона региона (примитивная фигура, состоящая из серии линий и служащая некоторой логической цели вашего объекта);
12) Pipes тоннель (примитивная фигура из серии линий (не замкнутых), которая определяет, как юнит должен забраться на ваш актив. В некотором роде я называю это телепортом);
13) Arrow emitter зона стрельбы (примитивная геометрическая фигура, задающая вектор стрелы башни, из которой будет выпущена стрела);
14) Flag флаг (некая позиция флага на вашем объекте).
Давайте подробно рассмотрим каждый элемент. Для единообразия между различными элементами и для облегчения понимания дальнейших шагов я буду описывать данные пункты в сочетании их с атрибутами (которые будут использоваться в последующих шагах).

Geometry Геометрия
Полное описание процесса создания 3d-моделей для вашего объекта не входит в данную тему, и я предполагаю, что вы знакомы хотя бы с основами 3d-моделирования и текстурирования.
Здесь мы рассмотрим, геометрию как элемент вашего вводимого объекта, стандарт наименования и свойства вашей геометрической модели.
Геометрический объект — это актив, который вы видите в игре. Это видимая часть вашей модели в игре.
Геометрия обычно разбивается на LODs Лоды (уровени детализации), что означает, что ваш объект будет иметь градацию, повторяющихся, но упрощённых таких же копий объектов в 3DMaxe и будет отображаться чуть упрощённей для отлёта камеры на тактической карте Игры. Обычное количество LODов на одну модель здания - 5.
Помимо LODов каждый геометрический объект может быть разделен на несколько частей. Это означает, что вы можете создавать различное количество моделей и рассматривать их как части одного и того же большого объекта.
Последний аспект геометрии, о котором мы должны упомянуть, это destruction ID - оригинальный ключ ID разрушения . Destruction ID определяет, какая геометрия будет показана на разных уровнях разрушения. До сих пор мне посчастливилось увидеть до 4 уровней разрушения, используемых в ванильных активах.
Naming standard Стандарт именования: pieceID_destructID_lodID
Где pieceID - это ключ вашей детали. Куски не могут иметь одинаковые ID, если не предполагается, что они будут заменены другим объектом с повышенным уровнем разрушения. Обычно на одну модель приходится один/два/три объекта. Большее количество частей необязательно, но хотя бы одна должна быть обязательно.
destructID - это идентификатор уровня разрушения. Здесь в ID части вы должны указать точно такой же ID части, какой вы использовали для предыдущего ID уничтожения, чтобы позже во время игры, когда вы уничтожите актив, модель была заменена следующим по порядку уничтожаемым активом. Обычно принято иметь один/два/три уровня уничтожения. Более высокие уровни необязательны, но хотя бы один обязателен.
lodID - это номер вашего лода. Как мы уже говорили, 5 — это стандартное количество лодов на один геометрический объект.
Кусок — это минимальная единица измерения. Для каждого куска у вас есть как минимум один уровень разрушения, и для каждого уровня разрушения у вас есть 5 LOD.
rigid_TYPE STAND_RIGID
class_TYPE DISPLAY
piece_INFO pieceID (такой же, как и в имени объекта)
destruct_ID destructID (такой же, как и в имени объекта)
graphics_OPTION GRAPHICS_HIGH
class_rigidINFO lodID
rigid_OBJECT
LODs example picture - пример градации лодов /по уровню качества/

pieces example picture – фрагмент градации файла

pieces example picture - разрушение пример на картинке ниже

Collision3d Файл Коллизии3d
Файл Коллизии3d - это невидимый геометрический элемент модели, который определяет некоторые физические свойства вашего нового объекта. В основном Collision3d помогает движку понять, попадает ли снаряд в ваш объект или нет. Этот элемент также не позволяет юнитам пройти через невидимую геометрию нового объекта в соответствии с его формой. Главным требованием при создании Коллизии является как можно меньшее количество вершин в объекте, потому что каждая вершина участвует в тяжёлом алгоритме просчёта самого эффекта, и это влияет на производительность и быстродействие в самой Игре. В отличие от геометрии, коллизия не имеет уровней LOD.
Naming standard Стандарт именования: pieceID_destructID_collision3d_[optional]
Где pieceID и destructID соответствуют ключам нового объекта (каждая часть коллизии должна соответствовать общей форме части объекта, а каждый уровень разрушения коллизии должен соответствовать общему уровню разрушения объекта).
collision3d - специальный тег, который указывает конструктору что это элемент объекта сделанный для того чтобы показывать коллизию этого объекта. Тег [optional] используется в особых случаях, например, если вы создаете актив шлюза. Поскольку у вас есть геометрия ворот, которая динамична при различных обстоятельствах, вам необходимо определить специальные теги, такие как gate_ajar и gate_closed.
Пример именования: piece02_destruct01_collision3d_gate_ajar означает, что piece02 - это коллизия модели не разрушенных ворот (в открытом режиме).
rigid_TYPE STAND_RIGID
class_TYPE TECH
piece_INFO pieceID (такой же как в имени объекта)
destruct_ID destructID (такой же как в имени объекта)
graphics_OPTION NOT_GRAPHICS
class_rigidINFO collision3d_[optional] (_[optional] это особый случай для открытых ворот, в других случаях вы должны использовать collision3d)
rigid_OBJECT
Collision3d пример на картинке ниже

Collisions Коллизии создаются на каждый объект и при каждом разрушении этого объекта

Animation Анимация
Анимация - это набор видимой геометрии с собственным анимационным клипом. Чаще всего анимация воспроизводится, когда ваш объект меняет уровень разрушения из-за повреждения. Во время этого процесса ваши оригинальные геометрические модели скрываются, а вместо них становится видимой геометрия анимации, которая воспроизводится до тех пор, пока не закончится, после чего вся геометрия, связанная с анимацией, снова скрывается, а вместо нее в игре отображается геометрия следующего уровня разрушения. Короче говоря: piece01_destruct01_lod1 получает повреждения определенной степени и согласно значению db в какой-то момент piece01_destruct01_lod01 становится невидимым и в то же время все модели building_piece01_destruct01_anim становятся видимыми, все их анимационные треки проигрываются до самого конца, а затем все building_piece01_destruct01_anim снова скрываются и игра делает видимым piece01_destruct02_lod01.
Вот цепь последовательности файлов с ключами /которые прописываются в Игре/ piece01_destruct01_lod01->building_piece01_destruct01_anim->piece01_destruct02_lod01 .
Файлы анимации обычно являются наиболее трудоемкими элементами объекта для создания. В отличие от создания meshes меша объекта, я вкратце опишу, как создавать анимации нового объекта.
Я использую плагин PhysX от NVIDIA для 3ds max. Я копирую свои геометрические модели, которые должны быть анимированы, вручную разбиваю их на различные части с тем же начальным положением, которое имела исходная mesh сетка, а затем определяю свойства rigid_body/kinematic_body/static_body плагина PhysX и моделирую сцену. Обычно мне приходится исправлять некоторые анимации, которые не выглядят законченными после разрушения.
Naming standard стандарт именования building_pieceID_destructID_[optional]_anim
Где building - это постоянный префикс, pieceID соответствует ключу объекта pieceID оригинальной геометрии, destructID соответствует оригинальному destructID (вы никогда не делаете анимацию для последнего уровня разрушения, потому что вы не можете разрушить самую разрушенную модель), а anim - это тег, который заставляет конструктор рассматривать этот ваш элемент как объект анимации. Тег [optional] определяет специальные анимации для различных состояний ворот (gate_closing, gate_opening, gate_closed_destruct, gate_open_destruct).
Важно отметить, что каждый новый фрагмент вашей оригинальной части должен быть назван таким же образом. Другими словами, когда вы разбиваете вашу исходную mesh сетку на куски этой исходной сетки, каждый кусок этой конкретной сетки должен иметь точно такое же имя.
Например, у нас был piece01_destruct01_lod01, и мы создали из него 10 кусков. Каждый фрагмент этой сетки должен быть назван как building_piece01_destruct01_anim
rigid_TYPE STAND_RIGID
class_TYPE DISPLAY
piece_INFO pieceID (такой же как в имени объекта)
destruct_ID destructID (такой же как в имени объекта)
graphics_OPTION GRAPHICS_HIGH
class_rigidINFO [optional]_anim (where [optional]_ это особый случай для ворот, в других случаях вы должны использовать anim)
rigid_OBJECT
Animation picture example – пример анимации

(обратите внимание, что последний кадр анимации полностью соответствует последнему уровню разрушения башни, за исключением частей, которые ушли под землю - именно такого результата вы должны добиться, чтобы сделать плавный переход) - поэтому сначала вы создаете неповрежденную геометрию -> создаете из нее анимацию, разбивая ее на независимые фрагменты и анимируя их с помощью NVIDIA's PhysX -> создаете поврежденную версию здания, копируя фрагменты анимации и объединяя эти объекты в один меш с именем pieceID_destruct02_lodID.

Geometry reference Ссылка на референц объект
Представьте, что вы сделали/нашли другой небольшой объект, такой как факел или дверь, или повторяющийся кусок стены и хотите использовать его в другом активе один или несколько раз. Иногда лучшим способом сделать это является ссылка на этот другой объект. Это именно то, чем является ссылка на geometry reference. Представление ссылки не является строгим. Это означает, что вы можете создать простой куб и использовать его как ссылку на другой объект. Что заставляет ссылку работать, так это правильное именование и атрибуты. Это не значит, что вы не можете использовать исходную модель в качестве ссылки. Иногда вы хотите увидеть, как она привязана к вашему объекту, поэтому лучшим способом будет использование исходной модели в качестве ссылки на саму себя.
Naming standard стандарт именования pieceID_destructID_file:filename
Где pieceID и destructID уникальны для самого референца, а не для модели, на которую вы ссылаетесь. тег file заставляет конвертер BOB рассматривать объект как ссылку на другой объект с именем filename, которое является точным именем актива, на который вы ссылаетесь.
Пример именования: piece01_destruct01_file: torch_sconce
rigid_TYPE STAND_RIGID
class_TYPE TECH
piece_INFO pieceID (такой же как в имени объекта)
destruct_ID destructID (такой же как в имени объекта)
graphics_OPTION NOT_GRAPHICS
class_rigidINFO key
rigid_OBJECT заданный путь к файлу (например, RigidModels\Buildings\torch_sconce\ where RigidModels\Buildings это местоположение ваших исходных и референц обьектов, а torch_sconce - имя на ссылающейся объект).
Пример инстанцирования файлов ниже

Hard хард элемент
Хард элемент - это примитивный объект, состоящий из замкнутого набора линий. Он приблизительно описывает границы видимого объекта на уровне земли. Харды используются для каждого уровня destruct /разрушения/. В большинстве случаев у вас есть только один хард для destructID, но в особых случаях, как в случае с воротами, вы создаете два харда на destructID объекта.
Naming standard стандарт именования pieceID_destructID_[optional]_hardID
Где pieceID и destructID - атрибуты именования прикрепленного геометрического файла. Тег tag [optional] используется для особых случаев, таких как ворота (например, piece02_destruct01_outlineID_hard). Как вы видите, при использовании опционального тега вы не указываете ID hard, а указываете ID optional. Тег hard является наиболее часто используемым, и если вы не указываете опциональный тег, вы также должны указать ID hard. В большинстве случаев это просто hard01. Хард создается на основе каждого разрушения (то есть вы должны создавать хард для каждого уровня разрушения destruction level).
В отличие от всех предыдущих объектов, которые рассматриваются как meshes сетки, этот объект не является сеткой. Это набор линий. Таким образом, в 3ds max для создания хардов используется объект Line.
rigid_TYPE STAND_RIGID
class_TYPE TECH
piece_INFO pieceID (такой же как в имени объекта)
destruct_ID destructID (такой же как в имени объекта)
graphics_OPTION NOT_GRAPHICS
class_rigidINFO [optional]_hardID (где [optional]_ используется для некоторых случаев, специфичных для ворот. В большинстве случаев необходимо использовать hardID. Однако если вы указываете необязательный тег, вы не должны указывать hard's ID)
rigid_OBJECT
Hard example picture пример площадки

Ground_ad поверхность земли
Тип объекта ground_ad используется для определения AI Hint, насколько я понял. Он состоит строго из 2 вершин и является объектом Line в сцене 3ds max. Обычно вы располагаете его в начале на уровне земли (это означает, что Z(вверх) = 0) с позицией Y(вперед/назад), смещенной в зависимости от того, где находится центр вашего актива вдоль этой оси). X также определяется как 0.
Naming standard стандарт именовани: pieceID_destructID_ground_ad
Где pieceID и destructID обычно имеют ID = 01 (потому что ground ID является единичным для модели и поэтому прикреплен к основной части, и ни один из уровней destruct _разрушения, кроме 01, не имеет этого типа объекта).
rigid_TYPE STAND_RIGID
class_TYPE TECH
piece_INFO pieceID (такой же как в имени объекта)
destruct_ID destructID (такой же как в имени объекта)
graphics_OPTION NOT_GRAPHICS
class_rigidINFO ground_ad
rigid_OBJECT
пример координатной площадки/земли/

Platform платформа
Объект платформы обычно представляет собой примитивную плоскую сетку, покрывающую область, которая позволит вашим юнитам стоять и передвигаться. Здесь важно упомянуть, что если вы создаете крепостные объекты, такие как стены, башни, ворота и т.д., вы должны убедиться, что платформы идеально соединяются и привязываются вершина к вершине в зонах соединения. В противном случае вы столкнетесь с тем, что юниты не смогут развернуться/переместиться на ваших объектах. Так же платформа создается на основании каждого destruct basis базисного разрушения объекта.
Naming standard стандарт именования: pieceID_destructID_platformID
Где pieceID и destructID - соответствующие ID "родительского" объекта видимой геометрии, т.е. если у вас есть стена, обозначенная как piece01_destructID_lodID, и вы создаете платформу для этой стены вы должны присвоить элементу ID идентификатор его видимой геометрии.
platformID - это уникальный ID платформы для каждого отдельного разрушения. Как вы можете догадаться, вы можете иметь более одной платформы на один уровень разрушения.
rigid_TYPE STAND_RIGID
class_TYPE TECH
piece_INFO pieceID (такой же как в имени объекта)
destruct_ID destructID (такой же как в имени объекта)
graphics_OPTION NOT_GRAPHICS
class_rigidINFO platformID
rigid_OBJECT
Platform пример на картинке ниже

Platform_Ground платформа_земли
Тип объекта platform_ground используется для того, чтобы позволить юнитам проходить через разрушенную версию вашего актива. Как вы можете догадаться, он используется в основном для разрушенных частей стены, как последний уровень разрушения. Platform_ground имеет относительно простую форму, но в отличие от обычной платформы, эта не является идеальной прямой плоскостью. Она имеет несколько изогнутую форму, где середина - самая высокая точка, а стороны - самые низкие, поэтому, когда юниты ступают на эту платформу, это выглядит так, будто они забираются на кучу мусора/отбросов. Границы этой платформы должны совпадать с границами вашего разрушаемого объекта, чтобы не казалось, что юниты пролетают над объектом или проходят под ним. Эта платформа все еще сделана из плоского примитивного 3d объекта и не имеет задних граней, только грани над уровнем земли (отсюда и название). Обычно platform_ground - это один объект такого типа на весь объект.
Naming standard стандарт именования: pieceID_destructID_platform_ground
Где pieceID и destructID наследуются от вашего последнего уровня разрушения. platform_ground - это постоянный тег, помогающий инструменту конвертации рассматривать его как объект platform_ground (очевидно).
rigid_TYPE STAND_RIGID
class_TYPE TECH
piece_INFO pieceID (такой же как в имени объекта)
destruct_ID destructID (такой же как в имени объекта)
graphics_OPTION NOT_GRAPHICS
class_rigidINFO platform_ground
rigid_OBJECT
Platform_ground пример на картинке ниже

EFLines линии бойниц/амбразур/
Уверен, что EFlines быстро станет самым ненавистным объектом в вашем наборе элементов для вашего объекта.
Эти линии представляют собой небольшие линейные объекты, основанные строго на 2 вершинах (да, те же линии используются для хардов). У вас есть набор EFLines для каждой платформы, потому что в процессе конвертации все ваши eflines привязываются к платформам, и если хотя бы одна из них не совпадает, вы не сможете конвертировать свой объект. Именно это и может сделать его неприятным именно для вас, как для автора всего этого хозяйства, которое вы хотите ввести в конструктор Ted.
Что же представляют собой эти элементы? Именно эти элементы/извиняюсь за тавтологию/ определяют поведение юнита, когда он стоит в пределах зоны efline. Вы когда-нибудь сталкивались с тем, как юниты поворачивают свои тела возле зубцов -бойниц на стенах, в то время как остальные юниты стоят позади них и ведут себя по-другому? Это именно то, для чего используются efline.
Обычная практика - иметь около 200 eflines на сцену/объект. Что еще хуже, приходится прикреплять атрибуты и свойства для каждого из них. К счастью, я нашел способ создать скрипт для 3ds max (он будет представлен в последнем уроке), который облегчает работу и делает всю эту работу одним щелчком мыши. Однако перед использованием скрипта вы должны создать все свои eflines и убедиться, что результат окончательный, потому что процесс необратим.
Naming standard стандарт именования: EFline_pieceID_destructID_lineID
Где EFline - константный тег, определяющий объект как объект efline. pieceID и destructID соответствуют соответствующей платформе (чтобы понять "родительскую" платформу вашего efline, просто проверьте глазами, лежит ли он на платформе или нет.
тег lineID обозначает уникальный идентификатор вашей линии. Важно отметить, что линии в пределах одного уровня разрушения не могут иметь одинаковый lineID, даже если они прикреплены к разным частям.
rigid_TYPE STAND_RIGID
class_TYPE TECH
piece_INFO pieceID (такой же как в имени объекта)
destruct_ID destructID (такой же как в имени объекта)
graphics_OPTION NOT_GRAPHICS
class_rigidINFO EFLineID
rigid_OBJECT

Docking_lines линии стыков при штурме
В отличие от EFLines, стыковочные линии легко и быстро создаются. Очевидно, что, как и EFLines и Hards, DockingLines - это те же объекты "линии", состоящие из 2 вершин (возможно, вы можете использовать больше, но я почти уверен, что строго 2 вершины и одна линия на dockingLine).
Эти линии служат точкой крепления осадных машин для десанта/осады вашего объекта (стена - осадная башня, ворота - таран и т.д.). Вы можете иметь несколько стыковочных линий на уровень разрушения, но у вас нет стыковочных линий на последний поврежденный уровень разрушения (очевидно, потому что он уже разрушен).
Naming standard стандарт именования: DockingLine_pieceID_destructID_lineID
Где DockingLine - константный тег, определяющий тип объекта. pieceID и destructID - соответствующие ID прикрепленной геометрии, а lineID - уникальный ID для каждой линии.
rigid_TYPE STAND_RIGID
class_TYPE TECH
piece_INFO pieceID (такой же как в имени объекта)
destruct_ID destructID (такой же как в имени объекта)
graphics_OPTION NOT_GRAPHICS
class_rigidINFO DockingLineID
rigid_OBJECT

Region_zones зоны_регионов
Region_zones не совсем понятны даже мне. По моему опыту, они определяют так называемую "зону поля боя" (да, похожую на ту, что есть в редакторе TEd), и эта зона позволяет вашим юнитам перемещаться/развертываться и делать остальные осадные действия на вашем объекте. Если EFLines и DockingLines определяют само действие/цель и определяют позиции для этого, то region_zones позволяют использовать эти линии в пределах области, определенной в region_zone. Область region_zone состоит из набора Lines линий и является объектом из Line в сцене 3ds max. Он создается так же, как и Hard элемент. Поэтому к region_zones применимо правило для Hard элементов: она должна быть заключена в набор линий, то есть первая и последняя вершины должны быть соединены общей линией.
Naming standard стандарт именования: region_zoneID
Где ID — это уникальный идентификатор объекта region_zone. Это означает, что вы можете иметь несколько региональных зон для одного объекта. Обычное количество region_zones в вашей сцене - 2 region_zones с 4 вершинами каждая (в случае, если ваш объект прямой). Мне неизвестно, почему вы должны определить как минимум две зоны региона, если вы покрываете одну и ту же область двумя зонами, а не одной.
rigid_TYPE STAND_RIGID
class_TYPE TECH
piece_INFO pieceID (определяется 01 как ID для такого типа объекта)
destruct_ID destructID (определяется 01 как ID для такого типа объекта)
graphics_OPTION NOT_GRAPHICS
class_rigidINFO region_zoneID
rigid_OBJECT

Pipe_wall_door стеновой тоннель_дверь
Тоннель — это "открытые - не замкнутые" наборы Линий (то есть вам не нужно соединять последнюю вершину с первой). Тип объекта в сцене - "Линия". Идея этого типа объекта - своего рода телепорт, и вот почему: когда вы приказываете юнитам забраться на стены, они идут к этим входу_тоннелю (невидимым в игре и обычно расположенным внутри дверей, соединяющих верхнюю и нижнюю двери), и как только они оказываются на определенном близком расстоянии от тоннеля_двери, они исчезают возле нижней двери и появляются у верхней двери на верху стены. Вот почему я называю это телепортацией.
Этот набор линий выглядит как линия, входящая внутрь геометрии двери (напоминающая нормальный вектор, но не строго перпендикулярная), затем следующие линии меняют направление в сторону оси вверх, а затем еще раз меняют направление в сторону верхних дверей. Именно поэтому этот объект называется тонель или труба - потому что его архитектура напоминает обычные отопительные короба_тонели или водопроводные трубы, которые вы используете для обогрева дома (они находятся либо возле стены, либо встроены в стену).
Naming standard стандарт именования: pieceID_destructID_pipe_wall_doorID
Где pieceID и destructID наследуются от имени родительского объекта (обычно это piece01 и destruct01, потому что трубы в большинстве случаев используются на уровне разрушения без повреждений, а не на уровне разрушения с повреждениями (очевидно, потому что двери сломаны)). pipe_wall_doorID - уникальный идентификатор конкретного объекта трубы.
rigid_TYPE STAND_RIGID
class_TYPE TECH
piece_INFO pieceID (определяется 01 как ID для такого типа объекта)
destruct_ID destructID (определяется 01 как ID для такого типа объекта)
graphics_OPTION NOT_GRAPHICS
class_rigidINFO pipe_wall_doorID
rigid_OBJECT

Arrow_emitter метатель стрел
Тип объекта arrow_emitter используется в основном для башен и предназначен для определения направления и положения (другими словами, вектора) стрелы, которая будет выпущена из вашей башни. Обычно в вашем объекте на башни есть небольшие окна в качестве бойницы_амбразуры, откуда будут метаться стрелы, и именно там вы должны разместить ваши метатели стрел. По моему опыту, метатели стрел могут быть любой формы, однако рекомендуется сделать их в виде плоскости с одной стороной, чтобы она определяла направление. Позже вы сопоставите положение и направление (и масштаб) объекта-плоскости с окном, из которого будет выпущена стрела, и сделаете это N раз (где N - количество окон в вашем объекте).
Naming standard стандарт именования: pieceID_destructID_arrow_emitterID
Где pieceID и destructID наследуются от имени родительского файла (геометрия со встроенными окнами для этой цели). Обычно ваши pieceID и destructID всегда = 01, потому что по очевидным причинам, когда ваша башня повреждена/разрушена, у вас больше нет доступа к бойницам для стрельбы (потому что первое, что будет повреждать игровой AI — это ваши башни).
EmitterID — это уникальный идентификатор вашего объекта-эмиттера, заданный в числовом порядке (так же, как и для любых других идентификаторов объектов).
rigid_TYPE STAND_RIGID
class_TYPE TECH
piece_INFO pieceID (определяется 01 как ID для такого типа объекта)
destruct_ID destructID (определяется 01 как ID для такого типа объекта)
graphics_OPTION NOT_GRAPHICS
class_rigidINFO arrow_emitterID
rigid_OBJECT

Flag флаг
Flag - самый неизвестный для меня тип объекта на данный момент. Я не пробовал проверить, для чего он используется, но если вы спросите меня, я бы поставил на то, что он используется как идентификатор для элемента пользовательского интерфейса, на котором он должен быть размещен. Представьте, что вы создаете башни разного масштаба, одни больше, другие меньше. Если вы программист, как вы убедитесь, что элемент пользовательского интерфейса (тип иконки актива, например, башня, ворота, стена и т.д.) находится только над объектом, а не внутри него (где-то посередине)?
С моей точки зрения, у вас есть два варианта: либо найти максимальные положения вершин и поместить элемент пользовательского интерфейса над этими значениями с некоторым заданным смещением, либо использовать специальный идентификатор, такой как этот флаг (флаг UI?).
В любом случае, это только мое предположение, и я не проверял, верно оно или нет, но то, что я могу сказать о процессе создания этого элемента объекта, выглядит следующим образом: Флаг — это любой вид геометрии, но обычно я использую бокс как место для объекта флага и определяю положение флага, указывая позицию для объекта бокса. Обычно флаг располагается на 2 или даже 3 метра выше самой высокой вершины объекта.
Naming standard стандарт именования: flag
Где flag — это постоянный тег. Как вы можете видеть, тег flag не имеет постфикса ID, и это означает, что вы можете иметь не более одного флага на ваш объект.
rigid_TYPE STAND_RIGID
class_TYPE TECH
piece_INFO piece01
destruct_ID destruct01
graphics_OPTION NOT_GRAPHICS
class_rigid INFO flag
rigid_OBJECT

Object Creationc Pipeline Конвейер создания объекта.
Для того чтобы правильно построить сцену в 3ds max наиболее быстрым и простым способом с минимальным количеством проб и ошибок, я обозначил так называемый конвейер создания объектов (OCP). Его цель - описать шаги, с чего начать, в каком порядке следовать и как собрать все воедино.
Мы разобьем OCP на следующие шаги:
1. Сначала создается атлас текстур. Это не очевидно, но для экономии памяти и повышения производительности вам необходимо сделать атлас текстур, который включает в себя все необходимые шаблоны текстур для всех случаев. Это означает, что вы используете одну текстуру для каждой модели определенной культуры. Вы можете посмотреть, как выглядят атласные текстуры в файлах ванили. Создание текстуры выходит за рамки данного руководства.
2. Создайте все lod части mesh сетки вашей модели. Очень важно строго следовать концепции модели, которую вы делаете. Потому что, если вы не уверены в окончательной форме, которую хотите создать, вам придется переделывать все почти с нуля несколько раз. Небольшие изменения все же допустимы на более поздних этапах, но постарайтесь свести их к минимуму. Здесь также очень важно учитывать, будет ли ваша модель самостоятельной или станет частью другой, более крупной модели. Например, с одной стороны, вы можете сделать отдельную модель произвольного дома, которая требует буквально только mesh_сетки и коллизий, но с другой стороны, вы хотите создать модели, которая будет соединена с воротами, башнями и другими частями крепостных укреплений. Это означает, что вы должны где-то сохранить размеры и точно следовать этим размерам. В противном случае ваши части не будут совпадать и логика не будет работать (логика означает, что ваши юниты не смогут размещаться на стенах, перемещаться по ним и т.д.).
Если вы просите совета, добавьте объект соединения в вашу сцену, только для ссылок на размеры. На этом конкретном этапе рекомендуется не создавать LODы, а только фрагменты и соответствующие им уровни разрушения. Важно: не создавайте поврежденные/разрушенные модели на этом этапе! Иначе вы рискуете не совместить их с анимацией.
3. Настройте параметры материалов. На этом этапе мы предполагаем, что вы создали 3d-модели и развернули их в соответствии с атласом текстур. Здесь нужно знать то же самое, что вы делаете при создании пользовательских моделей для юнитов, например, шлемов. Вы помещаете различные текстуры в соответствующие слоты в параметрах шейдера материала и указываете rigid_material. Однако здесь важен еще один шаг. Обычно у вас есть не только одна атласная текстура. Например, иногда у вас есть специальный набор текстур только для ворот или дополнительный атлас текстур для дверей, окон, колонн и т.д. Вы просто устанавливаете два разных материала, а затем создаете третий материал с типом Multi/Sub-Object Material. Вы просто перетаскиваете свои отдельные материалы в каждый слот новейшего материала. Для ссылки на различные материалы внутри одного супер материала используется идентификатор полигона в меню геометрии (он находится рядом с группами сглаживания). Очень важно отметить, что building assets поддерживают 2 слоя (канала) UVs. Это означает, что вы можете иметь 2 разных канала с разным расположением UV для дополнительных эффектов, таких как tiled_dirtmap.
4. Создавайте анимации. Для анимации вам понадобятся только meshes сетки деталей. Разделите их на фрагменты вручную и смоделируйте разрушение с помощью плагина NVIDIA PhysX для 3ds max. Этот шаг необязателен, поскольку у вас нет уровней разрушения для таких объектов, как дома или другие типовые "внутренние" здания, и даже если они у вас есть, вы, по понятным причинам, никогда не столкнетесь с тем, чтобы ИИ пытался повредить ваши внутренние здания. Важно: Только после завершения анимации вы должны скопировать все фрагменты анимации (за исключением фрагментов под землей по соображениям производительности) и объединить все фрагменты в отдельную mesh сетку.
5. Создайте простую форму куба, чтобы при необходимости ссылаться на внешние модели. Мы называем это инстансированием или ссылкой на уже существующие референц активы объектов.
6. Как только вы закончите с сетками и анимацией, можно приступать к созданию TECH-объектов. TECH относится к технике и обычно означает, что эти объекты не будут видны игроку, но играют огромную роль в логике игры.
К Tech объектам относятся: collision3d, hard, platform, platform_ground, bridging_columns, region_zones, eflines, docking_lines и др. Порядок здесь не строгий, и у вас есть свобода действий, однако я предлагаю оставить eflines и region zones напоследок и начать с collison3d. Это потому, что eflines наиболее сложны в работе, и вы определенно не захотите их переделывать.
7. Для этого шага предлагается создать оставшиеся элементы, такие как arrow emitters/метатель стрел/, pipes/тонели/ и т.д. Это также идеальное время для создания LODов в самой 3d_модели.
8. Этот шаг довольно скучный. Он требует определения пользовательских атрибутов объекта и свойств объекта для каждого объекта. Да! В вашей сцене (если это форт-актив) в среднем около 200 объектов! И для каждого из этих объектов вы должны определить пользовательские атрибуты и свойства. К счастью, я сделал несколько скриптов для 3ds max, которые облегчают этот процесс, но они не идеальны, и вам часто придется работать вручную.
9. Если все вышеперечисленные шаги были выполнены правильно, вы можете экспортировать сцену в файл .cs2 (не забудьте отметить "export all keys экспортировать все ключи", если у вас есть анимация в сцене). На этом шаге вы должны определить правила rules.bob и запустить BOB convert для обработки .cs2 файла и преобразования его в готовые для игры модельный активы.
10. На этом шаге вы должны немного поработать с базой данных. BOB генерирует 2 файла db, один - battlefield_buildings, а другой - models_buildings. Первый — это тот, который вы должны редактировать с помощью PFM, а второй не должен редактироваться (и не может быть отредактирован из-за ограничений PFM - на данный момент его уже можно редактировать программой RPFM). Как только вы закончите с этим, вы можете скопировать. meta файлы ванилы (используемые для определения SFX для активов) и импортировать ваши только что преобразованные файлы активов, готовых к игре, в ваш PACK файл с помощью PFM. На этом этапе ваш модельный актив состоит из (опционально).anim, rigid_model_v2 (используется для геометрии и ссылок на текстуры), metas (используется для ссылок на SFX), cs2.parsed (состоит из логики актива, включая коллизии), текстур и файлов базы данных.
11. Последний шаг зависит от того, как вы хотите использовать ваши активы. Если вы хотите использовать его в TEd для добавления на вашу пользовательскую карту, вам следует создать дополнительный файл пакета и импортировать ТОЛЬКО файлы базы данных вашего актива. Хитрость здесь в том, чтобы создать ваш pack_файл типом -> movie. Потому что другие типы паков не сделают ваш модельный актив видимым и доступным в TEd. Если вы больше не хотите, чтобы ваш актив был в TEd, но хотите, чтобы он появился в игре, вы должны иметь все файлы вашего актива в конечном файле pack и определить тип пака_pack-> mod. Не забудьте удалить тип movie pack, как только вы закончите с TEd, потому что movie packs заставляет вашу launcher лаучер игры крашится crash, когда вы пытаетесь включить/выключить моды в mod manager/менеджере модов//.

Вот вкратце схема действий:
Создание текстур -> создание мешей (за исключением damaged meshes - мешей повреждения) -> настройка материала -> создание анимации -> создание мешей повреждения на основе финального кадра анимации -> создание ссылок на референц мешей (экземпляров) -> создание логики -> создание специализированной логики для конкретного актива -> применение атрибутов и свойств -> экспорт, настройка правил и конвертация -> кодирование актива в DB -> добавление файлов в пакет.

How to bring custom buildings in-game_RU word_format (Reveal)

How to bring custom buildings in-game_EN word_format (Reveal)

Плейлист на youtube всего процесса от автора (Reveal)

Community Imperial: Urbi et Orbi - Сообщество Империал