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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Сейчас попробую перегнать меш в меш конвертере в 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

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

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

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

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

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

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

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

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

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

Можно подсмотреть как в мешконвертере решается проблема 10 значных имён, вроде там есть галка чтобы обрезать имена. В максе файл нужен со сглаживанием и маппингом. И не важно в каком будет формате obj, 3ds, md5mesh, главное чтобы в максе было хорошо.
А так задача перегнать текстовый меш в макс довольно сложна. Она ещё зависит и от того, на какой экспортер ориентироваться, потому что у разных экспортеров разные требования.
Ещё напоминание про консольную тулзу, иногда не требуется загонять файл в макс, а нужно просто перегнать меши в текстовый формат максимально приближенный к оригиналным мешам. Например это потребовалось делать для вставки в крайний патч новых жуж, а их там много было.
Ещё вариант обратный, иногда надо текстовый меш зашифровать в бинарный формат, чтобы его можно было импортнуть в макс плагином.

Так мне, как раз, и надо избавится от обрезания имён. И я не могу понять причину того, что имена в присланном примере обрезаны.

Как я уже говорил, и в obj, и в 3ds нет ограничений на длину имени (вернее есть, но там может быть очень длиное имя, на порядок линее 10 символов). Не понятно в какой момент имя режется. Вот в чём вопрос.

В моем образце 3ds я ставил галку в меш конвертере " обрезать до 10 символов" , ибо если я не ставил галку(обрезать), то меш конвертер напрочь отказывался сохранять корректно в 3DS(макс ругался на файл).

Сохранял в меш конвертере в 3ds потому ,что тогда маппинг
сохраняется !!!

Соответственно при загрузке в макс полученного 3ds и далее по цепочке и пошло "обрезание до 10 имен по знакам".


При сохранении меш конвертером в obj меш конвертер напрочь ломает маппинг и файл материалов . mtl НЕ СОЗДАЕТСЯ.

Попробуйте писать в OBJ с полными именами(как в бинарнике), главное маппинг и сглаживание попробовать сохранить при этом

Понятно теперь.

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

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

- Есть ли возможность при экспорте из Макса явно указать, чтобы он не объединял треугольники в полигоны? Просто мне лучше заранее это знать, чтобы при чтении obj, при встрече полигона отличного от треугольного, пилить их на треугольники. А это дополнительная возьня и ненулевая вероятность искажений модели/маппинга. Хотелось бы чтобы на всех этапах конвертирования вносилось минимальное кол-во изменений в оригинальную модель.

При экспорте в OBJ в максе(2012) выскакивает окно.

в нем есть окошечко FACES

в нем можно выбирать TRIANGLES или QUADS или POLYGONS

Как вам надо сделать сохранение(экспорт из макса) ????

В том образце OBJ моем я оставлял по умолчанию QUADS

А как надо ?

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

Вот скрин окна перед самым экспортом из макса в OBJ

Для Ила нужны TRIANGLES!

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

Спасибо за информацию.

Вот с настройками экспорта в OBJ в виде TRIANGLES

Спасибо.

В этом образце, как и надо, только треугольники.

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

Да бы не офтопить в теме вероятных перспектив, думаю пора завести отдельную темку под разработку Тула от Товарища NB79


появится кто то из модераторов, попросим перенести сюда всё касающееся ...

что бы не терять нити разговора)

Не успел всё доделать, очень много работы и очень мало свободного времени.

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

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

По именам. L0 - нулевой лод, L1 - следующий, и так далее. SH в конце имени для теней. Посмотрите также, нормально ли видно имена в Максе, не режутся ли?

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

Посмотрю ваши примеры.

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

Тоесть просто кубики, все равно ИЛ-2 оперирует центрами кубиков и ориентацией пивотов( осей) в центре этих кубиков

Ого, какие кубы здоровые. А надо ли таке огромные?

Да в принуипе и наверное не надо такие большие.

Я делал модель и она успешно летала уменьшив в максе кубики раза в 4...5 ,только что видны были.

С экспортом из макса в ИЛ-2 экспортером от МАРАЗ тоже при этом проблем не было

Этот большой размер лезет из меш конвертера. Они в нем большие показываются.

в архиве

1. текстовик ошибки при попытке открыть меш конвертером ваш OBJ

2. Два скрина при попытке открыть макс 2012 ваш OBJ. Макс начинает открывать, что-то видит и потом падает на сообщение об ошибке.

3. Третий скрин(странно) ваш obj нормально открылся в конвертере для MSFX

Естественно маппинг не могу глянуть, так как в макс не могу загрузить

Так, я кажется понял, в чём дело.

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

Цытата из спецификации:

----------------------------------------------------

f v1/vt1/vn1 v2/vt2/vn2 v3/vt3/vn3 . . .

Polygonal geometry statement.

Specifies a face element and its vertex reference number. You can
optionally include the texture vertex and vertex normal reference
numbers.

The reference numbers for the vertices, texture vertices, and
vertex normals must be separated by slashes (/). There is no space
between the number and the slash.

v is the reference number for a vertex in the face element. A
minimum of three vertices are required.

vt is an optional argument.

vt is the reference number for a texture vertex in the face
element. It always follows the first slash.

vn is an optional argument.

vn is the reference number for a vertex normal in the face element.
It must always follow the second slash.

----------------------------------------------------

А плагин (как и MeshConverter похоже) требует, чтобы нормали были обязательно определены.

А у нас, в Иловском меше, у теней (а ткже и у коллизий) как раз нормалей и нет. Фейс в obj описывается так:

f v1/vt1/vn1 v2/vt2/vn2 v3/vt3/vn3

Если у нас есть и вершины, и тех. координаты, и нормали, то мы имеем заполненными все три группы. Т.е., например так:

f 3129/2979/2979 3106/2956/2956 3134/2984/2984

Если нет текстурных координат, то эта же строчка будет выглядеть так:

f 3129//2979 3106//2956 3134//2984

Если нет нормалей и тек. координат, то эта же строчка будет выглядеть так:

f 3129// 3106// 3134//

Я написал эту часть экспорта в полном соответствии с спецификацией obj. По этому конвертер для MSFX файл и открывает. :) У меня тоже есть какой-то вьювер, который этот файл тоже нормально открывает. Придётся для Максовского плагина добавлять пустые нормали если их нет у объекта. Это будет раздувать файл.

Кстати, попробовал открыть MeshConverter-ом ваш файл, который с треугольниками для фейсов. MeshConverter падает с такой-же ошибкой. Тот вьювер, что есть у меня, ваш файл тоже отлично открывает. В MeshConverter-е, похоже, работа с OBJ очень криво прописана.

PS: Вот спецификация для obj, так, на всякий случай :) : http://www.martinreddy.net/gfx/3d/OBJ.spec

Ну вот такая у нас сложная работа-задача = отгадать, понять полет мыслей создателя ИЛ-2:lol:

ох ёлки... как всё серьёзно то тут... круто!!! WTG!))

Так тут, как раз, всё просто. :)

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

Спасибо огромное за разработку, NB79 :thx:
Пока утилиту не "пробовал", но подчеркну, что очень важно будет сохранение групп сглаживаний при экспорте .msh => .3ds, чтобы потом не мучится с ними с максе (очень затягивает разработку модификаций 3D).
Удачи в совершенствовании и релизах утилиты :beer: