Структура .WFT файла и офсеты в нём (GTA IV)

[aleks926820]

На днях появилось желание поковырять четверочные файлы моделей (.WFT .WDR). Наткнулся на одну несостыковку в секции Geometry (она одинакова как для .wdr так и для .wft файла).

Код: [Выделить]

Geometry (Размер блока 0x50)
--------------------------------------------------------------------
0x00 4b LONG Идентификатор секции (0xF4486B00)
0x04 4b LONG Неизвестно 1 (Usually 0)
0x08 4b LONG Неизвестно 2 (Usually 0)
0x0C 4b Offset VertexBuffer             //4х байтовый офсет на секцию VertexBuffer (смещение указывается от начала файла)
0x10 4b LONG Неизвестно 3 (Usually 0)
0x14 4b LONG Неизвестно 4 (Usually 0)
0x18 4b LONG Неизвестноn 5 (Usually 0)
0x1C 4b Offset IndexBuffer          //4х байтовый офсет на секцию IndexBuffer (смещение указывается от начала файла)
0x20 4b LONG Неизвестно 6 (Usually 0)
0x24 4b LONG Неизвестно 7 (Usually 0)
0x28 4b LONG Неизвестно 8 (Usually 0)
0x2C 4b LONG IndexCount
0x30 4b LONG FaceCount
0x34 2b Short VertexCount
0x36 2b Short PrimitiveType
0x38 4b LONG Неизвестно 9 (Usually 0)
0x3C 2b Short VertexStride
0x3E 2b Short Неизвестно 10 (Usually 0)
0x40 4b LONG Неизвестно 11 (Usually 0)
0x44 4b LONG Неизвестно 12 (Usually 0)
0x48 4b LONG Неизвестно 13 (Usually 0)
0x4C 4b LONG Набивка                 (0xCDCDCDCD)

Здесь меня интересуют офсеты на VertexBuffer и IndexBuffer. 4х байтовый офсет указывает на местоположение секции (смещение секции указано от начала файла, т.е. допустим если указано смещение VertexBuffer 0x3E80 то смещаясь на него от начала файла мы натыкаемся на идентификатор секции VertexBuffer 0xD8BA6B00. (См. ниже)

Код: [Выделить]

--------------------------------------------------------------------
VertexBuffer (BlockSize 0x64)
--------------------------------------------------------------------
0x00 4b LONG Идентификатор         (0xD8BA6B00)
0x04 2b Short VertexCount
0x06 2b Short Unknown 1 (Usually 0)
0x08 4b Offset DataOffset to VertexData
0x1C 4b LONG VertexStride (36 without normal map, 52 with normal map)
0x20 4b Offset VertexDeclarationOffset
0x24 4b LONG Unknown 2 (Usually 0)
0x28 4b Offset DataOffset to VertexData (Again)
0x2C 4b LONG Unknown 3 (Usually 0)
0x30 32b LONG    Padding                 (0xCD)
--------------------------------------------------------------------
IndexBuffer] (BlockSize 0x40)
--------------------------------------------------------------------
0x00 4b LONG Идентификатор       (0x70B86B00)
0x04 4b LONG IndexCount
0x08 4b Offset DataOffset to IndexData
0x0C 4b LONG Unknown 1 (Usually 0)
0x10 32b LONG    Padding                 (0xCD)
--------------------------------------------------------------------
И в этих офсетах обнаружилась несостыковка. Я просмотрел .wdr, .wft (один из объектов карты), .wft (модель автомобиля).
В случае с .wdr и .wft (который представляет собой объект карты) офсеты на Vertex Buffer и Index Buffer действительно ведут к этим секциям.
В случае с .wdr файлом и .wft файлом объекта.
(Я просматривал файлы cj_int_plant_4.wdr из int_veg.img и gb_probox03.wft из clothes.img)

А в случае с .wft файлом автомобиля офсет приводит в какую-то другую секцию (admiral.wft из vehicles.img).
Вот собсна несостыковка, о которой идет речь. Офсет приводит в какое-то другое место, а не в секцию Vertex buffer с идентификатором 0xD8BA6B.

При этом реальное местоположение секции VertexBuffer так скажем на смещении 69580 байт, а не на 29184, как указано в Geometry.

Вопрос - почему офсет на секцию Vertex buffer (и аналогично на секцию Index buffer) в .wft файле автомобиля приводит в какую-то другую секцию, а не в эту секцию (Vertex\Index buffer)? Может надо смещаться откуда-то из другого места? Кто в курсе?
Повторюсь, что в случае с .wdr и с .wft, представляющие собой элементы карты\интерьера, все в порядке. Данная ерунда наблюдается только моделями авто.

[Shagg_E]

Возможно, какой-то дополнительный блок информации (иерархия или прочие элементы).

[Shagg_E]

Передаю слова другого человека:

Пусть напишет на форумсе пользователю с ником Shvab (на русском), он офигенные вещи последнее время делает, буквально заново перекопал форматы IV, MCLA, RDR

[aleks926820]

Ответ найден.
К полученному значению смещения нужно применить операцию логического И с маской 0xFFFFFF. Тогда получится адекватное смещение к секции от начала файла.
На максскрипте это выглядит примерно так:

Код: [Выделить]

s=readlong wft #unsigned //читаем 4 байта смещения.
s = bit.and s (bit.hexasint "0xFFFFFFF") // применяем логическое И и получаем офсет в виде целого числа.
После чего смещаемся к полученному смещению от начала файла:
fseek wft s #seek_set //#seek_set означает, что смещаемся от начала файла.
fseek wft 0xC #seek_cur //затем смещаемся на 12 байт от текущего смещения, и следующие 4 байта будет заголовок нужной секции.P.S. Инфа была раскопана в вебархиве с сайта gtamodding.ru, который уже несколько месяцев недоступен.

[aleks926820]

Собственно говоря для чего это все ковырял:
https://libertycity.ru/files/gta-4/193341--wft-file-unlocker-script.html
Написал скрипт для снятия ZModeler Lock с .wft файлов.
Пользоваться просто - снять компрессию с .wft с помощью RSC Manager, скормить скрипту распакованный .wft файл, запаковать .wft файл обратно RSC Manager'ом. Где-то полторы дюжины моделек попробовал - все нормально импортнулись потом в занозу кроме одной модельки. Какая-то кривая моделька походу была, она не импортнулась даже после обработки скриптом для 010 Editor. А так вполне рабочий скрипт я считаю.
P.S. Кто может закиньте скрипт на сайт, пусть тут тоже будет.
P.S.S. Добавлю, что маску 0xFFFFFFF нужно применять ко всем офсетам вида [** ** ** 50] и [** ** ** 60].Это касается всех типов файлов - wdr wft wdd.