XML talk:ONLV

CRSA import

Old talk: I simply put this section here because I hope Neo will soon integrate it. --paradox-01 (talk) 17:28, 28 December 2013 (CET)

(You can try to edit the final ONLV*.oni on your own. See 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 local (https://dl.dropboxusercontent.com/u/139715/OniGalore/local_correct_pelvis.png, dead link) and global (https://dl.dropboxusercontent.com/u/139715/OniGalore/global.png, dead link) 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.
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 destroyed the hierarchy revealing the true local rotation values of each part.

Those rotations and positions where entered into Neo's matrix program (https://dl.dropboxusercontent.com/u/139715/OniGalore/OniMatrix_src.zip, dead link). I then put the matrix to into the CRSA instance of the extracted ONLV file, then reconverted to oni.

Ingame, the corpse was looking quite good (https://dl.dropboxusercontent.com/u/139715/OniGalore/CRSA_manually_imported.png, dead link). 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 example (https://dl.dropboxusercontent.com/u/139715/temp/snipers.dae, dead link) of an intact and a destroyed hierarchy.

Note to self: old code (https://dl.dropboxusercontent.com/u/139715/OniGalore/ModToolScript/CRSA_wip.txt, dead link) 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.

Edit // 8th Feb 2014 // getting rid of the null objects:

It's possible to calculate the local rotations in a hierarchy using matrix multiplication. The final matrix must be inverted and the xyz values multiplied by -1.

Before calculations are started the rotation order of all objects must be changed from ZYX to XYZ.

What makes the code bulky is the need to go through all involved body parts and that 19 times.

Edit // 9th Feb 2014 // getting not rid of the null objects:

The code seemed to work fine until different rotations were used for all objects in the hierarchy. So for now there will be no simplification.

Pathfinding with GridIgnore flagged objects

Regarding Pathfinding on uneven ground, my testing shows that it will work as long as the top of the ground is 20 world units or less above the BNV, any higher and the grid is no longer active and the AI will not move. EdT (talk) 18:08, 21 August 2013 (CEST)

Ok thanks, I will check this tomorrow so we are sure it's the same on pc/mac. --paradox-01 (talk) 20:33, 21 August 2013 (CEST)

Just curious, how did you get the number 17,9? I placed the BNV at 0 and until 19 world units, the pathfinding grids were visible using ai2_showgrids=1, but at a height of 20, the grids disappeared and the AI was no longer active. EdT (talk) 01:00, 23 August 2013 (CEST)

Like seen in the first vid I kept the BNV at all times at height 0. Only the top of the GridIgnore pyramid-thingy changes in height. I tested its top with 19,1; 19; 18,9; 18. See time code 03:17 - 03:22. AI still loses PF at height 18, so I decided to do the next height to be 16. PF works there again. The video ends there but I made more test until I reached 17,9 where AI seems to not randomly lose PF. -- At all times I didn't observed the grids, the AIs behavior was more important to me. Test files (https://dl.dropboxusercontent.com/u/139715/OniGalore/BNV_test.zip, dead link).

After more tests today, not only jumps can break PF at 17,9 - also rolls, cartwheels and running kicks do. There are probably more anims. Do those issues somehow have to do with the foot/pelvis height? I don't know what's going on anymore. ^_^' --paradox-01 (talk) 10:13, 23 August 2013 (CEST)

I had another look on the original pathfinding and noticed that ghosts aren't equally high... My test level didn't used ghosts at all, just one BNV, so OniSplit probably added some default values. (Maybe this also explains our different test results.) -- After splitting the BNV and adding high ghosts (https://dl.dropboxusercontent.com/u/139715/OniGalore/BNV_test_2.zip, dead link) the Strike was able to run on a plain that was 42 above the BNV. More testing could be done to determine the max height (if there's any). --paradox-01 (talk) 15:43, 23 August 2013 (CEST)

The tall ghosts work! Here is video from my old Outside level with updated bnvs and ghosts: https://www.youtube.com/watch?v=Yj3ptZnZtx0 EdT (talk)

Objects that are too low to pass them by sliding/crawling/sneaking

atm sliding under low objects don't seem to work

EdT (talk) The reason for this are the collision spheres, even though you slide, the collision spheres remain vertical.

Okay, thanks for the warning.

I remembered some old screenies and assumed it would be possible. Don't know where those were posted. Probably those object don't have collision at all. :(

paradox-01 (talk) 23:19, 27 February 2013 (CET)

Those hoops are ONWC weapons. Screens were created by Geyser shortly after the "chair video" discovery, that weapons can be kicked around by A.I. characters (and they even emit sound as they are dragged around) and thus it could be possible to simulate movable obstacles as unpickable weapons. The idea sort of failed because:

• weapons fade over time (can be worked around by setting BSL variable wp_disable_fade=1)
• there is a limit of 128 weapons and also no way how to work separately with a single weapon via BSL (no way to reposition it, no way to delete just the single weapon), so in case wp_disable_fade=1 the amount of BSL control over this feature is practically zero.
• and the most prominent, for some reason player character is excluded from the weapon-character collision. BSL command wp_kickable unfortunately also works only for A.I. characters.

Still, with the daodan.dll now being used to patch executable, this idea could come to life again again, if certain tweaks are done (player included in weapon-character collision, addition of BSL commands to work with weapons).

--Loser (talk) 06:46, 28 February 2013 (CET)

Textures that are not power of two

If you have textures that cause a crash because they are not power of two, please post here those *.oni files.

At the moment I fail to make the game go blam despite such texture for env/char. (500x501 px, OS 93 used) --paradox-01 (talk) 13:24, 22 September 2013 (CEST)

Sky dome - it's a fail

Maybe it's possible to create a very big sphere or dome that covers the entire level (and let Oni's skybox unused). If it's doable it could avoid ugly lines of the skybox coming from OpenGL rendering.

Update: 12 June 2012

New issues appeared that need to take care about:

• brightness:

The brightness can be somewhat influenced by BSL commands like with gl_fog_..., gs_farclipplane and must be set adequately.

• texture size:

The dome seen in the screenshot has a texture size of 512x512 and hence looks quite pixelated.

The problem might be solved by splitting the dome into sectors and giving each sector its own texture.

gl_fog_start=.99999

Update: 14 June 2012

• texture boarder and distortions:

Texture boarders have darker pixels so the UV must not reach them. Also after splitting the textures inside the editor there will be little distortions but they are still noticeable enough to make the sky look odd. Fine-tuning the UVs didn't really help.

• The gs_farclipplane max value makes the size of the dome quite limited: I think that the max radius here is somewhere between 2500 and 5000 world units.

I consider this as a fail. Oni would need bigger view range and a texture support of 2096x2096.

Ideas for OniSplit

bugfixes

CJBOs and the shared folder

You should be able to use the original OBJC files with the master xml file. But at the moment (v0.9.90.0, Win7 64-bit), BINACJBODoor.xml wants for example:

<Class>doors/TCdouble.oni</Class>

it should be

<Class>TCdouble</Class>

Works:

• Turret

Works not:

• Door
• Colsole
• Trigger

Not tested:

• Funiture

---

improvments

better support for script objects

               <Import Path="../level19_Final/compound_script_405.dae">
                   <Node>
                       <ScriptId>405</ScriptId>
                   </Node>
               </Import>

it should be just one line because of the keyword script

               <Import Path="../level19_Final/compound_script_405.dae"/>

door locklight

extracting an ONLV to xml should generate an extra file with door locklights ready for the CJBO particle file

---

Neo could update OniSplit so that it is searching specific strings in object names of a dae level file.

Doors

• string "door*" (e.g. doorBlastDoorMX2000) -> DOOR + BINACJBODoor + OBAN
  • but if the string is "door*cloneN" then the DOOR and OBAN creation gets skipped (e.g. doorBlastDoorMX2000clone3), only class name, rotation and position get written into BINACJBODoor

Animated objects

• string "*_BeforeAnim": that's first static object with collision data (e.g. BlueCar1_BeforeAnim)
• string "*_InAnim": that's the animated cutscene object (e.g. BlueCar1_InAnim)
• string "*_AfterAnim": that's the second static object with collision data (e.g BlueCar1_AfterAnim)

Fake-destructible objects

• string "*_BeforeAnim": that's first static object with collision data (e.g. ConcreteWall2_BeforeAnim)
• string "*_FragmentN": that's the group of animated cutscene objects (fragments of the static object) (e.g. ConcreteWall2_Frag5)
• string "*_ColFragN": that's the group of static objects with collision data (e.g. ConcreteWall2_ColFrag5)
• string "*_NoColFragN": that's the group of static objects without character collision (e.g. ConcreteWall2_NoColFrag5)
  NoColFrag would be useful if the fragments are quite numerous and small and hence would pose a problem to the pathfinding