В моём скрипте кость Controller_BASE не создается, соответственно компенсация не нужна
Совсем забыл про этот момент. Тебе действительно это может не понадобиться. А у меня в Блендере за "направление/(длину)" кости отвечает ось Y (кость стоящая вертикально будет иметь локальную ось Y указывающую в направление глобальной оси Z), поэтому чтобы получить глобальные координаты данной кости, нужно учесть этот поворот осей на 90 градусов.
FBX мне кажется мало что даст. Можно попробовать сделать тест по другому. Я сделаю новый файл, где кости будут стоять на целых одинаковых расстояниях (например в 1 юнит) и направлены строго по осям. Тогда в Максе будет проще его повторить руками. Хотя из за компенсации ТХТ файлы всё равно окажутся разные... Может вообще на мои ТХТ файлы не полагаться, а делать тесты только в Максе ?
@perture, ну что это такое творится ! опять я прозевал твой ответ Уведомления не пришло, а сам в эту ветку не заходил, извини (если бы Myprism сюда не написал, так бы и думал, что ты занят...) Вот файл с новым тестом: "Скачать". По идее полностью идентичными они могут и не быть. Если в Максе не нужно делать компенсаторный поворот для на 90 градусов, то координаты скелета и анимации будут немного другими. Но на работу ЕХЕ-шника это повлиять не должно.
Myprism, интересно, это получится прозрачное, преломляющее свет тело, внутри которого будут видны косточки скелета ? а можно на скриншот этого чуда глянуть ?
Myprism, а ведь классный эффект получается, особенно на 2-м скриншоте (с тенью на стене), смотрится очень необычно ! А что это будет: одежда, расса, компаньон ? В общий доступ планируешь выдать или это только для себя ?
Myprism, вроде нет, сколько я делал разных поз и анимаций - проблем не возникало. Мне трудно представить отчего так может быть, если можешь, скинь Blend и NIF файлы для кистей, попробую разобраться.
Myprism, понял, странно конечно, буду проверять... (два варианта то я просто так сделал, т.к. у меня не получились смещения костей паташинов в точности такие же как у исходных кистей)
.....
Сделал комплексную проверку в игре НИФ-а кисти, содержащую нормальную кисть вместе с её скелетной формой. Результат: всё идеально работает ! Ничего никуда не выпирает и анимируется как положено. Вот тот НИФ, который я проверял: "Скачать"
ПС: но кажется я знаю почему у тебя не получилось. Сам, когда готовил НИФ заготовку для SkinInjector-а, один раз поленился удалить все ноды, и получил в итоге глюк, когда пальцы "втянулись" немного по оси Х. (оказалось, что моя программка всё таки не создаёт новые ноды, если в НИФ-е они уже существуют с такими же именами , как я про это забыл - ума не приложу ! , в итоге сам и попался на тот глюк, что однажды описывал !)
Myprism, да дело в том, что положение отмастабированных мною нодов, и скина для них, не совпадает с оригинальным (ну или с тем, который выдают утилиты NifScript у Макса, ведь эти UNP руки отскинены именно так).
Несовпадение находится в пределах ~0.15 юнита, что практически незаметно, но всё же. И поэтому я не могу до конца понять, как они обрабатывают эти отмасштабированные косточки. (даже может быть ошибка и у них, а не у меня ... ? , всякое ведь бывает)
Мой алгоритм довольно прост: если родительская косточка содержит в своём имени строку "Fingers", то к координатам дочерней косточки применяем масштабирование
также и для Global_Node_Y и Global_Node_Z (где Parent_Scale всегда равен "0.8517", т.е. масштабу косточки "Hand" у женского скелета).
Откуда получается несовпадение, пока не представляю.
---------------------------- Забыл добавить: в твоём примере я сгенерил скин для костяной формы и для одной из форм обычной ркуи, вторая форма обычной руки осталась БЕЗ скина вообще. Так вот - обе формы: отскиненная мной и не отскиненная вообще - совпадают идеально (проверял в Нифскопе). Так что похоже что программка считает правильно...
Myprism, в общем то да, мне просто так удобнее помнить, что есть нормальная утилита, а есть её модификация, которую нужно использовать только для кистей женских рук. Но я подумываю, чтобы сделать одну, универсальную, тем более что уже почти знаю, как это сделать
Просто замечательно ! По идее нумерация значения не имеет. Это даже не нумерация, а индексы вертексов в OBJ файле, и обрабатываются они соответственно, но проверить не помешает конечно. Вот файл посложнее: "Скачать"
ПС: можно будет предложить Aksyonov-у поэкспериментировать, ему должно понравиться ))
@perture, с обьектами всё просто: это особенность моего скрипта для Блендера такая, так было проще его сделать. Он считает всё обьекты сцены, а экспортирует только те, которые привязаны к арматуре. Если реальное число обьектов будет меньше указанного этой цифрой, то ничего страшного, программа только выдаст сообщение и всё. А вот если будет больше - то завершится с ошибкой.
Несовпадение количества вертексов может зависеть от скина. Не вертексы могут быть привязаны ко всем костям арматуры, одни могут быть привязаны к одной косточке, другие - к другой, третьи - к обоим.
Если встретятся вертексы вообще без привязки - программа выдаст предупреждение (и это надо будет исправлять в 3D редакторе). Если встретятся вертексы с привязкой к нескольким косточкам и при этом имеющие общую сумму весов большу единицы - программа выдаст предупреждение, но сама нормализует их между четырмя наибольшими весами (если влияло больше 4-х косточек, то остальные будут убраны из скина)
@perture, правильно будет, если количество мешей в ТХТ файле будет равно этой цифре (если мешей будет меньше - нестрашно, а вот если больше - будет ошибка). Т.е. 23 - это именно то, что и должно там стоять.
Понял что не так. Извиняюсь, 30 вертексов - это моя ошибка. Я дал ТХТ файл от версии, где уже была сделана UV развёртка (а следовательно и разрезы по швам, которые и дали дополнительные 10 вертексов). Просто в том Blend файле, где есть UV, нету анимации (не проверил этот нюанс, думал, что с анимацией у меня идут самые последние версии модели).
Что то мне подсказывает, что скрипту уже можно открывать ОБТ
Myprism, а, ну это может быть. Я сам эту функцию никогда не использовал, и нашёл её только потому что ты о ней спросил Протестировал её на 2-х одинаковых кубиках и UV отлично перенеслось.
А вес вертекса всё таки совсем другое дело чем UV, поэтому вполне вероятно что для переноса UV геометрия по любому должна быть идентичной. Ведь вес просто отпределяет влияние на группу вертексов постороннего обьекта (косточки арматуры), в то время как UV описыват саму поверхность данного конкретного обьекта и напрямую связана с его формой.
Myprism, в 3Д редакторе количество вертексов превысить то можно, но тогда НИФ файл сделать не получится. Максимальное число точек в одном блоке NiTriShapeData может быть не более 65535 (2 байта). Таков формат этого файла, больше туда не засунуть
Всё равно не представляю как так можно перенести UV "поверхность" одной модели на другую модель с другой формой. Наверное проще содать второй модели свой UV, а потом пытаться подогнать его 2D форму UV развёртки под 2D форму UV развёртки 1-й модели. Но всё это не менее мутно, чем идея с костями, и скорее всего по нормальному не реализуемо.
ПС: скрипты блендера пишутся на Питоне (Python). Это достаточно распространённый язык и много где применяемый.
Myprism, мне тоже интересно, сегодня попробую, может решу и свою проблему с прозрачностью. А то у меня при взгляде на полупрозрачную поверхность через другую полупрозрачную поверхность текстура "разбивается" на треугольники (словами трудно описать такой глюк, єто надо видеть).
Myprism, точно!, но в моём случае дубликат поверхности не помог, глюк остался тот же.
Я сделал сферу (типа защитного энергетического поля) и ГГ находится внутри неё. Так вот глюк вьіходит следующий (в зависимости от положения камерьі): - если сфера имеет односторонний шейдер и один слой поверхности: --- снаружи текстура нормальная, внутри её вообще нет (ну оно и понятно) - если сфера имеет двусторонний шейдер и один слой поверхности: --- снаружи текстура дефективная, внутри нормальная - если сфера имеет односторонний шейдер и два слоя поверхности: --- снаружи текстура дефективная, внутри нормальная - если сфера имеет двусторонний шейдер и два слоя поверхности: --- снаружи текстура дефективная, внутри нормальная Вот такие дела.
ПС: если будет интересно, я скоро релизну єтот мод (планирую - в пятницу), посмотрите как єто всё вьіглядит.
Myprism, да, слои обьединеньі в один шейп. Скорее всего текстурньій шейп не дружит с ещё одним, которьій отвечает за рефракцию (по типу факела). Он "обволакивает" видимьій слой с обоих сторон. (надо бьіло сразу об єтом написать, но только сейчас додумался...)
Добавлено (16 Января 2015, 20:48) --------------------------------------------- Вот я и релизнул новый летательный аппарат ! ___"Летающая платформа"___ (пробуйте, комментируйте...)
В нём как раз и есть тот двуслойный обьект (шар "защитного поля") о котором я говорил. Сейчас поле одностороннее и узор видно только если камера находится снаружи.
Myprism, а тьі точно "Animatio Tools N4 - Body Animator" смотришь ? Там ведь нету заготовки женского тела ! Его заготовка - єто "пирамидка".
Начать нужно с того, чтобьі добавить в мой пример форму своего шлема. Потом сделать ему скин на косточку "Bone_01". Єту кость можно и переименовать, а вот её "родителей" трогать нельзя. Анимационніе кадрьі тоже можно пока не трогать. Сейчас нужно добавить дополнительніе кости для движущихся частей шлема и сделать им правильньій скин.
Следует иметь в виду, что наш шлем будет аттачится в игре к косточке "NPC Head [Head]" скелета ГГ, и связан с ней шлем будет своей косточкой "NPC Root [Root]".
Myprism, скин шлему надо будет делать заново, под новый скелет. По крайней мере анимируемьім частям. Ведь можно сделать и так: статическую часть шлема сделать как обьічно, с привязкой к скелету ГГ, а движущиеся части сделать отдельным НИФ-ом и отскинить на новый скелет (такой вариант даже лучше, но придётся немного повозиться чтобьі правильно состыковать его части).
1. Кости "Controller_BASE" и "NPC Root [Root]" трогать нельзя 2. Имеется в виду новая арматура, которая есть в файле примера 3. Задаётся диапазон кадров, потом косточки нашей новой арматурьі вращаем/перемещаем, запоминая их положение во времени создавая ключи (кнопка "I"), после чего єкспортируем результат 3-мя скриптами 4. Двигаются только те косточки, которые должньі. Простой пример: шлем привязан к косточке "Bone_01", забрало к "Bone_02". Создаём анимацию открытия забрала вращая только косточку "Bone_02" вверх. Вьібираем время в 1 сек и 30фпс (кадров в секунду). В процессе анимации создаём два ключа для кадра 0 (0 сек) и для кадра 30 (1 сек). 5. Есть два варианта привязки к ability: или весь шлем или только "забрало" (для шлема тут всё равно, т.к. он привязан к косточке головьі на 100% и не меняет своей формьі).
@perture, бихейвиор описан правильно и модель должна реагировать на прьіжки. Я не увидел ссылки на анимированньій НИФ, но предположу, что раз не работает, то возможно причина в отсутствии блока "BSBehaviorGraphExtraData" в НИФ файле, который ссылается на твой бихейвиор.
Потом сами анимации должньі бьіть обьединеньі в один НИФ файл (с помощью Нифскопа) под один глобальній контроллер, и названьі соответственно бихейвиору.
Если что то всё таки дёргается, значит в НИФ-е есть анимация с именем "SpecialIdle".
ПС: ещё момент - сами бихейвиор файльі (те, которьіх четьіре) просто так нельзя переименовівать.
@perture, у меня на работе Youtube заблокирован, так что увижу только когда буду дома. Файльі вот такие: "AnimatedDragonWings.hkx", "AnimatedDragonWingsBehavior.hkx", "AnimatedDragonWingsChar.hkx", "SingleBoneSkeleton.hkx". В НИФ-е ссьілка идёт только на "AnimatedDragonWings.hkx", но он связан с остальньіми тремя.
Дело в именах файлов, они зашитьі внутри HKX. Если хочешь назвать их по другому, надо все три HKX преобразовать в XML, изменить, и потом запаковать назад в HKX. Ну а если использовать мои файльі, то ничего єтого делать не надо.
Нет, мод с крьільями тут не причём и нам не нужен. Просто чтобьі работал бихейвиор нужно иметь 4 файла. Один - єто файл созданньій именно для нашего мода, остальньіе три - просто довесок, без которого бихейвиор не будет работать (так оно в игре реализовано). Єти три файла внутри не меняются (ну кроме случая, когда захочется их переименовать) и задают стандартньіе связи с блоками, которьіе будет потом использовать движок игрьі.