OBD:OBOA

ONI BINARY DATA OBDC << Other file types >> OFGA OBOA : Starting Object Array switch to XML:OBOA page Overview @ Oni Stuff

The primary use of an OBOA is to display animated objects in the environment (cars, helis, fans, etc.).

Offset	Type	Raw Hex	Value	Description
0x00	res_id	01 55 02 00	597	00597-.OBOA
0x04	lev_id	01 00 00 06	3	level 3
0x08	char[22]	AD DE	dead	padding
0x1E	uint16	62 00	98	array size
First array element (black outline): "setup" for a door or physical/animated object
0x00	link	01 56 02 00	598	link to 00598-.M3GA - geometry (or a glued-together set of geometries) displayed for this object
0x04	link	00 00 00 00	unused	link to OBAN - animation played when the object is created; a different animation can be selected with env_setanim
0x08	link	00 00 00 00	unused	link to ENVP - particles attached to this object (e.g., vehicle headlights)
0x0C	bitset32	00 12 00 00	in use, face collision	flags; the bits are as follows: 0x02 00 00 00 - never used in vanilla data ("is door"; set at runtime when creating a level's doors) 0x04 00 00 00 - never used in vanilla data ("ignore characters"; never used by the engine) 0x08 00 00 00 - never used in vanilla data ("force draw"; can be set at runtime with obj_force_draw) 0x10 00 00 00 - never used in vanilla data ("light source"; never used by the engine) 0x40 00 00 00 - never used in vanilla data ("delete me"; never used by the engine) 0x80 00 00 00 - never used in vanilla data ("notify collision"; set at runtime for a level's doors) 0x00 01 00 00 - never used in vanilla data ("invisible"; set at runtime with obj_show and obj_hide) 0x00 02 00 00 - in use; if disabled, there is no object setup in this element at all (see "Empty array elements" below) 0x00 04 00 00 - no collision; used for "blender" machine parts in manplant and for a piece of rope in Airport_III 0x00 08 00 00 - never used in vanilla data ("no gravity"; disables gravity, keeps other forces, if any) 0x00 10 00 00 - face collision (actually uses a bounding box); overrides 0x0400 if both are present; used only for doors in vanilla 0x00 20 00 00 - never used in vanilla data ("particles created"; runtime only) 0x00 40 00 00 - never used in vanilla data ("jello objects"; runtime only) 0x00 80 00 00 - never used in vanilla data ("flat lighting"; used in combination with obj_shade)
0x10	uint32	46 89 00 00	35142	the index of the doorframe GQ; used only for doors (0 for other objects)
0x14	uint32	01 00 00 00	1	door ID; used only for doors (0 for other objects); for doors that work in pairs the IDs differ by 4096 (i.e. by the 0x1000 bit)
0x18	uint32	00 00 00 00	0	"physics level"; the following values are possible: 0 - None; used for doors 1 - Static; never used in vanilla data 2 - Linear; response to external forces and collision (if any); never used in vanilla data 3 - Animated; used for non-doors 4 - Newton; functions equivalently to Linear; never used in vanilla data
0x1C	uint32	FF FF 00 00	65535	script ID (for obj_create, env_setanim etc); doors use 65535
0x20	vector	00 00 4F 43 1F 05 F6 42 98 7F CC C3	207.0 123.010002 -408.996826	object position
0x2C	quaternion	F2 04 35 3F 74 BC 82 B9 74 BC 82 B9 F3 04 35 3F	0.707107 -0.000249 -0.000249 0.707107	object rotation
0x3C	float	00 00 80 3F	1.0	object scale
0x40	matrix	FC FF 7F 3F 00 00 00 00 8A E3 38 BA 8A E3 38 BA 2E DE 4C 32 FC FF 7F BF C9 F5 13 2D 00 00 80 3F 2B DE 4C 32 00 00 4F 43 1F 05 F6 42 98 7F CC C3	0.999999 0.0 -0.000705 -0.000705 0.0 -0.999999 0.0 1.0 0.0 207.0 123.010002 -408.996826	debug origin matrix
0x70	char[64]	object_door_1		name of the object; informational only
0xB0	char[64]	L3_Gunk.ENV		file name from which this object was created; informational only

Physics

Physics may work if you set one of the "physics level" flags, but the implementation is buggy and incomplete: you may be able to add a object that can be pushed around, but if you try to jump on it you'll fall. If you run into an object, the collision will stop you, but an animated object cannot push you; intercepting a moving object with a moving character, for instance running towards Muro's van as it escapes Vago Lab, will stop you at the moment when you contact one of its collision spheres but you will not be pushed backward by the van and it will proceed to pass through you, allowing you to resume running forward.

You can shoot Muro's van as it drives away from you and you will see your shots impacting the rear door, but if you study the collisions closely you will see that they are striking an invisible sphere that encompasses the visible doors. So-called "face collision" can be requested in the OBOA setup and it will calculate and use bounding boxes for collision instead of spheres, but the FaceCollision flag is only set in the vanilla game data for doors – apparently Bungie West probably never felt the need for accurate collision on environmental objects created with OBOA because they didn't expect the player to interact with them; more or less all animations play during cutscenes where the player doesn't have control. Also, for rounder objects, it's hard to tell the difference between accurate spherical collision and accurate bounding box collision anyway.

That being said, the default spherical bounding volume that the engine calculates for each object is often incorrectly tiny, especially when a single object consists of two separate bodies (e.g. the pair of wheels on Muro's van, script ID 5, in level3_Final). Sometimes the sphere is correctly fit to the object geometry but the object is narrow (e.g. the crane cable over the acid vat, script ID 72, in level14_Final) and so the encompassing sphere is uncomfortably large, resulting in collision with a large invisible space around the object where a player would not expect it. To see the calculated collision volumes of objects, use ob_show_debug=1.

Position, rotation and scale are used only when the object is not animated, otherwise the origin matrix is used instead.

Object management

Objects are not automatically created when a level is loaded; they need to be created from scripts using the obj_create command. After that they can be controlled with other commands like obj_show, obj_hide, obj_kill, obj_shade, env_anim and env_setanim (also obj_force_draw, env_anim_block and env_setanim_block).

In some cases a level's geometry contains a static duplicate of the object's polygons, which is typically hidden (through "env_show objectScriptID 0") while the OBOA object is shown (and vice versa).

Flags

Besides the trivial "in use" flag, only two flags are used in the vanilla game data: "no collision" and "face collision" (used for doors).

Some of the other flags (e.g. "particles created") are reserved for runtime use, and others can be specified in game data. Some intriguing ones, like "light source", are completely defunct (always false).

Empty array elements

The last 32 elements of a level's OBOA are always empty (all data values are zero). Below is an overview table for each level showing OBOA array size vs. number of actual door/object setups.

level#_Final	1	2	3	4	6	8	9	10	11	12	13	14	18	19
OBOA array size	180	69	98	69	99	146	78	78	106	50	54	116	117	100
Actual elements	148	37	66	37	67	114	46	46	74	18	22	84	85	68

To be safe, OniSplit follows this convention when building a new level from XML, adding 32 empty elements at the end of the array, but the engine's purpose for these extra elements is not currently known.

M3GA use

The link at 0x00 in an object setup is to an M3GA, i.e., an array that can hold several M3GMs – which, in the OBOA context, behave as a single object (driven by the same animation or force - if any), as if glued together.

In the vanilla game data, the only OBOA objects to have several M3GMs in their M3GA are doors with glass sections; this is needed because (a) an M3GM can have only one texture and (b) door frames are required to have a fully opaque texture or else they will have an "inside-out" look because of the front-to-back rendering order. The only exception is door 45 in level6 (Airport Cargo Hangars), which has no transparent parts, and instead just links to the same M3GM twice.

One would expect the M3GA feature to be used for large animated objects that consist of several meshes, e.g. the express elevator in Griffin's office (intro of level18) or the satellite dish in level19 – but no, these are set up as separate "objects", with one M3GM per M3GA, animated synchronously. This is in contrast to the named M3GAs found in level0_Tools, which are actually used to group several M3GMs together, into pieces of "furniture".

Script IDs of grouped objects

Objects animated synchronously (e.g. a vehicle and its wheels) are typically set up with a continuous range of script IDs so that all related script commands, from obj_create to obj_shade to env_anim, can operate both on single objects and on ranges of objects (e.g., obj_create 10 12 creates objects 10 through 12).

These grouped objects can move as a rigid "whole" or there can be some relative motion within the group (e.g. wheels turning, doors opening, rotors tilting). This is because each object belongs to a separate OBOA element and thus has its own animation, assigned at creation or via script ID.

The logic behind the assigning of contiguous numbers to related objects is not obvious. It might make sense for wheels/doors to be "parented" to a vehicle's chassis so that they naturally follow it, but this is not done; both the chassis and the wheels/doors are animated in world space.

Additionally, recurring object sets (e.g. armored truck, motorcycle, Syndicate van) are not ordered consistently in all the levels where they appear:

• Armored truck (level1, gunk IDs): cabin 201, trailer 202, wheel pairs 203 to 207 (front to back); no gunk IDs for doors (so they can't be hidden).
• Armored truck (level1, OBOA IDs): cabin 207, trailer 206, wheel pairs 205, 203, 204, 201 and 202 (front to back); no animated door objects.
• Armored truck (level19, gunk IDs before ramming): cabin 152, trailer 151, wheel pairs 157, 155, 156, 159 and 158 (front to back), doors 154 (left) and 153 (right).
• Armored truck (level19, gunk IDs after ramming): cabin 252, trailer 251, wheel pairs 257, 255, 256, 259 and 258 (front to back), doors 254 (left) and 253 (right).
• Armored truck (level19, OBOA IDs): cabin 52, trailer 51, wheel pairs 57, 55, 56, 59 and 58 (front to back), doors 54 (left) and 53 (right).
• Motorcycle (level3, gunk IDs and OBOA IDs): bike 10, wheels 8 (front) and 9 (rear)
• Motorcycle (level4, gunk IDs and OBOA IDs): bike 10, wheels 11 (front) and 12 (rear)
• Motorcycle (level8, gunk IDs): bike 110, wheels 111 (front) and 112 (rear)
• Motorcycle (level8, OBOA IDs): bike 10, wheels 11 (front) and 12 (rear)
• BlackVan (level3 and level4, OBOA IDs): front/back 2, sides 3, top/bottom 4, wheel pairs 5 (front) and 6 (rear), doors 7
• BlackVan (level8, gunk IDs): front/back 101, sides 103, top/bottom 104, wheel pairs 105 (front) and 106 (rear), doors 108 (left) and 107 (right)
• BlackVan (level8, OBOA IDs): front/back 1, sides 3, top/bottom 4, wheel pairs 5 (front) and 6 (rear), doors 8 (left) and 7 (right)

The bottom line is that there don't seem to be any rules for the order of script IDs in a group. Possibly the IDs were not auto-assigned during import and were specified more or less manually.

Unused or missing object setups

Some object setups are left over from early development, completely unused in the game. The most famous example is Konoko's clothes from Chapter 4 (level4_Final), but hidden doors at the Warehouse also fall into that category.

Some object setups are completely missing from the game data but can be inferred from eponymous OBAN instances (object animations). OBAN are also used for cameras and "env-boxed" character animations (gliding, elevator/motorcycle rides, etc.), but camera and/or env-box animations are usually easy to tell apart from object motion.

The most significant evidence of missing objects is in level2 aka Musashi Manufacturing Plant, with the following big set of "orphaned" OBANs:

• solarpanel, solarbracket
• scanner, scanring, scanlens, scanlens2
• weldarm1, weldarm2, weldarm3, weldarm4, weldarm5

All 11 animations have a common length of 2400 frames (= 40 seconds) and are located in one of the "engine rooms" where the current "blender" and "fan" OBANs are. It seems to correspond to an elaborate manufacturing sequence (welding) involving a "solar panel" mounted on a moving bracket, a robotic welding arm and a "scanner" analyzing the process.

level2 also features an unused OBANwoof (299 frames = 5 seconds long), located in the lobby, not clearly intended for a camera or a flying object, as well as a missing env-box for Shinatama.

ONI BINARY DATA
OBDC << Other file types >> OFGA
OBOA : Starting Object Array
Level file