OBD:OBOA: Difference between revisions

7,064 bytes added ,  6 January 2022
m
minor touch-up
m (added some " : ")
m (minor touch-up)
 
(16 intermediate revisions by 4 users not shown)
Line 10: Line 10:
{{OBDtr| 0x04 | lev_id  |FFFF00| 01 00 00 06 | 3        | level 3 }}
{{OBDtr| 0x04 | lev_id  |FFFF00| 01 00 00 06 | 3        | level 3 }}
{{OBDtr| 0x08 | char[22] |00FF00| AD DE      | dead      | unused }}
{{OBDtr| 0x08 | char[22] |00FF00| AD DE      | dead      | unused }}
{{OBDtr| 0x1E | int16    |00FFFF| 62 00      | 98        | arrray size }}
{{OBDtr| 0x1E | int16    |00FFFF| 62 00      | 98        | array size }}
{{OBDtrBK}}
{{OBDtrBK| First array element (black outline): "setup" for a door or physical/animated object}}
{{OBDtr| 0x00 | int32    |FFC8C8| 01 56 02 00 | 1        | link to [[OBD:M3GA|00598-.M3GA]] }}
{{OBDtr| 0x00 | int32    |FFC8C8| 01 56 02 00 | 598      | link to [[OBD:M3GA|00598-.M3GA]] - geometry (or a glued-together set of geometries) displayed for this object }}
{{OBDtr| 0x04 | link    |FFFFC8| 00 00 00 00 | unused    | link to an [[OBD:OBAN|OBAN]] file }}
{{OBDtr| 0x04 | link    |FFFFC8| 00 00 00 00 | unused    | link to [[OBD:OBAN|OBAN]] - animation played when the object is created; a different animation can be selected with env_setanim }}
{{OBDtr| 0x08 | link    |C8FFC8| 00 00 00 00 | unused    | link to an [[OBD:ENVP|ENVP]] file }}
{{OBDtr| 0x08 | link    |C8FFC8| 00 00 00 00 | unused    | link to [[OBD:ENVP|ENVP]] - particles attached to this object (e.g., vehicle headlights)}}
{{OBDtr| 0x0C | bitset  |C8FFFF| 00         | 0        | unknown; always zero; maybe an unused bistet }}
{{OBDtr| 0x0C | bitset32 |C8FFFF| 00 12 00 00 | in use, face collision | flags; the bits are as follows:
{{OBDtr| 0x0D | bitset  |C8FFFF| 12          | 18        | generic options; it's a bitset; the following options are used (values in dec):
:'''0x01''' 00 00 00 - never used in Vanilla data (unassigned; never used at all?)
:'''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)
:'''0x20''' 00 00 00 - never used in Vanilla data (unassigned; never used at all?)
:'''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; possibly useless
: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)
}}
{{OBDtr| 0x10 | int32    |FFC8FF| 46 89 00 00 | 35142    | the index of the doorframe GQ; used only for doors (0 for other objects)}}
{{OBDtr| 0x14 | int32    |FFC800| 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)}}
{{OBDtr| 0x18 | int32    |C800C8| 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 (same as "Newton"); response to external forces and collision (if any); never used in Vanilla data
:3 - Animated; used for non-doors
:4 - "Newton" (same as Linear); response to external forces and collision (if any); never used in Vanilla data
}}
{{OBDtr| 0x1C | int32    |C87C64| FF FF 00 00 | 65535    | script ID (for obj_create, env_setanim etc); doors use 65535 }}
{{OBDtr| 0x20 | vector  |B0C3D4| 00 00 4F 43 1F 05 F6 42 98 7F CC C3 |207.0 123.010002 -408.996826 | object position }}
{{OBDtr| 0x2C | quaternion|E7CEA5| 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 }}
{{OBDtr| 0x3C | float    |FFDDDD| 00 00 80 3F | 1.0  | object scale }}
|- ALIGN=CENTER VALIGN=TOP
|0x40||matrix
|BGCOLOR="#64aaaa"|
{|cellspacing=1 style="white-space:nowrap;width:100%;"
|-
|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
|}
|
{|cellspacing=1 style="white-space:nowrap;width:100%"
|-
|0.999999 || 0.0 || -0.000705
|-
| -0.000705 || 0.0 || -0.999999
|-
|0.0 || 1.0 || 0.0
|-
|207.0 || 123.010002 || -408.996826
|}
|ALIGN=LEFT|origin matrix
{{OBDtr2|0x70 | char[64] |EBEBEB| object_door_1          | name of the object; informational only }}
{{OBDtr2|0xB0 | char[64] |8C8CCC| L3_Gunk.ENV            | file name from which this object was created; informational only }}
|}


The primary use of this data is to display animated objects in the environment (cars, helis, fans etc.). "Physics" may also work 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 fall. The two flavors "Linear" and "Newton" are equivalent (if there ever were differences between the two, they are gone now).


:0 - nothing
:2 - package used
:4 - object is a blender
:16 - object is a door


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


}}
{{OBDtr| 0x0E | int16    |C8FFFF| 00 00      | 0        | unknown; always zero; maybe two unused bistets }}
{{OBDtr| 0x10 | int8    |FFC8FF| 46          | 70        | unknown }}
{{OBDtr| 0x11 | int8    |FFC8FF| 89          | 137      | unknown }}
{{OBDtr| 0x12 | int16    |FFC8FF| 00 00      | 0        | unknown; always zero }}
{{OBDtr| 0x14 | int8    |FFC800| 01          | 1        | door ID; only used for doors; id must be higher than zero }}
{{OBDtr| 0x15 | int8    |FFC800| 00          | 0        | double door (0 <nowiki>= no, 16 =</nowiki> yes; both values in dec) }}
{{OBDtr| 0x16 | int16    |FFC800| 00 00      | 0        | unknown; always zero }}
{{OBDtr| 0x18 | int32    |C800C8| 00 00 00 00 | 0        | unknown; the following values are used:


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''').


:0 - none
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).
:3 - OBAN link used
----
;Flags
:Besides the trivial "in use" flag, only two are used in Vanilla game data: "no collision" (possibly useless, because collision is off by default anyway) and "face collision" (used for doors).
:Some of the other flags (e.g. "particles created") are reserved for runtime use, others can be specified in game data. Some intriguing ones, like "light source", are completely defunct.


 
----
(note: doors don't have OBAN links) }}
;Empty array elements
{{OBDtr| 0x1C | int16    |C87C64| FF FF      | -1        | object ID (-1 <nowiki>=</nowiki> not used) }}
:The last 32 elements of a level's OBOA are always empty (all data values are zero). Below is an overview table for Vanilla levels (OBOA array size vs. number of actual door/object setups).
{{OBDtr| 0x1E | int16    |C87C64| 00 00      | 0         | unknown; always zero }}
{|border=1 cellspacing=0
{{OBDtr| 0x20 | float    |B0C3D4| 00 00 4F 43 |207.000000 | initial x-position }}
!level#_Final
{{OBDtr| 0x24 | float    |B0C3D4| 1F 05 F6 42 |123.010002 | initial y-position (height) }}
!1
{{OBDtr| 0x28 | float    |B0C3D4| 98 7F CC C3 |-408.996826| initial z-position }}
!2
{{OBDtr| 0x2C | float    |E7CEA5| F2 04 35 3F | 0.707107  | x component of the initial rotation quaternion }}
!3
{{OBDtr| 0x30 | float    |E7CEA5| 74 BC 82 B9 | -0.000249 | y component of the initial rotation quaternion }}
!4
{{OBDtr| 0x34 | float    |E7CEA5| 74 BC 82 B9 | -0.000249 | z component of the initial rotation quaternion }}
!6
{{OBDtr| 0x38 | float    |E7CEA5| F3 04 35 3F | 0.707107  | w component of the initial rotation quaternion }}
!8
{{OBDtr| 0x3C | float    |FFDDDD| 00 00 80 3F | 1.000000  | initial scale of the object }}
!9
{{OBDtr| 0x40 | float    |64AAAA| FC FF 7F 3F | 0.999999  | m11 element of the initial position transform matrix }}
!10
{{OBDtr| 0x44 | float    |64AAAA| 00 00 00 00 | 0.000000  | m21 element of the initial position transform matrix }}
!11
{{OBDtr| 0x48 | float    |64AAAA| 8A E3 38 BA | -0.000705 | m31 element of the initial position transform matrix }}
!12
{{OBDtr| 0x4C | float    |64AAAA| 8A E3 38 BA | -0.000705 | m12 element of the initial position transform matrix }}
!13
{{OBDtr| 0x50 | float    |64AAAA| 2E DE 4C 32 |0.000000...| m22 element of the initial position transform matrix }}
!14
{{OBDtr| 0x54 | float    |64AAAA| FC FF 7F BF | -0.999999 | m32 element of the initial position transform matrix }}
!18
{{OBDtr| 0x58 | float    |64AAAA| C9 F5 13 2D |0.000000...| m13 element of the initial position transform matrix }}
!19
{{OBDtr| 0x5C | float    |64AAAA| 00 00 80 3F | 1.000000  | m23 element of the initial position transform matrix }}
|-
{{OBDtr| 0x60 | float    |64AAAA| 2B DE 4C 32 |0.000000...| m33 element of the initial position transform matrix }}
!OBOA array size
{{OBDtr| 0x64 | float    |64AAAA| 00 00 4F 43 |207.000000 | m14 element of the initial position transform matrix (x-position) }}
|180
{{OBDtr| 0x68 | float    |64AAAA| 1F 05 F6 42 |123.010002 | m24 element of the initial position transform matrix (y-position, height) }}
|69
{{OBDtr| 0x6C | float    |64AAAA| 98 7F CC C3 |-408.996826| m34 element of the initial position transform matrix (z-position) }}
|98
{{OBDtr2|0x70 | char[64] |EBEBEB| object_door_1          | name of the object }}
|69
{{OBDtr2|0xB0 | char[64] |8C8CCC| L3_Gunk.ENV            | internal object file name; maybe an old development relict }}
|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
|}
|}
For a new level built from XML by OniSplit, there are also 32 empty elements at the end of the array. The purpose of these extra elements is not currently documented.




Elements m41, m42, m43, m44 of both transform matrices are missing. m41, m42 and m43 are the projection transform coefficients and they are not needed so they are 0.0 and the m44 element is always 1.0 for a transform matrix. (column major transform matrices like in Open GL, for Direct 3D they need to be transposed)
----
;M3GA use (single M3GM vs. actual sets of several M3GMs)
: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 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 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 the final chapter - but no, these are set up as separate "objects", with one M3GM per M3GA, animated synchronously. This is in contrast to the named M3GA 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: 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).
:Contiguous 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 hierarchy of contiguous objects in the original scene (as modeled by the developers) is typically not known. It would make sense for wheels/doors to be "parented" to a vehicle's chassis, but at Oni level there is no parenting, i.e., both the chassis and the wheels/doors are animated in world space.
:The order of script IDs for contiguous groups of objects is not a reliable indicator of hierarchy. Thus, recurrent 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.


The initial position transform is used the place the object in the environment. For object that have an animation attached to them this is also the starting position of the animation sequence. The initial x,y and z position value together with the initial rotation quaternion and the initial scale factor contain basically the same information as the initial transform matrix and combining them in a transform matrix should result in the initial transform matrix (less the differences due to floating point computation errors)


----
;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 Oni, but can be inferred through eponymous OBAN instances (object animations). OBAN are also used for cameras and "env-boxed" character animation (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 a.k.a. 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.


{{OBD_File_Footer | type=OBOA | prev=OBDC | next=OFGA | name=Starting Object Array | family=Level}}
{{OBD_File_Footer | type=OBOA | prev=OBDC | next=OFGA | name=Starting Object Array | family=Level}}
{{OBD}}