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

[Sita.]

Чёткий квалифицированный комментарий

да функции вьюера нах не нужны (мне)
корректная конвертация bin -> txt нужны
чтоб ещё и сохранял в максовски-понимаемый формат да
чтоб и хиеры читал
и чтоб если и группы сглаживания и мапинг не херился )

[Sita.]

просьба к модераторам вынести всё касающееся в ветку NB79 Tool

[NB79]

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

2. Игра ИЛ-2 считает все в метрах с точностью до 6 знака после запятой
Соответственно учитывая наверное это вот секция сохраненная имеющимся меш конвертером

[MaterialMapping]
1 0
0.4999847 0
0.4999847 0.4999847
1 0.4999847

вот тот же самый меш сохраненный вашей программой

[MaterialMapping]
1.00002 0
0.5 0
0.5 0.5
1.00002 0.5

Может стоит последовать примеру создателей имеющегося меш конвертера в плане точности ?

А вот тут я должен важный комментарий сделать.

MeshConverter не правильно обрабатывает один из сохраняемых в бинарном меше тип данных. В бинарном меше несколько способов сохранения значений. В зависимости от величины значений в блоке данные могут сохраняться в виде одно, двух, трёх, или четырёх байтных значениях. Для целочисленных значений, кроме этого, дополнительно возможно сохранение значений в виде накапливающихся разниц двух соседних значений. Это сделано для уменьшения размера файлов. Так вот, один из способов сохранения, когда исходные четырёхбайтовые числа с плавающей точкой преобразуются в трёхбайтовые, все виденные мной утилиты обрабатывают неверно. За счёт этого разница и возникает.

Я специально потратил на изучение этого момента изрядное кол-во времени. Как я уже говорил, в СПШ модели сохранялись в текстовом формате. Я брал одинаковые модели из СПШ и текущей версии и конвертируя их MeshConverter-ом и своей тулзой сравнивал результат. На трёхбайтовом типе у МС и других утилит как раз погрешность и возникает. Они забывают в одном месте прибавлять/вычитать единицу.

А так, у меня выводятся значения с точностью до 6 (или 7-ми, не помню сейчас) знаков после запятой. Если значение, например, ровно 0.5, то незначащие нули просто не отображаются.

[carsmaster]

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

А вот тут я должен важный комментарий сделать..

Комментарий действительно важный и профессиональный.

Тогда мы вам доверимся полностью в этом вопросе.

Удачи и здоровья вам.

[yt2]

to N79:
сравнил меш CFAuxTorp.msh от самолёта А-20 из сфски 4.13 переведённый в текстовик вашей программой и оригинал.
отличия (сверял программой WinMerge)
1)как говорил выше carmaster отступ (пробел) в один символ не нужен
2) Секция [Common] записанная экспортером от 1С
NumBones 0 В оригинале тут между s и 0 три пробела, в вашем один
FramesType Single
NumFrames 1 В оригинале тут между s и 1 два пробела, в вашем один
Ерунда? Ерунда. Но всёж.
Иногда встречаются и меши сделанные Мараз экспортером, у них эта секция полностью совпадает с вашей
3)[Hooks]
хуки вида
0 -1 0 1 0 0 0 0 1 0.767157 -0.4956 -0.96075 совпадают.
хуки вида
0 -1 0 1 0 0 0 0 1 0.767157 -1.30 -0.91075
отличаются. в вашем число -1.30 записывается как -1.3
хуки вида
0 -1 0 1 0 0 0 0 1 0.0 -2.3 -0.6
отличаются. в вашем число 0.0 записывается как 0
4)[FaceGroups] (пример из другого меша)
1517 1125
0 0 1353 0 985 0
1 1353 164 985 140 0
тут различия опять в количестве пробелов. оригинальная тулза разделяет числа другим количеством пробелов между цифрами.
Опять же не принципиально, т.к. попадаются меши созданные не этой утилитой.
5)[Vertices_Frame0]
строка вида
-0.005127 -0.005096 0.000000 0.000000 0.000000 1.000000
записывается вашей программой как
-0.005127 -0.005096 0 0 0 1
6)[MaterialMapping]
Строка вида
0.000000 1.000000
записывается как
0 1

[NB79]

Кол-во разделительных пробелов между значениями не принципиально. Парсер строк всё равно сплитит сроку по первому, а остальные отбрасывает. Т.е., они в тексте только место занимают.

Аналогично и с числами с плавающей точкой. Для печати значений я использую стандартную процедуру форматирования. Ей на вход передаётся строка формата и она самостоятельно, под эту строку формата, формирует результат. Для FP использую "%.6g". Т.е., выводится до шести знаков после запятой, не значащие нули отрезаются. Опять же, парсер разделяет значения по разделителю (у нас это пробел) и потом программа конвертирует получившуюся строку в требуемый для секции тип. Если секция должна содержать целые типы - конвертит в целые, если дробные - в дробные. При конвертации дробных, для процедуры, не имеют значения не значащие нули, для неё 1.30 и 1.3 полностью эквивалентны. Точно также эквивалентны и 1 и 1.0, она одинаково их переведёт в число с плавающей точкой нужной точности, требуемой для той, либо иной секции. Ведь о том, какую точность использовать, в строке информации нет и об этом знает только потребитель этих значений в виде конечной программы, работающей с этими данными.

В принципе, я могу задать другой формат для вывода и принудительно выводить значения для каких-то секций в другом виде. Например, всегда выводить N знаков после запятой (6-7), независимо от того, значащие они, либо нет. Но практического смысла в этом не будет, парсер всё равно незначащие нули скипнет. Подобный вывод обычно используют только в эстетических целях, там, где надо оформить красивые и ровные таблицы. В остальных случаях, особенно при большом кол-ве выводимой информации, стремятся ограничивать вывод избыточной и не несущей практического смысла информации. Потому что это значительно увеличивает объёмы и время работы парсера, потом с этими данными работающего.

[yt2]

Задача распаковщика BIN-mesh -> TXT-mesh в первую очередь, в том чтобы распакованный текстовый меш максимально точно соответствовал оригинальному файлу. Даже в мелочах типа числа пробелов, количестве чисел после запятой и прочим мелочам.
Конвертеру вьюер не особо и нужен. Должна быть и консольная версия для пакетной обработки файлов.
В первую строку текстового меша записывайте информацию о том, какой утилитой был распакован файл, типа
// Generated by N79Tool32 v1.17
указывайте версию программы, разрядность программы и т.п
в секцию хуков начинайте со строки содержащей комментарий
[HookLoc] // each row is locator (matrix): axisX axisY axisZ translation.
В конце файла рудиментная строка
; eof
и всё. ваш текстовый меш будет максимально приближен к исходному оригинальному мешу.
Будет корректный исходник с ним уже можно проводить операции изменения дистанции лодов, переименовывать коллижены или материалы, добавлять или править положение хуков, изменять имена хуков и.т.п.

[NB79]

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

Без абсолютного знания исходных алгоритмов, начиная с момента конвертации бинарной модели из редактора, поной идентичности можно добиться только сидя и подгоняя какие-то части под то, что содержиться в каком-то единичном образце. А в следующем вполне может получиться так, что всё придётся опять подгонять. Я на это тратить время не хочу, это абсолютно бессмысленное занятие.

Повторю ещё раз. При конвертации не только информация о форматировании теряется, но и для некоторых типов данных теряется ТОЧНОСТЬ (для чисел с плавающей точкой). И с этим ничего сделать НЕВОЗМОЖНО, ибо в алгоритме трансформации ФИЗИЧЕСКИ ЗАЛОЖЕНА эта потеря точности. Операции деления/умножения чисел с плавающей точкой выполняются с конечной, не абсолютной, точностью. Причём в моделях эти числа уже с одинарной точностью и так (которые Single, четырёхбайтовое значение).

А вьювер нужен мне. Уж, простите.

[Sita.]

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

А вьювер нужен мне. Уж, простите.

))) ну никто и не настаивает на его отключении... просто Ут2 говорит что он для него не обязателен... а мне к примеру кажется что он мог бы быть полезен, вдруг сомневаешься какой в меше который выдёргиваешь

[NB79]

Пока отдельной темы нет напишу вопрос сюда.

Пишу экспорт/импорт в Wavefront obj. Читаю спецификацию и немогу понять некоторые моменты.

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

Вопрос: Есть ли у кого пример obj файла с анимированным мешем? Можно не из игры, мне надо посмотреть, как в таком случае действовать.

2) В меше обычно несколько лодов. В спецификации OBJ есть понятие lod. Но, на сколько я понял из спецификации, этот тег используется при визуализации в Blendere. Так-же, не понятно, у lod-а в obj отсутствует атрибут расстояния (если я правильно понял), только индекс от 1 до 100.

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

Будет очень здОрово, если вы сможете кинуть сюда пару образцов obj файлов записанных именно редактором (Blеnder-ом/Max-ом). Один - многофреймовый, второй - с несколькими лодами.

[yt2]

1)Анимированные меши пока малознакомы. Это например меш раскрывающегося парашюта. Помочь не могу.
2)Лоды при импорте сторонними программами/плагинами в максе выглядят как модели, просто им имена присваиваются соответственно номеру лода.
Типа Body_00 Body_01 Body_02 YBody_00 YBody_01 и т.п. Каждый лод имеет материалы назначенный данному лоду. Лоду дистанция видимости не передаётся, а выставляется при экспорте с макса плагином экспорта.

А отдельную тему никто создать не мешает. Лучше, если первый пост в ней напишите вы, а остальные посты можно и перекопировать даже без администраторов.

[NB79]

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

Это например меш раскрывающегося парашюта.

Ещё и парашютист и солдатики в директории 3do\humans\. Ещё есть меши с анимированными текстурами. С эти вообще глухо, фиг знает, как экспортировать.

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

2)Лоды при импорте сторонними программами/плагинами в максе выглядят как модели, просто им имена присваиваются соответственно номеру лода.
Типа Body_00 Body_01 Body_02 YBody_00 YBody_01 и т.п. Каждый лод имеет материалы назначенный данному лоду. Лоду дистанция видимости не передаётся, а выставляется при экспорте с макса плагином экспорта.

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

[yt2]

хуки и коллизии специально ни как не выделяются

Почему же?
Тени пишутся в секции шадоу. при импорте в макс им добавляется к имени базового лода префикс Y, а суффикс типа _00 определяет какому лоду относится тень
Хуки все их имена и координаты прописываются в отдельной секциях Hook. Обычно они являются объектами типа Dummy (это к Maraz экспортеру относится) или обычными мешами (это если официалам давать). Хук имеет ориентацию и координаты.
Коллизии тоже в отдельной секции. Имеют имя коллизии и описание точек. Это обычный меш, без маппинга и сглаживания, без просветов, типа однообъёмного. Для Мараз экспортера материал ему не нужен, для официалов сгодится материал Collision.

[NB79]

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

Почему же?
...
...

В спецификации Wavefront obj нет понятия "секция". Там команды. И для хуков и коллизий нет команд, которые их специально выделяют. В obj можно объявить объект, внутри него объявить группы. Группы имеют имена. И каким-то образом именно это имя и определяет, что это хук, или объект для фиксации коллизи. Я почему и просил образец obj файла сделанный не экспортёрами разнообразными, а редактором. Мне надо посмотреть, как именно редактор пишет эту информацию. Ибо формат obj файла позволяет не очень строго относится к записываемой информации. Он во многих случаях не строг к порядку наименования и следования различных блоков информации. А мне при чтении нужны чёткие ориентиры к чему относить те, либо иные данные. Ибо иловский формат мешей, в отличии от, строг к именам различных инфо-блоков. В нём и лоды, и фреймы, и хуки, тени, коллизии, всё именуется строго определённым образом. Для правильного экспорта/импорта мне нужно установить связь между именами в одном формате и именами в другом. То, что в Максе к имени что-то добавляется не помогает мне в установлении этой связи. Мне надо посмотреть имена из самого obj, как в файле именуются группы.

[Sita.]

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

[NB79]

Ребят, вы, кажется не понимаете.

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

Меня интересует как в obj даются имена хукам, теням и коллизиям! Только это. Именно в самом файле. Ибо формат иловского меша совершенно другой, чем obj. Блин, ну нет у меня 3д редакторов и ставить и и разбираться с ними, это потратить кучу времени. Неужели ни у кого нет obj файла с хуками, тенями и коллизиями для Ила? Я в это не верю.

[Sita.]

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

Ребят, вы, кажется не понимаете.

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

[carsmaster]

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

. Неужели ни у кого нет obj файла с хуками, тенями и коллизиями для Ила? Я в это не верю.

Сейчас попробую перегнать меш в меш конвертере в 3ds ,далее загружу его в МАКС, далее из макса в obj перегоню

Так пойдет ?

1. В архиве родной бинарный меш CF_D0(с коллизиями и хуками) от Ki-43-II(Multi1) есть

2. В меш конвертере перегнал родной меш в 3ds(правда меш конвертер косячит с координатами хуков, в одну кучу(точку) их все свалил

3. Загрузил 3ds в макс 2012, далее для наглядности и проверки маппинга, повесил нужную текстуру на материал Gloss1D0o (использует скин самолета) . Маппинг все нормально. Хуки вручную для наглядности раздвинул

4. Из макса перегнал в CF_D0.obj , создался автоматом файл материалов
CF_D0.mtl

5. Снова засунул полученный obj в макс 2102.
Вроде все нормально,в том числе и маппинг


Заметил особенность, после загрузки в макс-2012 полученного 3ds( из меш конвертера) хук назвался _Clip13 <B (в максе так выглядит)

При загрузки в макс созданного obj этот же хук зовется _Clip13__B

Для справки, при подготовки мешей в максе для экспорта в игру экспортером от МАРАЗА хуки именуются просто _Clip13

Тени именуются уCF_D0 -это тень для нулевого лода
Тоесть у теней для экспортера от МАРАЗ префикс y (игрек)


После меш конвертера в 3ds тень зовется
CF_D0 SH

В OBJ после макса тень зовется уже CF_D0_SH

[NB79]

Большое спасибо! Именно то, что нужно.

[NB79]

У меня тупик образовался.

При просмотре образца выяснилось, что имена объектов режутся, макс. длина имени 10 символов. На сколько я понял, Макс открывает obj тоже не на прямую, а при помощи плагина. Не понятно, в какой момент имя режется, в момент конвертации в 3DS MeshConverter-ом, или плагином в Максе при записи obj? Ни obj, ни Макс ограничений в 10 символов на имя не накладывают.

А имена важны для того, чтобы автоматически объекты приводить к нужному типу (лоды - к лодам, хуки - к хукам и т.д.). Потому что типы обектов поределяются именно по имени, другого способа нет, нет соответствующих атрибутов.

Решил не мучаться и читать/писать сразу в 3DS. Но и тут вылез косяк. С именами всё отлично, можно задавать имя длинее 10 символов и, соответственно, потом, при чтении 3DS, автоматически раскидывать объектны по соответствующим категориям. Однако, засада в том, что в 3DS не пишуться нормали, они вычисляются в момент открытия на основании групп сглаживания (smooth_group). И если при чтении я могу нормали рассчитать, то при записи (при экспорте из иловских мешей) я так и не понял, каким образом из имеющихся нормалей эти группы создать. Не нашел информации.

И того - тупик:

- При экспорте/импорте в obj, на каком-то этапе, режутся имена объектов, зато с нормалями нет проблем.

- При экспорте/импорте в 3DS всё отлично с именами, но при сохранении в 3DS теряется информации о сглаживании (пока я не нашел как с этим бороться).

У меня вопрос. Может ли Макс записать obj в котором имена объектов длиннее 10 символов? Если может, то я буду использовать для экспорта/импорта obj. Если нет, то придётся брать какой ни будь другой формат который не режет имена и позволяет сохранять/читать нормали (какой ни будь ase, например).