XML talk:TRAM

What we know and not know

Animations never stop, they flow from one to another.

The default case is a character getting spawned and then just standing there, he idles.

This brings us to the core attributes of an animation: type, state, variant. (In XML it is varient. [sic])

Theoretically you could recycle all attribute and build your own animation system, but that would not much practical.

The prone mode mod is an exception, in the context of the existing system it can be considered a logical expansion where BSL handles the transition.

Now then, the idle animation does not link to a specific followup animation - or for short "anim" - it rather links to a state being followed.

Ironically all anims have a <FromState> and a <ToState>, but no obvious <CurrentState> which can cause confusion on what the current anim actually is.

This gives us two options of how to think of the situation: either consider <FromState> being usually the <CurrentState>, or states exist only between anims and serve as transition rules.

Linking to a followup state allows for multiple choices of what specific animation comes next. For example there's a rare chance that Mai will sneeze if she idles for a long time.

An anim is picked up randomly from a pool of valid animations. Their probability or <Weight> is determined by TRAC - the anim collection.

           <TRACAnimation>
               <Weight>100</Weight>
               <Animation>TRAMKONOKOidle1</Animation>
           </TRACAnimation>
           <TRACAnimation>
               <Weight>100</Weight>
               <Animation>TRAMKONOKOidle2</Animation>
           </TRACAnimation>

Here's the sneeze animation with Weight 100, but the real chance of getting picked up is still low. Why?

Welcome to the world of Oni bugs mysteries.

           <TRACAnimation>
               <Weight>100</Weight>
               <Animation>TRAMKONOKOidle_spec3</Animation>
           </TRACAnimation>

A working example of <Weight> is the Ninja Moonwalk named taunt2.

           <TRACAnimation>
               <Weight>100</Weight>
               <Animation>TRAMNINCOMtaunt1</Animation>
           </TRACAnimation>
           <TRACAnimation>
               <Weight>5</Weight>
               <Animation>TRAMNINCOMtaunt2</Animation>
           </TRACAnimation>

To let an character flow from one anim state to another the <ToState> is used.

Let's say a SBG grenade hit Konoko, TRAMKONOKOblownup1 is played, meaning she falls to her back.

She is now in state FallenBack and the engine picks up next animation with <FromState>FallenBack.

KONCOMfallen_back puts the character into combat mode by using <Varient>Combat.

But if the player gives no input Mai will remain on the ground as <ToState>FallenBack creates a loop.

Question: Why is KONCOMgetup_lt not played automatically since it also has <FromState>FallenBack and <Varient>Combat?

It differs in its <Type>. Obviously most anim types are bound to user input and therefor are excluded from the automatically created pool of valid anims to follow.

A left mouse turn tells the engine to use an anim of type StandingTurnLeft.

This is true for KONOKOcomb_turnlt and KONCOMgetup_lt but only the latter matches the current <FromState> condition.

KONOKOcomb_turnlt has in fact <Varient>Combat, comb stands here for combat, not combo. Following Oni's naming convention, the file should have been named KONCOMturn_lt.

Knowing this behavior we can deduce that anims types registered to user input will make the engine ignore all the automatic anims inside the pool, therefor breaking the loop of KONCOMfallen_back.

Since KONCOMgetup_lt has <ToState>Standing and <Varient>Combat the following idle animation must also have <Varient>Combat.

So, next anim played will be KONCOMidle1 or KONCOMidle2.

[...]

ITO Round 2

The ITO bug seems to be caused by our limited knownledge of the animation system.

It turns out that the interpolating frame number can be overwritten by Shortcuts after all.

The Shortcuts tag should better have been named "AlternativeFromStates".

Shortcuts are accepted if their <Shortcut><FromState> value differs from the "primary" <Lookup><FromState> value.

If you want to make a Shortcut that uses the same FromState value then you have to set primary FromState value to None.

ITO test setup, prep.

Create static idle anim
Create kick type anim which moves pelvis by 20 units ?
Spawn at 0 0 0
Enable chr debug
Chr wait state running -> reset chr position
Record with OBS or just take notes?

1. sample

Modified animations with no rotations.

• idle: 60 f, key frames at 0 and 59
• comb_p: 20, key frames at 0 and 19
  • total target translation: 20 world units
  • total real translation: <20

Observed cycle: idle -> comb_p -> idle

Shortened list:

frame	translation	ITO frame	z-to-z translation delta	delta acceleration
0	0		[0/8]		0				
1	0		[1/8]		0				0
2	0		[2/8]		0				0
3	0.125		[3/8]		0.125				0.125
4	0.375		[4/8]		0.25				0.125
5	0.750		[5/8]		0.375				0.125
6	1.250		[6/8]		0.5				0.125
7	1.874		[7/8]		0.875				0.125
8	2.624		[8/8]		0.999				0.124
...	...				1				0.001
comb_p had itself an interpolation of 8 and therefor z translation continued within followup idle

There was no backwards drift in this. Need to change future setup.

Problem with exporting a textured character with non-native TRAC animation

This problem occurs with OniSplit v0.9.99.0 and earlier.

There are basically two commands:

OniSplit -extract:dae outputPath -anim:TRAMname.oni inputPath/ONCCorTRBSname.oni

OniSplit -extract:xml outputPath -anim-body:inputPath/ONCCorTRBS.oni inputPath/TRAMname.oni

First one cannot export TRAMs that aren't listed in character's TRAC.

The second cannot export characters with textures at all.

A textual comparison with WinMerge reveals that the outputs of native TRAMs are almost the same.

Except the chunks of <library_images>, <library_effects> and <library_materials> are missing in the second dae.

It follows <visual_scene> where the id has a different name which is not that interesting.

Inside, there are <instance_geometry> nodes which are pretty much empty for the second dae.

I restored only a few bones. Proof of concept.

In other words: for a complete textured and animated character you need to post-edit the dae which is actually xml code.

If we doesn't get Neo to fix it we will have to export the character twice automatically and let the OniSplit GUI provide the final dae.

I added a "Repair character textures" option to "Simple OniSplit GUI", though that feature wasn't tested very much.

old

how convert dae to xml / oni ...

... using batch files

Download this modding environment so you know that the following lines are about.

Before you can run those files you need to put your source files into the "input_folder".

"dae + xml(not 41) to oni.bat" will generate files with QKeys.

"dae to xml(41).bat" will generate files with EKeys.

... using the Windows address bar

The batch file code and the code used for the address bar are identical.

Look at this image and you will understand.

If you use the windows address bar you should have onisplit alway alongside your essential modding folders to have short commands like

onisplit41 -create:tram output_folder input_folder/*.dae

We want to type as less as necessary, don't we? =)

... using onisplit GUI

Keep in mind that the GUI is only a mask for onisplit. New onisplit versions - v0.52.9.0 or newer don't have the command -create:tram.

normal animations

You can convert such animation by choosing one of the two methods. (normal = no overlay anims)

- To create QKeyed-animation you need a helper xml file to be placed alongside the dae animation file.

- EKeyed-animations don't need a helper xml file but edits afterwards the creation.

In any case the amount of needed hand work is quite the same for both methods.

QKeyed-animation refuse to become edited. There's somehow a bug like Samer pointed out on the forums. (Is this still the case? - 5th Dec 2011) But that's not so tragic. You can edit the dae or the xml helper file and then merge them into an oni file again.

Like EdT said an advantage of the xml helper method is that you can breakdown a single dae file into smaller pieces. It's a comfortable way to create multiple animations from one source. E.g. you make combo animations in one dae - let's say punch (p), kick (pk), punch (pkp) - then you make 3 xml helpers. First file goes from frame 0 to 40, second file from 41 to 86, and third file from 77 to 140. The dae file has 120 frames but not the 3 oni files that will be created.

Some lines for the hypothetical second combo animation:

   	<DaeImport>
           <Path>TRAM######combo.dae</Path>
           <Start>41</Start>
           <End>78</End>
       </DaeImport>
       <Lookup>
           <Type>PK</Type>
           <AimingType>PK</AimingType>
           <FromState>Standing</FromState>
           <ToState>Standing</ToState>
           <Varient>Combat</Varient>
           <FirstLevel>0</FirstLevel>
           <Shortcuts />
       </Lookup>
       <Flags>Attack</Flags>

Don't forget to add types, variants, particle etc. to your xml file before you convert it to the oni format.

testing the created files

Either put them into an AE package or create a plugin.

There's a batch file available that create level0 plugins. Put the created plugin files in your GameDataFolder and run the game.