MREA (Metroid Prime): Difference between revisions

From Retro Modding Wiki
Jump to navigation Jump to search
>Aruki
imported>Jackoalan
No edit summary
 
(21 intermediate revisions by 4 users not shown)
Line 1: Line 1:
''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.
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.


{{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.}}
{{researchmoderate|reason=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.}}
{{research|minor|Discounting unknowns within the actual data sections, the main thing that still isn't known is what the unknown data section is for.}}


== Format ==
== Format ==


Like [[CMDL (Metroid Prime)|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.
Like [[CMDL (Metroid Prime)|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.
These are the sections that appear in each MREA file, in the order they appear in the file:
{| class="wikitable"
! Identifier
! Name
|-
| {{none}}
| [[#World Geometry|World Geometry]]
|-
| <code>AROT</code>
| [[#Area Octree|Area Octree]]
|-
| <code>SCLY</code>
| [[#Script Layers|Script Layers]]
|-
| <code>0xDEAFBABE</code>
| [[#Collision|Collision]]
|-
| {{none}}
| {{unknown|[[#Unknown Section|Unknown]]}}
|-
| <code>0xBABEDEAD</code>
| [[#Lights|Lights]]
|-
| <code>VISI</code>
| [[#Visibility Tree|Visibility Tree]]
|-
| {{none}}
| [[#Path|Path]]
|}


=== Header ===
=== Header ===
Line 12: Line 45:
{| class="wikitable"
{| class="wikitable"
! Offset
! Offset
! Size
! Type
! Description
! Count
! Name
! Notes
|-
|-
| 0x0
| 0x0
| 4
| u32
| '''Magic'''; always 0xDEADBEEF
| 1
| '''Magic'''
| Always <code>0xDEADBEEF</code>.
|-
|-
| 0x4
| 0x4
| 4
| u32
| '''Version'''; see [[MREA (File Format)|hub article]]
| 1
| '''Version'''
| See [[MREA (File Format)|hub article]] for a list of possible version numbers.
|-
|-
| 0x8
| 0x8
| 4 &times; 12
| float
| '''Transform matrix'''
| 12
| '''Area Transform'''
| Matrix that represents the area's transform from the origin. Most area data is pre-transformed, so this matrix is only used occasionally.
|-
|-
| 0x38
| 0x38
| 4
| u32
| '''Mesh count'''
| 1
| '''World Model Count'''
| Number of world models in this area.
|-
|-
| 0x3C
| 0x3C
| 4
| u32
| '''Section count''' (SC)
| 1
| '''Data Section Count'''
| Number of data sections in the file.
|-
|-
| 0x40
| 0x40
| 4
| u32
| '''Geometry section number''' (starts on materials)
| 1
| '''World Geometry Section'''
| Section index for [[#World Geometry|world geometry data]]. Always 0; starts on materials.
|-
|-
| 0x44
| 0x44
| 4
| u32
| '''SCLY section number'''
| 1
| '''Script Layers Section'''
| Section index for [[#Script Layers|script layer data]].
|-
|-
| 0x48
| 0x48
| 4
| u32
| '''Collision section number'''
| 1
| '''Collision Section'''
| Section index for [[#Collision|collision data]].
|-
|-
| 0x4C
| 0x4C
| 4
| u32
| '''Unknown section number'''
| 1
| '''Unknown Section'''
| Section index for [[#Unknown Section|unknown data]].
|-
|-
| 0x50
| 0x50
| 4
| u32
| '''Lights section number'''
| 1
| '''Lights Section'''
| Section index for [[#Lights|light data]].
|-
|-
| 0x54
| 0x54
| 4
| u32
| '''Empty section number'''
| 1
| '''Visibility Tree Section'''
| Section index for [[#Visibility Tree|visibility tree data]].
|-
|-
| 0x58
| 0x58
| 4
| u32
| '''PATH section number'''
| 1
| '''Path Section'''
| Section index for [[#Path|path data]].
|-
|-
| 0x5C
| 0x5C
| 4
| u32
| '''AROT section number'''
| 1
| '''Area Octree Section'''
| Section index for [[#Area Octree|area octree data]].
|-
|-
| 0x60
| 0x60
| 4 &times; SC
| u32
| '''Section sizes'''
| ''Data Section Count''
| '''Data Section Sizes'''
| Array containing the size of each data section in the file. Every size is always a multiple of 32.
|-
|-
| colspan=3 {{unknown|End of header; pad to 32 bytes before first section begins}}
| colspan=5 {{unknown|End of header; pad to 32 bytes before first data section begins}}
|}
|}


=== Geometry ===
=== World Geometry ===


''See [[Materials (Metroid Prime)]] and [[Geometry (Metroid Prime)]]''
''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:
MREA files have one material section, followed by a number of world models, each of which has its own set of geometry sections. There's couple small differences you'll usually see on world models compared to regular CMDL ones:
 
* Normals are ''always'' shorts, so vertex format 0 is never used.
* Most world models 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 world model starts with an extra header section which is formatted like this:


{| class="wikitable"
{| class="wikitable"
! Offset
! Offset
! Size
! Type
! Description
! Count
! Name
! Notes
|-
|-
| 0x0
| 0x0
| 4
| [[#Visor Flags|Visor Flags]]
| {{unknown|'''Unknown (flags?)'''}}
| 1
| '''Visor Flags'''
| 32-bit bitfield that sets parameters controlling how the mesh renders in different visors.
|-
|-
| 0x4
| 0x4
| 4 &times; 12
| float
| '''Transform matrix'''
| 12
| '''World Model Transform'''
| World model's transform from the area's local origin. The geometry data is pre-transformed, so this matrix can largely be ignored.
|-
|-
| 0x34
| 0x34
| 4 &times; 6
| float
| '''Axis-aligned bounding box'''
| 6
| '''World Model Bounding Box'''
| Pre-transformed axis-aligned bounding box for this model.
|-
|-
| 0x4C
| 0x4C
| colspan=2 {{unknown|End of mesh header section}}
| colspan=4 {{unknown|End of mesh header section}}
|}
|}


There's couple small differences you'll usually see on MREA meshes compared to CMDL ones:
==== Visor Flags ====
 
{| class="wikitable"
! Bit
! Hex
! Description
|-
| 0
| 0x1
| {{unknown|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
|}


* Vertices are ''always'' normals, so vertex format 0 is never used.
=== Area Octree ===
* 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 ===
{{main|AROT (MREA Section)}}


The AROT section operates on terrain geometry; it's used to implement things like projectile collision with terrain. It's mostly unknown.
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|Format known, needs documentation written up.}}


The SCLY section contains data for objects.
The SCLY section contains data for objects.
Line 119: Line 222:
=== 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?}}
''Main article: [[Area Collision (File Format)]]''
 
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. In the Prime 3/DKCR MREA format, this section is labelled <code>LLTE</code>.


=== Lights ===
=== Lights ===


{{todo|Antidote, would you mind writing the structure of this section?}}
This section is for dynamic lights. See the [[Lights_(Metroid_Prime)|Light]] article for details.


This section is for dynamic lights.
=== Visibility Tree ===


=== Empty Section ===
{{main|VISI (MREA Section)}}


This is usually listed with a size of 0. Currently unknown what this actually is.
This section is a PVS octree labeled "VISI". Some areas don't have visibility octrees; in that case this section will be completely empty and listed 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; its only value is a single [[PATH (File Format)|PATH]] file ID.
 
{| class="wikitable"
! Offset
! Type
! Name
|-
| 0x0
| Asset ID
| '''Area PATH Resource'''
|-
| 0x4
| colspan=2 {{unknown|End of section}}
|}


[[Category:File Formats]]
[[Category:File Formats]]
[[Category:Metroid Prime]]
[[Category:Metroid Prime]]

Latest revision as of 05:57, 26 February 2017

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 is almost completely documented
Discounting unknowns within the actual data sections, the main thing that still isn't known is what the unknown data section is for.


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.

These are the sections that appear in each MREA file, in the order they appear in the file:

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

Header

Offset Type Count Name Notes
0x0 u32 1 Magic Always 0xDEADBEEF.
0x4 u32 1 Version See hub article for a list of possible version numbers.
0x8 float 12 Area Transform Matrix that represents the area's transform from the origin. Most area data is pre-transformed, so this matrix is only used occasionally.
0x38 u32 1 World Model Count Number of world models in this area.
0x3C u32 1 Data Section Count Number of data sections in the file.
0x40 u32 1 World Geometry Section Section index for world geometry data. Always 0; starts on materials.
0x44 u32 1 Script Layers Section Section index for script layer data.
0x48 u32 1 Collision Section Section index for collision data.
0x4C u32 1 Unknown Section Section index for unknown data.
0x50 u32 1 Lights Section Section index for light data.
0x54 u32 1 Visibility Tree Section Section index for visibility tree data.
0x58 u32 1 Path Section Section index for path data.
0x5C u32 1 Area Octree Section Section index for area octree data.
0x60 u32 Data Section Count Data Section Sizes Array containing the size of each data section in the file. Every size is always a multiple of 32.
End of header; pad to 32 bytes before first data section begins

World Geometry

See Materials (Metroid Prime) and Geometry (Metroid Prime)

MREA files have one material section, followed by a number of world models, each of which has its own set of geometry sections. There's couple small differences you'll usually see on world models compared to regular CMDL ones:

  • Normals are always shorts, so vertex format 0 is never used.
  • Most world models 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 world model starts with an extra header section which is formatted like this:
Offset Type Count Name Notes
0x0 Visor Flags 1 Visor Flags 32-bit bitfield that sets parameters controlling how the mesh renders in different visors.
0x4 float 12 World Model Transform World model's transform from the area's local origin. The geometry data is pre-transformed, so this matrix can largely be ignored.
0x34 float 6 World Model Bounding Box Pre-transformed axis-aligned bounding box for this model.
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

To do:
Format known, needs documentation written up.

The SCLY section contains data for objects.

Collision

Main article: Area Collision (File Format)

Unknown Section

This one is sandwiched between collision and lights, and usually just contains a single 32-bit "1". Purpose is unknown. In the Prime 3/DKCR MREA format, this section is labelled LLTE.

Lights

This section is for dynamic lights. See the Light article for details.

Visibility Tree

Main article: VISI (MREA Section)

This section is a PVS octree labeled "VISI". Some areas don't have visibility octrees; in that case this section will be completely empty and listed with a size of 0.

Path

This is the final section in the file; its only value is a single PATH file ID.

Offset Type Name
0x0 Asset ID Area PATH Resource
0x4 End of section