05.09.2015, 23:08 | #41 | |
Местный
Регистрация: 12.04.2009
Сообщений: 5,059
|
Чёткий квалифицированный комментарий
Цитата:
__________________
ищется идейный Программер ) |
|
05.09.2015, 23:09 | #42 |
Местный
Регистрация: 12.04.2009
Сообщений: 5,059
|
просьба к модераторам вынести всё касающееся в ветку NB79 Tool
__________________
ищется идейный Программер ) |
06.09.2015, 00:11 | #43 | |
Местный
Регистрация: 12.07.2015
Сообщений: 417
|
Цитата:
MeshConverter не правильно обрабатывает один из сохраняемых в бинарном меше тип данных. В бинарном меше несколько способов сохранения значений. В зависимости от величины значений в блоке данные могут сохраняться в виде одно, двух, трёх, или четырёх байтных значениях. Для целочисленных значений, кроме этого, дополнительно возможно сохранение значений в виде накапливающихся разниц двух соседних значений. Это сделано для уменьшения размера файлов. Так вот, один из способов сохранения, когда исходные четырёхбайтовые числа с плавающей точкой преобразуются в трёхбайтовые, все виденные мной утилиты обрабатывают неверно. За счёт этого разница и возникает. Я специально потратил на изучение этого момента изрядное кол-во времени. Как я уже говорил, в СПШ модели сохранялись в текстовом формате. Я брал одинаковые модели из СПШ и текущей версии и конвертируя их MeshConverter-ом и своей тулзой сравнивал результат. На трёхбайтовом типе у МС и других утилит как раз погрешность и возникает. Они забывают в одном месте прибавлять/вычитать единицу. А так, у меня выводятся значения с точностью до 6 (или 7-ми, не помню сейчас) знаков после запятой. Если значение, например, ровно 0.5, то незначащие нули просто не отображаются. |
|
06.09.2015, 00:20 | #44 |
Пытающийся полететь
|
|
06.09.2015, 01:47 | #45 |
Местный
Регистрация: 18.01.2012
Сообщений: 787
|
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 |
06.09.2015, 11:52 | #46 |
Местный
Регистрация: 12.07.2015
Сообщений: 417
|
Кол-во разделительных пробелов между значениями не принципиально. Парсер строк всё равно сплитит сроку по первому, а остальные отбрасывает. Т.е., они в тексте только место занимают.
Аналогично и с числами с плавающей точкой. Для печати значений я использую стандартную процедуру форматирования. Ей на вход передаётся строка формата и она самостоятельно, под эту строку формата, формирует результат. Для FP использую "%.6g". Т.е., выводится до шести знаков после запятой, не значащие нули отрезаются. Опять же, парсер разделяет значения по разделителю (у нас это пробел) и потом программа конвертирует получившуюся строку в требуемый для секции тип. Если секция должна содержать целые типы - конвертит в целые, если дробные - в дробные. При конвертации дробных, для процедуры, не имеют значения не значащие нули, для неё 1.30 и 1.3 полностью эквивалентны. Точно также эквивалентны и 1 и 1.0, она одинаково их переведёт в число с плавающей точкой нужной точности, требуемой для той, либо иной секции. Ведь о том, какую точность использовать, в строке информации нет и об этом знает только потребитель этих значений в виде конечной программы, работающей с этими данными. В принципе, я могу задать другой формат для вывода и принудительно выводить значения для каких-то секций в другом виде. Например, всегда выводить N знаков после запятой (6-7), независимо от того, значащие они, либо нет. Но практического смысла в этом не будет, парсер всё равно незначащие нули скипнет. Подобный вывод обычно используют только в эстетических целях, там, где надо оформить красивые и ровные таблицы. В остальных случаях, особенно при большом кол-ве выводимой информации, стремятся ограничивать вывод избыточной и не несущей практического смысла информации. Потому что это значительно увеличивает объёмы и время работы парсера, потом с этими данными работающего. |
06.09.2015, 12:51 | #47 |
Местный
Регистрация: 18.01.2012
Сообщений: 787
|
Задача распаковщика BIN-mesh -> TXT-mesh в первую очередь, в том чтобы распакованный текстовый меш максимально точно соответствовал оригинальному файлу. Даже в мелочах типа числа пробелов, количестве чисел после запятой и прочим мелочам.
Конвертеру вьюер не особо и нужен. Должна быть и консольная версия для пакетной обработки файлов. В первую строку текстового меша записывайте информацию о том, какой утилитой был распакован файл, типа // Generated by N79Tool32 v1.17 указывайте версию программы, разрядность программы и т.п в секцию хуков начинайте со строки содержащей комментарий [HookLoc] // each row is locator (matrix): axisX axisY axisZ translation. В конце файла рудиментная строка ; eof и всё. ваш текстовый меш будет максимально приближен к исходному оригинальному мешу. Будет корректный исходник с ним уже можно проводить операции изменения дистанции лодов, переименовывать коллижены или материалы, добавлять или править положение хуков, изменять имена хуков и.т.п. |
06.09.2015, 15:48 | #48 |
Местный
Регистрация: 12.07.2015
Сообщений: 417
|
Полной идентичности с оригинальным (исходным) файлом всё равно добиться не получится. По причине того, что самый первый, оригинальный исходный файл, по дороге к бинарному претерпевает несколько трансформаций. И в процессе этих трансформаций теряется как точность при конвертации некоторых типов, так и всякая информация о изначальном форматировании текста. Тут отлично подходит фраза "фарш невозможно провернуть назад". Ведь в процессе перекодирования фундаментально меняется тип сохраняемых данных.
Без абсолютного знания исходных алгоритмов, начиная с момента конвертации бинарной модели из редактора, поной идентичности можно добиться только сидя и подгоняя какие-то части под то, что содержиться в каком-то единичном образце. А в следующем вполне может получиться так, что всё придётся опять подгонять. Я на это тратить время не хочу, это абсолютно бессмысленное занятие. Повторю ещё раз. При конвертации не только информация о форматировании теряется, но и для некоторых типов данных теряется ТОЧНОСТЬ (для чисел с плавающей точкой). И с этим ничего сделать НЕВОЗМОЖНО, ибо в алгоритме трансформации ФИЗИЧЕСКИ ЗАЛОЖЕНА эта потеря точности. Операции деления/умножения чисел с плавающей точкой выполняются с конечной, не абсолютной, точностью. Причём в моделях эти числа уже с одинарной точностью и так (которые Single, четырёхбайтовое значение). А вьювер нужен мне. Уж, простите. Последний раз редактировалось NB79; 06.09.2015 в 15:51. |
06.09.2015, 22:10 | #49 |
Местный
Регистрация: 12.04.2009
Сообщений: 5,059
|
))) ну никто и не настаивает на его отключении... просто Ут2 говорит что он для него не обязателен... а мне к примеру кажется что он мог бы быть полезен, вдруг сомневаешься какой в меше который выдёргиваешь
__________________
ищется идейный Программер ) |
08.09.2015, 19:24 | #50 |
Местный
Регистрация: 12.07.2015
Сообщений: 417
|
Пока отдельной темы нет напишу вопрос сюда.
Пишу экспорт/импорт в Wavefront obj. Читаю спецификацию и немогу понять некоторые моменты. 1) В Иле есть некоторое кол-во анимированных мешей. Анимация организуется за счтёт того, что создаётся некоторое кол-во фреймов, которые потом последовательно выводятся. Каждый фрейм - модель, с вершинами, фейсам, тенями, коллизиями и т.д. (если надо). Не понятно из спецификации, каким образом это всё группируется в obj файле. Вопрос: Есть ли у кого пример obj файла с анимированным мешем? Можно не из игры, мне надо посмотреть, как в таком случае действовать. 2) В меше обычно несколько лодов. В спецификации OBJ есть понятие lod. Но, на сколько я понял из спецификации, этот тег используется при визуализации в Blendere. Так-же, не понятно, у lod-а в obj отсутствует атрибут расстояния (если я правильно понял), только индекс от 1 до 100. Вопрос: Как в редакторе после экспорта из игры отображаются лоды? Все в куче с другими объектами? Или каким-то образом в нём всё можно разделить по группам? Вопрос связан с тем, что мне непонятно, как записывать. Можно каждый лод писать в свой файл, но это явно неудобно как для редактирования, так и для последующей сборке при импорте в игру. Тем более, для моделей, которые состаят из нескольких мешей. Писать в один файл - непонятно, как лоду передать дистанцию видимости. Или это не важно? Будет очень здОрово, если вы сможете кинуть сюда пару образцов obj файлов записанных именно редактором (Blеnder-ом/Max-ом). Один - многофреймовый, второй - с несколькими лодами. |
08.09.2015, 20:43 | #51 |
Местный
Регистрация: 18.01.2012
Сообщений: 787
|
1)Анимированные меши пока малознакомы. Это например меш раскрывающегося парашюта. Помочь не могу.
2)Лоды при импорте сторонними программами/плагинами в максе выглядят как модели, просто им имена присваиваются соответственно номеру лода. Типа Body_00 Body_01 Body_02 YBody_00 YBody_01 и т.п. Каждый лод имеет материалы назначенный данному лоду. Лоду дистанция видимости не передаётся, а выставляется при экспорте с макса плагином экспорта. А отдельную тему никто создать не мешает. Лучше, если первый пост в ней напишите вы, а остальные посты можно и перекопировать даже без администраторов. Последний раз редактировалось yt2; 08.09.2015 в 20:55. |
08.09.2015, 21:00 | #52 | |
Местный
Регистрация: 12.07.2015
Сообщений: 417
|
Ещё и парашютист и солдатики в директории 3do\humans\. Ещё есть меши с анимированными текстурами. С эти вообще глухо, фиг знает, как экспортировать.
Цитата:
|
|
08.09.2015, 21:25 | #53 | |
Местный
Регистрация: 18.01.2012
Сообщений: 787
|
Цитата:
Тени пишутся в секции шадоу. при импорте в макс им добавляется к имени базового лода префикс Y, а суффикс типа _00 определяет какому лоду относится тень Хуки все их имена и координаты прописываются в отдельной секциях Hook. Обычно они являются объектами типа Dummy (это к Maraz экспортеру относится) или обычными мешами (это если официалам давать). Хук имеет ориентацию и координаты. Коллизии тоже в отдельной секции. Имеют имя коллизии и описание точек. Это обычный меш, без маппинга и сглаживания, без просветов, типа однообъёмного. Для Мараз экспортера материал ему не нужен, для официалов сгодится материал Collision. |
|
09.09.2015, 00:46 | #54 |
Местный
Регистрация: 12.07.2015
Сообщений: 417
|
В спецификации Wavefront obj нет понятия "секция". Там команды. И для хуков и коллизий нет команд, которые их специально выделяют. В obj можно объявить объект, внутри него объявить группы. Группы имеют имена. И каким-то образом именно это имя и определяет, что это хук, или объект для фиксации коллизи. Я почему и просил образец obj файла сделанный не экспортёрами разнообразными, а редактором. Мне надо посмотреть, как именно редактор пишет эту информацию. Ибо формат obj файла позволяет не очень строго относится к записываемой информации. Он во многих случаях не строг к порядку наименования и следования различных блоков информации. А мне при чтении нужны чёткие ориентиры к чему относить те, либо иные данные. Ибо иловский формат мешей, в отличии от, строг к именам различных инфо-блоков. В нём и лоды, и фреймы, и хуки, тени, коллизии, всё именуется строго определённым образом. Для правильного экспорта/импорта мне нужно установить связь между именами в одном формате и именами в другом. То, что в Максе к имени что-то добавляется не помогает мне в установлении этой связи. Мне надо посмотреть имена из самого obj, как в файле именуются группы.
|
09.09.2015, 00:53 | #55 |
Местный
Регистрация: 12.04.2009
Сообщений: 5,059
|
вставлю пять копеек ... если я правильно помню и понимаю хук это всего лишь объект для обозначения центра чего либо ... вращения ..камеры .. появления визуального объекта или точка подвески бомбы .. конкретно в хуке в основном важно имя и его координаты как я понимаю
__________________
ищется идейный Программер ) |
09.09.2015, 01:44 | #56 |
Местный
Регистрация: 12.07.2015
Сообщений: 417
|
Ребят, вы, кажется не понимаете.
Я отлично знаю что и для чего в Иловском меше находится. Я ж его читаю и могу писать и в тексте, и в бинарном, и нарисовать и крутить-вертеть. То, что хук, это место присоединения другого объекта (хоть меша, хоть эффекта, хоть чёрта в ступе) я в курсе. Меня интересует как в obj даются имена хукам, теням и коллизиям! Только это. Именно в самом файле. Ибо формат иловского меша совершенно другой, чем obj. Блин, ну нет у меня 3д редакторов и ставить и и разбираться с ними, это потратить кучу времени. Неужели ни у кого нет obj файла с хуками, тенями и коллизиями для Ила? Я в это не верю. |
09.09.2015, 01:46 | #57 |
Местный
Регистрация: 12.04.2009
Сообщений: 5,059
|
тут я на все сто согласен я правда реально мало сейчас понимаю из того что вы тут творите)) я ж сказал ..5 копеек не более))
__________________
ищется идейный Программер ) |
09.09.2015, 02:02 | #58 | |
Пытающийся полететь
|
Цитата:
Так пойдет ? 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 Последний раз редактировалось carsmaster; 09.09.2015 в 03:22. |
|
09.09.2015, 03:28 | #59 |
Местный
Регистрация: 12.07.2015
Сообщений: 417
|
Большое спасибо! Именно то, что нужно.
|
11.09.2015, 16:37 | #60 |
Местный
Регистрация: 12.07.2015
Сообщений: 417
|
У меня тупик образовался.
При просмотре образца выяснилось, что имена объектов режутся, макс. длина имени 10 символов. На сколько я понял, Макс открывает obj тоже не на прямую, а при помощи плагина. Не понятно, в какой момент имя режется, в момент конвертации в 3DS MeshConverter-ом, или плагином в Максе при записи obj? Ни obj, ни Макс ограничений в 10 символов на имя не накладывают. А имена важны для того, чтобы автоматически объекты приводить к нужному типу (лоды - к лодам, хуки - к хукам и т.д.). Потому что типы обектов поределяются именно по имени, другого способа нет, нет соответствующих атрибутов. Решил не мучаться и читать/писать сразу в 3DS. Но и тут вылез косяк. С именами всё отлично, можно задавать имя длинее 10 символов и, соответственно, потом, при чтении 3DS, автоматически раскидывать объектны по соответствующим категориям. Однако, засада в том, что в 3DS не пишуться нормали, они вычисляются в момент открытия на основании групп сглаживания (smooth_group). И если при чтении я могу нормали рассчитать, то при записи (при экспорте из иловских мешей) я так и не понял, каким образом из имеющихся нормалей эти группы создать. Не нашел информации. И того - тупик: - При экспорте/импорте в obj, на каком-то этапе, режутся имена объектов, зато с нормалями нет проблем. - При экспорте/импорте в 3DS всё отлично с именами, но при сохранении в 3DS теряется информации о сглаживании (пока я не нашел как с этим бороться). У меня вопрос. Может ли Макс записать obj в котором имена объектов длиннее 10 символов? Если может, то я буду использовать для экспорта/импорта obj. Если нет, то придётся брать какой ни будь другой формат который не режет имена и позволяет сохранять/читать нормали (какой ни будь ase, например). |
Здесь присутствуют: 1 (пользователей: 0 , гостей: 1) | |
Опции темы | Поиск в этой теме |
Опции просмотра | |
|
|