Тёмная тема
Комментарий к Статье Формат 3DS: Первый шаг.
Где достать ifstream.h из примера Формат 3DS: Первый шаг.?
включать надо fstream.h (C-compatible) или просто fstream типа так:
#include <fstream.h> ifstream ifs; // или #include <fstream> std::ifstream ifs;
не понимаю
как объявить в модуле переменную string
тяжелый случай...
может
#include <string> using std::string
Если нет, то может стоит задавать вопросы более точно?
а кому вообще нужен этот формат и зачем? по-моему намного проще и удобнее придумать свой формат и экспортер для него, чем разбираться с 3ds
CyberZX
3ds поддерживается любой уважающий себя редактор моделей. Формат прост как пять копеек, есть стандартные либы для чтения/записи. Для начала - самое то.
У меня при попытке считать файл , содержащий объект , отличный от примитива (сфера,геосфера - созданного мной же в 3ds 5 ) получаеться затык на строчке :
chunk_pos=FindChunk(ifs,TRI_MAPPINGCOORS);
т.е chunk_pos == 0 , чего это означает - что у объекта нет текстурных координат ?
slSolo
Пользуйся готовыми библами и не будет затыков.
Посмотри, допустим, на 3dsftk.
статья хорошая максимум уважения его автору за неё...
единственное замечание возникает по поводу организации главной функции... для дальнейшего улучшения можно было организовать чтение чанков как while( не конец файла и файл открыт) а внутри него боооольшооой switch с именами чанков...(имхо это удобнее для дальнейшего расширения загрузчика).
у меня возник один вопрос....как лучше организовать чтение файла в плане наличия в нём множества объектов (одна модель может содержать много отдельных объектов)...как лучше сделать для дальнейшего развития загрузчика: одну большую модель с одним вертекс и индекс буффером или много маленьких каждая со своим? или какую нить комбинацию этих реализаций?
ЗЫ был бы очень признателен если автор напишет про реализацию анимации (самые основы хотя бы).
Может я чего-то не понимаю, но формат .3DS, описанный в статье очень сильно отличается от того, что в реале экспортит мой MAX (4-я версия).Совпадает только то, что в .3DS файле первые 2 байта = 4D4D и после 4 байта=размер файла, а после
все идёт навыворот, так идентификатор 3D3D присутствует, но он стоит как 16-17 байт.
Я экспортировал обычный куб и не нашел в файле идентификатора TRI_VERTEXLIST (0x4110), а также других.
Andree
Все Макс нормально экспортит. Такие бока возникают, когда прочитываешь блоки или скипишь их. Нужно учесть, что поле размера данных блока содержит размер блока с его заголовком. Поэтому, если этого не учесть и после заголовка считывать еще лишние 6 байт, то все наперекосяк и пойдет. Считывай данные блока размером chunk.size - 6.
Andree
Все очень легко объяснить. В статье, почемуто был пропущен один блок!!! А именно блок версии файла, который следует сразу за главным. Занимает он ровно 10 байт и поэтому 3d3d находится аж 17-18 байтом.
Прошу автора статьи учесть эти замечения.
Ах да!!! Совсем забыл сказать. ID этого блока 0x0002.
Слабоватая статья для данного портала. Также при внимательном прочтении и разборе замечено ряд багов. Наверно, самый главный это то, что данный код не будет работать (ничего грузить). Объяснение этому простое: тело T3DMesh::FindChunk написано так, что все родительские блоки будут не найдены, т.к. будут всего навсего пропущены.
Теперь о правильной обработке 3ds файлов. Необходимо вызвать рекурсивную функцию разбора, которая была применена к текущему блоку. Если немного непонятна идея, то можно поглядеть здесь http://www.enlight.ru/faq3d/examples/load3ds.c это опять же не самое качественное решение задачи, но вполне приемлемый вариант. Достаточно разобраться с форматом и вы увидите как можно его оптимизировать, что я и сделал для себя. А вообще, вот здесь лежит более удачное описание блоков: http://www.enlight.ru/faq3d/articles/75.htm
Больше всего же меня в статье поразило самомнение ее автора...Ну на троечку я думаю это дело тянет.
Спасибо за внимание. Если у кого-то есть интересная информация по формату 3ds, то добро пожаловать ко мне в аську.
Кто хорошо разбирается с форматом, помогите пожалуйста!
Правильно ли я понял, что вложенный в 0x3D3D блок 0x4000 ровно один, а в него вложено 1 или более блоков TRIMESH, каждый из которых - какая-то отдельная часть составного объекта?
CHUNK_FACEMAT(4130) вложен в CHUNK_FACELIST(4120) или в CHUNK_TRIMESH(4100)?
Несколько вопросов, касающихся работы с материалами граней.
В блоке 0x3D3D есть блок AFFF (материал), в который вложены A000 (название материала), А200 (текстура материала) и А300 (имя файла текстуры). Как вложены и вложены ли друг в друга А000, А200, А300, и как организовано перечисление материалов: НЕСКОЛЬКО AFFF, в которых по одному А000, А200, А300 или ОДИН AFFF, в котором по нескольку A000, A200, A300?
И такой вопрос: в AFFF и в его "детей" могут быть вложены еще и другие блоки?
Правильно ли я понял, что в общем случае может быть, скажем, N блоков TRIMESH, в каждом из которых для его нескольких граней используется M материалов FACEMAT, которые могут повотряться. И таким образом, число материалов, перечисленных в AFFF - от 0 до M*N?
Спасибо!
Тема в архиве.