Geometry (Donkey Kong Country Returns): Difference between revisions
>Aruki (Created page with "The format for ''geometry'' in Donkey Kong Country Returns appears in the CMDL and MREA formats. __TOC__ ==...") |
>Aruki No edit summary |
||
Line 3: | Line 3: | ||
__TOC__ | __TOC__ | ||
== Geometry == | |||
An important thing to note off the bat is that both CMDL and MREA files are split up into a number of 32-byte-aligned ''sections''; their respective headers both declare a section count, and list the sizes of each section contained in the file. This is required to navigate to different parts of the file, and is required in order to read the geometry data correctly. Sections are generally split based on the type of data contained in them, so one section might contain vertex coordinates, while another contains a surface (submesh) definition. For the purposes of this article, each subheader will mark the start of a new section; use that as your cue to advance to the next one. Check the [[CMDL (Donkey Kong Country Returns)|CMDL]] or [[MREA (Metroid Prime 3)|MREA]] pages for more info on how the sections work. | An important thing to note off the bat is that both CMDL and MREA files are split up into a number of 32-byte-aligned ''sections''; their respective headers both declare a section count, and list the sizes of each section contained in the file. This is required to navigate to different parts of the file, and is required in order to read the geometry data correctly. Sections are generally split based on the type of data contained in them, so one section might contain vertex coordinates, while another contains a surface (submesh) definition. For the purposes of this article, each subheader will mark the start of a new section; use that as your cue to advance to the next one. Check the [[CMDL (Donkey Kong Country Returns)|CMDL]] or [[MREA (Metroid Prime 3)|MREA]] pages for more info on how the sections work. | ||
Line 11: | Line 11: | ||
For vertex attributes, note that there's no count value present anywhere. If you want a rough count, you can divide the size of that attribute's section by the attribute's size; this approach doesn't account for padding, however. | For vertex attributes, note that there's no count value present anywhere. If you want a rough count, you can divide the size of that attribute's section by the attribute's size; this approach doesn't account for padding, however. | ||
=== Vertex Coordinates === | |||
Vertex coords can be stored as either floats or signed shorts, depending whether flag 0x20 is set in the header. If they're shorts, then they need to be divided by 0x2000 to get the corresponding float value. Since they're signed numbers, that means that 0 to 0x7FFF correspond to the range 0.0-4.0, and 0x8000 to 0xFFFF correspond to the range -4.0-0.0. | Vertex coords can be stored as either floats or signed shorts, depending whether flag 0x20 is set in the header. If they're shorts, then they need to be divided by 0x2000 to get the corresponding float value. Since they're signed numbers, that means that 0 to 0x7FFF correspond to the range 0.0-4.0, and 0x8000 to 0xFFFF correspond to the range -4.0-0.0. | ||
=== Normals === | |||
Vertex normals are usually stored as shorts. To get the corresponding float value, read as a signed short and divide by 0x4000. | Vertex normals are usually stored as shorts. To get the corresponding float value, read as a signed short and divide by 0x4000. | ||
=== Vertex Color === | |||
Normally unused, so this section is typically empty and zeroed out. | Normally unused, so this section is typically empty and zeroed out. | ||
=== Float UV Coordinates === | |||
These are stored as a sequence of two floats. | These are stored as a sequence of two floats. | ||
=== Short UV Coordinates === | |||
Like the short vertex coordinates, these are stored as signed shorts that should be divided by 0x2000 to get the corresponding float value. The short UVs section has received a fairly significant increase in usage in DKCR compared to the Prime series; in the Prime games, they were generally only used for lightmaps, whereas in DKCR they're often used by pretty much anything. | Like the short vertex coordinates, these are stored as signed shorts that should be divided by 0x2000 to get the corresponding float value. The short UVs section has received a fairly significant increase in usage in DKCR compared to the Prime series; in the Prime games, they were generally only used for lightmaps, whereas in DKCR they're often used by pretty much anything. | ||
=== Surface Definitions === | |||
This section is very small and simple; it simply declares a surface count and then lists the offsets to the end of each surface. Following this section, there'll be one additional section per surface. | This section is very small and simple; it simply declares a surface count and then lists the offsets to the end of each surface. Following this section, there'll be one additional section per surface. | ||
Line 54: | Line 54: | ||
|} | |} | ||
=== Surface === | |||
There will be one of these sections per surface. Each surface starts with a small 32-byte header; after that, the primitive data begins. | There will be one of these sections per surface. Each surface starts with a small 32-byte header; after that, the primitive data begins. |
Revision as of 02:56, 24 May 2016
The format for geometry in Donkey Kong Country Returns appears in the CMDL and MREA formats.
Geometry
An important thing to note off the bat is that both CMDL and MREA files are split up into a number of 32-byte-aligned sections; their respective headers both declare a section count, and list the sizes of each section contained in the file. This is required to navigate to different parts of the file, and is required in order to read the geometry data correctly. Sections are generally split based on the type of data contained in them, so one section might contain vertex coordinates, while another contains a surface (submesh) definition. For the purposes of this article, each subheader will mark the start of a new section; use that as your cue to advance to the next one. Check the CMDL or MREA pages for more info on how the sections work.
All data sections appear in the order that they're listed on this page.
For vertex attributes, note that there's no count value present anywhere. If you want a rough count, you can divide the size of that attribute's section by the attribute's size; this approach doesn't account for padding, however.
Vertex Coordinates
Vertex coords can be stored as either floats or signed shorts, depending whether flag 0x20 is set in the header. If they're shorts, then they need to be divided by 0x2000 to get the corresponding float value. Since they're signed numbers, that means that 0 to 0x7FFF correspond to the range 0.0-4.0, and 0x8000 to 0xFFFF correspond to the range -4.0-0.0.
Normals
Vertex normals are usually stored as shorts. To get the corresponding float value, read as a signed short and divide by 0x4000.
Vertex Color
Normally unused, so this section is typically empty and zeroed out.
Float UV Coordinates
These are stored as a sequence of two floats.
Short UV Coordinates
Like the short vertex coordinates, these are stored as signed shorts that should be divided by 0x2000 to get the corresponding float value. The short UVs section has received a fairly significant increase in usage in DKCR compared to the Prime series; in the Prime games, they were generally only used for lightmaps, whereas in DKCR they're often used by pretty much anything.
Surface Definitions
This section is very small and simple; it simply declares a surface count and then lists the offsets to the end of each surface. Following this section, there'll be one additional section per surface.
Type | Count | Name | Notes |
---|---|---|---|
u32 | 1 | Surface Count | |
u32 | Surface Count | Surface Offsets | Relative to the start of the first surface. |
Surface sections begin |
Surface
There will be one of these sections per surface. Each surface starts with a small 32-byte header; after that, the primitive data begins.
Offset | Type | Count | Name | Notes |
---|---|---|---|---|
0x0 | float | 3 | Center Point | Unknown purpose |
0xC | u16 | 1 | Mantissa | Always 0x8000 |
0xE | u16 | 1 | Primitive Table Size | This value is not reliable in the Metroid Prime series, so you probably shouldn't rely on it in DKCR either. |
0x10 | u32 | 1 | Unknown | Always 0?}} |
0x14 | u32 | 1 | Unknown | Always 0? |
0x18 | u16 | 1 | Unknown | Value varies, but is sometimes 0xFFFF |
0x1A | u16 | 1 | Material Index | |
0x1C | u8 | 1 | Unknown | Always 0xFF? |
0x1D | u8 | 1 | Visibility Group Index | |
0x1E | u16 | 1 | UV Array Index | If 0, this surface uses the float UVs array; if 1, this surface uses the short UVs array |
0x20 | End of surface header; primitive data starts |
The primitive data is a standard GX display list. Each primitive begins with a byte that contains the primitive type in the upper 5 bits, and the vertex format setting in the lower 3. After that is a 16-bit vertex count, followed by a series of 16-bit vertex attribute indices.
You'll need to check some settings on the material to read the primitive data properly; the material determines which vertex attributes are present.
There is no primitive count value; you'll need to continue reading data until you hit the end of the primitive table. There are a couple values you can use for reference; either the surface section size, or the surface's end offset. It's not recommended to use the primitive table size value because that value has been shown to be inaccurate in some cases in the Prime series and this may be the case in DKCR as well.
There are 7 primitive types supported by GX, indicated in the upper 5 bits of the flag value. Note that the game only ever actually uses triangles, triangle strips, and triangle fans; however, all of these primitives are supported by GX and are therefore supported by the game, and so they could be used in custom model files.
Value | Primitive |
---|---|
0x80 | Quads |
0x90 | Triangles |
0x98 | Triangle Strip |
0xA0 | Triangle Fan |
0xA8 | Lines |
0xB0 | Line Strip |
0xB8 | Points |