А что получается c хуками, если MeshConverter-ом сохранить в obj и потом этот obj открыть в Максе? Как там выглядит история с центром координат для хука?

При сохранении в OBj меш конвертер правильно раставляет хуки в пространстве. НО !!! так-же назначает все центры хуков(пивоты) в одну точку с координатами 0 0 0.

Тоесть по идеи тоже не правильно:(

Вот на скринах показаны пивоты для OBj и 3DS после меш конвертера

Для 3DS я вручную раздвинул абы как хуки(они все были в одну точку свалены и смотрелись как один хук)

Как я говорил, при экспорте в 3ds можно указать локальную матрицу. По этому оси для объекта определены. В obj возможности указать матрицу для объекта я не нашел. Может плохо искал.

Попробуем ещё один эксперимент провести. Если не сложно, то надо сделать следующее:

1) В Максе создать какой ни будь простой объект, хоть куб, имитирующий главный лод.
2) Добавить рядом второй объект, который будет имитировать хук.
3) Записать результат в obj.
4) Открыть этот obj Максом.

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

Кстати, а есть ли в Максе такое понятие, как хук? И если есть, то что с ним происходит при экспорте в obj и последующем открытии этого obj в Максе?

Будет немного обидно, если obj не позволит нормально перегонять файлы туда-сюда. Столько времени на него убили...

Увы, результаты моего эксперимента начинающего 3Дшника для нас неутешительный

1. Пробовал в OBJ загнать готовый самолет в максе, который нормально экспортируется и летает в игре.
Так вот при перегоне из макса в OBJ все хуки хоть и остались на месте в пространстве, но у всех хуков центры(пивоты) сбросилсь в центр глобальный, тоесть в 0 0 0 :(
Пару более мелких экспериментов провел еще в OBJ и хуками, результат тот же, в OBJ хуки теряют сразу свой родной центр(пивот) и получают пивот в 0 0 0:(

2. Отсюда делаю вывод OBJ (как вы и описывали) не может сохранить нужные нам центры хуков.

3. Есть еще формат FBX, но я глянул мельком его в максе при экспорте и там куча настроек экспорта. Этот формат хоть и сохраняет нужные нам центры хуков, но боюсь там сложности большие возникнут в настройках(что писать? как? с какими настройками импортировать-экспортировать из вашей проги и в макс?)

4. Как промежуточный вариант это экспорт вашей тулзой в OBJ меша из игры , импорт OBJ в макс и последующее ВРУЧНУЮ назначение уже в максе каждому хуку центра(пивота) с правильной ориентацией.
Да муторно немного, но гораздо менее муторно ,чем биться вообще с кривым экспортом через меш конвертер без вашей проги.

5. Ну и с перевернутыми аля текстурами в максе очень неплохо бы было что-то придумать.:beer:

Как то так пока.

Но как не крути, даже сейчас ваша прога очень полезна !!!

Да, развертку в 3д максе нужно флипнуть по вертикали. Полтора часа ждал, пока запекалась карта теней и все зря...%):D В любом случае большое спасибо за программу!

:good::thx:
А будет ли добавлена функция открытия хиер хима?

Him/sim будет после того, когда с частями, связанными с мешами будет всё в порядке. Там уже будет много проще всё открывать и записывать/конвертировать.

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

Полное сканирование всех мешей в игре показало, что имеются следующие проблемы:

- Дублирующияся хуки (Avia534, yak-7b(fr), yak-7b(multi1))
- Отсутствие имени хука при наличии данных для него (yak-7b(fr), yak-7b(multi1))
- Кол-во лодов в секции [LOD] не совпадает с реальным кол-вом лодов в меше (таких мешей много)
- Отсутствие секции, указывающей на кол-во блоков коллизий (в Жужах такая беда)
- Отсутствие секции. указывающей на кол-во частей в блоке коллизий (в Жужах, Р-11)

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

ВотЪ.

PS: Sita, я тебе лог со списком проблемных мешей чуть позже в личку скину.

Список всего замеченного отправь Site. По жужам можно сравнить сорцы, особенно касаемо добавленных в 413 жуж.

ок

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

Ниже описан доступный рядовому мододелу способ получения нужных ВСЕХ!! самолета и кокпита к нему , а так-же других обьектов:

1. ИЛ-2 создавался постепенно в том наполнении контентом что есть сейчас. По мере добавления новых самолетов и объектов создатели правили некоторые файлы в старых своих самолетах и вводили их в игру в новых патчах для игры в новых архивах SFS со следующим номером.
Что это значит? А то например файл CF_D0.msh лежащий в папке самолета 3do/Yak-3(Multi1) который вы извлекли экстратором из какого либо архива SFS , вовсе не 100% файл CF_D0.msh этого самолета что вам нужен. Соответственно вы вроде извлекли перебирая несколько архивов весь самолет и он может даже полететь. Но гарантии что это весь самолет в КРАЙНЕМ варианте от создателей игры нету.

2. Почему так происходит ? Да потому что архивы SFS в игру читаются и загружаются в последовательности их нумерации, тоесть сначала читается например fb_3do06.SFS , потом fb_3do07.SFS и так далее по нумерации архивов. Карты тоже грузяться тоже по номерам архивов.

А так как создатели игры постепенно правили некоторые файлы(например в Yak-3(Multi1) ,то вам могут попадаться для одного и того же самолета CF_D0.msh как в fb_3do06.SFS так и в архиве fb_3do07.SFS

Причем файл из крайнего по номеру архива и будет работать в игре !!!!!!!!!!!!!!!!

Была недавно ситуация с самолетом одним, когда использовались некотрые файлы старых версий самолета(без нужного количества коллизий). А нужный файл лежал ОДИНОКО в следующим по номеру архиве.

Так что самый лучший способ это последовательно ПО НОМЕРАМ извлекать все файлы самолета в одну папку, При совпадении путей и имен при извлечении из следующего архива по номеру НА ЗАМЕНУ соглашаться.

ТАК ПЕРЕБИРАЮТСЯ ВСЕ АРХИВЫ И ТОЛЬКО ПОЛУЧЕННАЯ ТАКИМ ПУТЕМ ПАПКА С САМОЛЕТОМ И БУДЕТ СОДЕРЖАТЬ КРАЙНИЕ ВЕРНЫЕ ВЕРСИИ ФАЙЛОВ ОТ РАЗРАБОВ И УСТАНЕННЫМИ НЕКОТОРЫМИ КОСЯКАМИ(конечно не все косяки разрабы устранили и в крайних версия)

В идеале надо все архивы распаковать последовательно в одну папку согласно номерам архивов, заменяя уже имеющиеся там файлы по одноименным путям

Причем надо иметь ввиду , что для архивов с цифро-буквенной нумерацией сначала распаковывается например fb_3do14.SFS , потом fb_3do14p.SFSи только потом fb_3do15.SFS

Для чего все напаисал то? А для того чтобы мужики не закрались ЛОЖНЫЕ косяки бы в те файлы что вы проверяете и работаете сними.
Может в игре есть и другой такой файл в другом архиве уже с исправлениями и без ошибок

глянул список Sit'ы. По жужам
проверил меш fakenose_d3 на Ju88A5Late
там действительно косяк в секции лодов. прописано три лода, хотя их 4
плюс некорректные дистанции указаны.
теперь почему - текстовые меши получал вручную через мешконвертер и правил им секцию лодов на всех новых жужах. видимо некоторые меши пропустил.
поэтому я товарища NB79 и терзал консольной версией его тулзы

т.е. некоторые меши новых жуж придётся его тулзой заново перевести в текстовый вид, занести им новые дистанции видимости как у всех остальных мешей, и отправить в патч 4.13.1
По жужам я могу это контролировать. Возможно и по Б24 материал найду если там много косяков.

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

Dump ?:)

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

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

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

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

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

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

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

ОФФТОП off

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

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

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

:good:

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

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

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

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

X- красная

Y-зеленая

Z- синяя

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

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

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