Difference between revisions of "MREA (Metroid Prime)"

From Retro Modding Wiki
Jump to: navigation, search
m (→‎Geometry)
Line 76: Line 76:
 
|}
 
|}
  
−
=== Geometry ===
+
=== Data Sections ===
 +
 
 +
MREA data sections are in the file in the following order:
 +
 
 +
{| class="wikitable"
 +
! Identifier
 +
! Name
 +
|-
 +
| {{none}}
 +
| [[#Geometry|Geometry]]
 +
|-
 +
| <code>AROT</code>
 +
| [[#Area Octree|Area Octree]]
 +
|-
 +
| <code>SCLY</code>
 +
| [[#Script Layers|Script Layers]]
 +
|-
 +
| <code>0xDEAFBABE</code>
 +
| [[#Collision|Collision]]
 +
|-
 +
| {{none}}
 +
| {{unknown|Unknown}}
 +
|-
 +
| <code>0xBABEDEAD</code>
 +
| [[#Lights|Lights]]
 +
|-
 +
| <code>VISI</code>
 +
| [[#Visibility Tree|Visibility Tree]]
 +
|-
 +
| {{none}}
 +
| [[#Path|Path]]
 +
|}
 +
 
 +
==== Geometry ====
  
 
''See [[Materials (Metroid Prime)]] and [[Geometry (Metroid Prime)]]''
 
''See [[Materials (Metroid Prime)]] and [[Geometry (Metroid Prime)]]''
Line 108: Line 141:
 
|}
 
|}
  
−
==== Visor Flags ====
+
===== Visor Flags =====
  
 
{| class="wikitable"
 
{| class="wikitable"
Line 139: Line 172:
 
|}
 
|}
  
−
=== AROT ===
+
==== Area Octree ====
  
 
{{main|AROT (MREA Section)}}
 
{{main|AROT (MREA Section)}}
Line 145: Line 178:
 
The AROT section stores the area's octree, accelerating back-to-front rendering of contained meshes, it is also used for spacial queries such as collision.
 
The AROT section stores the area's octree, accelerating back-to-front rendering of contained meshes, it is also used for spacial queries such as collision.
  
−
=== SCLY ===
+
==== Script Layers ====
  
 
{{todo|SCLY is definitely complicated enough to need its own article.}}
 
{{todo|SCLY is definitely complicated enough to need its own article.}}
Line 151: Line 184:
 
The SCLY section contains data for objects.
 
The SCLY section contains data for objects.
  
−
=== Collision ===
+
==== Collision ====
  
 
{{todo|Collision needs a separate article because it shares so many similarities with DCLN. How should we document the parts where the format diverges, though?}}
 
{{todo|Collision needs a separate article because it shares so many similarities with DCLN. How should we document the parts where the format diverges, though?}}
Line 157: Line 190:
 
You have three guesses what the collision section is for, and the first two don't count.
 
You have three guesses what the collision section is for, and the first two don't count.
  
−
=== Unknown Section ===
+
==== Unknown Section ====
  
 
This one is sandwiched between collision and lights, and usually just contains a single 32-bit "1". Purpose is unknown.
 
This one is sandwiched between collision and lights, and usually just contains a single 32-bit "1". Purpose is unknown.
  
−
=== Lights ===
+
==== Lights ====
  
 
This section is for dynamic lights, see the [[Lights_(Metroid_Prime)|Light]] article for details.
 
This section is for dynamic lights, see the [[Lights_(Metroid_Prime)|Light]] article for details.
  
−
=== Visibility Tree ===
+
==== Visibility Tree ====
  
 
This section is labeled "VISI". This section is sometimes not actually present in the file, labeled with a size of 0.
 
This section is labeled "VISI". This section is sometimes not actually present in the file, labeled with a size of 0.
  
−
=== Path ===
+
==== Path ====
  
 
This is the final section in the file; it's always 0x20 bytes, and its only value is a single [[PATH (File Format)|PATH]] file ID.
 
This is the final section in the file; it's always 0x20 bytes, and its only value is a single [[PATH (File Format)|PATH]] file ID.

Revision as of 19:45, 22 May 2016

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.


GravitySuitIcon.png 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.
Morphball wirerender.png This file format needs more research
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

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

Data Sections

MREA data sections are in the file in the following order:

Identifier Name
Geometry
AROT Area Octree
SCLY Script Layers
0xDEAFBABE Collision
Unknown
0xBABEDEAD Lights
VISI Visibility Tree
Path

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. 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 vertex 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.
  • Surfaces will usually have a bounding box in the extra data in the surface header. This bounding box is used for depth sorting.
  • Each mesh starts with an extra header section which is formatted like this:
Offset Size Description
0x0 4 Visor Flags
0x4 4 × 12 Transform matrix
0x34 4 × 6 Axis-aligned bounding box
0x4C End of mesh header section
Visor Flags
Bit Hex Description
0 0x1 Unknown
1 0x2 Disable rendering in Combat/Scan Visor
2 0x4 Disable rendering in Thermal Visor
3 0x8 Disable rendering in X-Ray Visor
4-5 0x30 Thermal heat level.
  • 0 - Cool
  • 1 - Hot
  • 2 - Warm

Area Octree

Main article: AROT (MREA Section)

The AROT section stores the area's octree, accelerating back-to-front rendering of contained meshes, it is also used for spacial queries such as collision.

Script Layers

GravitySuitIcon.png To do:
SCLY is definitely complicated enough to need its own article.

The SCLY section contains data for objects.

Collision

GravitySuitIcon.png 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

Retrieved from "http://www.metroid2002.com/retromodding/index.php?title=MREA_(Metroid_Prime)&oldid=1468"