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

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

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