|
|
Line 12: |
Line 12: |
| ==Level releases, forum threads and wiki pages== | | ==Level releases, forum threads and wiki pages== |
| ;Custom levels that have been created so far | | ;Custom levels that have been created so far |
| | * [http://oni.bungie.org/community/forum/viewtopic.php?id=2656 Island Level] (7/9/13) uses level 29 |
| * [http://oni.bungie.org/community/forum/viewtopic.php?id=2640 City Level Part 1] (12/7/13) uses level 23 | | * [http://oni.bungie.org/community/forum/viewtopic.php?id=2640 City Level Part 1] (12/7/13) uses level 23 |
| * [http://oni.bungie.org/community/forum/viewtopic.php?id=2619 Fight Club] (1/6/13)uses level 25 | | * [http://oni.bungie.org/community/forum/viewtopic.php?id=2619 Fight Club] (1/6/13) uses level 25 |
| * [http://oni.bungie.org/community/forum/viewtopic.php?id=2357 Old China] (12/5/12)uses level 24 | | * [http://oni.bungie.org/community/forum/viewtopic.php?id=2357 Old China] (12/5/12) uses level 24 |
| * [http://oni.bungie.org/community/forum/viewtopic.php?id=2302 Boss Battle] (18/3/12) uses level 23 | | * [http://oni.bungie.org/community/forum/viewtopic.php?id=2302 Boss Battle] (18/3/12) uses level 23 |
| * [http://oni.bungie.org/community/forum/viewtopic.php?id=2242 Parkour Challenge 2] (23/1/12)uses level 21 | | * [http://oni.bungie.org/community/forum/viewtopic.php?id=2242 Parkour Challenge 2] (23/1/12) uses level 21 |
| * [http://oni.bungie.org/community/forum/viewtopic.php?id=2235 Parkour Challenge] (16/1/12)uses level 21 | | * [http://oni.bungie.org/community/forum/viewtopic.php?id=2235 Parkour Challenge] (16/1/12) uses level 21 |
| * [http://oni.bungie.org/community/forum/viewtopic.php?id=2001 Mini-Partenon] (25/7/11)level 5 | | * [http://oni.bungie.org/community/forum/viewtopic.php?id=2001 Mini-Partenon] (25/7/11)uses level 5 |
| * [http://oni.bungie.org/community/forum/viewtopic.php?id=1957 Hexagon] (3/7/11)level 16 | | * [http://oni.bungie.org/community/forum/viewtopic.php?id=1957 Hexagon] (3/7/11)level 16 |
| * [http://oni.bungie.org/community/forum/viewtopic.php?id=1938 Junkyard] (23/6/11)uses level 15 | | * [http://oni.bungie.org/community/forum/viewtopic.php?id=1938 Junkyard] (23/6/11) uses level 15 |
| * [http://oni.bungie.org/community/forum/viewtopic.php?id=1736 Arena] (8/11/10)uses level 7 | | * [http://oni.bungie.org/community/forum/viewtopic.php?id=1736 Arena] (8/11/10) uses level 7 |
| * [http://oni.bungie.org/community/forum/viewtopic.php?id=1506 Maze] (15/2/10)uses level 5 | | * [http://oni.bungie.org/community/forum/viewtopic.php?id=1506 Maze] (15/2/10) uses level 5 |
| * [http://oni.bungie.org/community/forum/viewtopic.php?id=2024 Muro's Lair - Preview] (3/10/11)uses level 20 | | * [http://oni.bungie.org/community/forum/viewtopic.php?id=2024 Muro's Lair - Preview] (3/10/11) uses level 20 |
|
| |
|
| ;OCF threads about level creation | | ;OCF threads about level creation |
Line 512: |
Line 513: |
| ;Explanation: | | ;Explanation: |
|
| |
|
| Player enters the TV, "targets_gone" gets triggered. The variable "inside_target_function" should be 0 be default, so we are entering now the first if statement. Next, we can assume that the player didn't destroy all glass objects, so "num_broken" will be less than 18: "targets_are_not_gone" gets called. | | Player enters the TV, "targets_gone" gets |
| | |
| The TV function "targets_gone" would be triggered every frame but "targets_are_not_gone" increases the pause between checks: The TV gets deactivated for 60 frames. Then the TV becomes enabled again and will start anew until all glass objects got destroyed or player left the TV.
| |
| | |
| Unnecessary "targets_gone" functions will do nothing because "inside_target_function" was set to 1 by the first one.
| |
| | |
| "targets_are_gone" eventually disables the TV to prevent memory overflow, the function contains also all things "[...]" that you want to happen after the glass target broke.
| |
| | |
| | |
| =====Texture exchange=====
| |
| BSL command supported by PC and Mac:
| |
| : env_texswap ID texture
| |
| | |
| Might be useful to switch on/off static and animated textures. (News screen: running or off or smashed. Lava stream: flowing or stagnating or cooled down. Etc.)
| |
| | |
| | |
| =====[http://softimage.wiki.softimage.com/xsidocs/tex_vcolor_CreatingColoratVerticesCAVMaps.htm Vertex coloring]=====
| |
| Observation: The sniper tower from level 19 Syndicate Mountain Compound can be isolated and re-imported as it is. It will appear quite dark.
| |
| | |
| If we remove "_color" from the object the shadows will be gone next time we import the tower.
| |
| | |
| Mod Tool: Explorer [8]
| |
| | |
| Object
| |
| |
| |
| +-- Polygon Mesh
| |
| |
| |
| +-- Cluster
| |
| |
| |
| +-- Polygon
| |
| | |
| |
| | +-- [...]
| |
| |
| |
| +-- NodeProperties
| |
| |
| |
| +-- '''_color'''
| |
| +-- texcoord (Explicit UVWs)
| |
| |
| |
| +-- Vertex_Color_Def
| |
| | |
| So, how do we modify that data?
| |
| | |
| | |
| '''Single object shading'''
| |
| | |
| If there's already a vertex color property you can use Shift + W to activate "Paint Vertex Color Tool". With Control + W you can change the brush color. R + Hold Click + Move Mouse let you change the Brush size. The more vertices (points) you have the more detailed you can make the shadows/colors. But keep in mind that too many polygons can destroy collision which make characters fall through the ground.
| |
| | |
| If there's no vertex color property the first use of Shift + W will create that property. But you can also manually create it via Property > Color at Vertices Map.
| |
| | |
| Here you can see one of my [http://youtu.be/zWT0-LsjjBU early attempts of vertex coloring]. --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 18:18, 16 March 2013 (CET)
| |
| | |
| | |
| '''Level-wide shading'''
| |
| | |
| {| style="float:right"
| |
| |[http://i305.photobucket.com/albums/nn207/unknownfuture/Oni_Galore_Images/3D_modding/light_test_modtool_zps9c453b41.png http://i305.photobucket.com/albums/nn207/unknownfuture/Oni_Galore_Images/3D_modding/light_test_modtool_tn_zps9a3a3f2e.png]
| |
| | |
| [http://i305.photobucket.com/albums/nn207/unknownfuture/Oni_Galore_Images/3D_modding/light_test_ingame_zps08118244.png http://i305.photobucket.com/albums/nn207/unknownfuture/Oni_Galore_Images/3D_modding/light_test_ingame_tn_zps967c06a9.png]
| |
| |}
| |
| | |
| To get a general shading/lightning you can set up light sources. "Infinite" lights are useful as global lighting while "Light Box", "Point", "Neon" and "Spot" are more suitable as local light sources. They can be accessed via Primitives > Light.
| |
| | |
| By default a Mod Tool scene has one Infinite light but it doesn't shine in every direction so you might want to add more Infinite lights. Let's say one Infinite light for each direction (+X, -X, +Y, -Y, +Z, -Z) with an intensity of circa 0.25 (night) or 0.75 (day).
| |
| | |
| The illumination of those lights can be integrated into the vertex color property. There's some information [http://oni.bungie.org/community/forum/viewtopic.php?pid=29089#p29089 at OCF], the quoted information is somewhat triple so don't get confused by it: at first detailed, then summarized, then a checklist.
| |
| | |
| Basically you can go with the checklist:
| |
| | |
| * Property > Color At Vertices Map
| |
| * Property > Render Map
| |
| * In render map property page, under Sampling select Vertices Only
| |
| * Under Surface Color choose Enable, then in the box below select Vertex _Color, if that option does not appear click on the New button next to it.
| |
| * Under Map select Illumination only
| |
| * Finally, click on the button Regenerate Maps...
| |
| | |
| This must be done for all objects separately.
| |
| | |
| : [https://dl.dropbox.com/u/139715/OniGalore/vertex_color_script.txt There's a script] which can apply vertex color and render maps to all '''selected''' objects. Load it into the script editor [alt] + [4] and hit [F5] to run it. (Be sure the script language was set to vb script.)
| |
| : The variable "overwrite_VC" can be changed.
| |
| :: With "1" all existing CAV maps of selected objects will be overwritten. This can take some time.
| |
| :: With "0" only selected objects without CAV maps will be the script's target.
| |
| | |
| | |
| '''Notes on ModTool view modes'''
| |
| * "Constant" let you see the colors of the vertex coloring only.
| |
| * "Textured Decal" let you see object textures only.
| |
| * "Shaded" let you see the illumination only.
| |
| * "Textured" let you see the textured object with illumination and vertex coloring.
| |
| | |
| | |
| '''env_shade'''
| |
| | |
| If you use env_shade use it with caution. It completely overwrites the vertex coloring.
| |
| | |
| # BSL command
| |
| # env_shade obj_id obj_id R G B
| |
|
| |
| # examples
| |
| env_shade 7 7 # object 7 will be black
| |
| env_shade 7 7 0 0 0 # object 7 will be black
| |
| env_shade 7 7 .31 .999 .5 # object 7 will be quite green
| |
| env_shade 7 10 1 1 1 # object 7, 8, 9, 10 lose all their shading
| |
| | |
| | |
| =====Shadow casting objects=====
| |
| Advantage: this can give the level a more realistic impression.
| |
| | |
| Disadvantage: High amount of new textures needed.
| |
| | |
| How to create shadow maps:
| |
| | |
| * http://www.game-artist.net/forums/support-tech-discussion/5622-burning-shadows-onto-texture-xsi.html
| |
| <!-- http://caffeineabuse.blogspot.de/2008/12/cast-shadow-only-lights-in-xsi.html might be also interesting -->
| |
| | |
| Notes on map options:
| |
| * "Surface color and illumination": outputs used texture with added shadows
| |
| ** can be used to replace original texture
| |
| * "illumination only": output a texture that only contains the shadows
| |
| ** can be used on a new overlying, transparent surface
| |
| | |
| For other approaches see [[Lightmapping_levels|HERE]].
| |
| | |
| | |
| ====<Rooms>====
| |
| The Rooms tag is mandatory. It contains an import path to BNV and ghosts (*.dae) which are used to create pathfinding grids. For information on binary data see [[OBD:AKVA|HERE]].
| |
| | |
| Exemplary code piece of the master xml file:
| |
| <Import Path="env/lab_bnv.dae"/>
| |
| | |
| | |
| '''Fundamentals'''
| |
| * '''BNV''' are '''volumes''' (sometimes also named '''rooms''') that have a pathfinding grid assigned to them.
| |
| * For practical reasons you only need '''floors and ramps''' to build BNV. (Like seen in [http://edt.oni2.net/images/Hideout_BNV.jpg HERE.])
| |
| ** A BNV polygon can consist of 3 or more points but it's recommended to use '''shapes with 4 points''' because the other shapes usually waste more grid space. At the moment you can import only '''[[wikipedia:Convex|convex]]''' shapes.
| |
| * Secondly there are so called '''ghosts''' (vertical quads) that connect '''neighbouring BNV'''. AI can transit BNV only through ghosts.
| |
| : OniSplit gives error messages for ghosts that don't have 2 neighbouring BNV, for example:
| |
| BNV Builder: Ghost 'grid2' has no '''adjacencies''' at <-72,41 1,999 -166,6> and <-71 1,999 -168,21>, ignoring
| |
| | |
| | |
| '''Tolerance values'''
| |
| * horizontal distance from ''room'' to ''ghost'': 1
| |
| * vertical distance from ''room'' to ''ghost'': 18
| |
| * ''ghost'' horizontal dimension must be bigger than 0
| |
| * under optimal circumstances pathfinding works on a plane that is +4 world units above or -0,5 beneath the pathfinding grid
| |
| * normally characters can't pass low verticals like at staircases/curbs if those don't have a ramp, near ground level Y=0 is an exception where characters are allowed to step on a plane that is 4 world units above pathfinding grid; higher planes need a ramp
| |
| * max degree of ramp you can go on is 70°; bigger degrees make characters fall through to death (in those cases you might want to add invisible walls/boxes)
| |
| | |
| | |
| '''More notes on PF processing'''
| |
| * Actually, BNV and ghosts can have any name and don't need any texture.
| |
| * During pathfinding calculation OniSplit creates a new folder called "temp" and a subfolder "grids". There again is a file "''levelname''_grids.dae". That file contains ''rooms'' with textures "bnv_grid_''N''.tga" marking obstacles in the pathfinding. ''Ghosts'' will have a transparent texture "'''_marker_ghost'''.tga". You get those things also when you export a level. Transparent ''ghosts'' make it easier to see the rest of your level if you have many of those planes.
| |
| * In Mod Tool ''ghosts'' and ''rooms'' can be grouped under a null object. Right-click the null object to select all its children, then use "Selection Only [x]" as saving option. That way all the planes can be quickly saved to a *.dae file.
| |
| * You can influence the pathfinding creation of dangerous zones with danger quads. Read on [[#marker textures|HERE]].
| |
| * Another kind of influence is the [[#<Model>|gunk flag]] IgnoreGrid. It can be used to let OniSplit ignore the object during pathfinding creation. The grids in that place will be white.
| |
| | |
| | |
| [[Image:Pathfinding_grid.JPG|thumb|200px|right|''ai2_showgrids = 1'' in action]]
| |
| '''BSL commands'''
| |
| * chr_show_bnv = 1
| |
| :: shows number of bnv the player is standing on
| |
| * ai2_showgrids = 1
| |
| :: shows pathfinding grids
| |
| * ai2_chump
| |
| :: spawns a friendly striker that follows the player if possible, makes also pathfinding grids visible
| |
| * ai2_chump_stop = 1
| |
| :: striker stops to follow you
| |
| * ai2_chump_stop = 0
| |
| :: striker follows you again
| |
| | |
| | |
| =====Pathfinding on uneven ground=====
| |
| Pathfinding works on slight uneven ground as long as the polygons are 0,5 world units beneath or 4 world units above the BNV.
| |
| | |
| For bigger surface irregularities we can use a trick:
| |
| * The problematic polygons must be saved to an dae file and then referenced in the model section as an individual object.
| |
| * Then the <GunkFlags> tag needs to be '''''GridIgnore'''''.
| |
| * Additionally we create a plain (invisible if necessary) under the object so that Oni doesn't think there's a hole.
| |
| * The ghosts must be taller than the highest polygon to walk on. (This has been tested up to a height of 2000 world units.)
| |
| | |
| | |
| '''Symptoms of too small ghosts'''
| |
| | |
| A) AI can't run at all.
| |
| | |
| B) AI loses PF if tracked enemy performs animations that are out of the pathfinding volume. [http://youtu.be/vfKPzP5hiCo Here's] a video about of the "B" symptoms.
| |
| | |
| | |
| '''Missing boundaries'''
| |
| | |
| Let's say you have a BNV, tall ghosts, and a GridIgnore-flagged hill with trees and brushes and stuff.
| |
| | |
| Why do AI run against the trees?
| |
| : '''Cause:''' There are no red/orange grids that limits the AI movement. Normally, objects will produce red pathfinding grids. But objects that are 20 world units above the BNV are ignored just like objects with the IgnoreGrid flag.
| |
| : '''Solution:''' Add simple geometries like ''_marker_impassable fences'' or danger quads near the BNV.
| |
| | |
| | |
| '''Disappearing AIs'''
| |
| | |
| The ground is sometimes not solid. Then player and AIs will fall through it.
| |
| | |
| There's another case of disappearing AIs and it happens even if the ground is solid: on GridIgnore-flagged uneven ground AIs can fall through when they get out of view. Use one of these two BSL commands to avoid this problem:
| |
| : chr_lock_active ''AI_name''
| |
| : chr_all_active = 1
| |
| | |
| | |
| =====Debugging (OniSplit v0.9.93.0+)=====
| |
| * '''env_show_ghostgqs = 1''' makes the ghost quads visible
| |
| ** the original ghost quads can't be seen, Neo: "they are not included in the octtree and bsp tree"
| |
| ** to see them you must use the -debug option in the level creation command (available with OniSplit '''v0.9.93.0+''')
| |
| OniSplit.exe -create:level ''output_folder'' '''-debug''' ''input_folder''/''master_xml_file''.xml
| |
| | |
| Not all debugging/testing needs to be done in Oni. There also a [http://mods.oni2.net/node/256 file browser] which can display the whole level.
| |
| | |
| For example you can load an AKEV*.oni, select the level name and use hotkeys [B] and [P] to display BNV and ghosts.
| |
| | |
| | |
| ====[[#textures_tag|<Textures>]]====
| |
| =====... used for exceptions=====
| |
| This tag is mandatory.
| |
| | |
| AKEV textures will be imported by the master xml file automatically, you don't need to write them into that file.
| |
| | |
| : With OniSplit v0.9.82-93.0, the textures' formats will be DXT1 and BGRA4444 (for transparent ones).
| |
| : With OniSplit v0.9.94.0+ the textures' formats will be BGR and RGBA (for transparent ones).
| |
| | |
| To change the default texture import format, use the Texture'''s''' tag. (Possible with OniSplit v0.9.94.0+)
| |
| | |
| To change the format/flag/gunkflag of a specific texture, use the Texture tag.
| |
| | |
| An example:
| |
| | |
| <Textures Format="BGR" AlphaFormat="RGBA" MaxSize="512">
| |
| <Texture Name="GOO">
| |
| <Flags>TwoSided</Flags>
| |
| <Format>BGRA4444</Format>
| |
| <GunkFlags>NoCollision</GunkFlags>
| |
| <Image>env/images/GOO.tga</Image>
| |
| </Texture>
| |
| </Textures>
| |
| | |
| * Use gunkflag "TwoSided" to make surfaces visible from both sides.
| |
| * If the texture comes with gunkflag "NoCollision" then all objects with that texture will have no collision. Characters would fall through it.
| |
| | |
| Transparency and no collision makes both sense, let's say, for a water-like substance. The biolab use this for an area with green acid.
| |
| | |
| {| style="float:right"
| |
| |[http://i305.photobucket.com/albums/nn207/unknownfuture/Oni_Galore_Images/3D_modding/making_a_surface_transparent_and_twosided_zpsa8950d1f.png http://i305.photobucket.com/albums/nn207/unknownfuture/Oni_Galore_Images/3D_modding/making_a_surface_transparent_and_twosided_tn_zpsae6709f0.png]
| |
| | |
| '''Figure 1'''
| |
| |}
| |
| | |
| [[Image:AKEV_single_object_multiple_textures.png|thumb|200px|right|'''Figure 2'''<br>one object with multiple textures, one per polygon cluster]]
| |
| [[Image:AKEV_single_object_multiple_textures_ingame.png|thumb|200px|right|'''Figure 3'''<br>blue: twosided<br>glass: twosided and transparent<br>random metal: no flag (onesided)]]
| |
| | |
| | |
| '''TwoSided and transparent objects'''
| |
| | |
| It's also possible to set this in Mod Tool. Use one image source for diffuse and transparency.
| |
| | |
| It won't work with two image sources even if both sources use the same image. See '''Figure 1'''.
| |
| | |
| | |
| =====Regular textures=====
| |
| OniSplit automatically imports textures of objects in the [[#<Model>|<Model> section]]. Those objects could be considered as AKEV core geometry.
| |
| | |
| | |
| '''one texture per object'''
| |
| | |
| Furniture and Physics objects are allowed to have only one texture per object.
| |
| | |
| AKEV core geometry can have one texture or multiple textures - that's up to you to decide.
| |
| | |
| | |
| '''Multiple textures per object'''
| |
| | |
| '''Question:''' How do we apply multiple textures to an AKEV core object?
| |
| | |
| '''Answer:''' Assuming you are using Mod Tool the procedure will be like this. Repeat this for each cluster you create (except for projection). See also '''Figure 2 and 3'''.
| |
| | |
| * select some polygons
| |
| * goto Material > Phong
| |
| * hit [7] to open Render Tree
| |
| * add a texture and connect "Image" with "Phong", choose "diffuse" as illumination mode
| |
| * double-click "Image" to open Material page
| |
| * in Texture Projection section, click on "New" and choose a suitable projection
| |
| ** do this only if there isn't a projection in the "Texture_Coordinates_AUTO" cluster yet
| |
| ** OniSplit processes only one texture projection, see '''Figure 4'''
| |
| * choose texture and UV, fine-tune UV via [alt]+[7]
| |
| | |
| | |
| [[Image:AKEV_multiple_textures_one_projection.png|thumb|200px|right|'''Figure 4'''<br>use only one texture projection per object]]
| |
| | |
| | |
| Caution: textures will be fixed to one set of flags. You can't use the same texture A for an onesided cluster/object B and twosided cluster/object C. You would need to create a different named clone of that texture and apply that to cluster/object C.
| |
| | |
| | |
| =====Marker textures=====
| |
| Marker textures are used to import certain objects with special flags. Import those object alongside [[#<Model>|AKEV core]] geometry.
| |
| | |
| Marker textures aren't imported automatically. Add those textures to the final package / plugin, e.g. by some sort of batch code.
| |
| | |
| OniSplit.exe -create:txmp out env/markers/*.tga
| |
| | |
| | |
| The flags Transparent TwoSided NoOcclusion are only set if the same texture source is used for diffuse and transparency and if transparency setting are enabled. See subsection of "[[#... used for exceptions|... used for exceptions]]": "TwoSided and transparent objects".
| |
| | |
| | |
| '''danger quads'''
| |
| | |
| The pathfinding grids can have different colors with different meanings.
| |
| * white/gray - clear space
| |
| * green light - nearwall
| |
| * green - semipassable
| |
| * green dark - stairs
| |
| * blue very light - border 1
| |
| * blue light - border 2
| |
| * blue - border 3
| |
| * blue dark - border 4
| |
| * '''orange - danger'''
| |
| * red - impassable
| |
| | |
| For detailed information on colors see [[OBD_talk:AKVA/0x24#EFFECTS_of_various_pathfinding_grid_tile_types|HERE]].
| |
| | |
| Normally, OniSplit decide how to color the grids. But it's possible to add own danger quads to fine tune zones of great danger. Those orange areas will be generated with the 4 different blue borders around it.
| |
| | |
| Danger quads must have "'''_marker_danger'''" as texture name.
| |
| | |
| Results in flags: Transparent TwoSided NoCollision Invisible NoOcclusion Danger
| |
| | |
| | |
| '''collision boxes'''
| |
| | |
| AIs can get stuck in detailed geometry. This can be prevented with collision boxes.
| |
| | |
| Just create a box or other simple geometry around the problematic object and apply a textured to it named "'''_marker_barrier'''". Ingame the box will be invisible and has collision so characters can't get through. The pathfinding grid will be red where it comes in contact with the box, red is followed by a light green and then green.
| |
| | |
| Results in flags: Transparent TwoSided Invisible NoObjectCollision NoOcclusion
| |
| | |
| | |
| '''stairs'''
| |
| | |
| texture: '''_marker_stairs'''
| |
| | |
| Normally, characters can't move on stairs if they contain verticals. In this case you can use a sloping quad that is above or inside the staircases. It's possible to set the desired flags at the <Model> section but doing so and exporting self-made stair ramps is wasted time. So apply simply _marker_stairs to that quad, characters will move on that surface.
| |
| | |
| Results in flags: Stairs Transparent TwoSided Invisible NoObjectCollision NoOcclusion
| |
| | |
| No effect to pathfinding creation. Regularly textured stair geometry (that intersect the marker quad) will be flagged as NoCharacterCollision.
| |
| | |
| | |
| '''impassable'''
| |
| | |
| texture: '''_marker_impassable'''
| |
| | |
| Results in flags: Transparent TwoSided Invisible NoOcclusion
| |
| | |
| Impassable walls are very similar to collision boxes except that particle can also collide with it. The pathfinding grids will be also red, light green, and green.
| |
| | |
| | |
| '''blackness a.k.a. jello fix'''
| |
| | |
| texture: '''_marker_blackness'''
| |
| | |
| Results in flags: TwoSided NoCollision
| |
| | |
| Simply black walls. No effect to pathfinding creation.
| |
| | |
| | |
| '''doors'''
| |
| | |
| texture: '''_marker_door'''
| |
| | |
| Results in flags: DoorFrame Transparent TwoSided NoCollision NoOcclusion
| |
| | |
| Don't use this.
| |
| | |
| | |
| ====<Objects>====
| |
| Information on regular object collections can be looked up here:
| |
| : [[XML:BINA/OBJC/CHAR|Character.xml]] (has to contain player character if there's no AISA file with it)
| |
| : [[XML:BINA/OBJC/CONS|Console.xml]]
| |
| : [[XML:BINA/OBJC/DOOR|Door.xml]]
| |
| : [[XML:BINA/OBJC/FLAG|Flag.xml]]
| |
| : [[XML:BINA/OBJC/NEUT|Neutral.xml]]
| |
| : [[XML:BINA/OBJC/PART|Particle.xml]]
| |
| : [[XML:BINA/OBJC/PATR|PatrolPath.xml]]
| |
| : [[XML:BINA/OBJC/PWRU|PowerUp.xml]]
| |
| : [[XML:SNDD#BINACJBOSound.xml|Sound.xml]]
| |
| : [[XML:BINA/OBJC/TRIG|Trigger.xml]]
| |
| : [[XML:BINA/OBJC/TRGV|TriggerVolume.xml]]
| |
| : [[XML:BINA/OBJC/WEAP|Weapon.xml]]
| |
| | |
| | |
| =====Furniture.xml=====
| |
| The AKEV core geometry is more or less unique while this furniture file adds standard objects (e.g. crates and desks) to it.
| |
| | |
| {| class="wikitable" width="100%"
| |
| !width=150px| XML tag
| |
| !width=120px| content type
| |
| ! description
| |
| |-
| |
| | <?xml version="1.0" encoding="utf-8"?>
| |
| |valign="top"| float, flag
| |
| |valign="top"| Ignore this.
| |
| |-
| |
| | <Oni>
| |
| | -
| |
| |
| |
| |-
| |
| | <Objects>
| |
| | -
| |
| | This tag marks the file as BINACJBO.
| |
| |-
| |
| | <Furniture>
| |
| | -
| |
| | This tag marks the file as FURN.
| |
| |-
| |
| | <Header>
| |
| |
| |
| |
| |
| |-
| |
| |valign="top"| <Flags>
| |
| |valign="top"| flag
| |
| | Optional tag. Ignore it. Those flags were used in the past.
| |
| :None
| |
| :Locked
| |
| :PlacedInGame
| |
| :Temporary
| |
| :Gunk
| |
| |-
| |
| | <Position>
| |
| | float x3
| |
| | Optional tag. X Y Z position.
| |
| |-
| |
| | <Rotation>
| |
| | float x3
| |
| | Optional tag. X Y Z rotation.
| |
| |-
| |
| | <OSD>
| |
| | -
| |
| |
| |
| |-
| |
| |valign="top"| <Class>
| |
| |valign="top"| link
| |
| | File path to an [[XML:OFGA|OFGA]] (*.oni) file. Make sure that the OFGA comes also with the files it needs: M3GM and TXMP.
| |
| | |
| OFGA can hold multiple M3GM. That 3d content will be integrate into the AKEV.
| |
| |-
| |
| |valign="top"| <Particle>
| |
| |valign="top"| string
| |
| | This name gets written into <Tag> inside ONLV (ENVP section) and can be used with BSL commands.
| |
| | |
| E.g. you can take control over a particle via "particle BSL_name start". For more commands see [[XML:BINA/OBJC/PART#BSL_support|HERE]].
| |
| | |
| Caution with new OFGA files. The particle name will be composed of 2 parts and always includes an "_" underscore. '''Examples:'''
| |
| | |
| : FURN <Particle>test</Particle> + OFGA <Tag>streetlight</Tag> = '''test_streetlight'''
| |
| : FURN <Particle></Particle> + OFGA <Tag>streetlight</Tag> = '''_streetlight'''
| |
| : FURN <Particle>test</Particle> + OFGA <Tag></Tag> = '''test_'''
| |
| |}
| |
| | |
| | |
| ;Example
| |
| | |
| <?xml version="1.0" encoding="utf-8"?>
| |
| <Oni>
| |
| <Objects>
| |
| | |
| <Furniture>
| |
| <Header>
| |
| <Flags>Gunk</Flags>
| |
| <Position>-62.692 -29 108.35</Position>
| |
| <Rotation>181.522 356.021 178.114</Rotation>
| |
| </Header>
| |
| <OSD>
| |
| <Class>furniture/V_tctf_bigvan.oni</Class>
| |
| <Particle></Particle>
| |
| </OSD>
| |
| </Furniture>
| |
| | |
| </Objects>
| |
| </Oni>
| |
| | |
| | |
| =====Physics.xml=====
| |
| This file is for objects with "physics". Unlike AKEV core geometry or furniture, those objects can be animated.
| |
| | |
| : Little video tutorial: how to create [http://www.youtube.com/watch?v=ufDqgTXD7lQ a simple animated object]
| |
| | |
| {| class="wikitable" width="100%"
| |
| !width=150px| XML tag
| |
| !width=120px| content type
| |
| ! description
| |
| |-
| |
| | <?xml version="1.0" encoding="utf-8"?>
| |
| |valign="top"| float, flag
| |
| |valign="top"| Ignore this.
| |
| |-
| |
| | <Oni>
| |
| | -
| |
| |
| |
| |-
| |
| | <Physics>
| |
| | -
| |
| |
| |
| |-
| |
| | <Object Name="...">
| |
| | string
| |
| | Use an unique name for each object.
| |
| |-
| |
| |valign="top"| <ScriptId>
| |
| |valign="top"| integer
| |
| | Tested with BSL command ...
| |
| :obj_create Id [Id]
| |
| :obj_kill Id [Id]
| |
| :env_anim Id [Id]
| |
| :env_setanim Id [Id]
| |
| The script Id will be stored in ONLV's OBOA instance.
| |
| |-
| |
| |valign="top"| <Flags>
| |
| |valign="top"| flag
| |
| |
| |
| ;Object setup flags
| |
| :None
| |
| :InUse
| |
| :NoCollision
| |
| :NoGravity
| |
| :FaceCollision
| |
| |-
| |
| |valign="top"| <Physics>
| |
| |valign="top"| flag
| |
| | Optional tag of Object.
| |
| :None
| |
| :Static
| |
| :Linear
| |
| :Animated
| |
| :Newton (used with <Flags> FaceCollision to [http://www.youtube.com/watch?v=YICB7qugrtc make object pushable])
| |
| :: For a pushable object don't use import sub-tags such as animation name, flags, etc. Just use <Import Path="..." '''/'''> or <Import Url="..." '''/'''>
| |
| |-
| |
| | <Position>
| |
| | float x3
| |
| | Optional tag of Object. Only used for non-animated objects. X Y Z position.
| |
| |-
| |
| | <Rotation>
| |
| | float x3
| |
| | Optional tag of Object. Only used for non-animated objects. X Y Z rotation.
| |
| |-
| |
| | <Scale>
| |
| | float
| |
| | Optional tag of Object. Only used for non-animated objects.
| |
| |-
| |
| |
| |
| <Import Path="...">
| |
| | |
| <Import Url="...">
| |
| |valign="top"| link
| |
| |valign="top"| This tag comes in two variants. It doesn't matter what variant you use.
| |
| |-
| |
| | <Animation Name="...">
| |
| | link
| |
| | File path to *.dae file.
| |
| |-
| |
| |valign="top"| <Flags>
| |
| |valign="top"| flag
| |
| | Optional tag of Animation. For more information on those flags look [[XML:OBAN|OBAN]] page.
| |
| | |
| ;Object animation flags
| |
| :None
| |
| :Loop
| |
| :PingPong
| |
| :RandomStart
| |
| :AutoStart
| |
| :Local
| |
| |-
| |
| | <End>
| |
| | integer
| |
| | Optional tag of Animation. Frame number. Used to define the end of an OBAN from an *.dae file.
| |
| |-
| |
| | <Start>
| |
| | integer
| |
| | Optional tag of Animation. Frame number. Used to define the start of an OBAN from an *.dae file.
| |
| |}
| |
| | |
| | |
| ;Example
| |
| | |
| For documentation purpose the file here has been trimmed down.
| |
| <?xml version="1.0" encoding="utf-8"?>
| |
| <Oni>
| |
| <Physics>
| |
| | |
| <Object Name="motorcycle">
| |
| <ScriptId>8</ScriptId>
| |
| <Flags>FaceCollision</Flags>
| |
| <Import Url="motorcycle/export.dae">
| |
| <Animation Name="motorcycle02">
| |
| <Flags>AutoStart</Flags>
| |
| <End>880</End>
| |
| </Animation>
| |
| <Animation Name="motorcycle02_stop">
| |
| <Start>881</Start>
| |
| </Animation>
| |
| </Import>
| |
| </Object>
| |
| | |
| </Physics>
| |
| </Oni>
| |
| | |
| In this example OniSplit takes the "export.dae" file, looks what parts it contains and creates geometry files from it.
| |
| * M3GMhubs_rear.oni
| |
| * M3GMhubs.oni
| |
| * M3GMmotocycle.oni
| |
| It's a nice feature that hierarchies are supported here.
| |
| | |
| The motorcycle is made of 3 parts so 3 object animations ([[XML:OBAN|OBAN]]) will be created up to frame 880. Then OniSplit creates 3 more OBANs starting from frame 881.
| |
| | |
| The reason for the interruption at frame 880 is probably to give barabas a few more frames of glory in the cutscene.
| |
| * OBANmotorcycle0200.oni
| |
| * OBANmotorcycle0201.oni
| |
| * OBANmotorcycle0202.oni
| |
| * OBANmotorcycle02_stop00.oni
| |
| * OBANmotorcycle02_stop01.oni
| |
| * OBANmotorcycle02_stop02.oni
| |
| | |
| | |
| ;Notes about BSL usage:
| |
| | |
| The bio lab script file use the motorcycle objects and animations like this:
| |
| env_show 9 0 # hide static motorcycle parts (because they get visible at level start)
| |
| # in the original game the motorcycle is separated in object 8, 9 and 10
| |
| # also the OBAN files have a bit different names
| |
|
| |
| # static and animated objects are totally independent from each other
| |
| # they are stored in different arrays so their script ids can be the same or different
| |
|
| |
| obj_create 8 10 # create animation-ready motorcycle parts
| |
| env_anim 8 10 # animate those parts (not necessary if OBAN flag is "AutoStart")
| |
|
| |
| # the first animations would loop because of "AutoStart"
| |
| # so get the right timing to apply the other animations
| |
| # "motorcycle02_stop00" and the others will not loop because they don't have "AutoStart"
| |
| env_setanim 8 motorcycle02_stop00 # motorcycle
| |
| env_setanim 9 motorcycle02_stop01 # hubs
| |
| env_setanim 10 motorcycle02_stop02 # hubs_rear
| |
|
| |
| obj_kill 8 10 # delete animated parts
| |
| env_show 9 1 # show static motorcycle parts
| |
| | |
| | |
| ====corpse array (CRSA)====
| |
| As far as I know, direct CRSA import is not yet supported.
| |
| | |
| I simply put this section here because I hope Neo will soon integrate it. --[[User:Paradox-01|paradox-01]] ([[User talk:Paradox-01|talk]]) 17:28, 28 December 2013 (CET)
| |
| | |
| (You can try to edit the final ONLV*.oni on your own. See [[XML:ONLV#CRSA|HERE]].)
| |
| | |
| I only tried it once like an year ago, probably something was wrong with it.
| |
| | |
| Recently I tried to do similar with xml editing.
| |
| | |
| :Oni gets body parts by reading the referenced ONCC file and its links until it gets the 3D content
| |
| | |
| :So far the theory. In praxis the model will appear differently.
| |
| | |
| :While a folded (not ''animated'') corpse imports fine, a corpse with rotated bones becomes a mess.
| |
| | |
| :I tried rotations with [https://dl.dropboxusercontent.com/u/139715/OniGalore/local_correct_pelvis.png local] and [https://dl.dropboxusercontent.com/u/139715/OniGalore/global.png global] values, both ended up in a messed up state.
| |
| | |
| :With local values at least the pelvis looks correct.
| |
| | |
| :So what's the problem?
| |
| | |
| :: When we look at character animations (TRAM), for instance, the rotations of the right fist are just delta values of the right wrist, and right wrist holds only the delta values of the right arm, and so on.<br>So the final x y z rotation of the right fist is its own rotation plus all rotations down to the pelvis.
| |
| | |
| :: This method doesn't seem true for CRSA. With local rotations used, the pelvis was spawned correctly but not the other parts.
| |
| | |
| :: Due to this observations I think each body part is looked up separately which means for Oni to build the corpse with no hierarchal structure.
| |
| | |
| :: To test this I took a character, rotated the parts, and [[Mod_Tool#Exchange_meshes_in_hierarchies|destroyed]] the hierarchy revealing the true local rotation values of each part.
| |
| | |
| :: Those rotations and positions where entered into [https://dl.dropboxusercontent.com/u/139715/OniGalore/OniMatrix_src.zip Neo's matrix program.] I then put the matrix to into the CRSA instance of the extracted ONLV file, then reconverted to oni.
| |
| | |
| :: Ingame, the corpse was [https://dl.dropboxusercontent.com/u/139715/OniGalore/CRSA_manually_imported.png looking quite good.] There were some tiny difference which possibly come from the fact that the matrix program works with integers and not float values.
| |
| | |
| ::: Here's an [https://dl.dropboxusercontent.com/u/139715/temp/snipers.dae example] of an intact and a destroyed hierarchy.
| |
| | |
| ::: Note to self: [https://dl.dropboxusercontent.com/u/139715/OniGalore/ModToolScript/CRSA_wip.txt old code] meant for intact hierarchies. Needs to be changed later for proper local values.
| |
| | |
| ::: Let's take intact character for a new experiment.
| |
| | |
| ::: When we apply null objects to each body part and compare its local values with the parts of the destroyed hierarchy, the values are the same, just multiplied by -1.
| |
| | |
| ::: Second experiment. When the parts in the intact hierarchy becomes rotated, the values will not fit. Not until we reset the null's global values to 0; 0; 0 and multiply by -1 again.
| |
| | |
| ::: What does this mean?
| |
| | |
| :::: Still I've no clue how to ''calculate'' the required values but with the null objects it got a lot easier to ''farm'' them.
| |
| | |
| :::: So coding a workaround became a feasible option.
| |
| | |
| | |
| ==Level reimport==
| |
| ===Export of static geometry===
| |
| After the oni files have been exported, the extraction of objects can fail if their textures can't be found. Those objects probably use textures stored in level 0.
| |
| | |
| In that case use the "-search" argument to make correct extractions. In total the commands will look like this:
| |
| | |
| OniSplit.exe -export level0_files level0.dat
| |
| OniSplit.exe -export levelX_files levelX.dat
| |
| OniSplit.exe -extract:dae levelX_geometry levelX_files/AKEV*.oni -search level0_files
| |
| | |
| Possible output files:
| |
| * ''level''_bnv.dae
| |
| * ''level''_cons.dae
| |
| * ''level''_door.dae
| |
| * ''level''_env.dae
| |
| * ''level''_env_markers.dae
| |
| * ''level''_furn.dae
| |
| * ''level''_script_''N''.dae (by OniSplit v0.9.90.0+)
| |
| * ''level''_trig.dae
| |
| * ''level''_turr.dae
| |
| | |
| | |
| ===Export of animated geometry and cameras (OniSplit v0.9.90.0+)===
| |
| This is also known as scene export. All content exported by the scene file will be combined and saved in one single dae.
| |
| | |
| OniSplit.exe -extract:dae path_to/output_directory path_to/scene.xml
| |
| | |
| For the following example the scene.xml must be present in a folder containing all files used by the scene. In this case it's level3_Final (biolab).
| |
| | |
| <Scene>
| |
| <Node Name="camera">
| |
| <Camera />
| |
| <Animation>OBANCamout01.oni</Animation>
| |
| <Animation>OBANCamout02.oni</Animation>
| |
| <Animation>OBANCamout03.oni</Animation>
| |
| <Animation>OBANCamout04.oni</Animation>
| |
| <Animation>OBANCamout05.oni</Animation>
| |
| <Animation>OBANCamout06.oni</Animation>
| |
| </Node>
| |
| <Node Name="motorcycle02">
| |
| <Geometry>M3GMmotorcycle02.oni</Geometry>
| |
| <Animation>OBANmotorcycle02.oni</Animation>
| |
| <Animation>OBANmotorcycle02_stop.oni</Animation>
| |
| <Node Name="hubs">
| |
| <Geometry>M3GMhubs.oni</Geometry>
| |
| <Animation>OBANhubs.oni</Animation>
| |
| <Animation>OBANhubs_stop.oni</Animation>
| |
| </Node>
| |
| <Node Name="hubs_rear">
| |
| <Geometry>M3GMhubs_rear.oni</Geometry>
| |
| <Animation>OBANhubs_rear.oni</Animation>
| |
| <Animation>OBANhubs_rear_stop.oni</Animation>
| |
| </Node>
| |
| </Node>
| |
| </Scene>
| |
| | |
| When you load the dae in [[Mod_Tool|XSI]] you'll find the motorcycle and the lab level intro camera. If you select the camera (for better visibility) and press play you'll get to see the motorcycle into animation like you see it in game.
| |
| | |
| For real-time playback click on "Playback" option button and then "Real-Time Playback".
| |
| | |
| | |
| ;File structure
| |
| * The scene contains one or more '''nodes'''.
| |
| * Each node represents '''either one 3D object or one camera''' whereby the node name determines the object name inside the dae.
| |
| ** 3D objects do have a '''<Geometry>''' tag.
| |
| ** Cameras do have a '''<Camera />''' tag.
| |
| ** Each 3D object or camera can have '''one or multiple <Animation>''' tags. Multiple animations will be combined.
| |
| ** 3D objects can be organized in a '''hierarchy''' that gets created by the help of '''sub-nodes'''. Each sub-node can also have animations.
| |
| | |
| | |
| ;Scene import
| |
| According to Neo that feature is still under development.
| |
| | |
| | |
| ===Recycle object collections===
| |
| Following files can be reused at <Objects> without any drawback:
| |
| * BINACJBOCharacter.xml
| |
| * BINACJBOFlag.xml
| |
| * BINACJBONeutral.xml
| |
| * BINACJBOParticle.xml
| |
| * BINACJBOPatrol Path.xml
| |
| * BINACJBOPowerUp.xml
| |
| * BINACJBOSound.xml
| |
| * BINACJBOTrigger Volume.xml
| |
| * BINACJBOWeapon.xml
| |
| | |
| | |
| ===Locklights===
| |
| Door locklights must be transfered by hand from old ONLV (ENVP instance) to a) new ONLV or b) CJBO particle file.
| |
| | |
| For method b) you could use [https://dl.dropboxusercontent.com/u/139715/OniGalore/extract_ENVP.vbs THIS] script. [http://youtu.be/8HbPeNYqdY0 Demo vid].
| |
| | |
| The advantage is that you don't need to edit the new ONLV afterwards.
| |
| | |
| | |
| ===CJBO and vertex coloring===
| |
| * Object (xml) import via <Object> tag (master xml file) will get you objects without vertex coloring. (onisplit will pick *.oni class files from the shared folder.)
| |
| * Object (dae) import via <Model> tag (master xml file) should get you objects with vertex coloring but no functions. In that case add corresponding CJBO files by hand.
| |
| | |
| You can chose between those two methods for consoles, triggers, turrets and furniture without particle.
| |
| | |
| Doors and furniture with particle need always the xml method.
| |
| | |
| | |
| ==Level export==
| |
| This section is only about xml files. For dae export see [[#Level_reimport|HERE]].
| |
| | |
| The most parts of an Oni level are made of ONLV and AKEV. For AKEV's xml tags see [[XML:AKEV|HERE]].
| |
| | |
| You would only want to export those two files as xml if you want to check if a texture or an object really made it into the level or not.
| |
| | |
| | |
| ===ONLV===
| |
| {| class="wikitable" width="100%"
| |
| !width=150px| XML tag
| |
| !width=120px| content type
| |
| ! description
| |
| |-
| |
| |valign="top"| <ONLV id="...">
| |
| |valign="top"| integer
| |
| | ONLV's instance number. Should be 0.
| |
| |-
| |
| |valign="top"| <Name>
| |
| |valign="top"| char[64]
| |
| | Name of BSL '''folder'''.
| |
| : Save game slot and level number are defined inside [[XML:ONLD|ONLD]].
| |
| |-
| |
| |valign="top"| <Environment>
| |
| |valign="top"| link
| |
| | Link to [[XML:AKEV|AKEV]] via '''file''' name (AKEV''name''), don't use file suffix .oni
| |
| : Level geometry.
| |
| |-
| |
| |valign="top"| <Objects>
| |
| |valign="top"| link
| |
| | Link to [[#OBOA|OBOA]] via '''instance''' number (#''N'').
| |
| : The OBOA instance holds doors, animated objects (usually for cut scenes) and pushable object (they are not used the original game).
| |
| |-
| |
| |valign="top"| <SkyBox>
| |
| |valign="top"| link
| |
| | Link to [[XML:ONSK|ONSK]] via '''file''' name (ONSK''name''), don't use file suffix .oni
| |
| : This is the sky box.
| |
| |-
| |
| |valign="top"| <Characters>
| |
| |valign="top"| link
| |
| | Link to [[XML:AISA|AISA]] via '''file''' name (AISA''name''), don't use file suffix .oni
| |
| : This "AI Setup Array" is an alternative character collection. [[XML:BINA/OBJC/CHAR|CHAR]] is more powerful.
| |
| |-
| |
| |valign="top"| <ObjectQuadMap>
| |
| |valign="top"| link
| |
| | Link to [[#ONOA|ONOA]] via '''instance''' number (#''N'').
| |
| : This "Object Array" holds functional objects - doors, furniture, turrets, triggers and consoles - in addition it appears that the engine only searches for door type.
| |
| |-
| |
| |valign="top"| <Particles>
| |
| |valign="top"| link
| |
| | Link to [[#ENVP|ENVP]] via '''instance''' number (#''N'').
| |
| : Those "Environment Particle" contains traditionally only door lock lights and particles used by [[XML:OFGA|OFGA]].
| |
| |-
| |
| |valign="top"| <Corpses>
| |
| |valign="top"| link
| |
| | Link to [[#CRSA|CRSA]] via '''instance''' number (#''N'').
| |
| : This is a "Corpse Array". It's used to 'spawn dead characters' like Chung in level 1.
| |
| |}
| |
| | |
| | |
| ===OBOA===
| |
| Used for movable/moving objects.
| |
| | |
| {| class="wikitable" width="100%"
| |
| !width=150px| XML tag
| |
| !width=120px| content type
| |
| ! description
| |
| |-
| |
| | <OBOA id="...">
| |
| | integer
| |
| | Instance Id. Should be 1.
| |
| |-
| |
| | <Objects>
| |
| | -
| |
| | Array of <OBOAObject> tags.
| |
| |-
| |
| | <OBOAObject>
| |
| | -
| |
| | There are always 32 empty objects plus those that are actually used.
| |
| |-
| |
| | <Geometry>
| |
| | "#" + integer
| |
| | Link to M3GA instance. -- Doors are made of two parts: an animated and a static part. If this <Geometry> links to a door it will be the animated part.
| |
| |-
| |
| | <Animation>
| |
| | link
| |
| | OBAN''name''
| |
| |-
| |
| | <Particle>
| |
| | # + integer
| |
| | Link to ENVP instance. -- There can be multiple ENVP instances. One for locklights and other for those kind of particle.
| |
| |-
| |
| |valign="top"| <Flags>
| |
| |valign="top"| flags
| |
| |
| |
| : None
| |
| : InUse
| |
| : NoCollision
| |
| : NoGravity
| |
| : FaceCollision
| |
| |-
| |
| | <DoorGunkId>
| |
| | int32
| |
| | the index of the door frame GQ for door objects?
| |
| |-
| |
| | <DoorId>
| |
| | int32
| |
| | only used for doors; in the case of double doors both doors have the same id and they are flagged as "InUse FaceCollision"
| |
| |-
| |
| |valign="top"| <PhysicsType>
| |
| |valign="top"| flags
| |
| |
| |
| : None
| |
| : Static
| |
| : Linear (?)
| |
| : Animated (animated via OBAN)
| |
| : Newton (pushable object)
| |
| |-
| |
| | <ScriptId>
| |
| | int32
| |
| | script Id; used by BSL function obj_create; 65535 = not used
| |
| |-
| |
| | <Position>
| |
| | vector
| |
| | Float x3. Not used for animated objects.
| |
| |-
| |
| | <Rotation>
| |
| | quaternion
| |
| | Float x4. Not used for animated objects.
| |
| |-
| |
| | <Scale>
| |
| | float
| |
| | Not used for animated objects.
| |
| |-
| |
| | <Transform>
| |
| | matrix
| |
| | Float 3*3 + 3 more float for X Y Z position of the object. For more information on the matrix see [[OBD:CRSA]]. Used for animated objects.
| |
| |-
| |
| | <Name>
| |
| | char[64]
| |
| | name of the object; informational only
| |
| |}
| |
| | |
| | |
| ===ONOA===
| |
| Used by static objects (imported by object collections).
| |
| | |
| {| class="wikitable" width="100%"
| |
| !width=150px| XML tag
| |
| !width=120px| content type
| |
| ! description
| |
| |-
| |
| | <ONOA id="...">
| |
| | integer
| |
| | Instance Id.
| |
| |-
| |
| | <Elements>
| |
| | -
| |
| | This is an int32 array for the <ONOAElement> tags.
| |
| |-
| |
| | <ONOAElement>
| |
| | -
| |
| |
| |
| |-
| |
| |valign="top"| <ObjectId>
| |
| |valign="top"| integer
| |
| | Object Id and type to which this quad belongs (see AKEV's [[XML:AKEV#AGQG|AGQG]] for details).
| |
| : Actual object Ids can also be found in BINA/OBJC/####.
| |
| |-
| |
| | <QuadList>
| |
| | "#" + integer
| |
| | Link to IDXA instance. Each object has its own IDXA instance.
| |
| |}
| |
| | |
| Where do the links go to again?
| |
| | |
| ONOA <ObjectId> -> AKEV AGQG -> BINA/OBJC/#### by type and Id
| |
| ONOA <QuadList> -> ONOA IDXA -> AKEV AGQG by order
| |
| | |
| | |
| ===ENVP===
| |
| {| class="wikitable" width="100%"
| |
| !width=150px| XML tag
| |
| !width=120px| content type
| |
| ! description
| |
| |-
| |
| | <ENVP id="...">
| |
| | integer
| |
| | Instance Id.
| |
| |-
| |
| | <Particles>
| |
| | -
| |
| | This is an int16 array for the <ENVPParticle> tags. If there's no content <Particles /> is used.
| |
| |-
| |
| | <ENVPParticle>
| |
| | -
| |
| |
| |
| |-
| |
| | <Class>
| |
| | char[64]
| |
| | <font color="#777777">BINA3RAP</font>file<font color="#777777">.oni</font> <font color="#777777">(don't use file prefix/suffix)</font>
| |
| |-
| |
| | <Tag>
| |
| | char[48]
| |
| | particle's name for BSL commands, see [[OFGA#tags|OFGA]] for more information on name composition
| |
| |-
| |
| | <Transform>
| |
| | matrix
| |
| | Float 3*3 + 3 more float for X Y Z position of the particle. For more information on the matrix see [[OBD:CRSA]].
| |
| |-
| |
| | <DecalScale>
| |
| | int32, int32
| |
| | X Y
| |
| |-
| |
| |valign="top"| <Flags>
| |
| |valign="top"| flag
| |
| |
| |
| : None
| |
| : NotInitiallyCreated
| |
| |}
| |
| | |
| | |
| ===CRSA===
| |
| Wanted: "how to add corpses" tutorial
| |
| | |
| : Some related information can be found at [[AE:Authoring_custom_camera_animations|AE:Authoring custom camera animations]]
| |
| | |
| {| class="wikitable" width="100%"
| |
| !width=150px| XML tag
| |
| !width=120px| content type
| |
| ! description
| |
| |-
| |
| | <CRSA id="...">
| |
| | integer
| |
| | Instance Id.
| |
| |-
| |
| |valign="top"| <FixedCount>
| |
| |valign="top"| integer
| |
| | The array capacity <Corpses> is larger than the number of "fixed"/"used" corpses to allow the engine to store new corpses at runtime. "Fixed" means that those corpses are never overwritten/deleted at runtime, all new corpses are stored after the "fixed" ones. This means that "fixed" <= "used" <= "capacity".
| |
| |-
| |
| | <UsedCount>
| |
| | integer
| |
| |
| |
| |-
| |
| |valign="top"| <Corpses>
| |
| |valign="top"| -
| |
| | This is an int32 array for the <CRSACorpse> tags. By default Oni wants 20 slots for corpses. Unused corpses have their matrix and bounding box filled with zeros.
| |
| |-
| |
| |valign="top"| <CRSACorpse>
| |
| |valign="top"| -
| |
| | [[AE:Authoring_custom_camera_animations|New corpses]] can be made with BSL command "make_corpse filename" and some hex-editing.
| |
| : The pose of the corpse is taken from the player character.
| |
| : The contents of the files thus created can then be inserted as elements in a level's CRSA.
| |
| |-
| |
| | <CharacterClass>
| |
| | link
| |
| | [[XML:ONCC|ONCC]]''name''
| |
| |-
| |
| | <Transforms>
| |
| | -
| |
| | There are 19 <Matrix4x3> for each <Transforms> (which represents a body part).
| |
| |-
| |
| | <Matrix4x3>
| |
| | matrix
| |
| | Float 3x3 + float x3 for the last 3 values (X Y Z position). For more information about the matrix see [[OBD:CRSA]].
| |
| |-
| |
| | <BoundingBox>
| |
| | -
| |
| | Bounding box of the whole corpse.
| |
| |-
| |
| | <Min>
| |
| | float x3
| |
| |
| |
| |-
| |
| | <Max>
| |
| | float x3
| |
| |
| |
| |}
| |
| | |
| | |
| ===M3GA===
| |
| One M3GA instance per animated object.
| |
| | |
| Animated meshes of doors are embedded in ONLV. All other animated meshes are stored outside as M3GM files.
| |
| | |
| {| class="wikitable" width="100%"
| |
| !width=150px| XML tag
| |
| !width=120px| content type
| |
| ! description
| |
| |-
| |
| | <M3GA id="...">
| |
| | integer
| |
| | Instance Id.
| |
| |-
| |
| | <Geometries>
| |
| | -
| |
| | This is an int32 array for the <Link> tags.
| |
| |-
| |
| | <Link>
| |
| | link
| |
| |
| |
| : #''N'' (instance number) (for non-door)
| |
| : M3GM''name'' (for door)
| |
| |}
| |
| | |
| | |
| ===M3GM===
| |
| Read on [[XML:M3GM|HERE]].
| |
| | |
| Note that M3GMs have their own instances: PNTA, VCRA (x2), TXCA, IDXA (x2).
| |
| | |
| Doors store their animated geometry in ONLV while the static part comes from BINACJBODOOR.oni which again link to M3GM files.
| |
| | |
| | |
| ===IDXA===
| |
| {| class="wikitable" width="100%"
| |
| !width=150px| XML tag
| |
| !width=120px| content type
| |
| ! description
| |
| |-
| |
| | <IDXA id="...">
| |
| | integer
| |
| | Instance Id.
| |
| |-
| |
| | <Indices>
| |
| | -
| |
| | This is an Int32 array for the <Int32> tags.
| |
| |-
| |
| |valign="top"| <Int32>
| |
| |valign="top"| int32
| |
| |
| |
| ; From ONOA to AGQG elements
| |
| : Link to <AGQGQuad> in [[XML:AKEV#AGQG|AGQG]] by order. (The array in AGQG starts with 0, so for example <Int32>6</Int32> would link to 7th <AGQGQuad>.)
| |
| ; From M3GM to PNTA elements
| |
| : Read on [[XML:M3GM#PNTA|HERE]].
| |
| ; From M3GM to VCRA elements
| |
| : Read on [[XML:M3GM#VCRA|HERE]].
| |
| |}
| |