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 | 0x3 | Flags ? |
| 0x3 | 0x1 | SOBJ type ? (0x10 = model, 0x02 = skeleton) |
| 0x4 | 0x4 | Magic "SOBJ" |
| 0x44 | 0x4 | Y = Offset (self-relative) to bone correspondance array |
| 0x48 | 0x4 | X = Offset (relative to SOBJ magic) to SOBJ data structure (wrong ?) |
| 0x44+Y+0x00 | 0x4 | N = Number of bone IDs in bone correspondance array |
| 0x44+Y+0x14 | 0x4*N | Bone correspondance array |
| 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) |
| 0x28v1 | X (float), Y (float), Z (float), NX (float), NY (float), NZ (float), U (float), V (float), (local) Bone IDs (4*u8), Bone weights (4*u8) |
| 0x28v2 | X (float), Y (float), Z (float), NX (float), NY (float), NZ (float), U (float), V (float), Unk1 (u32), (local) Bone IDs (2*u8), Bone weights (2*u8) |
Vertex format 0x28 (and possibly others) supports multiple bone assignment. In this case, the sum of all bone weights is 0x64.
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 | A4 ? |
| 0xC | ETC1 (see notes below) |
| 0xD | ETC1A4 ? |
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.