[Jeff-Groves]

A long time ago, this basic structure was posted at SubSim.

 

SH III DAT FILE FORMAT

Skip the first 20 bytes they seem to be always the same.
Next 4 bytes are a long with the header string lenght.
Next is the author name and the "using Kashmir" stuff, total lenght as read above.

Next, file is made of "chunks". All chunks are like this:
ChunkType 4 bytes
Chunk Subtype/Version 4 bytes
chunk_size long (4 bytes)
Data (chunk_size bytes)


Chunk types and internal structure of each one:

type 0: EMPTY chunk
it's just 12 "00" bytes, so type, subtype and size are 0

type 1: 3D chunk
after the Chunk type, subtype/ver and size, format of the data part is like follows:
chunk_id: 8 bytes //this is used to reference this part inside the file. References usually found inside NODE (type 4) chunks
???????: 1 byte //don't know about this one
nverts: 4 byte long //number of vertices
vertex data: nverts * 3 floats(X,Y,Z)// these are vertices, 3 floats per vertex
ntri: 4 byte long //number of triangles;
triangle data: there are ntri triangles and their texture mapping, each one is as follows
vertex1: unsigned 2-byte int
vertex2: unsigned 2-byte int
vertex3: unsigned 2-byte int
texture coord1: unsigned 2-byte int
texture coord2: unsigned 2-byte int
texture coord3: unsigned 2-byte int
????????????: one byte
ntxcoords: 4 byte long //number of texture coordinates
texture coords data: ntxcoords * 2 floats // texture coordinates are 2D

some objects end here, but some have "TMAP" and a bunch of floats after this, dunno what is that yet so I skip it

type 2: TEXTURE REFERENCE?
after the Chunk type, subtype/ver and size, format of the data part is like follows:
chunk_id: 8 bytes //this is used to reference this part inside the file. References usually found inside NODE (type 4) chunks
then a bunch of bytes that I haven't figured yet, usually ending with a texture filename.

type 3: TGA FILE
these are the TGA files, just packed after the type, subtype and chunk size.

type 4: NODE (these tell us how parts are related to each other, in a tree-like hierarchy)
after the Chunk type, subtype/ver and size, format of the data part is like follows:
chunk_id: 8 bytes //this is used to reference this node inside the file. References usually found inside NODE (type 4) chunks
parent_id: 8 bytes //reference to the "parent" node. root nodes have 00 00 00 00 00 00 00 00 as parent
3dpart_id: 8 bytes //reference to the 3d part managed by this node, 00 00 00 00 00 00 00 00 if this is a "dummy" node with no visible 3d part
????????: 1 byte, seems to be always 00.
????????: 1 byte, seems to be related to the number of different type 2 nodes referenced from this one.
x offset: 4 bytes float //x offset from parent node
y offset: 4 bytes float //y offset from parent node
z offset: 4 bytes float //z offset from parent node

then comes the type 2 chunk references and some stuff I don't yet understand

type 6: DATA?
these are children of type 10 chunks, they seem to hold effects, commands, interactions, etc...
first 8 bytes are the reference to the type 10 parent. rest is strings and numerical values.

type 8: LABEL
these are used to label other nodes
format is:
8 byte parent chunk reference
string with label

type 10: DATA?
these seem to group type 6 chunks and attach them to type 4 nodes
first 8 bytes: id of this chunk
second 8 bytes: id of parent node
then comes some data, usually strings and numbers.

type 102: SCALE?
these come usually near the end of the files, they are a bunch of floats, probably some global scaling, have to test it

type 1001: INDEX
this one seems to be an index, there are chunk ID's and the corresponding file postition, might have to update this if some chunk has its size altered, but some tries suggest this doesnñr affect loading.



There are more chunk types, haven't had time to check them

I'll invite anyone to update that information. Me?
I already know.
Now if one knows a basic structure from SH3? One can follow the structure from SH5 and adapt!