Добавлено (29 Октября 2014, 12:39) --------------------------------------------- mxac, у меня тоже всякие разные коллизии показываются, но только если они не имеют блока "bhkCompressedMeshShapeData".
Myprism, Cardboarddog, особо не обращал внимания, поэтому не встречал НИФ-ов, в которых на один блок существовала бы ссылка из нескольких других блоков. Сам однажды попробовал так сделать, получил CTD и забросил это дело. Нельзя так нельзя. Хотя сейчас перечитал пост и не понял, как можно на разные NiTriShape (с юбкой, и без) цеплять одинаковый BSDDismemberSkinInsnance ? Скин же по любому разный будет...
А вот насчёт копирования некоторых блоков Нифскопом с последующим CTD встречался ооочень часто. Даже программку думал написать, которая бы сканировала все НИФ-ы в папке и это фиксила.
Проблема заключается в том, что при копировании блоков, Нифскоп сохраняет индексы на строки имён для блоков неизменными. И часто получалось так, что копирую какой то [NiTriShape]имеющий имя "model_1" с индексом 60 в другой НИФ файл, а в нём индексы строк заканчиваются на 20. Но скопированный блок так и будет иметь индекс 60 указывая в никуда, а в итоге в игре мы получим долгожданное CTD при вызове такого НИФ-а.
Трудность поиска такого бага заключается в том, что сам Нифсоп, не находя имени в массиве строк с подходящим индексом, подставляет туда строку с индексом "0", и вы в упор смотреть будете и не увидите проблемы. Можно только косвенно догадаться, зная что самая первая строка в вашем НИФ файле не может иметь индекс больше нуля, или заранее зная размер массива строк в вашем НИФ-е.
А вот тут поподробнее пожалуйста ! ))) Чего это там дублируется, у меня такого не было. Хотя нет, я догадываюсь в чём дело. Если сделать импорт в НИФ файл один раз, а потом в него же импортировать второй раз, то тогда да, будут дубли всех костей и их имён т.к. их присутствие моя программка не проверяет, а просто создаёт всё что ей нужно заново. Моему способу работы с НИФ-ами это абсолютно никак не мешало, т.к. скин переношу в самый последний момент и всегда использую для этого другой файл, а фактически работаю с НИФ-ом где скина нет. Ну или же в крайнем случае просто удаляю руками из НИФ-а все ноды скелета и скина.
Это те то чтобы глюк, просто особенность у программки такая (код проще выходит, если не заморачиватся поиском существующих элементов).
Aksyonov, в игре для скелета используются два файла: "skeleton.nif" и "skeleton.hkx", так вот в последнем файле тоже надо менять координаты костей, чтобы всё правильно заработало.
Aksyonov, можно попробовать увеличивать шанс выпадения анимации добивания до 100% при экипировке оружия. Как точно не знаю, но можно глянуть как это реализовано в моде "The Dance of Death - A Killmove Mod"
Myprism, помнится у тебя был интерес к программке, которая бы обрабатывала проблемы связанные с индексами имён и пустыми именами в НИФ файлах ?
Так вот, вчера у меня дошли таки руки, и набравшись вдохновения я написал немножко кода, призванного облегчить отлов этих незаметных багов. Если интересно, то вот сама утилита: "СКАЧАТЬ" (инструкция внутри). Позже оформлю её как положено, отдельным модом.
А сейчас мне интересно, может ей чего добавить или исправить надо ? В общем хочу собрать первые впечатления у знающих людей
Myprism, я сам её на всё свою папку "meshes" запустил, 6 гигов за ~3 минуты прошуршало и тоже нашло пару ошибок. В теле одежды одной компаньонки _0 была нормальная, а _1 содержала баг индекса. И один блок модели был без имени вообще. Теперь на два CTD в игре будет меньше Жаль только , что BSA архивы распаковывать для проверки надо.
@perture, анимации могут всем управлять, но их можно создавать и на отдельные части тела (для факела на левую руку например), или используя анимационные ключи только для поворота или только для масштабирования.
@perture, сказать трудно, нужно экспериментировать. Я создавал анимацию, используя все три вида ключей, и они все работали. Но скелет я никогда не менял, использовал или ванильный или XPMS.
Совпадение имён программой не проверяется т.к. это не вызывает ошибок, на сколько я знаю. Но если есть данные что вызывает, могу встроить.
Также можно ещё чего нибудь попроверять, давайте идеи
совпадение имени любого дочернего блока с именем корневого нода
Проверю, но мне кажется это не в совпадении имени дело, а в неправильном трактовании Нифскопом ошибочного индекса. Просто когда индекс выходит за пределы массива строк заголовка НИФ файла, то Нифскоп подставляет вместо имени строку с нулевым индексом, таким образом маскируя ошибку, приводящую в дальнейшем к вылету из игры.
Myprism, думал над этим, но там для меня очень много работы. Ведь придётся описать в программе все блоки, способные иметь индексы имён и потом перелопачивать их. У меня же описаны всего лишь около 20 основных, с которыми мне приходилось работать. К тому же выгода маленькая, просто НИФ файл станет опрятнее выглядеть.
Myprism, всё равно не получится, ведь чтобы знать используется данная строка или нет, нужно открыть каждый блок, содержащий поле для индекса имени, и проверить куда он указывает.
Меня по началу тоже это беспокоило, а потом привык Где не лень, просто чищу руками.
Я вообще всегда считал, что VertexColors это просто альтернативный способ покрасить модель В своём самом первом моде про личинок я так и делал, а ещё видел ванильную бутылочку у которой текстура бесцветная, но при этом в игре она зелёная, с переливом цвета, как раз за счёт VertexColors.
Aksyonov, а в шейдерньіх блоках НИФ файлов пола/стен/потолка не стоит случайно галочка "Cast_Shadow" ? Кажется именно она отвечает за то, будет ли поверхность отбрасывать тень или нет. Ну и на всякий случай проверь, чтобьі поверхность бьіла видимой с обеих сторон, тогда точно тень будет.
FroSTDS, ниф-скрипта под новьій Блендер я не дождался, поэтому сделал ему своеобразную замену. Можешь посмотреть на мои утилитьі (через мой профиль их легко найти). В принципе они умеют делать всё что нужно.
Никто не знает как ГГ, привязанного командой "SetVehicle()", заставить вращаться ? А то по вертикали углы камеры наклоняют и тело ГГ, а повороты по горизонтали - нет (камера то вращается, но поворота тела ГГ не происходит).
Или может какая то команда, позволяющая определить направление, куда смотрит камера ГГ (куда показывает курсор) ?
Рип, на сколько я знаю это делается только руками в 3Д редакторе и никакие модификаторы тут не помогут.
Я сам когда то написал программку, позволяющую автоматически перенатянуть одежду на любое другое скайримовское тело. И на объектах без особых "вогнутостей" она даже работала. Но на реальных, особенно качественных, моделях в итоге сильно комкалась сетка в упомянутых местах. Так что от этой идей пришлось отказаться.
Cardboarddog, я тоже экспериментировал с телом и могу подтвердить, что за основу тела берётся модель _0, и все морфы действуют именно на неё. И только когда ползунок веса выставляется на максимум, подгружается модель _1.
Myprism, это точно. И на сколько я помню именно с такой одеждой (где точки расположены наиболее близко к телу) и получается наилучший результат. Но даже со сложными моделями выходит довольно неплохо. Если особо не вглядываться, то дефектов сетки практически не видно. По крайней мере 99% времени игрового процесса никому и в голову не придёт, что там что то не так. Но если человек настроен на получение максимального качества, то тут только руками делать.
В своё время я экспериментировал с морфом одежды с ванильного тела на "пузатое" UNP, и одежда с объёмным воротником, складочками и пуговками переносилась идеально, кроме тех мест, где в теле были резкие переходы из выпуклого состояния в вогнутое (под грудью, на боках). Но комканость сетки хорошо заметна только в 3Д редакторе, в игре дефекты сглаживаются.
FroSTDS, на первом скриншоте видно, что блок [NiTriShapeData]никак не связан с [NiTriShape], но зато почему то аж целых два блока шейдеров. Это неправильно. Если сделал это руками, то надо исправить: вместо второго блока [BSLightingShaderProperty]поставить блок [NiTriShapeData](индексы 14 и 20).
Aksyonov, к сожалению доделать скрипт для 3Дмакса пока никто не предлагал, и я таких людей не знаю кто смог бы в этом помочь. Так что вопрос остаётся открытым.
Myprism, Вот скрипт экспорта Vertex Colors для триангулированной модели из Блендера в ТХТ файл: (импорт я не делал т.к. ни разу не было потребности а этом)
Код
#========================================================================================================== # Save VERTEX COLORS for Mesh #========================================================================================================== import bpy bpy.ops.object.mode_set(mode='OBJECT') MyObject = bpy.context.active_object if not MyObject: raise Exception("ERROR: No OBJECT selected.") MyObjectMesh = MyObject.data if not MyObjectMesh: raise Exception("ERROR: Could not get MESH data from Selected object")
# save Vertex Colors (for Trangulated mesh ONLY) (OBJ file already must have Triangulated faces) # Эти группы ВертексКолоров соотведствуют координатам вертексов в Фейсах (сколько в обьекте Фейсов - столько будет экспортировано строк )
for faces in facelist: MyFileWrite("%10.6f " % colorlist[faces.index].color1.r) # VertexColor for First vertex in Face MyFileWrite("%10.6f " % colorlist[faces.index].color1.g) MyFileWrite("%10.6f " % colorlist[faces.index].color1.b) MyFileWrite("%10.6f " % colorlist[faces.index].color2.r) # VertexColor for First vertex in Face MyFileWrite("%10.6f " % colorlist[faces.index].color2.g) MyFileWrite("%10.6f " % colorlist[faces.index].color2.b) MyFileWrite("%10.6f " % colorlist[faces.index].color3.r) # VertexColor for First vertex in Face MyFileWrite("%10.6f " % colorlist[faces.index].color3.g) MyFileWrite("%10.6f\n" % colorlist[faces.index].color3.b)
MyFileWrite("[End]\n") MyFile.close() print("\nWriting to file [%r] done." % FilePath)
Полученный ТХТ файл нужно указать программке "MeshInjector" в качестве третьего параметра.
Программирую я на MS Visual Studio 2013/2010 Express. Спецификацию НИФ-а узнал случайно, глянув в помощь Нифскопа. У него просто море информации оказалось, и именно такой, которая нужна программисту. После этого и началось всё моё "творчество" )))
Дубли блоков или имён у меня никак не влияли на импорт скина, поэтому я и не усложнял себе задачу их устранением. Конечно можно искать существующие блоки по именам, и если такие уже есть, то не создавать их, а использовать существующие. Сделать это относительно просто, но может возникнуть проблема. Если вдруг где то в НИФ файле окажется Нод с таким же именем, но никак не относящийся к нашему скину, то будет такой баг, который потом фиг найдёшь просто так. В общем надёжнее будет просто создать все нужные блоки и сделать привязку именно к ним.
Aksyonov, ну всё таки пользователей, знающих Макс, на порядок больше, чем знающих Блендер, поэтому шанс встретить такого человека всё таки существует )))
@perture, в моём моде "Body Animator" есть скрипт, экспортирующий скелет, скин и анимацию модели в текстовые файлы. Один пользователь на Нексусе попробовал переделать его под Макс, и кое что у него даже получилось, но потом он пропал и скрипт так и остался недоделанным. Вот про него и речь.
Aksyonov, ну как такое можно обещать ? это уж как получится
@perture, формат файлов очень простой, но словами его долго описывать. В архиве мода есть пример с готовыми текстовыми файлами, глянь на них пожалуйста.
Файл скелета состоит из: - имени текущей кости, - имени родительской кости, - строки координат текущей кости в пространстве, - матрицы поворотов текущей кости, - "компенсаторные" координаты для текущей кости в пространстве, - "компенсаторная" матрица поворотов. ("компенсаторные" параметры нужны для создания патишина, их удобнее генерить в Блендере, чем писать для них код на Си)
Файл скина состоит из: - количества Моделей (если анимируется несколько раздельных обьектов, которые будут иметь каждый свой NiTriShape блок) - имени Модели - количество костей, управляющих моделью - имя Кости - номер вертекса _______ вес вертекса (от 0 до 1)
Файл анимации состоит из: - общее время всей анимации - имя Кости - количество кадров - время, координаты перемещения ( X, Y, Z ), координаты вращения ( W, X, Y, Z ), масштаб (по умолчанию вращение экспортируется в кватернионах, но можно и в эйлеровых координатах, для этого заголовок [Begin]должен быть немного другим)
@perture, проблема в неправильном экспорте матриц поворотов для дочерних костей. Но если все кости в Маске будут иметь "нулевую" матрицу поворотов, то скрипт экспортирует скелет без ошибок.
@perture, матрицы поворотов тоже. Matrix.invert() переворачивает все углы в противоположную сторону. Обычно это нужно, чтобы посчитать "компенсаторную" матрицу для патишина, или преобразовать матрицу глобальных углов в локальные (для данной косточки относительно родительской).
@perture, да, все изменения происходят в локальной системе координат для каждой косточки, это только для создания "патишинов" используются глобальные координаты. Да и в Блендере так же просто: например в имени функции получения матрицы дописываешь в конце _local и получаешь в локальной системе (или наоборот .. )
@perture, "компенсаторные" координаты рассчитываются как обратные текущим, но только в глобальной системе координат (т.к. все вертексы модели находятся именно в ней). И нужны только для создания патишн-блоков [NiSkinInstance].
Своими словами: их роль "вернуть" вертексы, задействованные скином данной косточки на своё место. Если просто привязать вертексы к ноду-косточке (без компенсаторного патишина) то все они переместятся в систему координат этой косточки и модель порвёт на части. В патишн-блоке хранятся данные об обратном преобразовании, Нифскоп (/Движок игры) берёт их и возвращает каждый вертекс на своё место. Надеюсь у меня получилось объяснить
Мы Вконтакте
) 