Для остановки анимации движения достаточно удалить ключи анимации по оси "Y" у рот кости которая подходит к копчику модели - bandicam 2025-08-01 16-08-45-865.mp4

vova2112Для остановки анимации движения достаточно удалить ключи анимации по оси "Y" у рот кости которая подходит к копчику модели - Вложение 75777

Да, действительно отличный способ, и не нужно никаких промежуточных конвертаций, спасибо!

Разве что я замечал, что у некоторых моделей вперед по Y двигаются несколько костей (подозреваю, что в случаях когда модель состоит из нескольких мешей). В целом можно быстро обнаружить эти кости экспортнув анимацию в SMD, а далее прогнать скрипт, который отследит какие номера костей двигаются вперед по Y во время move анимации. После чего уже убрать ключи анимации для этих костей в 3ds Max. 

Хотя сейчас еще попробовал таким образом пофиксить move анимацю у мечника, и в случае с ним такой способ не сработал, там двигаются 4 кости 1 - Sword_joint, 2 - Shield_joint, 3 - SpeedLineSword и 9 - Hip. Двигаются они по итогу на одно и то же расстояние, но пофреймовые сдвиги у них не совпадают, и если попробовать просто убрать движение вперед для этих костей, то меч и щит не будут перемещаться по Y, и из-за этого на некоторых кадрах меч и щит начинают выпадать из рук мечника. 

auromoleanДа, действительно отличный способ, и не нужно никаких промежуточных конвертаций, спасибо!

Разве что я замечал, что у некоторых моделей вперед по Y двигаются несколько костей (подозреваю, что в случаях когда модель состоит из нескольких мешей). В целом можно быстро обнаружить эти кости экспортнув анимацию в SMD, а далее прогнать скрипт, который отследит какие номера костей двигаются вперед по Y во время move анимации. После чего уже убрать ключи анимации для этих костей в 3ds Max. 

Хотя сейчас еще попробовал таким образом пофиксить move анимацю у мечника, и в случае с ним такой способ не сработал, там двигаются 4 кости 1 - Sword_joint, 2 - Shield_joint, 3 - SpeedLineSword и 9 - Hip. Двигаются они по итогу на одно и то же расстояние, но пофреймовые сдвиги у них не совпадают, и если попробовать просто убрать движение вперед для этих костей, то меч и щит не будут перемещаться по Y, и из-за этого на некоторых кадрах меч и щит начинают выпадать из рук мечника. 

Лол, да, в героях такое бывает, вот у рыцаря всадник, конь, копье и щит будут двигаться как независимые объекты

Если у вас есть возможность сделать отдельную модель смерти то я бы сделал так
Для смерти использовал бы обычную модель
Для боя сделал бы меч и щит привязанными к рукам

Добавлено через 7 минут
Возможно изначально оружие и латник это 2 разные модели, их объединили в группу "глобал" и при загрузке они склеились в то что мы имеем

Пока  прямых доказательств нет) но может скоро будут

Но есть косвенное доказательство - у рыцаря многие кости имеют сложные имена Global|Hip|Chest, это баг импорта, так происходит когда в скелете есть кости с не уникальным именем, например у коня есть кость Hip, и у всадника есть Hip - к ним приплюсовываться имена предыдущих костей пока имя не станет уникальным

fktifzobr@mail.ruЛол, да, в героях такое бывает, вот у рыцаря всадник, конь, копье и щит будут двигаться как независимые объекты

Если у вас есть возможность сделать отдельную модель смерти то я бы сделал так
Для смерти использовал бы обычную модель
Для боя сделал бы меч и щит привязанными к рукам

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

В целом move анимации для таких юнитов как мечники можно все еще фиксать скриптом, который плавно убирает смещение по Y у двигающихся костей. Наш скрипт находит кости которые двигаются вперед по Y, далее вычисляет на какое расстояние каждая кость двигается в течение всей анимации, а далее делит это расстояние на кол-во кадров в анимации, и для двигающихся костей начинает для каждого фрейма пропорционально отнимать позицию по Y.
Условно если анимация длится 15 кадров и смещение у кости было скажем 15 метров, то от позиции Y на первом кадре отнимается 1 метр, для второго кадра 2 метра, для третьего 3 и тд. Если фиксить это таким образом, то щит и меч не выпадают из рук мечника, но все равно присутствуют кадры, на которых видно что щит немного ездит по руке. Но это возможно уже проблемы того как GR2 плагин для 3ds max 2008 считывает GR2 анимации. GrannyExporter делает это лучше, но к сожалению он на последних кадрах Move анимации пытается вернуть модель на изначальную позицию, а на такую анимацию мы уже не можем прогнать наш скрипт. 
Еще у некоторых моделей, например у фурий, очень не постоянная скорость во время move анимации, то есть фурия бежит как бы рывками. И если прогнать такой скрипт, который пытается сгладить все фреймы анимации пропорцинально, то итоговая move анимация хоть и будет воспроизводиться "на месте", но будет видно как фурию метает то немного вперед, то немного назад. То есть анимация бега фурии на месте будет выглядеть дергано. Но после того как я сделал импорт этой анимации в Unreal Engine, и начал воспроизводить эту анимацию не просто на месте, а задав персонажу фурии движение вперед с нужной скоростью (для этого надо посмотреть значение внутри <MovementSpeed> тега в xdb файле с move анимацией), то дергание перестает быть видно, и фурия начинает бежать рывками схоже с оригиналом. 

Всем привет, 

А кто-нибудь сталкивался с проблемой при работе с Архангелом когда при загрузке меша выдает вот такую ошибку:
Calculating normals didn't go too well for submesh 

Столкнулся с ней при загрузке модели с экрана города инферно, закрыть ошибку не выходит, она продолжает бесконечно появлятся.
Вместо Архангела попробовал конвертировать эту модель через mesh2wrl, однако итоговый WRL файл судя по всему имеет пробемы с UV, потому что при накладывании материала меш просто становится черным.
До этого mesh2wrl я не пользовался, возможно для корректного UV нужно сделать еще какие-то действия?

Загрузил исходный файл модели и WRL файл на гугл диск: https://drive.google.com/drive/u/1/folders/1k_flQrjwj4j13_6ZB8RDx4-MByRP4IJt

может просто вывернуты внутрь нормали?

Добавлено через 49 секунд
файлы там , надеюсь, без вирусов? чтобы загрузить, глянуть...

auromoleanВсем привет, 

А кто-нибудь сталкивался с проблемой при работе с Архангелом когда при загрузке меша выдает вот такую ошибку:
Calculating normals didn't go too well for submesh 

Столкнулся с ней при загрузке модели с экрана города инферно, закрыть ошибку не выходит, она продолжает бесконечно появлятся.
Вместо Архангела попробовал конвертировать эту модель через mesh2wrl, однако итоговый WRL файл судя по всему имеет пробемы с UV, потому что при накладывании материала меш просто становится черным.
До этого mesh2wrl я не пользовался, возможно для корректного UV нужно сделать еще какие-то действия?

Загрузил исходный файл модели и WRL файл на гугл диск: https://drive.google.com/drive/u/1/folders/1k_flQrjwj4j13_6ZB8RDx4-MByRP4IJt

Всё так и есть. Если добавить модификатор Unwrap UVW, то можно увидеть, что координаты текстуры располагаются предположительно по мировым координатам и у модели не настроена текстурная сетка, отсюда и проблемы.
Чтобы их решить надо назначить материал модели и настроить текстурную сетку под исходную текстуру.

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

Добавлено через 9 минут
аа, нет, переделал файл врл еще раз, и нормально открылось.....а какая там текстура должна быть?

Pavlinhoможет просто вывернуты внутрь нормали?

Тоже сначала так подумал, пофиксил их, но ничего не поменялось, а когда попробовал приложить текстуру для проверки UV, то модель просто стала красной, судя по всему там на каждом вертексе UV = 0,0.

vova2112Всё так и есть. Если добавить модификатор Unwrap UVW, то можно увидеть, что координаты текстуры располагаются предположительно по мировым координатам и у модели не настроена текстурная сетка, отсюда и проблемы.
Чтобы их решить надо назначить материал модели и настроить текстурную сетку под исходную текстуру.

Спасибо, попробую подогнать UV в блендере или 3ds max.

Pavlinhoа какая там текстура должна быть?

Текстуру загрузил в ту же папку на гугл диск (в dds и tga форматах): https://drive.google.com/drive/u/1/folders/1k_flQrjwj4j13_6ZB8RDx4-MByRP4IJt

Сама модель находится в игровых файлах вот тут data/Arenas/Town/NewInferno/arc.xdb

Получилось починить UV в блендере, для начала просто конвертировал WRL в OBJ и при импорте в блендер UV уже выглядел лучше, видно было что текстура накладывается, хоть и не совсем корректно, в итоге нужно было лишь отзеркалить UV по Y и текстура применилась как положено. 

Всем спасибо! 

auromoleanПолучилось починить UV в блендере, для начала просто конвертировал WRL в OBJ и при импорте в блендер UV уже выглядел лучше, видно было что текстура накладывается, хоть и не совсем корректно, в итоге нужно было лишь отзеркалить UV по Y и текстура применилась как положено. 

Всем спасибо! 

там в блендере есть плагин, который сразу врл может импортить...ну уже поздно, задача решена = хорошо, но я вчера когда смотрел врл, во 2 раз уже - там нормальная развертка вроде была, я потому и попросил текстуру (чтобы не искать по папкам ), посмотреть как ляжет )))) ну ладно )))

Pavlinhoтам в блендере есть плагин, который сразу врл может импортить...ну уже поздно, задача решена = хорошо, но я вчера когда смотрел врл, во 2 раз уже - там нормальная развертка вроде была, я потому и попросил текстуру (чтобы не искать по папкам ), посмотреть как ляжет )))) ну ладно )))

Да, возможно надо было сразу плагин для блендера попробовать, импорт WRL в 3ds max видимо как-то некорректно UV считывал 

мне кажется, чем меньше всех этих "переходов", тем точнее и лучше экспорт/импорт.....