CGFX

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), Bone IDs (4*u8), Bone weights (4*u8)

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.

Skeleton data

Skeleton data is stored in an array. Each entry is 0xE0 bytes in length and organized this way :

Offset	Length	Description
0x0	0x4	Offset (self relative) to name symbol
0x8	0x4	Joint ID
0xC	0x4	Parent joint ID
0x10	0x4	Signed offset (self-relative) to parent joint
0x2C	0xC	Angle vector (floats, x, y, z)
0x38	0xC	Position vector (floats, x, y, z)
0x44	0x30	Transformation matrix (4x3)
0x70	0x30	Identity matrix ? (4x3)

Each entry stores the joint transformation data twice; once as angle/position vectors and once as a transformation matrix. Each entry also stores a second matrix which appears to always be identity. (?)

CANM

CANMs are used to store skeletal animation data.