Changes

Jump to navigation Jump to search
6,444 bytes added ,  09:42, 31 July 2018
m
Line 1: Line 1:  
CGFX is a container format used to store graphics resources. It can contain 3D models, textures and animation data.
 
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
 +
| 0x2
 +
| CGFX header size
 +
|-
 +
| 0x8
 +
| 0x4
 +
| Revision
 +
|-
 +
| 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. 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:
 +
{| class="wikitable"
 +
|-
 +
! N
 +
! Type
 +
|-
 +
| 0
 +
| Models
 +
|-
 +
| 1
 +
| Textures
 +
|-
 +
| 2
 +
| LUTS (Material/Color/Shader look-up tables?)
 +
|-
 +
| 3
 +
| Materials
 +
|-
 +
| 4
 +
| Shaders
 +
|-
 +
| 5
 +
| Cameras
 +
|-
 +
| 6
 +
| Lights
 +
|-
 +
| 7
 +
| Fog
 +
|-
 +
| 8
 +
| Environments
 +
|-
 +
| 9
 +
| Skeleton animations
 +
|-
 +
| 10
 +
| Texture animations
 +
|-
 +
| 11
 +
| Visibility animations
 +
|-
 +
| 12
 +
| Camera animations
 +
|-
 +
| 13
 +
| Light animations
 +
|-
 +
| 14
 +
| Emitters
 +
|-
 +
| 15
 +
| Unknown
 +
|}
    
== DICT ==
 
== DICT ==
Line 15: Line 136:  
| 0x4
 
| 0x4
 
| Magic "DICT"
 
| Magic "DICT"
 +
|-
 +
| 0x4
 +
| 0x4
 +
| DICT size (in bytes)
 
|-
 
|-
 
| 0x8
 
| 0x8
 
| 0x4
 
| 0x4
| DICT size (in bytes)
+
| Number of entries
 
|-
 
|-
 
| 0xC
 
| 0xC
 
| 0x4
 
| 0x4
| Number of entries
+
| ?
 +
|-
 +
| 0x10
 +
| 0x2
 +
| Unknown. Seems to be shifted left by 4 bits in the source.
 +
|-
 +
| 0x10
 +
| 0x2
 +
| ?
 +
|-
 +
| 0x12
 +
| 0xA
 +
| ?
 
|}
 
|}
   Line 37: Line 174:  
|-
 
|-
 
| 0x4
 
| 0x4
| 0x4
+
| 0x2
 +
| ?
 +
|-
 +
| 0x6
 +
| 0x2
 
| ?
 
| ?
 
|-
 
|-
Line 46: Line 187:  
| 0xC
 
| 0xC
 
| 0x4
 
| 0x4
| Value (often offsets)
+
| Offset (self-relative) to object
 
|}
 
|}
   −
== CMDL Header ==
+
== CMDL ==
    +
CMDL is used to describe a 3D model.
 +
 +
CMDL Header :
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
Line 58: Line 202:  
|-
 
|-
 
| 0x0
 
| 0x0
 +
| 0x4
 +
| Flags (bit 7: hasSkeletonSobj)
 +
|-
 +
| 0x4
 
| 0x4
 
| 0x4
 
| Magic "CMDL"
 
| Magic "CMDL"
Line 63: Line 211:  
| 0x8
 
| 0x8
 
| 0x4
 
| 0x4
| CMDL section size (in bytes)
+
| ?
 +
|-
 +
| 0xC
 +
| 0x4
 +
| Offset (self-relative) to model name
 +
|-
 +
| 0x10
 +
| 0x18
 +
| ?
 
|-
 
|-
 
| 0x28
 
| 0x28
 
| 0x4
 
| 0x4
| Offset (self-relative) to first DICT
+
| Number of entries in Animation Types DICT
 
|-
 
|-
 
| 0x2C
 
| 0x2C
 +
| 0x4
 +
| Offset (self-relative) to Animation Types DICT
 +
|-
 +
| 0x30
 
| 0xC
 
| 0xC
 
| Global scale vector (3 floats : x, y, z)
 
| Global scale vector (3 floats : x, y, z)
 
|-
 
|-
| 0xB0
+
| 0x3C
 +
| 0x18
 +
| ?
 +
|-
 +
| 0x54
 +
| 0x30
 +
| Matrix 1
 +
|-
 +
| 0x84
 +
| 0x30
 +
| Matrix 2
 +
|-
 +
| 0xB4
 
| 0x4
 
| 0x4
| N/2, where N is the number of entries in SOBJ list
+
| Number of Vertex Info SOBJ entries
 
|-
 
|-
| 0xB4
+
| 0xB8
 
| 0x4
 
| 0x4
| Offset (self-relative) to SOBJ list
+
| Offset (self-relative) to Vertex Info SOBJ list
 
|-
 
|-
 
| 0xBC
 
| 0xBC
 +
| 0x4
 +
| Number of MTOB DICT entries
 +
|-
 +
| 0xC0
 
| 0x4
 
| 0x4
 
| Offset (self-relative) to MTOB DICT
 
| Offset (self-relative) to MTOB DICT
 
|-
 
|-
| 0xB4+[0xB4]
+
| 0xC4
| 0x4*N*2
+
| 0x4
| SOBJ list; each word is an offset (self-relative) to an SOBJ structure
+
| 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
 
|}
 
|}
   −
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.
+
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.
 
The second DICT in the CMDL section contains offsets to MTOB objects.
   Line 104: Line 304:  
|-
 
|-
 
| 0x0
 
| 0x0
 +
| 0x4
 +
| Flags (bit 4: model; bit 1: skeleton)
 +
|-
 +
| 0x4
 
| 0x4
 
| 0x4
 
| Magic "SOBJ"
 
| Magic "SOBJ"
 
|-
 
|-
| 0x44
+
| 0x8
 +
| 0x4
 +
| ?
 +
|-
 +
| 0xC
 +
| 0x4
 +
| Unknown symbol offset (self-relative)
 +
|-
 +
| 0x10
 +
| 0xC
 +
| ?
 +
|-
 +
| 0x1C
 +
| 0x4
 +
| Offset (self-relative) to Unknown1 (appears to hold array of floats) ?
 +
|-
 +
| 0x20
 +
| 0xC
 +
| Mesh position offset (X/Y/Z floats)
 +
|-
 +
| 0x2C
 +
| 0x4
 +
| Face groups count
 +
|-
 +
| 0x30
 +
| 0x4
 +
| Offset (self-relative) to face groups offset array
 +
|-
 +
| 0x34
 +
| 0x4
 +
| ?
 +
|-
 +
| 0x38
 +
| 0x4
 +
| Vertex groups count
 +
|-
 +
| 0x3C
 +
| 0x4
 +
| Offset (self-relative) to vertex groups offset array
 +
|-
 +
| 0x40
 +
| 0x4
 +
| Unknown offset (self-relative) ?
 +
|}
 +
 
 +
Face groups:
 +
 
 +
{| class="wikitable"
 +
|-
 +
! Offset
 +
! Length
 +
! Description
 +
|-
 +
| 0x0
 +
| 0x4
 +
| Bone groups count
 +
|-
 +
| 0x4
 +
| 0x4
 +
| Offset (self-relative) to UInt32 bone group IDs array
 +
|-
 +
| 0x8
 +
| 0x4
 +
| ?
 +
|-
 +
| 0xC
 +
| 0x4
 +
| Unknown2 count
 +
|-
 +
| 0x10
 +
| 0x4
 +
| Offset (self-relative) to Unknown2 offset array
 +
|}
 +
 
 +
Unknown2:
 +
 
 +
{| class="wikitable"
 +
|-
 +
! Offset
 +
! Length
 +
! Description
 +
|-
 +
| 0x0
 +
| 0x4
 +
| Face group descriptor count
 +
|-
 +
| 0x4
 +
| 0x4
 +
| Offset (self-relative) to face array descriptors offset array
 +
|-
 +
| 0x8
 +
| 0x4
 +
| Unknown3 count
 +
|-
 +
| 0xC
 +
| 0x4
 +
| Offset (self-relative) to UInt32 Unknown3 array
 +
|-
 +
| 0x10
 +
| 0x8
 +
| ?
 +
|}
 +
 
 +
Face array descriptor:
 +
 
 +
{| class="wikitable"
 +
|-
 +
! Offset
 +
! Length
 +
! Description
 +
|-
 +
| 0x0
 +
| 0x4
 +
| Flags (bit 1: vertex index format: 0=byte, 1=short)
 +
|-
 +
| 0x4
 +
| 0x4
 +
| ?
 +
|-
 +
| 0x8
 +
| 0x4
 +
| Vertex index array size (in bytes)
 +
|-
 +
| 0xC
 +
| 0x4
 +
| Offset (self-relative) to vertex index array
 +
|}
 +
 
 +
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:
 +
 
 +
{| class="wikitable"
 +
|-
 +
! Offset
 +
! Length
 +
! Description
 +
|-
 +
| 0x0
 +
| 0x4
 +
| Flags (0x40000002)
 +
|-
 +
| 0x4
 +
| 0x4
 +
| ?
 +
|-
 +
| 0x8
 +
| 0x4
 +
| ?
 +
|-
 +
| 0xC
 +
| 0x4
 +
| ?
 +
|-
 +
| 0x10
 +
| 0x4
 +
| ?
 +
|-
 +
| 0x14
 
| 0x4
 
| 0x4
| X = Offset (relative to SOBJ magic) to SOBJ data structure
+
| Vertex array size (in bytes)
 
|-
 
|-
| X+0x18
+
| 0x18
| 0x1
+
| 0x4
| Face data format (?) : 0x1 = u8, 0x3 = u16
+
| Offset (self-relative) to vertex array
 
|-
 
|-
| X+0x20
+
| 0x1C
 
| 0x4
 
| 0x4
| Face data section size (in bytes)
+
| ?
 
|-
 
|-
| X+0x24
+
| 0x20
 
| 0x4
 
| 0x4
| Face data section offset (self-relative)
+
| ?
 
|-
 
|-
| X+0x58
+
| 0x24
 
| 0x4
 
| 0x4
| Vertex data section size (in bytes)
+
| Vertex stride/size in bytes (see below)
 
|-
 
|-
| X+0x5C
+
| 0x28
 
| 0x4
 
| 0x4
| Vertex data section offset (self-relative)
+
| Unknown3 count
 
|-
 
|-
| X+0x68
+
| 0x2C
| 0x1
+
| 0x4
| Vertex data format size (in bytes)
+
| Offset (self-relative) to component declaration offset array
 
|}
 
|}
 +
 +
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:
    
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
! Vertex format size
+
! Offset
 +
! Length
 
! Description
 
! Description
 +
|-
 +
| 0x0
 +
| 0x4
 +
| Flags (0x40000001)
 +
|-
 +
| 0x4
 +
| 0x4
 +
| Vertex component type (see below)
 +
|-
 +
| 0x8
 +
| 0x4
 +
| ?
 +
|-
 +
| 0xC
 +
| 0x4
 +
| ?
 +
|-
 +
| 0x10
 +
| 0x4
 +
| ?
 
|-
 
|-
 
| 0x14
 
| 0x14
| X (float), Y (float), Z (float), U (float), V (float)
+
| 0x4
 +
| ?
 
|-
 
|-
 
| 0x18
 
| 0x18
| X (float), Y (float), Z (float), Unk (u32?), U (float), V (float)
+
| 0x4
 +
| ?
 +
|-
 +
| 0x1C
 +
| 0x4
 +
| ?
 
|-
 
|-
 
| 0x20
 
| 0x20
| X (float), Y (float), Z (float), NX (float), NY (float), NZ (float), U (float), V (float)
+
| 0x4
 +
| ?
 +
|-
 +
| 0x24
 +
| 0x1
 +
| Component data type (see below)
 +
|-
 +
| 0x25
 +
| 0x1
 +
| ?
 +
|-
 +
| 0x26
 +
| 0x1
 +
| ?
 +
|-
 +
| 0x27
 +
| 0x1
 +
| ?
 
|-
 
|-
 
| 0x28
 
| 0x28
| X (float), Y (float), Z (float), NX (float), NY (float), NZ (float), U (float), V (float), Unk1 (u32?), Unk2 (u32?)
+
| 0x4
 +
| Number of values in this component (e.g. XYZ->3, UV->2)
 +
|-
 +
| 0x2C
 +
| 0x4
 +
| Multiplier for this component's values (float)
 +
|-
 +
| 0x30
 +
| 0x4
 +
| Position of this component within vertex stride
 +
|}
 +
 
 +
Vertex formats with bone data support multiple bone assignment. In this case, the sum of all bone weights is 0x64.
 +
 
 +
Vertex component types:
 +
 
 +
{| class="wikitable"
 +
|-
 +
! Value
 +
! Type
 +
|-
 +
| 0x00
 +
| Position
 +
|-
 +
| 0x01
 +
| Normal
 +
|-
 +
| 0x02
 +
| ? (unobserved)
 +
|-
 +
| 0x03
 +
| Color
 +
|-
 +
| 0x04
 +
| UV0
 +
|-
 +
| 0x05
 +
| UV1
 +
|-
 +
| 0x06
 +
| ? (unobserved, possibly UV2)
 +
|-
 +
| 0x07
 +
| Weight
 +
|-
 +
| 0x08
 +
| Index
 +
|}
 +
 
 +
Vertex component data types:
 +
 
 +
{| class="wikitable"
 +
|-
 +
! Value
 +
! Type
 +
|-
 +
| 0x00
 +
| sbyte
 +
|-
 +
| 0x01
 +
| byte
 +
|-
 +
| 0x02
 +
| short
 +
|-
 +
| 0x03
 +
| ? (unobserved, possibly ushort)
 +
|-
 +
| 0x04
 +
| ? (unobserved, possibly int)
 +
|-
 +
| 0x05
 +
| ? (unobserved, possibly uint)
 +
|-
 +
| 0x06
 +
| float
 
|}
 
|}
 +
 +
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.
    
== TXOB ==
 
== TXOB ==
    
TXOBs are contained within MTOBs. They can describe textures; if such is the case, then their structure is as follows :
 
TXOBs are contained within MTOBs. They can describe textures; if such is the case, then their structure is as follows :
      
{| class="wikitable"
 
{| class="wikitable"
Line 166: Line 653:  
|-
 
|-
 
| 0x0
 
| 0x0
 +
| 0x4
 +
| Flags
 +
|-
 +
| 0x4
 
| 0x4
 
| 0x4
 
| Magic "TXOB"
 
| Magic "TXOB"
 
|-
 
|-
| 0x14
+
| 0x8
 +
| 0x8
 +
| ?
 +
|-
 +
| 0xC
 +
| 0x4
 +
| Offset (self-relative) to symbol
 +
|-
 +
| 0x18
 
| 0x4
 
| 0x4
 
| Texture height
 
| Texture height
 
|-
 
|-
| 0x18
+
| 0x1C
 
| 0x4
 
| 0x4
 
| Texture width
 
| Texture width
 
|-
 
|-
| 0x30
+
| 0x28
| 0x1
+
| 0x4
 +
| Mipmap levels
 +
|-
 +
| 0x34
 +
| 0x4
 
| Texture format ID (see table below)
 
| Texture format ID (see table below)
 
|-
 
|-
| 0x38
+
| 0x3C
 
| 0x4
 
| 0x4
 
| Texture height (?)
 
| Texture height (?)
 
|-
 
|-
| 0x3C
+
| 0x40
 
| 0x4
 
| 0x4
 
| Texture width (?)
 
| Texture width (?)
 
|-
 
|-
| 0x40
+
| 0x44
 
| 0x4
 
| 0x4
 
| Texture data size
 
| Texture data size
 
|-
 
|-
| 0x44
+
| 0x48
 
| 0x4
 
| 0x4
 
| Texture data offset (self-relative)
 
| Texture data offset (self-relative)
Line 237: Line 740:  
|-
 
|-
 
|0xB
 
|0xB
|ETC1 (see notes below)
+
|A4 ?
 
|-
 
|-
 
|0xC
 
|0xC
|ETC1A4 ?
+
|ETC1 (see notes below)
 
|-
 
|-
 
|0xD
 
|0xD
|A4 ?
+
|ETC1A4 ?
 
|}
 
|}
   Line 249: Line 752:  
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.
 
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 ==
Line 263: Line 806:  
| 0x4
 
| 0x4
 
| Offset (self relative) to name symbol
 
| Offset (self relative) to name symbol
 +
|-
 +
| 0x4
 +
| 0x4
 +
| ?
 
|-
 
|-
 
| 0x8
 
| 0x8
Line 288: Line 835:  
| Transformation matrix (4x3)
 
| Transformation matrix (4x3)
 
|-
 
|-
| 0x70
+
| 0x74
 
| 0x30
 
| 0x30
 
| Identity matrix ? (4x3)
 
| Identity matrix ? (4x3)
Line 298: Line 845:     
CANMs are used to store skeletal animation data.
 
CANMs are used to store skeletal animation data.
 +
 +
== Tools ==
 +
* Every File Explorer
 +
* Ohana3DS and its forks
 +
* SPICA
 +
 +
== Links ==
 +
* Another CGFX Format Description (Archived Page): [https://web.archive.org/web/20150511211029/http://florian.nouwt.com/wiki/index.php/CGFX_(File_Format) http://florian.nouwt.com/wiki/index.php/CGFX_(File_Format)]
 +
 +
[[Category:File formats]]
2

edits

Navigation menu