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

[carsmaster]

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

Переделал сохранение obj-а (всё ещё не полное, пока надо разобраться что не так с загрузкой). Проверьте, пож., будет Макс его грузить, или нет. И если загрузит, то всё ли нормально.

1. Дописал в ваш файл материалов(.mtl) используемые текстуры(текстуры кинул в ту же папку что и obj) чтобы открывались сразу с текстурами .

Используемые текстуры дописал по аналогии как конвертер MSFX пишет в создаваемый файл .mtl при сохранении в OBJ

newmtl Glass2
Ns 50.0000
Ni 1.5000
d 1.0000
Tr 0.0000
Tf 1.0000 1.0000 1.0000
illum 2
Ka 0.9176 0.9176 0.9176
Kd 0.9176 0.9176 0.9176
Ks 0.0000 0.0000 0.0000
Ke 0.0000 0.0000 0.0000
map_Kd glass.tga

newmtl Gloss1D0o
Ns 50.0000
Ni 1.5000
d 1.0000
Tr 0.0000
Tf 1.0000 1.0000 1.0000
illum 2
Ka 0.8353 0.9176 0.9176
Kd 0.8353 0.9176 0.9176
Ks 0.0000 0.0000 0.0000
Ke 0.0000 0.0000 0.0000
map_Kd skin1o.tga

2. Имеются странности в вашем файле. Тоесть с текстурами файл открывается MSFX конвертере и показывает нормальный маппинг на экране,
2.1 при сохранении в 3ds в этом MSFX конвертере и последующей загрузке этого 3ds в макс маппинг становится такой же неправильный как и в описании пункта 3 ниже


3. При загрузке вашего obj стразу в макс2012 вроде все нормально, но маппинг НЕ ПРАВИЛЬНЫЙ !!! показывает

Пробовал сразу в максе разобраться куда сдвинут маппинг и вот картинки в архиве.

4. Там еще "заплатками" имеются полигоны использующие материал NULL. На скрине из макса это БЕЛО_ГОЛУБЫМ цветом они показываются. Эти полигоны вроде тоже выводятся, правда в списке материалов в максе материал NULL отсутсятвует. В подготовленных для экспорта в игру файлах этот материал часто присутствует и назначен определенным дополнителшьным полигонам. Насколько мне известно эти полигоны с материалом NULL используются для закрытия СТЫКОВ мешей . Этот материал NULL для меня пока темное дело, тут например должен У2 подключится и пояснить наверное.

[NB79]

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

3. При загрузке вашего obj стразу в макс2012 вроде все нормально, но маппинг НЕ ПРАВИЛЬНЫЙ !!! показывает

Пробовал сразу в максе разобраться куда сдвинут маппинг и вот картинки в архиве.

Хм. Возможно, что я понимаю откуда у этой проблемы растут ноги.

Скины у самолётов в формате IMF. У TGA формата в заголовке есть флажок указывающий на то, как сканлайны в файле идут. Если он не установлен, то идут сверху вниз. Если установлен, то снизу вверх. У IMF такого флага нет. При конвертации из IMF в TGA этот флаг нужно всегда устанавливать, в IMF сканлайны идут снизу вверх (по крайней мере другого ни разу я не видел).

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

У себя, при отрисовке модели, я всегда смотрю, надо ли переворачивать картинку перед тем, как текстуру биндить. Если надо, я меняю верх с низом. Текстуры рисуются правильно. И ваш конвертер для MSFX тоже маппинг показывает правильно, значит он тоже смотрит на этот флаг и при биндинге текстур, если надо, переворачивает их.

Возможно, что Максу надо принудительно переворачивать текстурные координаты. Но если это так, то это очень неприятно. Во-первых, это чревато различными не предсказуемыми косяками. Во-вторых, возникает путаница в текстурах, становится непонятно, когда надо переворачивать, когда нет. Мне не нравится даже сама идея, что надо что-то менять во входном потоке, и без этого во всёй это процедуре конвертации проблем масса. Может в Максе есть какая ни будь настройка, в которой указывается, что у текстуры надо верх с низом поменять местами?

Хотя это всё равно очень странно.

[carsmaster]

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

Хм. Возможно, что я понимаю откуда у этой проблемы растут ноги.

вы правы, отразил текстуру в фотошопе по вертикали и в вашем файле маппинг стал нормально видится в максе.

Вот и думаю в чем засада, в ИЛ-2 впервые сталкиваюсь с таким .Текстуры из IMF в TGA перегонял проверенным безлтказным ViewIMF-V1_0.exe Так как МАКС c IMF(из ИЛ-2) не может работать

С таким "переверт" текстурами сталкивался в MSFX или X-Plane , когда они используют текстуры DDS. Там тоже бывает приходится для работы с моделью в максе перевертывать текстуры.

В ИЛ-2 с таким сталкиваюсь впервые.

Давайте "выдайте"(если конечно сейчас можно это) людям тулзу с возможностью записи, попробуем на разных мешах набрать статистику далее

[Pumping_Noise]

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

[NB79]

В Иле часть текстур - TGA, а часть (возможно, что большая, не проверял) - IMF. Как уже говорил, для IMF нужно верх с низом менять местами.

Мне сложно сказать, в каком месте возникает проблема. На Макс сложно грешить в вопросах работы с изображениями, продукт очень солидный. Может проблема в конвертере IMF в TGA, он ведь картинку конвертит так, чтоб для просмотра верх был верхом. А ИЛ при биндинге текстур ориентируется на то, чтобы текстура села правильно. Если у модели маппинг перевёрнут, то и картинку нужно перевернуть. Т.е., если вы делаете модель, то в экспорт идёт модель именно с той текстурой, что была при изготовлении модели. И тогда Ил покажет модель корректно. А как эта картинка показывается во вьювере - совершенно не важно. Текстуры для Ила изначально делались в DDS. Потом их конвертировали в TGA. Потом часть текстур дополнительно конвертировалась в IMF. Мне кажется, что проблема где-то здесь и зарыта. Движок Ил биндит IMF текстуры зная об особенностях их ориентации. Конвертер же конвертит IMF так, чтобы верх РИСОВАЛСЯ верхом.

Конвертером я не пользуюсь, у меня работа с IMF своя прописана. Моя утилита может работать и с TGA, и с IMF текстурами, ей без разницы. Надо будет наверное при экспорте делать и экспорт текстур, и если текстура IMF, то конвертить её в TGA так, чтоб в Максе она показывалась и мапилась правильно.

[carsmaster]

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

В Иле часть текстур - TGA, а часть (возможно, что большая, не проверял) - IMF. Как уже говорил, для IMF нужно верх с низом менять местами..

А вот эта настройка не поможет зацепиться за проблему?

Вот два скрина настроек меш конвертера при экспорте меша в 3ds например .

первый с настройками по умолчанию

второй рекомендуемые авторами меш конвертера, там в двух местах надо -1 ставить

[NB79]

Не знаю, пока ничего сказать не могу.

На самом деле в Иловских материалах есть поля и скалирования, и смещения. Но они, на сколько я понимаю, немного для другого используются. Они используются при биндинге текстур и отрисовке модели.

Что будет с моделью в самой игре, если принудительно менять модели и текстуры, я не знаю. Не хотелось бы сейчас вносить изменения сразу во много мест. Иначе потом, в случае каких-то проблем, будет вообще не разобраться откуда ноги растут.

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

PS: Обновлённую утилитку с записью в obj выложу завтра, не всё доделано. Основной работы сейчас много, на утилитку очень мало времени очтаётся.

[carsmaster]

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

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

Весьма здравый подход.
Удачи вам.
Спасибо за желание внести свой вклад в развитие ИЛ-2.

[Sita.]

да... достойное дело!

[NB79]

Пффф...

Однако, я так сохранение в obj до конца и не доделал. Плотно залип с хуками и по этому не дописано сохранение коллизий и библиотеки материалов. В аттаче версии, которые записывают obj, без коллизий и библиотеки материалов. Надеюсь, что смогу к завтрему дописать недостающее.

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

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

В Ил-2 хук представляет из себя матрицу поворота (3x3, w векторов = 0) и 3 компонента из матрицы перемещения (из нижнего ряда матрицы 4x4, w = 1). И тут самый важный для правильного экспорта/импорта момент: фактически хук, это точка, но объект, присоединяемый к этой точке должен в соответствии с матрицей поворота оказаться развёрнут относительно его локальных координат.

С одной стороны - в этом ничего сложного нет. Про маричные преобразования литературы вагоны и учат их на первом, кажется, курсе института (я учил 35 лет назад ). Однако у нас имеется некоторая проблема. В obj нельзя описывать локальные матрицы. В 3ds, например, можно, а в obj нет. Или я тупой и не мог найти в спецификации соответствующий механизм.

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

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

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

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

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

Ещё один момент, связанный с хуками и obj форматом, это размер куба на месте хука. Поскольку у нас объект после трансформаций, то нужную для Ила матрицу при импорте из obj в игру надо будет рассчитывать из модели. Кстати, именно по этому, скорее всего, в MeshConverter-е кубы имеют длину грани 1 и такие здорОвые. Так считать проще. Но я не хочу делать их слишком большими, выбрал размер грани 0.5, вроде так по лучше чисто визуально. Что в этом важно. Если вы во время редактирования поменяете размеры граней для кубов на месте хука, то есть риск того, что точка присоединения поплывёт и поплывёт матрица поворота. Размеры кубов на месте хуков при редактировании и в экспорте в obj лучше не трогать. При экспорте в 3ds - пофиг. Там локальные матрицы сохраняются при записи.

Вроде всё на сегодня. Посмотрите, правильно ли экспортируются хуки и нет ли каких косяков. Во вьювере добавил вкл/выкл показа хуков. Имейте ввиду, иногда хук сидит внутри модели и чтоб его увидеть надо включить показ одной сетки (ну и хуков, естественно ).

[carsmaster]

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

Пффф...
.

Еще раз спасибо за Ваш труд. очень полезная тулза получается.

1. Проверил пока мельком, открывает правильно даже те бинарные меши, что меш конвертер не мог открыть корректно.
Эти упрямые меши ваша тулза и в OBJ корректно перевела. В максе все верно кажет.
Единственное ,что как и раньше приходится для макса текстуру после перевода из IMF в TGa прогой ViewIMF-V1_0.exe ,переворачивать в фотошопе,чтоб маппинг правильно отображался в максе.

2. Теперь по хукам. Меш конвертер например все хуки в формате 3ds валит в центр координат, хотя их там несколько(хуков).

НО !!! у полученных таким образом хуков через меш конвертер(хоть хуки все и свалены в одну кучу) имеется свой центр координат(пивот) У каждого свой по которому и можно увидеть ориентацию самого каждого хука.

Ваша прога сейчас корректно расставляет в пространстве сами хуки по местам. Все вроде нормально выглядит.

НО !!!! вот незадача, у всех хуков центр координат локальный (пивот) каждого хука установлен в центр координат глобальный ,тоесть в 0 0 0

Тоесть у каждого хука центр в одном и том же месте и ориентация соотвенственно одинаковая

А должно быть у каждого хука свой центр(пивот) координат в центре кубика видимого и соответсвенно при перемещении кубика в максе и центр должен двигаться вместе с кубиком


Если описал сумбурно и непонятно, то дайте знать и сделаю скрины.

[NB79]

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

[carsmaster]

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

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

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

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

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

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

[NB79]

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

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

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

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

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

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

[carsmaster]

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

.

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

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

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

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

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

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

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

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

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

[Pumping_Noise]

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


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

[NB79]

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

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

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

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

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

ВотЪ.

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

[yt2]

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

[carsmaster]

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

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

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

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

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

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

[yt2]

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

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