Asset Types (Типы ресурсов)

В этой теме перечислены все типы ресурсов (ассетов) в игре Bannerlord, а также то что можно с ними делать:
Добавление и переопределение ресурсов
Анимации (Animations)
Тела (Bodies)
Объекты и префабы (Entities & Prefabs)
Материалы (Materials)
Меши (Meshes)
Правила наименования ресурсов
Переопределение сцен и префабов
Пути (Paths)
Скрипты (Scripts)
Скелеты (Skeletons)
Текстуры (Textures)

 

Спойлер: Добавление и переопределение ресурсов

В RGL вы можете легко переопределить существующие ресурсы или создать новые в редакторе для вашего мода. Механизм переопределения работает путем замены существующих ресурсов на те, которые вы указали в каталоге ресурсов вашего модуля. Модуль сопоставляет ваши пользовательские ресурсы с теми, которые ранее были зарегистрированы другими модулями по их именам. Это происходит по порядку загрузки модулей.

Если Модуль A и Модуль B загружаются в дополнении к модулю Native, соответственно, список конечных ресурсов и их источников, будет следующим:



В настоящее время модифицируемые типы ресурсов это:

• Материал
• Меш
• Текстура
• Физическая форма

Иерархия папок
Система ресурсов обрабатывает некоторые папки в каталоге модуля специально в соответствии с их именами. Вот список этих папок и их значений:

• Assets: Включает редактируемые файлы *.tpac, в которых хранятся метаданные каждого ресурса.
• AssetSources: включает исходные файлы импортированных ресурсов (.psd, .fbx).
• AssetPackages: включает файлы *.tpac только для чтения. Он генерируется, когда модуль упаковывается для клиентских сборок.
• EmAssetPackages: включает файлы *.tpac только для чтения. Он генерируется, когда модуль упаковывается для сборки редактора.
• DsAssetPackages: включает файлы *.tpac только для чтения. Генерируется, когда модуль упаковывается для сборки сервера.
• RuntimeDataCache: включает автоматически сгенерированные данные, необходимые движку для каждого ресурса. Может быть удален, но при запуске может потребоваться время для создания с нуля.

Разрешения на модифицирование
Система ресурсов ищет разные папки в зависимости от версии исполняемого файла игры (game’s running executable). В зависимости от наличия этих папок система решает, можно ли изменить модуль или его можно использовать только в режиме чтения. Если вы хотите поделиться своим модулем, вы можете упаковать свои ресурсы и поделиться упакованными папками, не распространяя тысячи файлов и их источников. У вас есть три варианта упаковки ваших ресурсов:

• Клиент: другие могут активировать ваш модуль для игры. Вы должны распространять папку AssetPackages.
• Редактор: другие могут использовать ваш модуль в редакторе, но не могут его изменять. Используется, если вы хотите, чтобы другие извлекали модули из вашего модуля. Вы должны распространить папку EmAssetPackages.
• Сервер: используется для сборки сервера. Все данные, не относящиеся к серверу, удаляются. Вы должны распространить папку DsAssetPackages.

Если вы хотите, чтобы другие люди смогли использовать ваш модуль, как и вы, с возможностью его изменения, вам нужно поделиться папками Assets, AssetSources и, возможно, RuntimeDataCache .

Переопределение материалов
Переопределение материалов может быть выполнено путем создания нового материала с тем же именем, что и материал, который вы хотите переопределить. Перейдите в каталог ресурсов вашего модуля и щелкните правой кнопкой мыши на empty place (пустое место) на панели браузера. Создайте новый материал и назовите его так же, как материал, который вы хотите переопределить.


Материал существующего меша, замещенный Модулем А

На этом этапе все ссылки на материалы в системе будут перенаправлены на ваш пользовательский материал.


Переопределение мешей
Модели можно импортировать из файлов нескольких форматов (например, Trf, Fbx). Ресурсы, импортированные из одного файла, группируются по их именам в соответствии с правилами именования ресурсов (asset naming convetions). Представьте себе файл fbx следующим образом:

• Model.fbx
  • wall(Меш)
  • wall.lod1(Меш)
  • wall.lod3(Меш)
  • bo_wall(Физическая форма)

Согласно условностям об именах ресурсов, первые три ресурса будут сгруппированы в один меш, в котором три субмеша имеют разные LOD`ы. В конце будут импортированы два ресурса из Model.fbx: wall (Меш) и bo_wall (Физическая форма).

Следуя этим правилам, вы можете экспортировать новый файл геометрии (например, fbx), который содержит группу мешей, имена которых начинаются на wall. В этом случае новый меш стены будет создан из этих субмешей, а существующий меш будет полностью заменен тем, который вы предоставили. Имя файла геометрии не учитывается. Стоит отметить, что переопределение меша происходит на уровне меша. Невозможно переопределить одиночный субмеш через переопределение модуля.


Существующий кубический меш с именем testbox переопределен Модулем А с помощью чайника.


Переопределение текстур
Переопределение текстур очень похоже на материалы. Вам необходимо импортировать новую текстуру с тем же именем, что и текстура, которую вы хотите переопределить. Вы также можете переименовать любую уже импортированную текстуру во что-то, что соответствует имени текстуры, которую нужно переопределить.


Существующая текстура альбедо с именем roman_ground_d переопределена Модулем А с белой текстурой




Переопределение физических форм
Для переопределения физических фигур необходимо импортировать физическую форму с тем же именем ресурса, который вы хотите заменить. Установите флажок Asset naming conventions (Правила наименования ресурсов), чтобы увидеть возможность импорта физических фигур.


Существующая форма тора заменена Модулем A с помощью специальной формы аквилы

 

Спойлер: Анимации

Модификация системы анимации
Экспорт анимации для Bannerlord
Настройки анимации по умолчанию

• Частота кадров: 30 кадров в секунду (оптимальная) или 60 кадров в секунду
• Скелет гуманоида или существа (Rig, прим. перевод - оснастка)
• Максимальное количество поддерживаемых костей: 64
• Кости, которые не используются, должны содержать «_notused» в конце строки. Также корневая кость (самая высокая кость в иерархии) должна содержать это только для анимации.
• 

Настройки экспорта FBX (Autodesk Maya)
Эти настройки применяются к Maya. Программное обеспечение аналогичного типа может содержать такие же настройки. Когда мы экспортируем новую оснастку в первый раз, экспортированный файл FBX должен содержать скелет и меш.

Первоначальная настройка (Скелет + меш)



Экспорт только настроек анимации
Мы обязательно отключили параметры, связанные с мешем и скином, перед экспортом анимации. Использовать название сцены (Use scene name) очень важно проверять при экспорте как для анимации, так и для оснастки. Также убедитесь, что корневая кость содержит «_notused» в конце строки.



Мы следим за тем, чтобы не отправлять какие-либо Ограничения и определения скелетов (Constraints and Skeleton Definitions). Параметры Constraints (ограничения), Connections (соединения) and Unit (единица) должны быть установлены, как показано на рисунке ниже. Наш движок также использует букву «Z» как верхнюю ось.



Определение новых анимаций
После экспорта вашей анимации, чтобы ссылаться на нее в игре, вам необходимо добавить новые анимационные клипы из браузера ресурсов, которые ссылаются на эту анимацию. Для этого вы должны использовать кнопку «Анимационный клип» (Animation Clip) внутри родительской сборки «Создать» (Create). Наиболее важными свойствами этих клипов являются:

• id: ID (уникальное имя) анимационного клипа, который будет использоваться в других системах
• source1: начальный ключевой кадр анимационного клипа.
• source2: конечный ключевой кадр анимационного клипа.
• anim_data_name: ресурс исходной анимации, который был импортирован в движок для этого клипа.
• duration: продолжительность этого анимационного клипа в секундах.

Типичная анимация также содержит некоторые необязательные атрибуты. Самый распространенный - blend_in_period, который устанавливает продолжительность смешивания с существующей анимацией и достижения 100% веса. blend_out_period - противоположность этому смешиванию, но у него есть важное отличие. Смешивание фактически означает, что анимация заканчивается раньше, чем заданная продолжительность, а остальная часть анимации будет использоваться только для смешивания с другой анимацией. Но продолжительность смешивания устанавливается только blend_in_period. Наличие более длинного blend_out_period, чем blend_in_period следующей анимации, не увеличивает длительность смешивания. Это просто помогает смешению выглядеть более гладким, поскольку во время этого смешивания, если обе анимации воспроизводятся одновременно, это выглядит визуально более привлекательно. Анимация с 0 blend_out_period просто приостанавливается во время перехода к следующей анимации.

У анимации есть еще несколько дополнительных атрибутов:

• priority: Приоритет просто разрешает/запрещает воспроизведение анимации в качестве прерывания во время выполнения другой анимации. Анимации с более высоким приоритетом воспроизводятся с более низким или равным приоритетом как прерывания.
• param1, param2, param3: Параметры используются в случаях, когда движку требуются дополнительные данные. Они могут иметь совершенно разные значения.
• sound_code: проигрывает звук при воспроизведении анимации.
• step_points: это точки шага для звука.
• voice_code: проигрывает голос при воспроизведении анимации.
• facial_anim_id: преобразовывает лицо в это при воспроизведении анимации.
• left_hand_pose, right_hand_pose: преобразовывают руки в их значения при воспроизведении анимации.
• Combat_parameter_id: это дает дополнительный набор информации для двигателя (см. combat_parameters.xml)
• blends_with_action: этот атрибут ссылается на другое действие (предупреждение: действие, а не анимацию) для смешивания анимации. Это действительно только тогда, когда движок требует смешивания двух анимаций (например, блокировка щита вверх/вниз, колебания оружия, требующие сбалансированной и несбалансированной версии и т.д.).
• continue_to_action: этот атрибут вызывает другое действие (предупреждение: действие, а не анимацию), которое должно быть воспроизведено вскоре после завершения этой анимации. Анимация считается завершенной всегда, когда достигается длительность (blend_out_period).

Анимации обычно содержат два других узла: flags и clip_usage_data. clip_usage_data - это общий указатель данных, который может относиться к blend_data, displacement_data, bipedal_movement_and_ik_data и quadrupedal_movement_data. Их использование в основном для конкретных случаев, и их детали выходят за рамки этого объяснения. Однако флаги используются почти для всех анимаций и требуют некоторых пояснений. Возможные флаги, которые можно использовать для анимации:

• disable_agent_agent_collisions: отключает столкновения между агентами.
• ignore_all_collisions: отключает все столкновения.
• Ignore_static_body_collisions: отключает столкновения со статическими телами.
• use_last_step_point_as_data: точка 4-го шага считается данными, а не точкой звука.
• make_bodyfall_sound: создает звук падения, когда тело касается земли.
• client_prediction: предотвращает отправку анимации по сети.
• keep: не завершает анимацию по окончании и вместо этого сохраняет ее как приостановленную.
• restart: заставляет анимацию запускаться с самого начала, если эта же анимация уже воспроизводится этим скелетом.
• client_owner_prediction: предотвращает отправку анимации по сети только для агентов, которые контролируются этим клиентом.
• make_walk_sound: проигрывает жестко запрограммированные звуки ходьбы.
• disable_hand_ik: предотвращает применение обратной кинематики руки во время анимации.
• blends_according_to_look_slope: позволяет смешивать анимацию с другой анимацией в соответствии с наклоном взгляда, при этом эта анимация направлена вниз.
• synch_with_horse: воспроизводит анимацию без использования ее исходной продолжительности, вместо этого она соответствует прогрессу с анимацией маунта.
• use_left_hand_during_attack: позволяет боевой системе проверять левую руку как коллайдер во время атаки.
• lock_camera: запрещает игрокам управлять камерой во время этой анимации.
• lock_movement: предотвращает перемещение агентов во время этой анимации.
• synch_with_movement: воспроизводит анимацию без использования ее исходной продолжительности, вместо этого она совпадает с прогрессом с анимацией движения агента.
• enable_hand_spring_ik: позволяет применить к рукам пружинную обратную кинематику для приложения к ним сил движения нижней части тела.
• enable_hand_blend_ik: позволяет инверсной кинематике пытаться немного удерживать руки в исходном положении, когда эта анимация начинается путем смешивания исходной позиции и позиции анимации.
• synch_with_ladder_movement: воспроизводит анимацию без использования ее первоначальной продолжительности, вместо этого она соответствует прогрессу с перемещением агента по лестнице.
• do_not_keep_track_of_sound: запрещает движку удерживать ссылку на звук при его воспроизведении.
  
• reset_camera_height: уменьшает дополнительную высоту камеры для этой анимации.
• disable_auto_increment_progress: предотвращает воспроизведение анимации и вместо этого приостанавливает ее при текущем прогрессе. Прогресс может быть установлен вручную из кода.
• enforce_lowerbody: предотвращает воспроизведение предыдущего канала и анимации движения во время этой анимации.
• enforce_all: действительно только для канала 0. Запрещает воспроизведение анимации канала 1 и движения во время этой анимации.
• cyclic: анимация повторяется и никогда не заканчивается.
• enforce_root_rotation: вращение живота (корня) берется из этой анимации вместо предыдущего канала или анимации движения для внутренних вычислений.
• allow_head_movement: позволяет голове агента двигаться в соответствии с направлением взгляда.
• disable_foot_ik: отключает обратную кинематику стопы для этой анимации.
• effect_by_movement: позволяет добавлять анимацию суммирования движения поверх этой анимации, чтобы улучшить ощущение дрожи.
• update_bounding_volume: отключает оптимизацию ограничивающего прямоугольника, следует использовать, когда агент выходит за свои обычные границы с этой анимацией.
• align_with_ground: выравнивает фрейм агента с землей во время этой анимации.
• ignore_slope: предотвращает выравнивание четвероногих агентов по земле во время этой анимации.
• displace_position: обновляет положение агента в мире во время анимации, используя данные смещения.
• enable_left_hand_ik: заставляет левую руку оставаться на целевом кадре этой анимации даже во время смешивания с другими анимациями с использованием обратной кинематики.
• ignore_scale_on_root_position: позволяет положению живота (корня) оставаться в том же положении с исходной шкалой, что позволяет агентам лучше взаимодействовать с объектами.
• randomization_weight: рандомизирует анимацию внутри альтернативной группы с этим значением. Более высокое значение позволяет чаще выбирать анимацию.

Изменение/добавление новых действий
Анимации агента сопоставляются с наборами действий как действия. Чтобы установить новую анимацию для существующего действия, сначала вам нужно определить новый анимационный клип через браузер ресурсов. Анимационные клипы определяют время начала и окончания анимации, частоту кадров и различные свойства. Затем вам нужно отобразить его в action_sets.xml для определенного набора действий. Если необходимо создать новое действие, сначала вам нужно добавить его как новую строку в action_types.xml, а затем проделать те же шаги, что и выше.

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

У каждого действия есть несколько атрибутов. Эти атрибуты жестко запрограммированы, чтобы движок мог понимать определенные свойства действия. Атрибуты:

тип (по умолчанию: actt_other):

• actt_other,
• actt_defend_fist,
• actt_defend_shield,
• actt_defend_forward_2h,
• actt_defend_up_2h,
• actt_defend_right_2h,
• actt_defend_left_2h,
• actt_defend_forward_1h,
• actt_defend_up_1h,
• actt_defend_right_1h,
• actt_defend_left_1h,
• actt_defend_forward_staff,
• actt_defend_up_staff,
• actt_defend_right_staff,
• actt_defend_left_staff,
• actt_ready_ranged,
• actt_release_ranged,
• actt_release_throwing,
• actt_reload,
• actt_ready_melee,
• actt_release_melee,
• actt_parried_melee,
• actt_blocked_melee,
• actt_fall,
• actt_jump_start,
• actt_jump,
• actt_jump_end,
• actt_jump_end_hard,
• actt_kick,
• actt_weapon_bash,
• actt_passive_usage,
• actt_equip_unequip,
• actt_idle,
• actt_guard,
• actt_mount,
• actt_dismount,
• actt_dash,
• actt_mount_quick_stop,
• actt_hit_object,
• actt_sit,
• actt_sit_on_the_floor,
• actt_ladder_raise,
• actt_ladder_raise_end,
• actt_rear,
• actt_strike_light,
• actt_strike_medium,
• actt_strike_heavy,
• actt_strike_knock_back,
• actt_mount_strike

usage_direction (необязательно):

• ud_attack_up,
• ud_attack_down,
• ud_attack_left,
• ud_attack_right,
• ud_defend_up,
• ud_defend_down,
• ud_defend_left,
• ud_defend_right,
• ud_defend_any,
• ud_attack_any

action_stage (необязательно):

• as_attack_ready,
• as_attack_quick_ready,
• as_attack_release,
• as_reload_phase_1,
• as_reload_phase_2,
• as_defend,
• as_defend_parry

Использовать измененные действия довольно просто, вам просто нужно изменить действие на отображение анимации в файле action_sets.xml, и этого, вероятно, будет достаточно. Но если вы хотите создать новое действие или создать новое поведение для существующего действия, возможные способы интеграции его в игру:

• Вызов действия из кода: класс Agent имеет для этого необходимые функции. По соображениям производительности не забудьте кэшировать индекс действия с помощью класса ActionIndexCache.
• Использование действия в motion_sets.xml: этот файл содержит два набора: motion_sets и full_movement_sets. Motion_set содержит все анимации, необходимые для движения персонажа во всех направлениях в одной стойке и состоянии. Full_movement_set содержит группу movemen_sets, чтобы удовлетворить все стойки и все состояния: ходьба, бег, ходьба на корточках и бег на корточках с левой и правой стойками. Пожалуйста, имейте в виду, что приседание не имеет левой стойки, и поэтому при использовании некоторых видов оружия во всех случаях используется только правая стойка (например, оружие дальнего боя в Native). full_movement_sets содержат свои условия как атрибуты: left_stance и motion_mode.
• Использование действия в item_usage_sets.xml: отсюда следует указывать новые боевые действия, если они не требуют изменения боевой системы. Отсюда можно настроить действия бездействия, охраны, использования оружия, использования удара для каждого элемента с определенными условиями. В дополнение к этому отсюда также ссылаются на действия, определенные в файле motion_sets.xml. Слишком много условий и атрибутов для usage_sets, чтобы объяснить их здесь, но существующие примеры должны помочь вам понять, как все работает. Одна важная и не такая простая деталь заключается в том, что все определенные здесь способы использования проходят сверху вниз, и используется первое использование, удовлетворяющее условию. Поэтому важно, чтобы в верхней части списка находились варианты использования, которые имеют больше ограничений, а в нижней части - запасные.
• Использование действия в monster_usage_sets.xml: как и item_usage_sets.xml, этот файл содержит возможные действия, которые агенты могут выполнять, в зависимости от типа элемента. Это могут быть удары, прыжки, падения и опоры. Для четвероногих агентов есть еще несколько возможностей: upper_body_movements, передвижения и motion_adders. Этот файл требует более подробного объяснения, но его структура похожа на item_usage_sets.xml, и показанные там примеры не требуют пояснений. Опять же, для всех случаев использования просматриваются сверху, и используется первое использование, которое удовлетворяет условиям. Поскольку условия сильно различаются для разных условий действий, иногда условие может использоваться вне его значения (т.е. значение is_heavy становится условием скорости для четвероногих падений и ударов). И некоторые направления могут не применяться для определенных условий (некоторые действия проверяют 4 направления, некоторые проверяют front_left и front_right вместо front, а некоторые проверяют только поперечные направления: front_left, front_right, back_left и back_right), поэтому рекомендуется поэкспериментировать немного, если вы попытаетесь выйти за рамки того, что дает вам собственный код. Чтобы увидеть все возможные body_parts, пожалуйста, проверьте bone_body_types.xml, который в основном содержит некоторые атрибуты для частей тела, связанных с проверками боевых столкновений.

 

Спойлер: Тела (Bodies)

Тела определяют физические границы объектов. Их можно назначить объектам в сценах или префабах. Пользователи могут редактировать Body Flags (флажки тел), чтобы изменить их поведение.

Флажки тел

• Двусторонний (Two Sided): заставляет физический движок использовать обе стороны многоугольников для этого тела.
• Ограничитель ИИ (AI Limiter): используется для пометки тел, которые будут использоваться только против ИИ, за исключением игрока.
• Разрушаемая дверь (Destructible Door): используется автоматическим генератором навигационного меша, чтобы не помещать навигационный мештпод разрушаемые двери.
• Отключение (Disabled): отключает физику для этого префаба или экземпляра объекта.
• Барьер (Barrier): обеспечивает беспрепятственный выход агентов изнутри тела.
• Исключить привязку пути (Exclude Path Snap): точки пути не привязываются к этим телам.
• Не сталкиваться с камерой (Don’t Collide With Camera): камера игрока не сталкивается с этими телами.
• Динамический (Dynamic): физический движок имитирует движение этого объекта.
• Подвижный (Moveable): этот флажок указывает, что это тело и его объект-владелец могут перемещаться.
• Лестница (Ladder): следует отдавать мешам лестниц, чтобы они функционировали должным образом.
• Имеет ступеньки (Has Steps): следует отдавать телам лестниц со ступеньками, чтобы агент мог правильно по ним подняться. (Тело лестниц должно быть отделено от других частей объекта).

Физика агентов требуется для работы гладких и низкополигональных физических объектов. Объекты снарядов требуют большей точности, чтобы лучше моделировать застрявшие снаряды. Приведенные ниже флаги можно использовать для двух разных тел для каждого объекта. Если ни один из флагов не выставлен, на тела реагируют и снаряды, и агенты.

• Agent Only: только агенты реагируют на эти тела.
• Missile Only: только ракеты реагируют на эти тела.

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

Имена импортированных тел окклюдеров должны начинаться с «occ_».

 

Спойлер: Объекты и префабы (Entities & Prefabs)

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

Префабы
Префабы - это объекты шаблона, которые не разрывают соединение с префабом даже после того, как он сохранен в сцене. Сложные объекты могут быть построены один раз и сохранены как префаб для использования в любое время и в любой сцене. Более поздние обновления префаба также повлияют на уже сделанные сцены. В Bannerlord почти все объекты миссий (mission objects) и реквизиты сцены (scene props) являются префабами.

Правила подключения
После того, как префаб помещен в сцену, все значения в префабе (цвета меша, преобразования дочерних предметов, значения скрипта) связаны с исходным префабом и будут обновляться после каждого изменения исходника. Любое изменение сцены для этих значений разорвет связь. Помните, что любая операция «Добавление» (Addition) к префабу в сцене разорвет всё соединение префаба. Примеры: добавление нового меша, системы частиц, источника света, дочернего объекта или компонента скрипта.

 

Спойлер: Материалы (Materials)

Материалы определяют характеристики рендеринга мешей. Они содержат информацию о шейдере и текстуре, а также флажки рендеринга (определяемые шейдером и глобальные). Меш может состоять из одного материала. Начальное значение материала меша будет назначено через имя данного материала в сторонних приложениях для редактирования меша. Материалы можно создавать и редактировать с помощью Material Browser (браузера материалов), к которому можно получить доступ через Resource Browser (Браузер ресурсов). Материал также можно редактировать во время выполнения (runtime) с помощью скриптов и поведений (behaviours). Более подробную информацию о редактировании материалов и материалах по умолчанию движка можно найти в Редакторе материалов.

 

Спойлер: Меши (Meshes)

Меши содержат позиции и атрибуты полигонов, которые будут использоваться на этапе рендеринга. Каждый меш имеет один материал, который определяет его поведение при отрисовке (rendering behaviour). Они сгруппированы внутри MetaMesh по их уровню LOD. Кроме того, на одном уровне LOD может быть несколько мешей с разными материалами. Более подробную информацию об импорте мешей в движок можно найти в Редакторе материалов.

Система LOD
Современные движки используют системы LOD (уровни детализации), чтобы гарантировать, что близкие к экрану модели используют большее количество ресурсов графического процессора, чем дальние. Это достигается за счет уменьшения качества меша в зависимости от расстояния до камеры. Эта система гарантирует, что соотношение многоугольников к пикселям на экране максимально одинаково. Расстояния LOD по умолчанию следующие: 15, 22,5, 30, 50, 70, 130, 210 метров. Эти расстояния предназначены для наилучшего качества графики, и их можно уменьшить с помощью параметров «Environment Quality» (качество окружающей среды) и «Character Quality» (качество персонажа).

 

Спойлер: Правила наименования ресурсов

Чтобы различать и систематизировать ресурсы, а также упростить процесс создания ресурсов, необходимо учитывать некоторые предопределенные правила.

Меши
Все меши, импортированные из одного файла геометрии (например, fbx), сгруппированы по своим именам. Чтобы добавить LOD меша, просто добавьте ”.lod<n>“ к имени вашего меша. Здесь n - число LOD'а.
Рассмотрим файл fbx, как показано ниже:

asset.fbx:

• wall_damaged
• wall_damaged_v2
• wall_damaged_v2.lod1
• wall_damaged.lod1
• wall_damaged.lod2

Из файла asset.fbx будут импортированы два меша: wall_damaged, wall_damaged_v2. Эти меши будут иметь два и один ЛОДа соответственно. Если ваше программное обеспечение для моделирования не поддерживает точки в именах (например, Maya), вы также можете использовать «_» вместо «.» для указания ЛОДов (например, wall_damaged_v2_lod1).
В меше не может быть более одного материала, поэтому на этапе импорта фазовые меши (phase meshes) будут разделены на субмеши в соответствии с использованием материалов для полигонов. К именам этих автоматически сгенерированных мешей будут добавлены порядковые номера. Рассмотрим меш wall_damaged из трех разных материалов. Имя импортированного меша будет wall_damaged, и он будет иметь три субмеша с именами wall_damaged.1, wall_damaged.2, wall_damaged.3.

Примечание:
Во время импорта меша, материалы, определенные в файлах геометрии, не создаются. Вы должны создавать материалы вручную с тем же именем, на которое они ссылаются из файлов геометрии.

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

Капсулы
Если имя узла начинается с bo_capsule, он будет импортирован как форма аналитической капсулы. Размеры этой капсулы определяются по следующим правилам:

• Локальные оси XY приняты за радиальную плоскость капсулы.
• Локальная ось Z принимается за направление капсулы (высота).
• Масштаб объекта по осям XY должен быть равен.

Используются только ориентация и протяженность узлов капсулы. Любой прикрепленный к ним контент (например, меш) игнорируется.

Сферы
Если имя узла начинается с bo_sphere, он будет импортирован как форма аналитической сферы. Размеры этой сферы определяются размерами узла. Центр узла также будет центром формы сферы. Используются только ориентация и размеры узлов сферы. Любой прикрепленный к ним контент (например, меш) игнорируется.

Составные формы
Вы можете комбинировать разные типы фигур для создания более сложных фигур. Чтобы экспортировать составную форму, вы должны создать узел, имя которого начинается с bo_composite. К этому узлу можно добавлять дочерние узлы с разными типами форм.

• bo_composite_building1
  • bo_capsule1
  • bo_capsule2
  • bo_sphere
  • bo_building_walls

Эта форма будет импортирована как один ресурс с именем bo_composite_building1.

Текстуры
Вы можете дать базовые подсказки для своей текстуры, следуя этим правилам:

• Текстуры альбедо оканчиваются на _d
• Текстуры нормалей оканчиваются на _n
• Зеркальные текстуры оканчиваются на _s
• Текстуры карты высот оканчиваются на _h

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

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

• Иерархия костей скелетов должна соответствовать.
• Каждый костный узел должен иметь свое имя, оканчивающееся жестко запрограммированным номером кости (например, _0, _1), чтобы номера костей скелетов, происходящих из разных файлов, совпадали, независимо от процесса экспорта вашего ПО для моделирования или инструмента экспорта. Существуют следующие правила, которым должно соответствовать каждое имя кости:
  • Добавленные индексы костей должны начинаться с нуля.
  • Добавленные индексы костей не должны быть больше или равны количеству костей.
  • Две кости не могут иметь одинаковый костный индекс.

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

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

Примечание:
Некоторые программы автоматически экспортируют анимацию с заранее заданными именами (например, 3DS Max -> take_001). Это приведет к тому, что несколько скелетных анимаций будут импортированы с одним и тем же именем, если у вас есть более одного скелета, определенного в вашем файле геометрии, поскольку движок интерпретирует данные анимации, определенные для каждого скелета, как разные ресурсы. Из-за этого вы получите предупреждение о дублировании актива. Чтобы избежать этого, лучше всего экспортировать один скелет на файл геометрии. Вы также можете отключить импорт анимации в настройках импорта этого файла.

 

Спойлер: Переопределение сцен и префабов

Вы можете переопределить существующие сцены и префабы, создав новые с тем же именем.

Примечание:
Вы должны помнить, что переопределение префабов может нарушить существующие скрипты, если вы измените иерархию объектов. Убедитесь, что вы сохранили иерархию объектов, чтобы избежать возможных критических ошибок, если ваш объект используется существующими скриптами.

Префабы
Определения префабов хранятся в файлах xml, расположенных в папке Prefabs в каталоге каждого модуля.

Сцены
Сцены хранятся в двух отдельных папках SceneObj и SceneEditData в каталоге каждого модуля. В папке SceneObj хранятся файлы, необходимые для открытия сцены в клиентском режиме, а в SceneEditData хранятся файлы, необходимые для операций редактирования.

 

Спойлер: Пути (Paths)

В RGL «Пути» используются для определения непрерывных точек в сцене. Они имеют уникальные имена и могут использоваться игровой логикой по разным причинам. Пути определяют, как движутся осадные машины в миссиях. Кроме того, для полевых боевых миссий кандидаты на начальные точки возрождения определяются через путь. Логика появления выбирает две позиции для команд в зависимости от размера битвы. Подробную информацию о редактировании пути можно найти в разделе Редактирование пути.

 

Спойлер: Скрипты (Scripts)

Компоненты скрипта - это исполняемые сценарии (executable scripts), которые прикрепляются к объектам и могут использоваться для реализации различных функций игрового процесса. В Bannerlord много логики игрового процесса написано через компоненты скрипта. Например стулья, брошенное оружие, осадные машины. Есть много разных обратных вызовов, которые могут быть унаследованы и заполнены этими компонентами скрипта.

Обратные вызовы

• Constructor: в конструкторе необходимо присвоить значения по умолчанию его общедоступным переменным (переменным, которые могут быть изменены создателем сцены). В конструкторе компонент скрипта не назначается ни объекту, ни сцене. Кроме того, вы не должны писать никакой логики, которая имеет побочный эффект, потому что, даже если он создан, компонент скрипта может быть удален после открытия сцены из-за системы уровней обновления.
• OnPreInit: вызывается после того, как компонент скрипта назначается его объекту-владельцу в сцене. Находясь в этом обратном вызове, вы можете быть уверены, что пользовательские переменные из этого экземпляра скрипта установлены. Однако другие компоненты скрипта других объектов могут быть еще не назначены. Таким образом, в предварительной инициализации не должно быть никакого логического кода, который полагается на другие компоненты скрипта. Например, в pre-init ManagedObject регистрируется в массиве управляемых объектов в текущем экземпляре миссии.
• OnInit: вызывается после загрузки миссии и инициализации всех скриптовых компонентов объектов. Вы можете использовать любой тип логического кода внутри этого обратного вызова. Скрипты, созданные во время выполнения, также получают этот обратный вызов.
• OnEditorInit: версия редактора при инициализации. Вызывается при загрузке сцены из редактора. Помните, что в редакторе нет миссии или состояния игры.
• OnTick: вызывается для каждого компонента скрипта в каждом кадре миссии из одного и того же потока (thread).
• OnEditorTick: версия редактора функции OnTick.
• IsOnlyVisual: если у вас есть компонент скрипта, который является только визуальным и не имеет никакого логического кода, который должен выполняться на выделенном сервере, вы должны вернуть true в этой функции. Это гарантирует, что этот тип скриптов не будет работать на выделенном сервере.
• OnEditorVariableChanged: вызывается в редакторе всякий раз, когда пользователь изменяет общедоступную переменную в этом компоненте скрипта. Этот обратный вызов может использоваться для любого изменения состояния визуальной логики, если сценоделу нужна мгновенная обратная связь в сцене редактора.
• OnRemoved: вызывается при удалении объекта или компонента скрипта. Если у вас есть какие-либо выделенные объекты, которые хранятся где-то еще (например, статические контейнеры), вы можете использовать этот обратный вызов, чтобы убедиться, что они не просочились.

 

СКЕЛЕТЫ

Пока разработчики ничего не написали

 

Спойлер: Текстуры (Textures)

Текстуры можно импортировать через Asset Browser (Браузер ресурсов). Их можно назначить материалам через Редактор материалов. Слоты текстур материалов PBR можно найти в Редакторе материалов.

Примечание:
Максимальное значение разрешения текстур ландшафта - 2048 на 2048.