OBD:AKVA

From OniGalore
Revision as of 15:54, 18 September 2007 by Ssg (talk | contribs) (design)
Jump to navigation Jump to search
ONI BINARY DATA
AKOT << Other file types >> BINA
AKVA : BNV Node Array
switch to XML:AKVA page
Overview @ Oni Stuff
OBD.png


Akva a.gif


Offset Type Raw Hex Value Description
0x00 res_id 01 4E 02 00 590 00590-.AKVA
0x04 lev_id 01 00 00 06 3 level 3
0x08 char[20] AD DE dead unused
0x1C int32 1E 01 00 00 10000 array size
First element (black outline)
0x00 int32 00 00 00 00 0 index into AKBP array; BSP tree for this BNV
0x04 int32 00 00 00 00 0 BNV's ID (same as index in array)
0x08 int32 00 00 00 00 0 index into AKBA array; "side" range start
0x0C int32 06 00 00 00 6 index into AKBA array; "side" range end
0x10 int32 FF FF FF FF -1 index in array of child BNV
0x14 int32 FF FF FF FF -1 index in array of sibling BNV
0x18 int32 FF FF FF FF -1 unknown (always -1 in level 3; other levels not checked)
0x1C int32 C9 00 00 00 201 size of the pathfinding grid along x in tiles
0x20 int32 16 00 00 00 22 size of the pathfinding grid along z in tiles
0x24 offset A0 3A 47 00 00 47 3A A0 at this position starts the pathfinding grid part in the raw file
0x28 int32 F7 01 00 00 503 size of the pathfinding grid part in the raw file in bytes
0x2C float 00 00 80 40 4.000000 tile size of the pathfinding grid
0x30 float 00 00 20 41 10.000000 AABB X- (AABB = Axis-aligned bounding box)
0x34 float 00 00 58 C1 -13.500000 AABB X-
0x38 float 00 80 2A C4 −682.000000 AABB Z-
0x3C float 00 40 47 44 797.000000 AABB X+
0x40 float 00 00 22 42 40.500000 AABB Y+
0x44 float 00 00 19 C4 -612.000000 AABB Z+
0x48 int32 FE FF FE FF -65538 unknown; always the same in level 3 (other levels not checked); maybe these 4 bytes are two shorts ==> then FEFF = -2
0x4C int32 00 00 00 00 0 BNV's ID again
0x50 int32 00 00 00 00 0 unknown, always zero
0x54 int32 00 00 00 00 0 unknown, always zero
0x58 int32 00 00 00 00 0 unknown, always zero (was it a raw file offset once?)
0x5C bitset32 04 00 00 00 4 identifier for the next five floats; see explanation below this table
0x60 float 00 00 00 00 0.000000 if "sloped", x-component of floor/ceiling normal
0x64 float 00 00 00 00 0.000000 if "sloped", y-component of floor/ceiling normal
0x68 float 00 00 00 00 0.000000 if "sloped", z-component of floor/ceiling normal
0x6C float 00 00 00 00 0.000000 if "sloped", distance of floor plane to origin
0x70 float 00 00 00 00 0.000000 if "sloped", distance of ceiling plane to origin


General
BNVs are volumes that have a pathfinding grid assigned to them.
The grid itself is in the RAW, while its overall parameters are in the DAT.
  • Child AKBP tree refines the volume after the AABB is checked
  • Child AKBA defines the "sides" needed by the pathfinding graph
0x00 - AKBP tree
This binary space partition (BSP) tree is used for a refined check against a character's position.
0x08 - AKBA range
The "sides" of a BNV define the quads by which an AI can transit to adjacent BNVs.
0x10 - Children and siblings
Those occur when smaller BNVs are completely included into larger ones.
The bigger BNV only links to its first child. If there are several children, the sibling link is used to define the series.
Examples: lobby in CHAPTER 03 . PUZZLE PIECES (level3), big hall under main power line in CHAPTER 08 . AN INNOCENT LIFE (level10).
0x1C - Pathfinding grid
The RAW format is rather complex (see HERE). It requires the X and Z size for parsing.
BNV 165 in level4 (far side of tarmac, behind the fence) has a non-zero X-Z grid size but no RAW data.
Notably, that one BNV also has the 16 flag set at 0x5C (see below).
The grid usually "bleeds" outside the (x,z) extent of the BNV.
The amount of bleeding is defined by the grid's size (in tiles) and by the size of a tile.
The grid seems to be always centered of the "floor" of the BNV's AABB (see above).
0x30 - AABB
The axis-aligned bounding boxes are used for a first, quick check against a character's position.
(note that the AKVA itself is looked up via the octtree: 2nd IDXA of the AKOT + OTLF)
0x5C - Floor and ceiling
Bitset:
  • the 4 bit is always set (meaning unknown)
  • the 16 bit is set only for BNV 165 of level4 (no RAW part, see above)
  • the 1 bit is set for BNVs involving "sloped" floors and ceilings
(typical environment requiring this feature is compact staircases)
The sloped floor and ceiling are used to apply a final cut to the volume defined by the AKBP tree
(the walls of which are typically vertical (possibly not axis-aligned) and horizontal)
When the "sloped" bit isn't set, all 5 floats are always zero (and are probably ignored anyway).
The 3 power lines in level10 have all 5 floats equal to zero even though the "sloped" bit is set
(possibly a design error: interestingly, BNV detection and pathfinding work fine for those 3).


ONI BINARY DATA
AKOT << Other file types >> BINA
AKVA : BNV Node Array
Level file