Another round of modelbin format digging
First part.
Second part.
Third part.
Today focus is VLay and IndB data structure.
VLay is "Vertex data Layout" i think.
VLay data structure is:
Header entry with Id number.
Main data entry:
Code: Select all
Word - Number of name entries
DWord - Name 1 lenght in X-bytes
X-bytes - Name 1 string
DWord - Name 2 lenght in bytes
X-bytes - Name 2 string
etc.
Word - Number of data entries
Data entries part 1 (xNumber of data entries):
Word unk. (name number in hex or data type (need to check more samples))
Word unk. (data block number (UV numbers here too))
Word unk. (number of blocks used in IndB)
Word 00 00
DWord unk. (data type?)
DWord FF FF FF FF
Dword 00 00 00 00
Data entries part 2 (xNumber of data entries):
Dword - unk. (data type related)
DWord (or byte byte 00 00) - unk. (VLay type? Matched for identical VLay entries in different modelbins (and cars))
How this data looks being sorted into table:
(
live version is here)
Id part gives a way to connect VLay data with VerB blocks:
(same Id for VLay, Verb and MBuf blocks, some of VerB (with lowest LODs) don't have a VLay and MBuf connected (maybe they use empty "FF" VLay))
This looks pretty enough for reading any vertex data we want, like UV1-5, so, it's time to patiently wait for
shak-otay comes back (this saturday)
.gif "Smile"){kind=small}
Will this solve the scaling issue of UVs?