CGFX

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

CGFX header :

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

DATA contains a list of DICT references.

DATA header (for N = 0..15) :

The DATA header contains the entry counts and offsets for each DICT entry. The number of entries can vary (probably based on the version?), but are always in the following order. Any unused entries are zeroed.

Typical entries:

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

DICT header :

DICT entry:

CMDL is used to describe a 3D model.

CMDL Header :

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 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 :

Face groups:

Unknown2:

Face array descriptor:

Vertex groups come in a number of different formats. Typically the first vertex group entry is of format 0x40000002 and contains the actual vertex array.

Vertex group format 0x40000002:

Each mesh’s primary vertex group contains an array of vertex component declaration objects, defining the order and parameters for each of a vertex’s components.

Vertex component declaration:

Vertex formats with bone data support multiple bone assignment. In this case, the sum of all bone weights is 0x64.

Vertex component types:

Vertex component data types:

Vertex components are stored as one of the above data types, and the vertex component declaration contains a multiplier that adapts the values to the float version which the game will use. For example, color RGBA values are stored as bytes, and the multiplier converts them from 0-255 to 0-1.0, and position components using short values are normalized via the multiplier to take advantage of the entire short value range.

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

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.

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

LUTS Header:

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 is stored in an array. Each entry is 0xE0 bytes in length and organized this way :

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. (?)

CANMs are used to store skeletal animation data.

• Every File Explorer
• Ohana3DS and its forks
• SPICA

• Another CGFX Format Description (Archived Page): 🔗 http://florian.nouwt.com/wiki/index.php/CGFX_(File_Format)

Category:File formats