Difference between revisions of "AROT (MREA Section)"
From Retro Modding Wiki
(→Node Entry) |
|||
| Line 7: | Line 7: | ||
They are structured recursively, starting with a ''root'' node and traversing their way to individual ''leaf'' nodes. | They are structured recursively, starting with a ''root'' node and traversing their way to individual ''leaf'' nodes. | ||
A full-branch octant will split sub-octants across 3-tiers, one for each dimension of euclidean space. | A full-branch octant will split sub-octants across 3-tiers, one for each dimension of euclidean space. | ||
| + | |||
| + | Within each octant is an index to a bitmap relating that AABB-volume to a set of meshes within the MREA; they | ||
| + | are sorted and culled accordingly. Actors, particle effects, and other visual entities are also sorted and culled | ||
| + | according to which octant(s) they intersect. | ||
=== Layout === | === Layout === | ||
Revision as of 04:48, 12 April 2015
Left: Recursive subdivision of a cube into octants. Right: The corresponding octree.
Within MREA resources, the AROT section stores an octree which is used to accelerate rendering of areas in back-to-front order.
Octrees are a form of BSP tree that subdivide an area in 3-dimensions. They are structured recursively, starting with a root node and traversing their way to individual leaf nodes. A full-branch octant will split sub-octants across 3-tiers, one for each dimension of euclidean space.
Within each octant is an index to a bitmap relating that AABB-volume to a set of meshes within the MREA; they are sorted and culled accordingly. Actors, particle effects, and other visual entities are also sorted and culled according to which octant(s) they intersect.
Layout
| Data Type | Element Count | Description | Notes |
|---|---|---|---|
| Header | 1 | Octree Header | |
| long | round_up(bitmap_bit_count / 32) * bitmap_count | Mesh Bitmap Array | An array of word-packed bitmaps relating octant nodes to sets of MREA meshes |
| long | node_count | Node Indirection Table | Since nodes use variable-length-encoding, there is an indirection table with byte-offsets (relative to first node) |
| Node Entry | node_count | Node Entry Table | Tightly-packed blob of nodes |
Header
| Offset | Size | Data Type | Description | Notes |
|---|---|---|---|---|
| 0x0 | 4 | long | Magic | AROT
|
| 0x4 | 4 | long | Version | Always 0x1 |
| 0x8 | 4 | long | Mesh-Bitmap Count | Count of mesh-bitmaps |
| 0xC | 4 | long | Mesh-Bitmap Bit-Count | Count of bits in each mesh-bitmap (matches MREA's mesh count) |
| 0x10 | 4 | long | Node Count | Number of octant nodes |
| 0x14 | 24 | float2x3 | AABB | AABB that fully-encloses area and serves as the octree's root-shape |
Node Entry
| Offset | Size | Data Type | Description | Notes |
|---|---|---|---|---|
| 0x0 | 2 | short | Bitmap Index | Index of the mesh bitmap defining a set of MREA meshes for this octant node |
| 0x2 | 2 | short | Additional Child Count | If non-zero, this counts the octant's child-nodes in addition to the first child (a value of 0x7 actually indicates 8 child-nodes)
If zero, this node-entry ends here |
| 0x4 | 2 | short[additional_child_count + 1] | Node Child Indexes | Variable-length array of node-entry indices that are children of this node-entry |
