NB79 Tool - разработка)

[NB79]

Сообщение от carsmaster

Вот эта фраза несколько смутила, а особенно вкупе некоторыми ошибками в мешах дефолтный(что вы описали).

У меня свой софт для работы с SFS, всех этих проблем в нём просто нет. Он работает с данными так, как с ними работает игра и он много сложнее всех существующих экстракторов.

[carsmaster]

Сообщение от NB79

У меня свой софт для работы с SFS, всех этих проблем в нём просто нет. Он работает с данными так, как с ними работает игра и он много сложнее всех существующих экстракторов.

Dump ?

[Sita.]

ок

[NB79]

Не знаю, что за Dump.

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

[carsmaster]

Сообщение от NB79

Не знаю, что за Dump....

Dump это я имел ввиду дамп актуальных данный напрямую из игры во время ее работы. В принципе есть такая технология для ИЛ-2 тоже.

[NB79]

Сообщение от carsmaster

Dump это я имел ввиду дамп актуальных данный напрямую из игры во время ее работы. В принципе есть такая технология для ИЛ-2 тоже.

А, понятно, разговор о технологии.

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

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

Примерно так.

ОФФТОП off

[NB79]

Так, в аттаче версии с записью в obj всего, кроме библиотеки материалов.
Заодно добавил возможность смотреть коллизии. Надо будет ещё и тени показывать.

Проверте, всё ли нормально пишется. Если всё нормально, то начнём разбираться с материалами, что б экспортировалось без необходимости в дальнейшем переворачивать текстуры.

[carsmaster]

Сообщение от NB79

Так, в аттаче версии с записью в obj всего, кроме библиотеки материалов..

Вроде все работает как надо, надо еще завтра погонять на разных мешах.
Спасибо за труды.

[Sita.]

[NB79]

Сообщение от carsmaster

Вроде все работает как надо, надо еще завтра погонять на разных мешах.

Сигнальте о результатах и пойдём дальше уговаривать текстуры.

[carsmaster]

Сообщение от NB79

Таким образом, при экспорте хуков приходится создавать какой ни будь объект, поворачивать в соответствии с матрице поворота и смещать в соответствии с матрицей перемещения. Вот по этому мы и видим на месте хуков кубы. А у куба 6 граней, и если все грани закрашены одинаковым образом, то совершенно не понятно каким образом расположены его локальные оси, т.е., куда он смотрит - ХЗ. Чтобы этого избежать я крашу грани кубов в разный цвет, по нему визуально можно понять его ориентацию. Это важно потому, что если вы этот куб крутанёте при редактировании, то, для примера, на месте хука с утечкой топлива топливо начнёт вытекать вверх. Пока, из-за того, что запись библиотеки материалов не доделана, всем граням назначен Default материал. Когда доделаю они будут красится так, как у меня во вьювере:

Front - ярко краный
Back - тёмно красный

Bottom - ярко зелёный
Top - тёмно зелёный

Right - ярко синий
Left - тёмно синий

Либо могу назначить другие, нужные вам цвета. Может есть что-то общепринятое в мире 3Д моделинга, я ж не в курсе.

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

Ниже разбирается ситуация в обозначении цветов сторон кубиков хуков, ибо насколько я понимаю вы сделаете возможность красить кубики уже в конечном файле OBJ. Соответственно загрузив в макс мы сможем определить по цветам где у кубика оси X-Y-Z по цветам и направление вектора оси. Соответственно и назначить и правильно выставить пивот.

На скриншотах представленно классическое представление ЦВЕТОВОГО отображения осей X-Y-Z в МАКСе

X- красная

Y-зеленая

Z- синяя

мне кажется и стороны кубика хуков стоит красить в соответствии с максовской "цветовкой"

Причем мне кажется надо красить всего 3 стороны кубика, в соответствии с направлением векторов осей X-Y-Z .
А другие 3 стороны кубиков хуков можно оставить и просто серыми.

Для примера взят все тот же меш CF_D0(без теней, лодов и коллизий) от Ki-43-II(Multi1) , хуки ВРУЧНЮ раскидал спонтанно для наглядности

[NB79]

Сделаю под Макс.

Вообще, для хуков, при импорте их Макса, будет важно соблюдение определённых правил. Так как матрица трансформации при сохранении в obj должна восстанавливаться из модели объекта, надо будет соблюдать определённые правила при создании и редактировании хуков.

Первое. Хук обязательно должен иметь 8 вершин и 12 граней (куб, параллелепипед)
Второе. Порядок нумерации вершин должен быть определён единообразно (сейчас с планшета пишу, уточню потом, но кажется: против часовой, от передней нижней правой).

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

Но это мы уже потом доточим до нужной кондиции, когда импорт модели в игру делать будем (загрузку в тулзу из obj, или 3ds). Сейчас надо материалы добить правильно, последнюю неопределённость устранить.

[carsmaster]

Сообщение от NB79

Сделаю под Макс....

....Но это мы уже потом доточим до нужной кондиции, когда импорт модели в игру делать будем (загрузку в тулзу из obj, или 3ds). Сейчас надо материалы добить правильно, последнюю неопределённость устранить.

Это просто праздник какой-то

[Grog]

Ничего не понимаю во всём этом, но!!!
Чувствую, что надвигается что то грандиозное, важное!
NB79!
Спасибо тебе огромное, за то что созидаешь для любимой игры!

[Sita.]

вообще Шикарно)))

[NB79]

Спасиб!

Но вопросов пока всё равно много.

Например. Иловский материал имеет до четырёх слоёв. Назначение слоёв мне пока до конца не ясно. Где-то первый слой и есть текстура, остальные пустые. А в корабликах, например, первый слой - пустой, имя текстуры во втором. В дополнение к этому материалы имеют древовидную иерархию с наследованием части параметров от родителя к потомку (дерево при чтении материалов я строю). В общем, повозиться там есть с чем. Надо физический смысл структуры mat до конца понять.

[carsmaster]

Сообщение от NB79

Например. Иловский материал имеет до четырёх слоёв. Назначение слоёв мне пока до конца не ясно. Где-то первый слой и есть текстура, остальные пустые. .

Ну мне не встречалось использование двух и более СЛОЕВ в материале в игре.

В ИЛ-2 есть "заготовки" кода и обрезки былых идей, которые в настоящей версии игры не используются, так как "ведут в никуда"

Насколько мне известно в игре "Вторая мировая" ,что построена на движке ИЛ-2 есть использование второго слоя явно для многих моделей. Но там используются текстуры DDS и второй слой в материаля это попытка изобразить убогий бамп(рельеф)

В ИЛ-2, да можно тоже подключить второй слой, но он будет работать либо в убогом режиме смешивания либо вообще заместит первый слой.

Моя практика показывает полную бестолковость использование второго слоя в текущей версии движка. (или мои познания не полны)

Сообщение от NB79

А в корабликах, например, первый слой - пустой, имя текстуры во втором. .

С корабликами никогда не занимался.

Можно для примера выложить МАТ файл кораблика с пустым первым и ТЕКСТУРНЫМ вторым слоями ?

Сообщение от NB79

В дополнение к этому материалы имеют древовидную иерархию с наследованием части параметров от родителя к потомку (дерево при чтении материалов я строю). В общем, повозиться там есть с чем. Надо физический смысл структуры mat до конца понять.

У меня сложилось представление, что использование лежащего в папке с самолетом файла Base.mat связано исключительно для экономии "места в памяти" и снижения объема(времени) чтения параметров материалов.
Просто основные параметры берутся из ОДНОГО файла Base.mat , а уж исключительные в файле самого материала меша.
Вот и все, вот и все "дерево" материалов

Мне кажется данный способ на современном железе лишен смысла. Ибо не 2001 год на дворе и никто не считает память " а у меня 128Мб памяти" или " А у меня целых 512Мб памяти".

Ибо есть куча модов работающих на ура, в которых это "дерево" материала(родитель потомок) исключено.
Все параметры описаны в КАЖДОМ файле материала(пусть даже они и на 80% общие для всех материалов).

[NB79]

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

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

Мат с пустым слоем сейчас закину. В корабликах таких масса, почти все, наверное.

[NB79]

На счёт "почти все" я загнул всё же. Сейчас глянул - много, но меньше половины.

Вот, из "Авроры" несколько, даже не рылся особо. Текстуры в слое 1 (нумерация слоёв идёт от нуля, т.е., это второй слой):

[carsmaster]

Сообщение от NB79

..Вот, из "Авроры" несколько, даже не рылся особо. Текстуры в слое 1 (нумерация слоёв идёт от нуля, т.е., это второй слой):

Спасибо, посмотрел.
Я как то упустил из виду повреждения, все ваши примеры как раз и есть наложение вторым слоем повреждений на первый(скин) слой при "событие" повреждение-попадание снаряда..

Тоесть попросту говоря СЛОЙ 0 вовсе не пустой у объекта ,он просто из основного материалы берется.

Тоесть изначально все равно один слой пользуется. Ну примерно как и у самолетов дырки накладываются потом сверху скина



Тоесть аля "оверлей"