Difference between revisions of "MREA (Metroid Prime)"
m (→Geometry) |
m ({{research}}) |
||
| Line 4: | Line 4: | ||
{{todo|There's a LOT of sections that are mostly known, but need some documentation written up. SCLY and collision need separate articles (although the unique parts of the collision format, like the octree, could maybe be documented here). The rest should probably stay on this page.}} | {{todo|There's a LOT of sections that are mostly known, but need some documentation written up. SCLY and collision need separate articles (although the unique parts of the collision format, like the octree, could maybe be documented here). The rest should probably stay on this page.}} | ||
| − | {{ | + | {{research|2|The AROT section is largely unknown, there's a lot of unknowns in the lights section, and we don't know what the unknown/empty sections are for. That's not even touching on how much is unknown in SCLY.}} |
== Format == | == Format == | ||
Revision as of 09:02, 14 March 2015
See MREA (File Format) for the other revisions of this format.
The MREA format defines areas (rooms) in Metroid Prime. It's a massive format that contains tons of different data, including terrain geometry, collision, objects, lights, and more.
|
To do: There's a LOT of sections that are mostly known, but need some documentation written up. SCLY and collision need separate articles (although the unique parts of the collision format, like the octree, could maybe be documented here). The rest should probably stay on this page. |
|
This file format needs more research The AROT section is largely unknown, there's a lot of unknowns in the lights section, and we don't know what the unknown/empty sections are for. That's not even touching on how much is unknown in SCLY. |
Contents
Format
Like CMDL, 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
| Offset | Size | Description |
|---|---|---|
| 0x0 | 4 | Magic; always 0xDEADBEEF |
| 0x4 | 4 | Version; see hub article |
| 0x8 | 4 × 12 | Transform matrix |
| 0x38 | 4 | Mesh count |
| 0x3C | 4 | Section count (SC) |
| 0x40 | 4 | Geometry section number (starts on materials) |
| 0x44 | 4 | SCLY section number |
| 0x48 | 4 | Collision section number |
| 0x4C | 4 | Unknown section number |
| 0x50 | 4 | Light section number |
| 0x54 | 4 | VISI section number |
| 0x58 | 4 | PATH section number |
| 0x5C | 4 | AROT section number |
| 0x60 | 4 × SC | Section sizes |
| End of header; pad to 32 bytes before first section begins | ||
Geometry
See Materials (Metroid Prime) and Geometry (Metroid Prime)
MREA files have one material section, followed by a number of meshes, each of which has its own set of geometry sections. Each mesh starts with an extra header section which is formatted like this:
| Offset | Size | Description |
|---|---|---|
| 0x0 | 4 | Unknown (flags?) |
| 0x4 | 4 × 12 | Transform matrix |
| 0x34 | 4 × 6 | Axis-aligned bounding box |
| 0x4C | End of mesh header section | |
There's couple small differences you'll usually see on MREA meshes compared to CMDL ones:
- Normals are always shorts, so vertex format 0 is never used.
- Most MREA meshes use lightmaps, so normally the first UV coordinate on each texture will read from the short UV array. This isn't always the case, though; you need to make sure you check the material so you know where to read from.
- Submeshes will usually have a bounding box in the extra data in the submesh header. This bounding box is used for depth sorting.
AROT
The AROT section operates on terrain geometry; it's used to implement things like projectile collision with terrain. It's mostly unknown.
SCLY
|
|
To do: SCLY is definitely complicated enough to need its own article. |
The SCLY section contains data for objects.
Collision
|
|
To do: Collision needs a separate article because it shares so many similarities with DCLN. How should we document the parts where the format diverges, though? |
You have three guesses what the collision section is for, and the first two don't count.
Unknown Section
This one is sandwiched between collision and lights, and usually just contains a single 32-bit "1". Purpose is unknown.
Lights
This section is for dynamic lights, see the Light article for details.
Visibility Tree
This section is labeled "VISI". This section is sometimes not actually present in the file, labeled with a size of 0.
Path
This is the final section in the file; it's always 0x20 bytes, and its only value is a single PATH file ID.
Tools
- Parax's MREA maxscript can import MREA terrain geometry into 3DS Max.
