Шаг первый

Структура xom файла.

Небольшое вступление от k^2

Итак теперь нарисую схематичный вид файла:

В кратце звучит так: в фотраме xom идет количество типов, количество контейнеров, описание типов, потом таблица строк, потом сами данные, начинающиеся CNTR и заканчивающиеся началом следующего контейнера.

Шаг второй
Как же загружается этот формат

Программа считывает количество типов и контейнеров, считывает информацию о том какие типы в файле, и то сколько каждого. Затем она считывает таблицу строк. И тут наступает самое сложное, считываются контейнеры, в зависимости от его типа, т.е. размер и контейнера, и тем самым начало следующего определяется типом.

Когда все данные загружены в память, по ним строится дерево.

Ищется базовый контейнер, который и является корнем дерева, обычно это XDataBank. В этом контейнеры хранятся ссылки на остальные контейнеры. И таким образом строится дерево. (в этом есть большой плюс! Если создан один контейнер, и на него ссылаются куча других, то экономится размер файла, т.е. не нужно писать одинаковые данные. Этим объясняется маленький размер файлов на примере карт)

Итак, наша задача, расшифровать как можно больше типов, чтобы можно было построить дерево, если дерево построено верно, то мы сможем изменять файл, именно так я и поступал с Scripts.xom для W3D где все типы я раскодировал, а именно:
XContainer
LevelDetails
XResourceDetails
XUintResourceDetails
XContainerResourceDetails
XDataBank

Шаг третий
Декодирование типов.

Итак для начала приведу список типов к примеру из модели шляпы HatAfro:

Так мы видем слева в XomView. Где в скобках отмечается количество элементов.

На сегодня хватит, переваривайте....

Можешь это поточнее, т.е. длины в байтах и по каждому слову, типа Offset Strings. Все данные, как я понял идут сплошняком?
Как я всё это дело понял:
MOIK | version | ? | Num Types | Num Counteiner | Base Counteiner
затем Num Types записей вида:
TYPE | Num Counteiner | GUID type | Name Type
затем заголовок таблицы строк:
GUID | SCHM |? | STRS | Num Strings | Offset Strings

а дальше непонятно про Offset Strings, и что значат индексы.
Что такое Base Counteiner? Строка/число?
Что есть Name Type? индекс строки/число?
Что есть GUID type?

Да все данные идут сплошняком... Что и усложняет декодирование.

Offset это длинна таблицы строк, т.е. то где строки кончаются и начинаются контейнеры.
В таблице индексов строк, стоят Offset в байтах, до начала нужной строки, длина строки определяется нулем, т.е. Pchar формат.

После строк идут данные, сплошняком...

Приведу пример для наглядности того же HatAfro.xom:

XNode(0) -> XInteriorNode(1)
XGroup(2)
XCore(0) -> XShape(1)
XShader(0)-> XSimpleShader(1)
XAttribute(0) -> XMaterial(1)
XImage(1)
XTextureStage(0) -> XTextureMap(0) -> XOglTextureMap(1)
XGeometry(0)-> XGeoSet(0) -> XIndexedGeoSet(0)-> XIndexedTriangleSet(1)
XVertexDataSet(0)
XCoordSet (0)
XNormalSet(0)
XColorSet(0)
XTexCoordSet(0)
XCoord3fSet(1)
XNormal3fSet(1)
XColor4ubSet(1)
XTexCoord2fSet(1)
XIndexArray(0) -> XIndexSet(1)
XMatrix(0) -> XTransform(1)
XCollisionGeometry(1)
XCollisionData(2)
XFortsExportedData(1)
XDetailObjectsData(1)
XGraphSet(0)
XContainer(0)

Уже что-то вырисовывается

XIndexedTriangleSet(1) :

0x0E 0x0A 0x0B 0x0C 0x0D - прямые индексы на контейнеры
XIndexSet(1)
XCoord3fSet(1)
XNormal3fSet(1)
XColor4ubSet(1)
XTexCoord2fSet(1)

Похожая структура и в 3DS файлах.

Загадка что такое 0xD2 и

FF FF 7F 7F FF FF 7F
7F FF FF 7F 7F FF FF 7F
FF FF FF 7F FF FF FF 7F
FF

...

По поводу пустых контейнеров, то я думаю это надклассы , попробую их связать:

Они содержат массив треугольников, XCollisionGeometry - это поверхность активная в игре.

Итак. по тому что я сейчас имею, я могу добавить в XomView отображение данных в виде 3D модели, с натянутыми текстурами. и отобразить поверхность в которую заключена модель.

Но главная задача - это раскодировать XGraphSet, когда он будет декодирован, то в все дерево построится, и мы будем видеть xom файл как файл с ресурсами, в котором можно будет экспортировать и импортировать ресурсы!!!

Первый байт это указание на количество ресурсов,
каждый указатель длинной в 18 байт, где последнии 2 байта изменчивые.
Можно сделать вывод что первые 16 байт указывают на Тип ресурса, а последние два байта на его местоположение....

...

Последний байт указывает на строку!!!
в итоге имеем следующую структуру:
XGraphSet HatAfro.xom

0x05 - количество типов
1- {6A E6 DB E4 FA 86 6B 45 A7 3F F9 13 0E 12 DF EB} 01 07
2- {ED C2 8F C5 8E 9E 05 45 9B AA 55 75 E9 CD 6D C6} 11 08
3- {ED C2 8F C5 8E 9E 05 45 9B AA 55 75 E9 CD 6D C6} 12 09
4- {5F 30 94 DB 73 B3 FC 42 B1 85 2E 01 B2 8F 82 12} 14 0A
5- {E1 D7 EF 28 99 0C BF 43 A6 7D 15 FE 53 98 6A 3B} 13 0B

Из таблицы строк получаем:

07 - world
08 - Collision Data
09 - Phantom Collision Data
0A - Detail Objects
0B - Forts Exported Data

Из индексов получаем:
01 - XInteriorNode
11 - XCollisionData [0]
12 - XCollisionData [1]
14 - XDetailObjectsData
13 - XFortsExportedData

Как видно все верно!!!!!!!

Чтобы увидеть 3D модель нужно Выделить XCollisionGeometry.
Пока что он умеет лишь это. Ну и корректно сохраняет bin код, в отличие от предыдущего.

Но даже с этими возможностями я полазил по ресурсам W3D W4 WF.

Прикольно =)