Difference between revisions of "MREA (Metroid Prime 3)"
m (→Section Numbers) |
m (→Header) |
||
Line 69: | Line 69: | ||
| u32[SC] | | u32[SC] | ||
| - | | - | ||
− | | '''Section | + | | '''Section sizes''' |
|- | |- | ||
| colspan=4 {{unknown|End of main header data; pad to 32 bytes before compressed section definitions}} | | colspan=4 {{unknown|End of main header data; pad to 32 bytes before compressed section definitions}} |
Revision as of 09:13, 19 May 2015
See MREA (File Format) for the other revisions of this format.
The MREA format, which defines areas/levels, received another large layout overhaul in Metroid Prime 3. The level geometry data received the biggest update, with a new material format, lot of things being moved around, and a few entirely new sections being introduced. This article covers Metroid Prime 3, the MP3 E3 prototype, and Donkey Kong Country Returns.
This file format needs more research There are a few sections we know nothing about. |
Contents
Format
MREA 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
The header is identical between MP3 and DKCR.
Offset | Type | Size | Description |
---|---|---|---|
0x0 | u32 | 4 | Magic Number; always 0xDEADBEEF |
0x4 | u32 | 4 | Version; see hub article |
0x8 | float[12] | 48 | Transform matrix (transform of the area in world space) |
0x38 | u32 | 4 | Mesh count |
0x3C | u32 | 4 | Layer count |
0x40 | u32 | 4 | Section count (SC) |
0x44 | u32 | 4 | Compressed block count |
0x48 | u32 | 4 | Section number count |
0x4C | u32[5] | 0x14 | Padding |
0x60 | u32[SC] | - | Section sizes |
End of main header data; pad to 32 bytes before compressed section definitions |
Compressed Blocks
Compressed blocks are defined in the same manner as Metroid Prime 2. The MREA format contains compressed blocks that can each contain a number of regular file sections within them. These blocks are compressed using segmented LZO1X-999 in Metroid Prime 3, and segmented zlib in Donkey Kong Country Returns. Compressed blocks are padded to 32 bytes, but their padding is located at the beginning of the block rather than the end, so it's required to account for the padding before you start decompressing. The compressed data is segmented, which means there's multiple segments of data that are compressed/decompressed separately. Each segment starts with a 16-bit size value. The size value is signed; a negative value indicates the segment is not compressed (this is done when compressing a segment doesn't reduce its size). Each segment is 0x4000 bytes large when decompressed (except the last one).
Compressed blocks are defined after the main header. After reading them, pad to 32 bytes before the section numbers portion of the header starts.
Offset | Type | Size | Description |
---|---|---|---|
0x0 | u32 | 4 | Buffer size (0x120 bytes larger than uncompressed size - same as uncompressed size for uncompressed blocks) |
0x4 | u32 | 4 | Uncompressed size |
0x8 | u32 | 4 | Compressed size (if 0, that indicates an uncompressed block) |
0xC | u32 | 4 | Section count (the number of regular sections contained in this block) |
0x10 | Block definition end |
Section Numbers
The section numbers portion of the header indicates the index of each major data chunk. Some of these chunks contain multiple sections; in that case the number will point to the first section of the chunk. Each number is a short 8-byte struct:
Offset | Type | Size | Description |
---|---|---|---|
0x0 | char[4] | 4 | Section type |
0x4 | u32 | 4 | Section number |
Here are all the possible section numbers and what they are:
FourCC | Description |
---|---|
AABB | Axis Aligned Bounding Boxes |
APTL | PTLA file |
COLI | Collision |
DEPS | Dependencies |
EGMC | EGMC file |
GPUD | GPU Data (level geometry) |
LITE | Lights |
LLTE | Unknown |
PFL2 | PATH file |
PVS! | Probable Visibility Set |
ROCT | Area Octree (AROT) |
RSOS | RSO file list (Revolution Shared Object) |
SGEN | Script Generator layer (SCGN) |
SOBJ | Script Object layers (SCLY) |
WOBJ | World Object; always 0, points to the materials section |
Materials
Materials are identical to those found in CMDL files.
Mesh Headers
The WOBJ sections are unique: they don't have a valid section number, and are always set to 0, however they are always in the sections immediately following the Materials, simply iterate through the mesh count and read the following structs:
Main Header
Type | Description | Notes |
---|---|---|
long | Unknown | Most likely visor flags in MP3, unknown use and DKCR |
CTransform4f | Transformation Matrix | Meshes location in world space |
CAABox | Bounding Box | Likely used for Depth sorting as in previous games. |
Submesh Offsets
Type | Description | Notes |
---|---|---|
long (SC) | Submesh count | |
long | Submesh Offsets[SC] | Relative to the start first submesh, (i.e, the first offset points the the end of the first submesh) |
Following the submesh data are two unknown sections, they both seem to be arrays of flags or indices but nothing is known about them.
AROT
Following the WOBJ sections is usually AROT. AROT is a BSP Tree that appears to be used for shot-collision and possibly depth sorting, nothing is known about how to handle this section.
AABB
The AABB section is exactly what it sounds like, it's an array of Axis-Aligned Bounding Boxes, assembling a BVH tree. AABB starts with the number of bounding boxes with each one consisting of the following struct:
Type | Description | Notes |
---|---|---|
CAABox | Axis Aligned Bounding Box | Used to assist depth sorting, and/or collision |
long | Unknown | The first entry in the table always covers the entire, with this value always being -1 |
short | Self Index | 1 indexed position of this particular AABB entry, but ONLY if the previous value is -1. |
short | Self Index | 1 indexed position of this particular AABB entry, but ONLY if the previous value is -1. |
GPU Description Section (GPUD)
The GPUD section is a bit confusing at first glance, however it's really no different from the previous MREA version in terms of ordering. There is also one GPUD per WOBJ section
The section order is as follows:
Vertices
The vertices are always 32bit floats, even in DKCR
Normals
The normals are always 32bit floats.
Colors
Usually 0 filled and completely unused, it's stored in MREA simply for completeness.
Float Texcoords
Metroid Prime 3 uses these exclusively, even for lightmaps, which simplifies UV handling quite a bit.
Short Texcoords
This is only used in DKCR and can be used for anything, not just for lightmaps
Submeshes
The submesh format is exactly the same as the Geometry formats found in Metroid Prime 3 and DKCR.