CMDL (Donkey Kong Country Returns)
See CMDL (File Format) for the other revisions of this format.
The CMDL format is DKCR's model format. It's similar to the CMDL format found in the Metroid Prime trilogy, but with a lot of additions and changes, and some layout changes.
|
To do: WIP, will finish soon |
|
This file format needs more research Where to begin? Materials need a lot of research (they're very similar if not the same as Metroid Prime 3). A lot of the visibility group data is unknown. The submesh headers contain a lot of unknowns, and the possible vertex format settings are unknown. Geometry should be split off into a separate article if it's confirmed that it's the same format that's used in MREA (which is fairly likely). Materials should also be split off once more is known about them. |
Format
Like the previous CMDL formats, DKCR CMDL files are split up into a number of 32-byte aligned sections. Every section both starts and ends on a 32-byte boundary. These are used to separate different parts of the file; different types of sections typically indicate different sets of data. The header declares the section count and the size of each one; using these is the only way to navigate the file.
Header
| Offset | Type | Size | Description |
|---|---|---|---|
| 0x0 | u32 | 4 | Unknown; always 0x9381000A - likely either magic value or 16-bit magic/version |
| 0x4 | u32 | 4 | Flags; see blow |
| 0x8 | float[6] | 0x18 | Model Bounding Box |
| 0x20 | u32 | 4 | Section count (SC) |
| 0x24 | u32 | 4 | Material set count |
| 0x28 | - | - | Visibility group data; present if flag 0x10 is set. See below for structure. |
| - | u32[] | 4 × SC | Section sizes |
| End of header; pad to multiple of 32 before first section starts | |||
Flags
The following flags are possible:
| Bit | Hex | Description |
|---|---|---|
| 0 | 0x1 | Unknown |
| 1 | 0x2 | Unknown |
| 2 | 0x4 | Unknown |
| 3 | 0x8 | Unknown |
| 4 | 0x10 | Enable visibility groups |
| 5 | 0x20 | Store vertex positions as shorts |
Visibility Groups
This section is present in the header if bit 0x10 is set, after the material set count and before the section sizes.
| Offset | Type | Size | Description |
|---|---|---|---|
| 0x0 | u32 | 4 | Unknown |
| 0x4 | u32 | 4 | Visibility Group count |
The following structure repeats for each group:
| Offset | Type | Size | Description |
|---|---|---|---|
| 0x0 | u32 | 4 | Name length |
| 0x4 | string | - | Visibility Group name |
Finally, it ends with this before the sizes begin:
| Offset | Type | Size | Description |
|---|---|---|---|
| 0x0 | u32 | 4 | Unknown |
| 0x4 | u32 | 4 | Unknown |
| 0x8 | u32 | 4 | Unknown |
| 0xC | u32 | 4 | Unknown |
| 0x10 | u32 | 4 | Unknown |
Materials
There's not much known about the material format currently; DKCR seems to use the same material format as Metroid Prime 3. The main difference in DKCR compared to Prime 3 is that in Prime 3, each material set would get its own section. In DKCR, every material set is in the same section. Each material set begins with a material count, and each material begins with its own size. The main thing that's needed to read geometry is the vertex attribute flags, which are located at 0xC in the material structure (not counting the size).