Давайте я ещё раз о группах сглаживания, применительно к игре, расскажу.

Меши игры не содержат в себе групп сглаживания. Что такое "группы сглаживания"? Условно, это некий атрибут, указывающий на то, каким образом должна рассчитываться нормаль к вершине. Мы объединяем полигоны с одинаковыми атрибутами и при загрузке модели, ориентируясь на эти атрибуты, рассчитываем нормали для всех верши. Однако, то, что приемлемо для разработки моделей совершенно не годится для игры. Расчёт нормалей операция дорогая, занимающая приличное время. Если это десяток полигонов, то это не беда, но если у нас куча мешей и тысячи полигонов, то это уже становится проблемой. Негоже заставлять игрока сидеть перед монитором и любоваться на неторопливый прогресс загрузки.

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

Вот по этому и взят для конвертации obj, в отличии от 3ds он может писать в себя нормали. Группы сглаживания тоже, но в иловском меше их нет. По этому я и не пишу их в obj.

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

Так-что, групп сглаживания в ближайшее время точно не будет. А там - посмотрим будут ли на них силы и ваще. :)

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

MARAZ экспортер пишет текстовый меш например с такими строками

[CoCommon]
[NBlocks 1] тут квадрат скобки

[CoCommon_b0]
Nparts 1 тут маленька буква "p"

[CoCommon_b0p0]
Type Mesh
[NFrames 1] тут квадрат скобки
Name Live


Меш конвертер пишет это же самое вот так:

[CoCommon]
NBlocks 1

[CoCommon_b0]
NParts 1

[CoCommon_b0p0]
Type Mesh
NFrames 1
Name Live

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

MeshError: FileName = "3333333333333333333333\Новая папка\MY_FIELD_PACK\Z-ga-konus-bwS\z-ga-konus-bwS\3DO\Buildings\Russia\DummyplaneG\live.msh"; ReadTextCoCommonInfo:ElementCount <> 1 (0). SectionName = "CoCommon"

Меш конвертеру по барабану на эти тонкости, он читает без проблем и меши из MARAZ экспортера с квадратными скобками и маленькой буквой в названии. Так как игра спокойно работает с мешами от MARAZ, то следовательно и игре пофиг на эти вещи

Если можно подлечите пожалуйста вашу прогу от привередливости к квадратным скобкам и регистру букв.

В архиве меши с текстурами

live.msh меш на котррый ругается ваша прога(меш конвертер все нормально ему)

33live.msh тот же меш ,но правленный, вручную убрал скобки и маленькую букву"p" заменил на большую "P". Ваша прога увидела и открыла меш.





С уважение Сергей.

Чувствительность к регистру можно исправить. А вот со скобками всё сложнее и совсем не так, как кажется. :)

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

Для лучшего понимания. В игре есть универсальный способ сохранения данных, файл секций. Он может существовать в двух видах, текстовом и бинарном (сигнатура бинарного "BS", от "Binary Sect", как я понимаю :) ). В этих файлах может находится любая произвольная информация. О том, что и как прочитать знают только модули, которые вычитывают соответствующую информацию из этих файлов. Модуль оперирует только с теми секциями и данными имена которых для него определены. Например, загрузчик карт ничего не знает о секциях для загрузчика мешей, и на оборот. Вы запросто можете в файл меша добавить секции с произвольными именами и заполнить эти секции любой фигнёй, загрузчик мешей просто проигнорирует эту информацию, потому что
ничего о ней не знает и не предполагает её наличие в файле. И никаких ошибок при этом не возникнет.

Чтение данных происходит следующим образом:
1) Загрузчик просит у парсера вернуть ему ссылку на секцию с определённым именем
2) Если секции с таким именем нет, то загрузчик по заданному разработчиками алгоритму может ругнуться (если эти данные обязательно должны присутствовать), либо заполнить структуры данными по умолчанию (не сообщая об ошибках).
3) Если ссылка на секцию получена, то далее загрузчик просит у парсера различные данные из этой секции и аналогично, если данные в секции присутствуют, то читает их. Если нет, то по заложенным разрабами алгоритмам для этого загрузчика: либо ругается, либо заполняет по умолчанию.

Итак: Если первый символ в строке открывающая скобка ("[") и в этой же строке присутствует закрывающая ("]"), то парсер однозначно трактует это как начало новой секции и всё, что между этими скобками находится считается именем секции.

По этому:

1) Чувствительность к регистру я могу убрать, это я не ожидал просто, что имена регистронезависимые. В игре-то, имена заданы с регистром. Кстати, надо бы посмотреть, действительно ли регистронезависимые, может просто вместо значения из файла берётся значение по умолчанию, если имя отлично от того, что присутствует в игре.

2) С открывающей скобкой никаких изменений делать не буду, ибо это приведёт к появлению неоднозначных последствий.

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

Кстати, прошу прощение за пропадание. Не пропал, тут. :) Просто сейчас адовое кол-во работы и практически нет свободного времени на всё остальное, только на работу и сон.

Загрузка всей модели сделана уже больше недели назад, нет времени её экспорт прикрутить. Постараюсь к выходным приделать экспорт хотя-бы в текстовые меши.

Спасибо за пояснения толковые.
Тогда поступлю(да и поступил уже) проще, В Хексе поправлю экспортер от MARAZ , просто удалю(чтоб не писал) скобки в тех секциях что я указвал на своих примерах меша экспортера от MARAZ.

В принципе все работает уже(экспортер), правда при загрузке Макса ругается на ошибки загрузки плагина, но макс запускается и экспортер потом работает.
Скорее всего в файле экспортера от Maraz какая нибудь проверка описана на CRC файла напрмер. Пр загрузке проверил, увидел (после моих изменений) не соответствие, РУГНУЛСЯ, но решил, что и так сойдет и работе экспортера это НЕ МЕШАЕТ.:D

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

Основная масса людей(кто остался тут) сами ковыряются в свободное время, на энтузиазме.

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

Так что в любом случае спасибо за реальные результаты вашей работы.

очень знакомо! :pilot:

Мне кажется кроме сохранения модели в виде отдельных мешей, стомит добавить в функционал запись ВСЕЙ! модели в сборе в виде одного файла, пусть и состоит она из отдельных мешей.

Ведь самое важно это собрать корректно по координатам всю модель в максе .

В hier.him как раз и описан принцип сборки всей модели ,с учетом поворотов и смещений каждого меша.
Было бы очень неплохо иметь всю целую модель тоже.

Так я ж говорю, модель давно грузится вся. :) Надо только её экспорт прикрутить.

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

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

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

И ещё из того, что сделано помимо загрузки всей модели. Первое, это по подгрузке текстур. Теперь, если грузится модель самолёта и путь к модели содержит "3do\plane\", т.е. так, как в игре, то автоматом подтягиваются текстуры из папки "summer" для этого самолёта. Тля нулевого лода, если там есть tgb, берётся она. TGA или IMF - значения не имеет, я IMF нормально читаю. Второе, это разделение модели на степени повреждения, если в ней это предусмотрено. И третье, более качественное текстурирование за счёт того, что читаю и применяю почти все параметры из mat файлов. Чего пока не сделано, это настройка отражающих способностей материалов на основе данных из mat файла. Опять же, из-за нехватки времени. Модельки сейчас очень похоже на игру выглядят. :)

:good::beer::konoplya:

круто однако :good:

В аттаче версии с загрузкой полных моделей. Можно загружать him, sim, так-же и отдельные меши (msh). Меши могут быть как бинарные, так и текстовые.

Вжные моменты:

1) Текстуры могут быть как TGA, так и IMF
2) Текстуры грузятся из текущей директории
3) Если при загрузке путь содержит "\3do\plane\", то при загрузке эта директория сканируется и собирается список всех доступных для модели скинов (которые лежат в директориях summer, winter и т.д.). Можно создавать свои директории с любым именем и кидать туда свои скины. Главное, чтобы они были:

a) TGA/IMF
b) содержали три версии для лодов (skin1o, skin1p, skin1q)

Если кроме этого для нулевого лода в директории есть и tgb, то для него будет использован он. Скины можно переключать. Также можно переключать различные уровни повреждения (ели оно доступно для модели).

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

Ещё один момент, который является следствием того, что все правила сборки сразу недоступны, это z-fighting (дрожание текстур с некоторых частях модели). Кратко, что это такое и почему возникает:

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

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

Ну и при отображении возможны некоторые артефакты связанные с блендингом. Во-первых - при отрисовке я не сортирую полигоны, а во-вторых - мне непонятен физ. смысл одного параметра в материале (tfBlendAdd). Во общем, где-то что-то может просвечивать когда не надо, или на оборот, не просвечивать. :)

Ещё добавил пару опций. Во-первых, отрисовку нормалей. А во-вторых - возможность закраски полигонов цветными треугольниками. Это, как раз, для выявления в модели мест, где возможно возникнавение z-fighting'а и нахождения кривоватых мешей. Такие действительно есть, например, дублирующиеся полигоны, когда они в абсолютно одинаковой позиции. Если оключить текстурирование, включить цветные полигоны и отображение только каркаса, то при вращении модели хорошо видно мерцающие рёбра там, гду высока вероятность возникнавения z-fighting'а.

Ещё сделал сохранение положения и размера окра, а также опцый отображения.

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

Ещё включил анизатропную фильтрацию текстур и сглаживание (если карта расширение поддерживает).

Вроде всё, но может чего забыл. :) Проверяйте и раппортуйте здесь битьём в бубен. :)

Ух ты.. Классно.

Пребольшое спасибочки!

Загрузил и перегнал пару моделей. Все наглядно смотрится.

Уже получился прекрасный !! Нужный инструмент!!

:good::beer:

Ни фига себе!! Ничего не понял(своими железными мозгами) из начертанного в посте от NB79,
но!!! Чутьё подсказывает что сделано нечто(впрочем, как я ранее и полагал) грандиозное и значимое!
Спасибо огромное за работу!:beer:

Спасибо большое! :thx:

В аттаче новая версия.

1) Переделал текстурирование. Оно всё равно отличается от игры, но более на неё похоже.
2) Убрал возможность крутить модель по оси Y. Ввиду отсутствия необходимости это делать, только мешало.
3) Добавил возможность при показе хуков выбирать конкретные.
4) Добавил возможность показа оверлеев.
5) Добавил возможность залазить в кокпиты. :) В общем, если у модели есть камеры, то можно по ним переключаться. При переключении камер взгляд в центр не ставлю. Может потом сделаю.

Вроде всё.

Теперь по поводу записи всей модели в один obj файл.

Подумав на эту тему пришел к выводу, что делать это нельзя. Причина этого кроется в том, как модель из отдельных мешей собирается. Проблема в том, что меши соединяются между собой через матрицы трансформации. И, соответственно, если собирать модель в один файл, то придётся пересчитывать все вершины в единую систему координат. Это не сложно, но при этой операции теряется исходная ориентация мешей, что приводит к том, что меши, которые могут двигаться в игре (например пропеллер, или педали, или РУС и т.д.) могут терять ось относительно которой они должны вращаться. Ситуация в чем-то на хуки похожа, но в хуках я крашу грани, что даёт возможность оси нужным образом в Максе развернуть. С мешами так не получится. В общем, сделать запись в один obj не проблема, но бессмысленно. По этому делать это не буду. Надо всё-же пробовать какой ни будь другой формат для экспорта найти, который от этих проблем избавлен и позволяет сохранять в себе нормали и матрицы трансформации. Может попробую восстановить по нормалям, полигонам и вершинам группы сглаживания и писать всё в 3ds. Но не знаю, как уже говорил, что из этого может получится.

Пока так.

Стучите о багах и косяках сюда.

Спасибо за обновление.:beer::good:

Бесспорно, все Ваши аргументы с потерей пивотов двигающихся мешей весьма весомы.

Но мне кажется даже сейчас очень было бы неплохо иметь всю модель в OBJ собранную и текстурированную.

Нужно это на тот случай ,если опытный человек захочет переработать всю модель или МНОГИЕ ее детали.

Для опытного человека расставить пивоты у движущихся мешей заново не очень большая проблемы. Тем более не сотни мешей двигающихся.
Вы можете сказать, что если считать и лоды у движущихся мешей, то наберется куча работы. Конечно Вы будете правы. Но ...

Если честно сказать, то лоетает куча самолетов в 1 лод всего и игры спокойно переваривает все.

Больше того скажу, у меня летает ПО-2(У-2) на 250 000 поликов высокодетализированный(так для экспериментов экспортировал частично в игру).

К чему я это ?

А вот к чему: Считаю лоды сейчас на нынешнем железе и в нашей игре для новых самолетов можно и не делать , от слова СОВСЕМ.:D

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

Мое имхо: OBJ весь объект нужен !!

Ну, тогда наверное сделаю возможность экспортить раздельными и одним файлом, на выбор. Тока времени свободного маловато. :(

Несколько предложений по программе - вдруг реализуемо :)

1. добавить возможность двигать движок "Дистанция" не только мышкой но и с кнопок на одно деление. Мышкой получатся довольно резко, а иногда надо плавно приблизить-отдалить чтобы лучше рассмотреть.
2. после открытия через hier him всей модели сделать возможность отключать произвольные меши.

А вообще программа очень полезная и удобная! Спасибо!

Кнопками можно двигать. :)

Выбираем ползунок (либо табом, либо ткнув в него мышкой) и стрелками можно сдвигать на нужную позицию. PgUp/PgDown аналогично, только шаг сдвига больший. Home/End сдвигают сразу в начало/конец диапазона. :)

Это и для дистанции, и для поворотов модели.

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

Пока идея для этого такая. Дерево со структурой модели. Если встали на корневую ноду, то рисуем всю модель. Если пошли в дереве по нодам, то модель в виде лёгкой сетки, в выбранный меш рисуем нормально. Либо вместо сетки блендить. Но пока не решил до конца как удобнее будет и это не в первой очереди в планах.

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

Доброго времени суток! :) Попробовал только что вашу утилитку... в целом она очень хорошая и информативная, но вот что касается экспорта в .obj есть один "недочет". Импортил я, например, меш в формате 3ds, созданный мешконвертером 1.18, в макс. И все, что мне осталось сделать для его правильного обратного экспорта в иловский меш - это восстановить хиерархию (привязки лодов, коллизий и объектов теней к нулевому или другим лодам) и поменять их названия для корректного экспорта. Ну и сглаживание восстановить.
А ваш экспортер воспринимает тень как один из материалов лода (хотя "по-иловски" это отдельный объект), соответственно, это нужно бы исправить...
Конечно, в максе совсем несложно разделить объект по материалам, но тем не менее... На заметку вам)

В любом случае, за утилиту - спасибо)

Не понятно что имеется ввиду под "один из материалов лода". Тени пишу как объект. Мне бы по подробнее, с картинками, если можно. Как для дурака. :)

PS: Завис я с освещением. Блин, не понимаю, как в Иле значения из MAT файлов, связанные с освещением, используются и интерпретируются. В материале явно какие-то коэффициенты, из которых по определённому алгоритму высчитывается хар-ки материала, отражающая способность, амбиентное и диффузное освещение, самосветимость материала. Значения могут быть от 0.0 до 2.0, для SpecularPow - от 0.0 до 128.0 (и с ним, как раз всё понятно). Голову сломал. Может кто знает формулу расчёта света для иловского материала? Был бы благодарен. А то сейчас, то что сделано у меня, сделано от балды и не правильно показывает.

Чуть позже все покажу :)

Внесу я, пожалуй, свои пять копеек. Мне кажется, что не стОит принимать сейчас эту "фичу" как приоритетно важную, а стОило бы прикрутить возможность экспорта в формат .3ds :ups:

Ну, как я уже говорил, в этой тулзе я удовлетворяю своё любопытство в области 3Д. :)

В 3дс, скорее всего не будет. Вроде ase для экспорта подходит, буду в него пробовать. В нём, вроде, есть всё необходимое.

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

ох ты ж ё .... какие люди))))

Звучит как тост!:D

После долгих рассмотрений разных форматов сделал выбор в пользу ase. Это вроде Максовский формат, аналог 3ds, но в отличии от него позволяет писать в себя нормали. Минус у него, что он текстовый и результы будут здорОвые, плюс он изрядно навороченный и мне при написании и отладке негде его открывать для проверки. :) А из плюсов его - в нём и локальные матрицы, и Dummy объекты (которые хуки), и нормали, и дерево зависимостей. В общем, сложный формат и быстро его не напишу, очень сейчас много основной работы.

Здравствуйте))

Пусть будет ase, Мастеру видней что лучше. А что текстовый и размеры- это дело пятнадцатое. У нас ведь посути тоже меши все текстовые, так что переживём.
Ждём-с с нетерпением.

Жень, вопрос из ряду офтопа) ты чего то творить собираешься?)))

Как выдаётся время- рисую одну хероту потихоньку(естественно не подходящую к ДТшным стандартам). ;)
Пока дело к финалу не подойдёт- анонсировать не буду.:mad:

2 А Поцчему Ви спгашиваете?

.
Да просто мало нас, тех кто работает... Надо как то кооперироваться) тем более с твоим опытом)

Дык у меня если уж и раньше всё было кривое да неправильное, несоответствующее Высоким Стандартам ДТ, то сейчас, спустя несколько лет и подавно)))
PS: Честно говоря на свои нынешние сетки моделей самому смотреть страшно.

Ну так и мы не сильно то мастера) а когда несколько голов работают, оно как то ловчее выходит) опять же опыт работы с ява програмингом дюже ценен)

Почти четыре года, на самом деле :ups:

Проблема в том,что если Макс я хоть както помню(время от времени рисуя всякую хрень), то Яву забыл походу окончательно.

Как быстро летит время...

PS: господа Модераторы, может не будим флудить в этой теме, а переедем в другое место?

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

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

Я уже говорил, и не раз :) , что хочу сделать прямой двусторонний конверт в родные форматы, bin -> Max и Max -> bin, а всё остальное, это просто промежуточные этапы исключительно из-за навороченности 3Д темы самой по себе. :)

а починить разверку при импорте возможно? Сейчас ее нужно в максе отзеркаливать по вертикали.:rolleyes: