Спасибо, конечно, за спасибо! :) Но!

Есть большая ж. Даже так - Ж! Группы сглаживания в Иловских мешах не сохраняются!

Для того, чтобы ускорить загрузку моделей в игре, иловский меш уже содержит все необходимые, предварительно рассчитанные нормали. Т.е., в таком подходе большой плюс в том, что у тебя все необходимые данные просто грузятся в буферы и отдаются на отрисовку. Не надо на этапе загрузки моделей рассчитывать нормали (а это занимает время и требует определённых манипуляций с данными). Разработчики не ставили целью возможность восстановить модель из своего формата, им это не нужно было, у них модели и так были в наличии. А вот скорость загрузки моделей и простата манипуляций с ними для них важна.

Я уже давно ломаю голову над тем, как можно из имеющихся данных попробовать восстановить группы сглаживания. К сожалению простых и надёжных способов для этого нет. И открытых алгоритмов для этого, похоже тоже нет. Беглым просмотром в гугле я ничего толкового на эту тему не нашел, даже намёков на решение. Придётся придумывать самостоятельно, а это очень трудоёмкая и непростая задача. Не знаю, буду ли я этим вообще заниматься. Было бы хотя бы годное описание мат аппарата для этой задачи, хоть можно было бы оценить во что это выливается. У меня опыта в решении такого рода задач нет. Как я уже говорил, 3Д я раньше вообще не занимался.

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

Вот такие пироги.

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

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

формат .3ds в принципе не сохраняет сглаживание. Из любого формата можешь прям в максе экспортнуть в .3ds и открыть. Сглаживания не будет. Меня больше интересует хиер хим. Т.е. открыть модель целиком в максе, повернуть все по-человечески и экспортить в Ил. Открывал кокпит ЛА5. Приборная панель повернута вправо, кресло влево, педали вообще сзади.:lol:

А какие сохраняют без наличия других проблем?

Может тогда есть возможность сразу конвертнуть в .max? :rolleyes:

ндык .obj. В идеале .fbx.:)

Макс открывает. Материалы, мапинг вроде на месте. Только носом вниз почему-то.

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 подключится и пояснить наверное.

При открытии в максе убери галку с Flip Z-Y axiz

если вы пытаетесь из текстового меша сделать корректный импорт в макс, то под этот материал NULL должно резервироваться ID1 в мультиматериале вашей модели. Дефолтный стандартный список материалов для самолётов где-то тут лежал в одной из соседних веток, там NULL Gloss1D0o Gloss1D1o Gloss1D2o Matt1D0o Matt1D1o и т.д., включая материалы для теней Shadow и т.п. Всего в районе 32 материалов для внешек самолётов. В кабинах уже стандартизации, понятно дело нет, там всё зависит от самой кабины. Но желательно всё же резервировать и там материал с ID1 под материал NULL.
Файлы объектов наземки используют обычно только два основных метериала, но и там нужно по-хорошему оставлять для NULL материала ID1.
Я всегда считал, что из текстового меша фейсы с материалом нуль не восстановить, т.к. сами фейсы в текстовый меш не идут, а используются для просчёта нормалей смежных фейсов. Пример на практике применения материала NULL был рассмотрен choisek-ом в теме E13A, где он сглаживал им заслонки радиаторов на капоте.
Также, сколько я видел конвертеров мешей, ни один из них абсолютно корректно группы сглаживания не восстанавливал, и файлик приходилось пилить вручную.
А ну и про масштаб напомню, хорошо бы, чтобы при импорте в макс можно было указывать масштаб вручную, тк в иле принято модели в максе делать в масштабе 20:1.

Если вспомнить, что во время появления Ила основным средством его распространения были CD-диски забота разработчиков о размере не покажется излишней.

Ну по крайней мере меш конвертер что-то пытается изобразить-показать при конвертации в 3ds например. Эти(NULL) полигоны ,вроде как лишние на первый взгляд выводятся и в максе видятся.

Хотя с другой стороны, может забить на этот NULL и от безисходности смирится с последующим вручную работой в максе с этим материалом ?

Или как предложил У2 просто забить место в списке материалов для NULL в виде ID1

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Пффф...

Однако, я так сохранение в 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 - пофиг. Там локальные матрицы сохраняются при записи.

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

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

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

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

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

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

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

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

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


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

А что получается 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) , хуки ВРУЧНЮ раскидал спонтанно для наглядности