Difference between revisions of "CMDL (Tropical Freeze)"

From Retro Modding Wiki
Jump to: navigation, search
(Unfinished. Saving as a WIP.)
 
Line 120: Line 120:
  
 
The VBUF section defines vertex buffers; each buffer can have different vertex types, with different strides and attributes.
 
The VBUF section defines vertex buffers; each buffer can have different vertex types, with different strides and attributes.
 +
 +
==== Header ====
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 135: Line 137:
 
|-
 
|-
 
| 0x1C
 
| 0x1C
−
| colspan=2 | End of MESH header
+
| colspan=2 | End of VBUF header
 
|}
 
|}
 +
 +
==== Vertex Buffer ====
  
 
{|class="wikitable"
 
{|class="wikitable"
Line 143: Line 147:
 
! Description
 
! Description
 
|-
 
|-
−
|  
+
| 0x0
 +
| 4
 +
| '''Vertex count'''
 +
|-
 +
| 0x4
 +
| 4
 +
| '''Attrib count''' (AC)
 +
|-
 +
| 0x8
 +
| 0x14 × AC
 +
| '''Vertex attributes'''
 +
|-
 +
| colspan=3 | End of vertex buffer
 
|}
 
|}
 +
 +
==== Vertex Attribute ====
 +
 +
{|class="wikitable"
 +
! Offset
 +
! Size
 +
! Description
 +
|-
 +
| 0x0
 +
| 4
 +
| Unknown
 +
|-
 +
| 0x4
 +
| 4
 +
| '''Offset'''
 +
|-
 +
| 0x8
 +
| 4
 +
| '''Stride'''
 +
|-
 +
| 0xC
 +
| 4
 +
| Unknown
 +
|-
 +
| 0x10
 +
| 4
 +
| Unknown (likely attrib type/format)
 +
|-
 +
| 0x14
 +
| colspan=2 | End of attribute
 +
|}
 +
 +
=== IBUF ===
 +
 +
Just like how the VBUF section defines vertex buffers, the IBUF section defines index buffers. Each index buffer only has one value associated with it, so it's fairly simple, and you generally will only see one or two index buffers per file.
 +
 +
==== Header ====
 +
 +
{| class="wikitable"
 +
! Offset
 +
! Size
 +
! Description
 +
|-
 +
| 0x0
 +
| 24
 +
| '''"IBUF" [[Section Header (Tropical Freeze)|section header]]
 +
|-
 +
| 0x18
 +
| 4
 +
| Index buffer count
 +
|-
 +
| 0x1C
 +
| colspan=2 | End of IBUF header
 +
|}
 +
 +
==== Index Buffer ====
 +
 +
{| class="wikitable"
 +
! Offset
 +
! Size
 +
! Description
 +
|-
 +
| 0x0
 +
| 4
 +
| '''Format''' (1 means unsigned short; 2 means unsigned long)
 +
|-
 +
| 0x4
 +
| colspan=2 | End of index buffer
 +
|}
 +
 +
=== GPU ===
 +
 +
The GPU section contains raw buffer data that's fed to the GPU. It's essentially just a giant blob with all the vertex and index buffers laid out next to each other. The tricky part is, all the buffer data is LZSS-compressed, and not only is the metadata required to decompress it is stored in the pak, rather than in the model files themselves, but that metadata is also the only way to distinguish the different buffers from each other (especially the index buffers, since they have no count value you can use to calculate the size of the buffer).
 +
 +
As such, this section can't be read correctly if the model file is unpacked and completely left as-is; it needs to be either read directly from the pak, or the metadata needs to be included in the file in some way. A good unpacker should append the metadata to the end of the file.
 +
 +
Note: Page explaining the compression algorithm and how to decompress it is coming soon.
 +
 +
== PAK Metadata ==
 +
 +
The pak metadata for the model formats contains mainly information related to the size and layout of the GPU section, and the metadata required to locate and decompress specific buffers within it.
 +
 +
{| class="wikitable"
 +
! Offset
 +
! Size
 +
! Description
 +
|-
 +
| 0x0
 +
| 4
 +
| Unknown; always 4?
 +
|-
 +
| 0x4
 +
| 4
 +
| '''GPU section offset'''
 +
|-
 +
| 0x8
 +
| 4
 +
| '''GPU chunk count''' (CC)
 +
|-
 +
| 0x8
 +
| 8 × CC
 +
| '''GPU chunk definitions'''
 +
|-
 +
| -
 +
| 4
 +
| '''Compressed vertex buffer count''' (VC)
 +
|-
 +
| -
 +
| 0x10 × VC
 +
| '''Vertex buffer definitions'''
 +
|-
 +
| -
 +
| 4
 +
| '''Compressed index buffer count''' (IC)
 +
|-
 +
| -
 +
| 0x10 × IC
 +
| '''Index buffer definitions'''
 +
|-
 +
| colspan = 3 | End of pak metadata
 +
|}
 +
 +
=== GPU Chunk ===
 +
 +
For large models, the GPU section might be split up into multiple chunks, rather than read as one data buffer; all offsets into the GPU section will be relative to the start of the chosen chunk.
 +
 +
{| class="wikitable"
 +
! Offset
 +
! Size
 +
! Description
 +
|-
 +
| 0x0
 +
| 4
 +
| '''Size'''
 +
|-
 +
| 0x4
 +
| 4
 +
| '''Offset'''
 +
|-
 +
| 0x8
 +
| colspan=2 | End of GPU chunk definition
 +
|}
 +
 +
=== Compressed Buffer ===
 +
 +
The format for compressed buffer definitions is the same regardless of buffer type (vertex/index).
 +
 +
{| class="wikitable"
 +
! Offset
 +
! Size
 +
! Description
 +
|-
 +
| 0x0
 +
| 4
 +
| '''GPU chunk index'''
 +
|-
 +
| 0x4
 +
| 4
 +
| '''Start offset''' (relative to the start of the chosen GPU chunk)
 +
|-
 +
| 0x8
 +
| 4
 +
| '''Compressed size'''
 +
|-
 +
| 0xC
 +
| 4
 +
| '''Decompressed size'''
 +
|-
 +
| 0x10
 +
| colspan=2 | End of compressed buffer definition
 +
|}
 +
 +
[[Category:File Formats]]
 +
[[Category:Donkey Kong Country: Tropical Freeze]]

Revision as of 05:34, 24 January 2015

The CMDL, SMDL, and WMDL format are Tropical Freeze's three model formats. All three are the same basic format, with SMDL and WMDL each containing an extra data section at the start of the file. With the Wii U's graphics system being updated from GX to GX2, the Retro model format has been dramatically overhauled, bearing little to no resemblance to the previous CMDL format found in DKCR and the Prime series.

Format

After the RFRM Header, the first section of the file is SKHD in SMDL, and WDHD in WMDL. Following those extra sections, all three formats start with a header.

HEAD

Offset Size Description
0x0 24 "HEAD" section header
0x18 4 Unknown
0x1C 4 Unknown
0x20 4 Unknown
0x24 4 Unknown
0x28 4 Unknown
0x2C 24 Axis-aligned bounding box
0x30 4 Extra data flag

If the ending flag is 1, then a large chunk of extra data follows before the next section begins; otherwise, the HEAD section ends.

MTRL

Materials. To do.

MESH

The MESH section does what the name suggests: it defines submeshes. The MESH section header is as follows:

Offset Size Description
0x0 24 "HEAD" section header
0x18 4 Submesh count
0x1C End of MESH header

Each submesh definition is structured as follows:

Offset Size Description
0x0 4 Unknown; always 3?
0x4 2 Material ID
0x6 1 Vertex buffer ID
0x7 1 Index buffer ID
0x8 4 Start index
0xC 4 Index count
0x10 4 Unknown
0x14 1 Unknown; usually seems to be either 0 or 1, possibly a bool value
0x15 End of submesh definition

VBUF

The VBUF section defines vertex buffers; each buffer can have different vertex types, with different strides and attributes.

Header

Offset Size Description
0x0 24 "VBUF" section header
0x18 4 Vertex buffer count
0x1C End of VBUF header

Vertex Buffer

Offset Size Description
0x0 4 Vertex count
0x4 4 Attrib count (AC)
0x8 0x14 × AC Vertex attributes
End of vertex buffer

Vertex Attribute

Offset Size Description
0x0 4 Unknown
0x4 4 Offset
0x8 4 Stride
0xC 4 Unknown
0x10 4 Unknown (likely attrib type/format)
0x14 End of attribute

IBUF

Just like how the VBUF section defines vertex buffers, the IBUF section defines index buffers. Each index buffer only has one value associated with it, so it's fairly simple, and you generally will only see one or two index buffers per file.

Header

Offset Size Description
0x0 24 "IBUF" section header
0x18 4 Index buffer count
0x1C End of IBUF header

Index Buffer

Offset Size Description
0x0 4 Format (1 means unsigned short; 2 means unsigned long)
0x4 End of index buffer

GPU

The GPU section contains raw buffer data that's fed to the GPU. It's essentially just a giant blob with all the vertex and index buffers laid out next to each other. The tricky part is, all the buffer data is LZSS-compressed, and not only is the metadata required to decompress it is stored in the pak, rather than in the model files themselves, but that metadata is also the only way to distinguish the different buffers from each other (especially the index buffers, since they have no count value you can use to calculate the size of the buffer).

As such, this section can't be read correctly if the model file is unpacked and completely left as-is; it needs to be either read directly from the pak, or the metadata needs to be included in the file in some way. A good unpacker should append the metadata to the end of the file.

Note: Page explaining the compression algorithm and how to decompress it is coming soon.

PAK Metadata

The pak metadata for the model formats contains mainly information related to the size and layout of the GPU section, and the metadata required to locate and decompress specific buffers within it.

Offset Size Description
0x0 4 Unknown; always 4?
0x4 4 GPU section offset
0x8 4 GPU chunk count (CC)
0x8 8 × CC GPU chunk definitions
- 4 Compressed vertex buffer count (VC)
- 0x10 × VC Vertex buffer definitions
- 4 Compressed index buffer count (IC)
- 0x10 × IC Index buffer definitions
End of pak metadata

GPU Chunk

For large models, the GPU section might be split up into multiple chunks, rather than read as one data buffer; all offsets into the GPU section will be relative to the start of the chosen chunk.

Offset Size Description
0x0 4 Size
0x4 4 Offset
0x8 End of GPU chunk definition

Compressed Buffer

The format for compressed buffer definitions is the same regardless of buffer type (vertex/index).

Offset Size Description
0x0 4 GPU chunk index
0x4 4 Start offset (relative to the start of the chosen GPU chunk)
0x8 4 Compressed size
0xC 4 Decompressed size
0x10 End of compressed buffer definition
Retrieved from "http://www.metroid2002.com/retromodding/index.php?title=CMDL_(Tropical_Freeze)&oldid=84"