CGFX is a container format used to store graphics resources. It can contain 3D models, textures and animation data.

DICT

DICTs are generic structures used to store values (and associate them to a key ?). A DICT header is 0x1C bytes long.

DICT header :

Offset Length Description
0x0 0x4 Magic "DICT"
0x8 0x4 DICT size (in bytes)
0xC 0x4 Number of entries

DICT entry:

Offset Length Description
0x0 0x4 ?
0x4 0x4 ?
0x8 0x4 Offset (self-relative) to symbol
0xC 0x4 Value (often offsets)

CMDL Header

Offset Length Description
0x0 0x4 Magic "CMDL"
0x8 0x4 CMDL section size (in bytes)
0x28 0x4 Offset (self-relative) to first DICT
0x2C 0xC Global scale vector (3 floats : x, y, z)
0xB0 0x4 N/2, where N is the number of entries in SOBJ list
0xB4 0x4 Offset (self-relative) to SOBJ list
0xBC 0x4 Offset (self-relative) to MTOB DICT
0xB4+[0xB4] 0x4*N*2 SOBJ list; each word is an offset (self-relative) to an SOBJ structure

CMDL is used to describe a 3D model. A CMDL section refers to outside data; it can not be considered separately from the rest of the CGFX file. The second DICT in the CMDL section contains offsets to MTOB objects.

SOBJ

SOBJ structures can be used to describe 3D objects that are part of the model. If such is the case then they will follow this structure :

Offset Length Description
0x0 0x4 Magic "SOBJ"
0x44 0x4 X = Offset (relative to SOBJ magic) to SOBJ data structure
X+0x18 0x1 Face data format (?) : 0x1 = u8, 0x3 = u16
X+0x20 0x4 Face data section size (in bytes)
X+0x24 0x4 Face data section offset (self-relative)
X+0x58 0x4 Vertex data section size (in bytes)
X+0x5C 0x4 Vertex data section offset (self-relative)
X+0x68 0x1 Vertex data format size (in bytes)
Vertex format size Description
0x14 X (float), Y (float), Z (float), U (float), V (float)
0x18 X (float), Y (float), Z (float), Unk (u32?), U (float), V (float)
0x20 X (float), Y (float), Z (float), NX (float), NY (float), NZ (float), U (float), V (float)
0x28 X (float), Y (float), Z (float), NX (float), NY (float), NZ (float), U (float), V (float), Unk1 (u32?), Unk2 (u32?)

TXOB

TXOBs are contained within MTOBs. They can describe textures; if such is the case, then their structure is as follows :


Offset Length Description
0x0 0x4 Magic "TXOB"
0x14 0x4 Texture height
0x18 0x4 Texture width
0x30 0x1 Texture format ID (see table below)
0x38 0x4 Texture height (?)
0x3C 0x4 Texture width (?)
0x40 0x4 Texture data size
0x44 0x4 Texture data offset (self-relative)
Texture format ID Description
0x0 RGBA8
0x1 RGB8
0x2 RGBA5551
0x3 RGB565
0x4 RGBA4
0x5 LA8
0x6 HILO8
0x7 L8
0x8 A8
0x9 LA4
0xA L4
0xB ETC1 (see notes below)
0xC ETC1A4 ?
0xD A4 ?

Every texture format has its texture data divided into 8x8 tiles. See SMDH for more information. ETC1 is a compressed texture format which compresses blocks of 4x4 pixels into u64s. These u64 are traditionally stored in big endian; however, nintendo's implementation stores them in little endian. ETC1 textures are stored in 8x8 tiles; decompressed 4x4 therefore have to be organized accordingly. See [1] for implementation example.