Пишу импортёр *.object для блендер 3д. У меня не получается нормальные текстурные координаты получить. ЮВи вершины расположены нормально, но соединены не в том порядке в котором должны быть. Подскажите, что за данные находятся в блоках 0x7777-0x910-0x1008 и 0x7777-0x910-0x1012. Координаты вершин находятся в 0x1012, но их сразу импортировать нельзя. Нужны какие то действия, чтобы отсортировать в нужном порядке эти координаты. Но что именно, я не знаю. Помогите разобраться.

http://stalkerin.gameru.net/wiki/index.php...0%BE%D0%B2_SDK)
http://stalkerin.gameru.net/wiki/index.php....BE.D1.82_excid

https://yadi.sk/d/Mp6jVkV25LrXI - скрипты импорта\экспорта object для 3Ds Max 2010, можешь в исходниках подглядеть.

PS: Никто тут плагины экспорта\импорта под SketchUP 2014 (Язык Ruby) случаем писать не умеет? Я б деловое предложение предложил бы.

А здесь на сайте есть, кто в блендере моделит?

Очень редкий для ST редактор, может единицы, а так на врятли. Переходи на 3Ds Max или Maya.

Я скачал исходники конвертера бардака. В файле todo.txt нашёл: "? импорт/экспорт .object/.skl [blender]"
Т.е. Бардак планировал писать плагины для блендера? Никто не знает?

На сколько мне известно о нём давно уже ничего не слышно.

Планировал. Будешь ждать пока Бардак напишет?

Извиняюсь, вопрос несколько относится к оффтопу, вопрос может показаться тупым, но всё же косается разбора форматов: вот как Вы, все те кто написал различные утилиты, конвертеры и другие программы для работы с форматами игр ST и Metro, вскрываете эти самые форматы? Допустим есть тот же формат (*.object) или (*.ogf), пример может выбрал не из легких, или формат игровых архивов (*.db), (*.vfs*) для Metro, с чего начинается анализ неизвестного формата, как его вскрыть? Как вы определяете чанки, если это "чанковый" формат (в HEX?), как определяете что в них содержится, их размер и как с ними работать? Скиньте линки на статьи, форумы и(или) любую другую информацию как это делается, буду признателен за поддержку. Заранее спасибо.

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

MegaNub, http://www.render.ru/books/show_book.php?book_id=470

Выкладываю скрипт для импорта object в Blender 2.67b:

Скачать (Яндекс диск)

Поддерживаются только статические. readme в архиве.

С анализа программы которая знает формат. Билды сталкера отлично работают под дебаггером + в билдах есть отладочная инфа, помогающая при декомпиляции

А что значит анализ? Это дизассемблирование движка билда и просмотр кода? И вообще, как бардак узнавал про форматы?

Именно.


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

а как в билдах включить режим дебагга? И где отладочная информация находится? В консоли и логах?

Pavel_Blend, запустить билд под дебагером, x86dbg например, найти интересующее место в коде и изучать как оно работает. Я надеюсь ты знаешь язык ассемблера.

Если что - я знаю. Чем смогу - помогу 3д художнику.

Исходный код в сети, что вы в самом то деле...

Не, он же писал, что код сохранения пысовских форматов стянут с пыс. А учитывая тот факт, что ковырять сталкир он начал ещё в 2006 году (если не раньше), можно сделать вывод, что бинарники наверняка были от дебажных билдов.
Уж если бы были исходники, то он бы реализовал экспорт анимации камеры.

Интересно, Лохотрон уже знает?

Загрузчик и сохранялка .anm файлов в библиотеке xray_re есть.

Как в анекдоте есть 3 путя:
1) Наличие исходников, дальше найти нужный участок кода и тупо скопипастить.
2) Дизасм кода как отметил Neo][ и курение асмы или перегон в псевдокод СИ и курение его, дальше только воссоздать алгоритм.
3) Курить формат хэксом, строить предположения и проверять их.

По поводу 3го варианта, как это обычно происходит:
- ясен пень что все будет выглядеть как куча байтов.
- мы знаем что чаще всего быйты были получены из конкретных типов. К примеру int =4 байта.
- включаем внимательность и немного работаем калькулятором, глаз цепляется за последовательности int int int, делаем предположение что это может быть координата вершины
- отсюда вытекает закономерный вопрос а сколько их там будет подряд? Значит гдето перед ними или в самом начал\конце файла будет число которое это укажет
- пробуем на глаз определить конец этих последовательностей(лучше конечно посчитать сколько раз подряд идут int).
- к примеру на предыдущем шаге мы получили число 100, пробуем предположить что это x y z вершин, делим 100\3 =33.3, не подходит т.к. число должно быть целым, предполагаем что это x y z d значит 100/4 = 25 уже лучше, запомним это число т.к. будем искать его упоминание. Так же можно на всякий случай предположить что мы ошиблись и тип short а значит всего 2 байта т.е. 100/2 = 50 вершин x y. Возможно это и другой тип данных. К слову на этом этапе проще всего попытаться представить числа на бумаге если думаешь что это координаты.
- ищем эти числа перед последовательностьй, вначале\конце файла. Предположим что нашли.
- проверяем полученное на другом файле, если число координат скажем перед началом последовательностей совпало то УРА, мы нашли где лежат вершины.
- дальше по схожему алгоритму ищем предположительно другие последовательности (нормали, текстурные координаты, текстурную развертку и много друго что может там оказаться)
- постепенно неизвестных последовательностей и байтов стало намного меньше и получилось нечто такое "int неизвестно, int число вершин последовательность_вершин, char[] название_анимации последовательность_кадров_анимации".
- зная это уже можем писать конвертер.
* Из сложностей:
1) типов данных может быть много
2) не факт что они идут последовательно
3) байты бывают little и big endian
4) данные могут быть шифрованы\сжаты начиная от чего то стандартного типа zlib и заканчивая чем то своим и сложным
5) данные могут быть не полные, когда смещения начала\конца\числа последовательности хранятся гдето отдельно или захардкожены в программе
6) не всегда известно что ожидать внутри файла, к примеру зная что это точно модель то можно точно сказать что в файле точно есть как минимум координаты вершин.
7) внутри может быть целая структура из структур
8) возможно что то забыл.

Что удобнее 2 или 3й вариант, ну ОТЦЫ знают асму и си и естественно отлично представляют структуры и на глаз переводя ричность\битность а значит разберут формат раз в 5 быстрее чем лохи только с 3м вариантом. При этом может быть и обратный эффект, если библиотек\ехе много и они обфусцированы и защищены то на декомпиляция от интереса уйдет намного больше времени чем чистый 3й вариант. Тоже относится и к 1му варианту, в зависимости от глубины кода по проге может оказаться что скопипастить не получится а в лучшем случае удасться узнать какието мелкие моменты которые проще забрать, или же наоборот окажется проще не разбираться с кодом а наткнуться на нечто типа dump\unpack\extract и останется всеголишь его вызвать.

К изложенному выше можно еще добавить четвертый путь: подцепиться к процессу при помощи отладчика и посмотреть какой код выполнится при чтении нужного файла с диска. Вариант с дизассемблированием не особо поможет т.к. для того чтобы проанализировать нужный кусочек кода придется проделать очень много работы.

При наличии исходников задача упрощается в разы.

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

Орхетектор, современные игры не особо располагают для подключения отладчика =)

saas, встречаются и это юзается не только в инструкциях процев, к примеру как минимум ява свой код хранит в big endian, многие форматы файлов юзают такой порядок байт и т.д.

https://github.com/OpenXRay/xray-16/blob/ma.../EditMeshIO.cpp


https://github.com/OpenXRay/xray-16/blob/ma...or/EditObject.h

Автору советую выкачать архив с исходниками вот из этой ветки и поиском в far-подобном файловом менеджере поискать ответы на свои вопросы.

Ну вот например из игр кто использует такой порядок байт в файлах? Кроме майнкрафта, конечно же.

saas, тут я к триалсу распаковщик както делал, так в нем часть файлов была одном порядке байт а часть в обратном. Самый живой пример и самый массовый network byte order т.е. прямо сейчас по ТСР байтики летает у тебя в big endian . Самый популярный формат картинок тоже в big endian =) Это из того что вспомнил.
PS порядок байт несет смысл не только от архитектуры проца но и от других вещей.

А вообще об этом бы неплохо написать. Я тоже очень долго не мог понять.

У нас есть:
1. VMap (содержит UV координаты вес кости)
2. VMRef (содержит индекс VMap-ы и индекс UV или веса в этой VMap-е).
3. Треугольники. Содержат индекс вертекса и индекс VMRef, по которому надо выйти на нужную VMap-у и взять нужное значение из неё.

Ссылок на VMap в VMRef может быть несколько. В билде с городом ацтеков можно было накладывать до 8 тексткур на один материал.
В новых версиях в VMap к каждой координате(или весу) добавили индекс точки(или полигона) который её использует. Зачем?

Формат .object не для слабаков, короче.

Это зависит от реализации протокола верхнего уровня, сам по себе транспорт конечно же не знает что за данные по нему гоняют.
А вообще порядок следования байт определяется железом, в подавляющем большинстве это Intel/AMD, потому как правило все разработчики выбирают обратный порядок.


В Doom3 имеется поддержка как обратного так и прямого порядка.