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

== CGFX ==

CGFX header :
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Magic "CGFX"
|-
| 0x4
| 0x2
| Byte order mark: FFFE (little endian) or FEFF (big endian)
|-
| 0x6
| 0x4
| CGFX header size
|-
| 0xA
| 0x2
| ?
|-
| 0xC
| 0x4
| File size (bytes)
|-
| 0x10
| 0x4
| Number of entries
|}

A typical CGFX file contains two main entries, beginning directly after the CGFX header: DATA and IMAG.

== DATA ==

DATA contains a list of DICT references.

DATA header (for N = 0..15) :
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Magic "DATA"
|-
| 0x4
| 0x4
| DATA Size (in bytes)
|-
| 0x8 +(N*8)
| 0x4
| Number of entries in DICT N
|-
| 0xC +(N*8)
| 0x4
| Offset (self-relative) to DICT N
|}

The DATA header contains the entry counts and offsets for each DICT entry. There are always sixteen entries; any unused entries are zeroed.

Typical entries:
{| class="wikitable"
|-
! N
! Type
|-
| 0
| Models
|-
| 1
| Textures
|-
| 2
| LUTS (Material/Color/Shader look-up tables?)
|-
| 3
| Unknown
|-
| 4
| Unknown
|-
| 5
| Cameras
|-
| 6
| Lights
|-
| 7
| Fog
|-
| 8
| Environments
|-
| 9
| Skeleton animations
|-
| 10
| Texture animations
|-
| 11
| Unknown animations
|-
| 12
| Unknown
|-
| 13
| Unknown
|-
| 14
| Unknown
|-
| 15
| Unknown
|}

== DICT ==

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

DICT header :
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Magic "DICT"
|-
| 0x4
| 0x4
| DICT size (in bytes)
|-
| 0x8
| 0x4
| Number of entries
|-
| 0xC
| 0x10
| ?
|}

DICT entry:
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| ?
|-
| 0x4
| 0x2
| ?
|-
| 0x6
| 0x2
| ?
|-
| 0x8
| 0x4
| Offset (self-relative) to symbol
|-
| 0xC
| 0x4
| Value (often offsets)
|}

== CMDL ==

CMDL is used to describe a 3D model.

CMDL Header :
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Flags (bit 7: hasSkeletonSobj)
|-
| 0x4
| 0x4
| Magic "CMDL"
|-
| 0x8
| 0x4
| ?
|-
| 0xC
| 0x4
| Offset (self-relative) to model name
|-
| 0x10
| 0x18
| ?
|-
| 0x28
| 0x4
| Number of entries in Animation Types DICT
|-
| 0x2C
| 0x4
| Offset (self-relative) to Animation Types DICT
|-
| 0x30
| 0xC
| Global scale vector (3 floats : x, y, z)
|-
| 0x3C
| 0x18
| ?
|-
| 0x54
| 0x30
| Matrix 1
|-
| 0x84
| 0x30
| Matrix 2
|-
| 0xB4
| 0x4
| Number of Vertex Info SOBJ entries
|-
| 0xB8
| 0x4
| Offset (self-relative) to Vertex Info SOBJ list
|-
| 0xBC
| 0x4
| Number of MTOB DICT entries
|-
| 0xC0
| 0x4
| Offset (self-relative) to MTOB DICT
|-
| 0xC4
| 0x4
| Number of Vertex Info SOBJ entries
|-
| 0xC8
| 0x4
| Offset (self-relative) to Vertex Info SOBJ list
|-
| 0xCC
| 0x4
| Number of Unknown DICT entries
|-
| 0xD0
| 0x4
| Offset (self-relative) to Unknown DICT
|-
| 0xD4
| 0xC
| ?
|-
| 0xE0
| 0x4
| Skeleton Info SOBJ offset (self-relative) [only present if flag bit 7 is set]
|-
| 0xB8+[0xB8]
| 0x4*N
| Vertex Info SOBJ self-relative offset list
|}

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 :

{| class="wikitable"
|-
! 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)
|}

{| class="wikitable"
|-
! 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 :

{| class="wikitable"
|-
! 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)
|}

{| class="wikitable"
|-
! 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#Icon_graphics|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 [https://gist.github.com/smealum/8897237] for implementation example.

== LUTS ==

Appears to contain color lookup tables possibly for use with shaders.

LUTS Header:
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Magic "LUTS"
|-
| 0x4
| 0x2
| Seems to adhere to powers of 2 (width/height/flags?)
|-
| 0x6
| 0x2
| Seems to adhere to powers of 2 (width/height/flags?)
|-
| 0x8
| 0x4
| ?
|-
| 0xC
| 0x8
| all zeroes ?
|-
| 0x14
| 0x4
| ?
|-
| 0x18
| 0x4
| Offset to DICT (self-relative) ?
|}
All observed instances have an otherwise unreferenced DICT section immediately afterward (the last LUTS value being a 0x4, which may describe the relative position of that DICT), which appears to describe material specularity.

== Skeleton data ==

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

{| class="wikitable"
|-
! 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.

== Links ==
* Another CGFX Format Description: [http://florian.nouwt.com/wiki/index.php/CGFX_(File_Format) http://florian.nouwt.com/wiki/index.php/CGFX_(File_Format)]

CGFX

2014-09-08T16:34:02Z

Planetarian: /* DATA */

2014-09-04T16:29:24Z

Planetarian: added info on the CGFX/DATA headers ~~~~

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

== CGFX ==

CGFX header :
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Magic "CGFX"
|-
| 0x4
| 0xC
| ?
|-
| 0x10
| 0x4
| Number of entries
|}

A typical CGFX file contains two main entries, beginning directly after the CGFX header: DATA and IMAG.

== DATA ==

DATA contains a list of DICT references.
The DATA header contains the entry counts and offsets for each DICT entry, and holds sixteen such references. Unused references are zero-padded.

DATA header (for N = 0..15) :
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Magic "DATA"
|-
| 0x4
| 0x4
| DATA Size (in bytes)
|-
| 0x8 +(N*8)
| 0x4
| Number of DICT entries
|-
| 0xC +(N*8)
| 0x4
| Offset (self-relative) to DICT
|}

== DICT ==

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

DICT header :
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| Magic "DICT"
|-
| 0x8
| 0x4
| DICT size (in bytes)
|-
| 0xC
| 0x4
| Number of entries
|}

DICT entry:
{| class="wikitable"
|-
! Offset
! Length
! Description
|-
| 0x0
| 0x4
| ?
|-
| 0x4
| 0x4
| ?
|-
| 0x8
| 0x4
| Offset (self-relative) to symbol
|-
| 0xC
| 0x4
| Value (often offsets)
|}

== CMDL Header ==

{| class="wikitable"
|-
! 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 :

{| class="wikitable"
|-
! 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)
|}

{| class="wikitable"
|-
! 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 :

{| class="wikitable"
|-
! 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)
|}

{| class="wikitable"
|-
! 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#Icon_graphics|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 [https://gist.github.com/smealum/8897237] for implementation example.

== Skeleton data ==

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

{| class="wikitable"
|-
! 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.