Создание подвижных элементов для брони.
Примечание.
На практике оказалось, что это не самый лучший метод.
В виду глючности реактора, а не в силу ошибочности самой возможности этого метода.
Проще использовать (Constrains) которые позволяют точнее привязывать поведение одного предмета по отношению к другому.
Непосредственно пример, см. здесь.
И использование ниф файлов 4.2 версии, здесь.
Реэкспорт через ФБХ позволяет получать анимации пригодные для МВ.
Но все же, реактор дает более "живые" результаты. Поскольку позволяет предмету действовать самостоятельно.
В то время, как контроллеры связей не предоставляют такой возможности.
Примечание.
Удобнее, создавать анимации (реактором) для небольших фрагментов, нежели работать с целым Base_Anim.
После подклеивать полученные результаты в один файл, размещая оные в соответствующих группах анимаций.
См. здесь.
Havok 1!
1. базовая анимация 3-ст. Детали доспеха прикрепленные к ее скелету.
2. Разместить детали по одной стороне скелета, слинковать.
*если нужна одна деталь, если планируется создание двух бодипартов, на разные стороны тела,
то создать и здесь копии. Что наверное логично и создаст разнообразие анимаций в игре.
3. Отделить подвижные части от базовых деталей, которые загрузить в DMCollection.
*т.е. они будут служить колиженами для подвижных элементов.
4. Определиться, как будет вести себя детали по отношению к базовым и создать соответствующие связи.
Например создать отдельную кость, которую прилинковать к скелету, а деталь, соединить уже с этой костью.
Либо к этой кости добавить некую сетку, от которой будет зависеть подвижная часть.
5. Применить, к деталям и их костям, наборы коллекций.
Петли, регдолы и прочая.
6. Создать анимации в приделах групп оной.
Т.е. синхронизировать.
7. Сгруппировать подвижные детали с их «якорями» и экспортировать по отдельности.
8. В нифскопе, приклеить эти группы в детали доспеха.
*либо собрать прямо в максе.
Т.е. смерджив группы с исходном файлом набора брони.
Этот вариант более предпочтителен.
В случае с существами, все много проще, но принцип тот же.
|
|
|
|
Однако, расчеты бывают не так просты, как кажется на первый взгляд.
|
На практике, толкового вышло не много___)))
|
Более навороченный вариант пластинчатого наплечника.
Фиксация по краям PoinTOpointами и Linear Dashpot по центру.
Впрочем, петля оказалась более правильным решением.
Наплечник одевается на "тело" - например ББ, или имперскую тунику к которой применена "тушка".
Первый элемент наплечника Unyielding и привязан к ключице скелета, либо только оная Unyielding, а первый элемент имеет вес и прочая.
Но это сложный для просчета вариант, который также потребует переклейки деталей в нифскопе.
Экспорт.
Сгруппировать все детали выровнять в позициях обычного, исходного, наплечника и экспортировать.
В нифскопе приправить блеском и прочим.
Обратите внимание!
Оба наплечника должны быть выровнены по одному направлению!
Т.е. хотя придется создавать правый и левый, т.к. анимации у них различна, но сами модели должны иметь выравнивание в одном направлении! Иначе "левый" окажется перевернутым будучи одет на НПС ГГ в игре.
Думается, если действительно задаться такой задачей, можно создать весьма "живые" доспехи
адекватно реагирующие на движение тела в игре.
НО!
Это будет весьма ДОЛГО и потребует очень точной настройки реактора, т.к. объекты склонны к разного рода взаимным пролезаниями и иным глюкам.
Примечание.
На момент написания этой заметки (в 2016ом) было создано два пластинчатых наплечника с анимацией только в Идолах.
Но, результат в игре, не порадовал. (ситуация не изменилась и в 2019ом - прим. ред.)
Т.е. практикой была доказана сама возможность, такого анимирования деталей брони, но само их поведение, по отношению к движениям носителей оказалось плохо подходящим.
Можно думать, что при наличие желания и времени это вполне поправимо.
Примечание.
Иной раз проще все сделать руками.
Банально вращая помещая объект в нужную позицию.
Например, так была сделана латная юбка у Оркской кирасы в Симфонии.
- К базовому скелету была добавлена доп-кость, на которую юбка была закреплена.
- В момент передвижения, когда видимая оболочка ног начинала проходить сквозь юбку, ее несколько поворачивали.
Реактор не справился с этой задачей.
Юбка крутилась, прыгала, проходила сквозь объекты и делала ровно то, что не должна была делать.
Впрочем, проблема не в методе, а в настройках реактора, либо в иных системных глюках которые создали подобные проблемы.
Впрочем, вероятно, лучше было бы использовать Reaction Manager. Это такая продвинутая версия Wire Parameters.
Но быстрее, оказалось все сделать вручную, да...
На тот момент (2017) метод использования связей не был изучен в должной мере, увы.
