MREA (Metroid Prime 3): Difference between revisions

From Retro Modding Wiki
Jump to navigation Jump to search
imported>Antidote
No edit summary
>Aruki
 
(40 intermediate revisions by 3 users not shown)
Line 1: Line 1:
The '''.MREA file format''' is used to define areas in Metroid Prime 3 and Donkey Kong Country Returns. MREA files are broken up into many sections, and each section serves a specific purpose.
''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.
 
{{research|moderate|Research needed on the area octree and visibility tree sections to verify structure and check for version differences. Also the purpose of the LLTE section is unknown.}}


{{researchmoderate
|reason=Still a few sections we know nothing about.
}}
__TOC__
__TOC__


=Universal Header=
== 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 ===


This header is shared between Metroid Prime and Donkey Kong Country, and is fairly straight forward.
The header is identical between MP3 and DKCR.


{| class="wikitable"
{| class="wikitable"
!Offset
! Offset
!Size
! Type
!Description
! Count
! Name
! Notes
|-
| 0x0
| u32
| 1
| '''Magic'''
| Always <code>0xDEADBEEF</code>.
|-
| 0x4
| u32
| 1
| '''Version'''
| See [[MREA (File Format)|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.
|-
|-
|0x0
| 0x38
|4
| u32
|'''Magic Number''' 0xDEADBEEF
| 1
| '''World Model Count'''
| Number of world models in this area.
|-
|-
|0x4
| 0x3C
|4
| u32
|'''Version'''; see hub article
| 1
| '''Script Layer Count'''
| Number of script layers in this area.
|-
|-
|0x8
| 0x40
|48
| u32
|'''Transformation Matrix''' The position of the area in world-space
| 1
| '''Data Section Count'''
| Number of data sections in the file.
|-
|-
|0x38
| 0x44
|4
| u32
|'''Mesh Count'''
| 1
| '''Compressed Block Count'''
| Number of compressed data blocks in the file.
|-
|-
|0x3C
| 0x48
|4
| u32
|'''SCLY Count'''
| 1
| '''Section Number Count'''
| Number of section numbers at the end of the header.
|-
|-
|0x40
| 0x4C
|4
| u32
|'''Section Count'''
| 5
| '''Padding'''
| Padding bytes that align the file with the next multiple-of-32 offset.
|-
|-
|0x0
| 0x60
|4
| u32
|'''Compressed Block Count'''
| ''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.
|-
|-
|0x4
| colspan=5 {{unknown|End of main header data; pad to 32 bytes before compressed section definitions}}
|4
|'''Section Number Count'''
|}
|}


=Compressed Blocks=
==== Compressed Blocks ====
[[MREA_(Metroid_Prime_2)#Compressed_Sections|Compressed]] blocks are handled in the exact same manner as Metroid Prime 2, however with DKCR simply replace LZO with zlib.
 
=Section Numbers=
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).


Section Numbers are preceded by the compressed blocks, each section is designated in the following:
Compressed blocks are defined after the main header. After reading them, pad to 32 bytes before the section numbers portion of the header starts.


<code>let N=Section Number Count</code>
{| class="wikitable"
{| class="wikitable"
!Type
! Offset
!Description
! Type
! Count
! Name
! Notes
|-
| 0x0
| u32
| 1
| '''Buffer Size'''
| This is always 0x120 bytes larger than the uncompressed size on compressed bytes, and the same value as the uncompressed size on uncompressed blocks
|-
| 0x4
| u32
| 1
| '''Uncompressed Size'''
|
|-
| 0x8
| u32
| 1
| '''Compressed Size'''
| This is 0 on uncompressed blocks.
|-
|-
|FourCC
| 0xC
|Section type
| u32
| 1
| '''Data Section Count'''
| The number of regular data sections contained in this block.
|-
|-
|Long
| 0x10
|Section Number
| colspan=5 {{unknown|Block definition end}}
|}
|}


Repeat <code>N</code> times, one for each section, and the sections sections are associated with the following FourCC values:
==== Section Numbers ====
 
The section numbers portion of the header indicates the section 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:
 
{| class="wikitable"
! Offset
! Type
! Count
! Name
|-
| 0x0
| char
| 4
| '''Section Type'''
|-
| 0x4
| u32
| 1
| '''Section Index'''
|}


<code>WOBJ</code> can be listed multiple times, but its section index is always 0 (pointing to the materials section). Every other section number always appears in every MREA file once (none are optional). Here are all possible section numbers and what they are, in the order that they appear in the file: (note this is both the order the section numbers are listed in as well as the order that the sections themselves appear in the file)


{|class="wikitable"
{| class="wikitable"
!FourCC
! FourCC
!Description
! Description
! MP3
! DKCR
|-
|-
|AABB
| <code>WOBJ</code>
|Axis Aligned Bounding Boxes
| [[#Materials|Materials]] + [[#World Model Definition|World Model Definition]]
| {{check}}
| {{check}}
|-
|-
|APTL
| <code>ROCT</code>
|{{unknown|Unknown}}
| [[#Area Octree|Area Octree]]
| {{check}}
| {{check}}
|-
|-
|COLI
| <code>AABB</code>
|Collision
| [[#Surface Group Bounding Boxes|Surface Group Bounding Boxes]]
| {{check}}
| {{check}}
|-
|-
|DEPS
| <code>GPUD</code>
|Dependencies
| [[#GPU Data|World Geometry GPU Data]]
| {{check}}
| {{check}}
|-
|-
|EGMC
| <code>DEPS</code>
|{{unknown|Unknown}}
| [[#Dependencies|Dependencies]]
| {{check}}
| {{check}}
|-
|-
|GPUD
| <code>SOBJ</code>
|Submesh data, e.g, vertices, normals, etc.
| [[#Script Layers|Script Layers]]
| {{check}}
| {{check}}
|-
|-
|LITE
| <code>SGEN</code>
|Lights
| [[#Generated Script Objects|Generated Script Objects]]
| {{check}}
| {{check}}
|-
|-
|LLTE
| <code>COLI</code>
|{{unknown|Unknown}}
| [[#Collision|Collision]]
| {{check}}
| {{check}}
|-
|-
|PFL2
| <code>LITE</code>
|Path file
| [[#Lights|Lights]]
| {{check}}
| {{check}}
|-
|-
|PVS!
| <code>LLTE</code>
|Area vis octree, used for culling unseen geometry
| {{unknown|[[#Unknown Section (LLTE)|Unknown]]}}
| {{check}}
| {{check}}
|-
|-
|ROCT
| <code>PVS!</code>
|{{unknown|Unknown}}
| [[#Visibility Tree|Visibility Tree]]
| {{check}}
| {{check}}
|-
|-
|RSOS
| <code>RSOS</code>
|Revolution Shared Objects
| [[#RSO Module List|RSO Module List]]
| {{check}}
| {{check}}
|-
|-
|SOBJ
| <code>PFL2</code>
|SCLY Layer data, there can be multiple copies, but only the first is indicated.
| [[#Path|Path]]
| {{check}}
| {{nocheck}}
|-
|-
|SGEN
| <code>APTL</code>
|{{unknown|Unknown}}
| [[#Portal Area|Portal Area]]
| {{check}}
| {{nocheck}}
|-
|-
|WOBJ
| <code>EGMC</code>
|Mesh Header, always 0, the number of WOBJ sections is determined by the mesh count in the header.
| [[#Static Geometry Map|Static Geometry Map]]
| {{check}}
| {{nocheck}}
|}
|}


== Sections ==
=== Materials ===  
=== Materials ===  
[[Materials (Metroid Prime 3)|Materials]] are identical to those found in [[CMDL (Metroid Prime 3)|CMDL]] files.
''See [[Materials (Metroid Prime 3)]]''
 
Identical to the material format found in [[CMDL (File Format)|CMDL]]. There is just one materials section which is shared across all world models.
 
=== World Model Definition ===
 
The world geometry definitions always appear immediately following the materials section. Each definition is a sequence of four sections. All four of these sections are identical to their structure in the previous MREA formats in both MP3 and DKCR, so check those pages:
 
* [[MREA (Metroid Prime)#World Geometry|World Model Header]]
* [[Geometry (Metroid Prime)#Surface Offsets|Surface Definitions]]
* [[Geometry (Metroid Prime)#Surface Group IDs|Surface Group IDs]]
* [[Geometry (Metroid Prime)#Surface Lookup Table|Surface Lookup Table]]
 
=== Area Octree ===
''See [[AROT (MREA Section)]]''
 
=== Surface Group Bounding Boxes ===
''See [[MREA (Metroid Prime 2)#Surface Group Bounding Boxes]]''
 
=== GPU Data ===
''See [[Geometry (Metroid Prime)]] or [[Geometry (Donkey Kong Country Returns)]]''
 
This section contains the GPU buffer data used to render world geometry. This is generally the same as in previous games, with the following sequence of sections repeated once per world model:
 
* '''Vertices''': Always floats; world geometry vertices are never packed into shorts.
* '''Normals''': Always floats; world geometry normals are never packed into shorts.
* '''Colors''': Contains 32-bit RGBA8 colors. This section is not used in any official assets and is always zeroed out.
* '''Float UV Coordinates''': In Metroid Prime 3, this is the only UV coordinates section, so it's used for everything.
* '''Short UV Coordinates''': Only appears in Donkey Kong Country Returns; can be used for anything, not only lightmaps as in previous games.
* '''Surfaces''': One section per surface. For details on the structure of these sections check [[Geometry (Metroid Prime)#Surface|Geometry (Metroid Prime)]] page for MP3 and the [[Geometry (Donkey Kong Country Returns)#Surface|Geometry (Donkey Kong Country Returns)]] page for DKCR.
 
=== Dependencies ===
 
{{research|minor|How does this section work with SCGN?}}
 
This section is basically a list of all resources that this area depends on, not unlike a [[DGRP (File Format)|DGRP]] file. After the initial dependency list, there's a second array which provides a list of offsets into the dependency list. These offsets are used to indicate which dependencies are needed for individual script layers, with the last offset pointing to resources that are used by the area itself as a whole (world geometry textures and the [[#Path|PATH]]/[[#Portal Area|PTLA]]/[[#Static Geometry Map|EGMC]] assets).


=== Mesh Headers ===
[[STRM (File Format)|STRM]] assets are not included in this list.
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 ====
{| class="wikitable"
{|class="wikitable"
! Type
!Type
! Count
!Description
! Name
!Notes
! Notes
|-
|-
|long
| u32
|'''Unknown'''
| 1
|Most likely visor flags in MP3, unknown use and DKCR
| '''Dependency Count'''
| Count of dependencies in the next array.
|-
|-
|CTransform4f
| [[#Dependency|Dependency]]
|'''Transformation Matrix'''
| ''Dependency Count''
|Meshes location in world space
| '''Dependency List'''
| List of resources used by this area.
|-
|-
|CAABox
| u32
|'''Bounding Box'''
| 1
|Likely used for Depth sorting as in previous games.
| '''Offset Count'''
| Count of offsets in the next array. Should be equal to the script layer count + 1.
|-
| u32
| ''Offset Count''
| '''Dependency List Offsets'''
| Each element is an offset into the dependency list to indicate where the dependencies for individual script layers begins. There's one offset per script layer, then the last offset points to resources used by the area itself outside of script layers.
|-
| colspan=5 {{unknown|End of dependencies section}}
|}
|}


==== Submesh Offsets ====
==== Dependency ====
{|class="wikitable"
 
!Type
{| class="wikitable"
!Description
! Offset
!Notes
! Type
! Count
! Name
|-
| 0x0
| Asset ID
| 1
| '''Dependency Asset ID'''
|-
|-
|long (SC)
| 0x8
|'''Submesh count'''
| char
|
| 4
| '''Dependency Asset Type'''
|-
|-
|long
| 0xC
|'''Submesh Offsets[SC]'''
| colspan=3 {{unknown|End of dependency}}
|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.
=== Script Layers ===
 
{{todo|This section is known, needs documentation written}}
 
=== Generated Script Objects ===
 
{{todo|Almost identical to script layers but there are some slight differences in the header}}
 
This section is an extra [[#Script Layers|script layer]] that contains generated objects (anything spawned by a Generator).
 
=== Collision ===
 
''Main article: [[Area Collision (File Format)]]''
 
=== Lights ===
''See [[Lights (Metroid Prime)]]
 
=== Unknown Section (LLTE) ===
 
This section always contains just a single 32-bit 1. It doesn't appear to do anything, so the purpose of this section is unknown.
 
=== Visibility Tree ===
 
{{research|major|This section is largely unknown}}


=== AROT ===
=== RSO Module List ===
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 ===
This section is a list of RSO modules used by script objects in the area. Like the dependencies section, there's also a list of offsets to indicate which RSOs are used by each script layer.
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:


{|class="wikitable"
{| class="wikitable"
!Type
! Type
!Description
! Count
!Notes
! Name
! Notes
|-
|-
|CAABox
| u32
|'''Axis Aligned Bounding Box'''
| 1
|Used to assist depth sorting, and/or collision
| '''RSO Count'''
| Count of RSO modules listed in the next array.
|-
|-
|long
| string
|'''Unknown'''
| ''RSO Count''
|The first entry in the table always covers the entire, with this value always being -1
| '''RSO Module List'''
| This is a series of zero-terminated strings. Each string is the filename of a .rso file.
|-
|-
|short
| u32
|'''Self Index'''
| 1
| 1 indexed position of this particular AABB entry, but ONLY if the previous value is -1.
| '''Offset Count'''
| Count of offsets in the next array. Should be equal to the script layer count * 2.
|-
|-
|short
| u32
|'''Self Index'''
| ''Offset Count''
| 1 indexed position of this particular AABB entry, but ONLY if the previous value is -1.
| '''RSO Module List Offsets'''
| Each element is an offset into the RSO module list to indicate which modules are required by each script layer. For some reason there are two offsets per script layer.
|-
| colspan=4 {{unknown|End of RSOs section}}
|}
|}


=== GPU Description Section (GPUD) ===
=== Path ===
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:
This section only contains a single [[PATH (File Format)|PATH]] asset ID.
==== Vertices ====
The vertices are always 32bit floats, even in DKCR


==== Normals ====
{| class="wikitable"
The normals are always 32bit floats.
! Type
! Count
! Name
|-
| Asset ID
| 1
| '''Area PATH Resource'''
|-
| colspan=3 {{unknown|End of section}}
|}


==== Colors ====
=== Portal Area ===
Usually 0 filled and completely unused, it's stored in MREA simply for completeness.


==== Float Texcoords ====
This section only contains a single [[PTLA (File Format)|PTLA]] asset ID.
Metroid Prime 3 uses these exclusively, even for lightmaps, which simplifies UV handling quite a bit.


==== Short Texcoords ====
{| class="wikitable"
This is only used in DKCR and can be used for anything, not just for lightmaps
! Type
! Count
! Name
|-
| Asset ID
| 1
| '''Area PTLA Resource'''
|-
| colspan=3 {{unknown|End of section}}
|}
 
=== Static Geometry Map ===
 
This section only contains a single [[EGMC (File Format)|EGMC]] asset ID.


==== Submeshes ====
{| class="wikitable"
The submesh format is exactly the same as the Geometry formats found in Metroid Prime 3 and DKCR.
! Type
! Count
! Name
|-
| Asset ID
| 1
| '''Area EGMC Resource'''
|-
| colspan=3 {{unknown|End of section}}
|}


[[Category:File Formats]]
[[Category:File Formats]]
[[Category:Moderate research needed]]
[[Category:Metroid Prime 3: Corruption]]
[[Category:Metroid Prime 3: Corruption]]
[[Category:Donkey Kong Country Returns]]
[[Category:Donkey Kong Country Returns]]

Latest revision as of 02:09, 10 May 2017

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
Research needed on the area octree and visibility tree sections to verify structure and check for version differences. Also the purpose of the LLTE section is unknown.


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 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 Script Layer Count Number of script layers in this area.
0x40 u32 1 Data Section Count Number of data sections in the file.
0x44 u32 1 Compressed Block Count Number of compressed data blocks in the file.
0x48 u32 1 Section Number Count Number of section numbers at the end of the header.
0x4C u32 5 Padding Padding bytes that align the file with the next multiple-of-32 offset.
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 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 Count Name Notes
0x0 u32 1 Buffer Size This is always 0x120 bytes larger than the uncompressed size on compressed bytes, and the same value as the uncompressed size on uncompressed blocks
0x4 u32 1 Uncompressed Size
0x8 u32 1 Compressed Size This is 0 on uncompressed blocks.
0xC u32 1 Data Section Count The number of regular data sections contained in this block.
0x10 Block definition end

Section Numbers

The section numbers portion of the header indicates the section 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 Count Name
0x0 char 4 Section Type
0x4 u32 1 Section Index

WOBJ can be listed multiple times, but its section index is always 0 (pointing to the materials section). Every other section number always appears in every MREA file once (none are optional). Here are all possible section numbers and what they are, in the order that they appear in the file: (note this is both the order the section numbers are listed in as well as the order that the sections themselves appear in the file)

FourCC Description MP3 DKCR
WOBJ Materials + World Model Definition
ROCT Area Octree
AABB Surface Group Bounding Boxes
GPUD World Geometry GPU Data
DEPS Dependencies
SOBJ Script Layers
SGEN Generated Script Objects
COLI Collision
LITE Lights
LLTE Unknown
PVS! Visibility Tree
RSOS RSO Module List
PFL2 Path
APTL Portal Area
EGMC Static Geometry Map

Materials

See Materials (Metroid Prime 3)

Identical to the material format found in CMDL. There is just one materials section which is shared across all world models.

World Model Definition

The world geometry definitions always appear immediately following the materials section. Each definition is a sequence of four sections. All four of these sections are identical to their structure in the previous MREA formats in both MP3 and DKCR, so check those pages:

Area Octree

See AROT (MREA Section)

Surface Group Bounding Boxes

See MREA (Metroid Prime 2)#Surface Group Bounding Boxes

GPU Data

See Geometry (Metroid Prime) or Geometry (Donkey Kong Country Returns)

This section contains the GPU buffer data used to render world geometry. This is generally the same as in previous games, with the following sequence of sections repeated once per world model:

  • Vertices: Always floats; world geometry vertices are never packed into shorts.
  • Normals: Always floats; world geometry normals are never packed into shorts.
  • Colors: Contains 32-bit RGBA8 colors. This section is not used in any official assets and is always zeroed out.
  • Float UV Coordinates: In Metroid Prime 3, this is the only UV coordinates section, so it's used for everything.
  • Short UV Coordinates: Only appears in Donkey Kong Country Returns; can be used for anything, not only lightmaps as in previous games.
  • Surfaces: One section per surface. For details on the structure of these sections check Geometry (Metroid Prime) page for MP3 and the Geometry (Donkey Kong Country Returns) page for DKCR.

Dependencies

This file format is almost completely documented
How does this section work with SCGN?


This section is basically a list of all resources that this area depends on, not unlike a DGRP file. After the initial dependency list, there's a second array which provides a list of offsets into the dependency list. These offsets are used to indicate which dependencies are needed for individual script layers, with the last offset pointing to resources that are used by the area itself as a whole (world geometry textures and the PATH/PTLA/EGMC assets).

STRM assets are not included in this list.

Type Count Name Notes
u32 1 Dependency Count Count of dependencies in the next array.
Dependency Dependency Count Dependency List List of resources used by this area.
u32 1 Offset Count Count of offsets in the next array. Should be equal to the script layer count + 1.
u32 Offset Count Dependency List Offsets Each element is an offset into the dependency list to indicate where the dependencies for individual script layers begins. There's one offset per script layer, then the last offset points to resources used by the area itself outside of script layers.
End of dependencies section

Dependency

Offset Type Count Name
0x0 Asset ID 1 Dependency Asset ID
0x8 char 4 Dependency Asset Type
0xC End of dependency

Script Layers

To do:
This section is known, needs documentation written

Generated Script Objects

To do:
Almost identical to script layers but there are some slight differences in the header

This section is an extra script layer that contains generated objects (anything spawned by a Generator).

Collision

Main article: Area Collision (File Format)

Lights

See Lights (Metroid Prime)

Unknown Section (LLTE)

This section always contains just a single 32-bit 1. It doesn't appear to do anything, so the purpose of this section is unknown.

Visibility Tree

This file format needs a lot of research
This section is largely unknown


RSO Module List

This section is a list of RSO modules used by script objects in the area. Like the dependencies section, there's also a list of offsets to indicate which RSOs are used by each script layer.

Type Count Name Notes
u32 1 RSO Count Count of RSO modules listed in the next array.
string RSO Count RSO Module List This is a series of zero-terminated strings. Each string is the filename of a .rso file.
u32 1 Offset Count Count of offsets in the next array. Should be equal to the script layer count * 2.
u32 Offset Count RSO Module List Offsets Each element is an offset into the RSO module list to indicate which modules are required by each script layer. For some reason there are two offsets per script layer.
End of RSOs section

Path

This section only contains a single PATH asset ID.

Type Count Name
Asset ID 1 Area PATH Resource
End of section

Portal Area

This section only contains a single PTLA asset ID.

Type Count Name
Asset ID 1 Area PTLA Resource
End of section

Static Geometry Map

This section only contains a single EGMC asset ID.

Type Count Name
Asset ID 1 Area EGMC Resource
End of section