Animations

[KnightErrant]

Thanks GrumpyOldMan and zxiang1983,

I checked the time stamps just to be sure because its
easy to forget to delete the packs. Seems right but going to try it again.
What is different is I am modifying the animation family
directly, not making a new one. I'll retest what I'm doing
just to be sure and if I don't see the distortion I'll do it
zxiang1983's way and make a new family.

Oops, wait a minute. Re-read the post more carefully. zxiang1983
says he copied MTW2_Halberd_Secondary which doesn't have
a charge entry or a charge_attack or a charge_to_ready anim
command. It inherits? (sorry, OOP terminology) its parent anim
is the MTW2_2HSwordsman so is he overriding those commands?

Still, useful information, I'll try it my way. Then the other way.
If I see a problem maybe its an interplay between MTW2_2HSwordsman.

[KnightErrant]

Well, that was dumb of me.
Check the battle_models.modeldb file to find out
the animations to use. Ok, sorry, now I'm on the same
page here. Making a new MTW2_Halberd_Seondary_sandy anim
family to do this right.

Edit: Got the distortion on the face now. Thanks for the
help in recreating this.

[KnightErrant]

Already tried this above but here's the basepose for
MTW2_2HSwordsman which the secondary anim should inherit:

0    skeleton pose data, all bones including Scene_Root
+0.0000000000 +0.0000000000 +0.0000000000
+0.0000000000 +0.0000000000 +0.0000000000
+0.0952388123 +0.0007522844 -0.0000000077
+0.0225613099 -0.4644488394 +0.0143959811
+0.0241626594 -0.3995065689 -0.0316339098
-0.0000000069 +0.2124620080 +0.0000000008
-0.0002945330 +0.2115577459 +0.0000000299
-0.0000617082 +0.2349730581 +0.0000000668
+0.0003562513 +0.0108101442 -0.0034470249
+0.0016836975 +0.1178482324 -0.0744606256
+0.0132546443 +0.1300113499 -0.0273839179
+0.1653589010 -0.0517836586 +0.0034832843
+0.3022063971 +0.0111386608 -0.0137691963
+0.2838369906 -0.0030556759 +0.0263375118
-0.0102220895 +0.1300113499 -0.0273839179
-0.1678023189 -0.0517838039 +0.0034833583
-0.3021733165 +0.0111954408 -0.0144314421
-0.2838012278 -0.0032004344 +0.0267044473
-0.0952387825 +0.0007523637 +0.0000000220
-0.0216093510 -0.4641437531 +0.0230784994
-0.0250775032 -0.3986376822 -0.0406115167

and here's the pose data from the charge anim from new_2h_axe_halberd:

0    skeleton pose data, all bones including Scene_Root
+0.0000000000 +0.0000000000 +0.0000000000
-0.0000000000 +0.0000000969 -0.0000000000
+0.0952388048 +0.0007522567 -0.0000001105
+0.0225616489 -0.4644486904 +0.0143948821
+0.0241624303 -0.3995064199 -0.0316330455
-0.0000000002 +0.2124619335 +0.0000000074
-0.0002945446 +0.2115576714 +0.0000000356
-0.0000617125 +0.2349729091 +0.0000000648
-0.0015659207 +0.1178484261 -0.0744630992
+0.0002055460 +0.0108106285 -0.0034593104
+0.0132546341 +0.1300111562 -0.0273842439
+0.1653588265 -0.0517836101 +0.0034830223
+0.3022063673 +0.0111382734 -0.0137693156
+0.2838367820 -0.0030559180 +0.0263374485
-0.0102220811 +0.1300111562 -0.0273842085
-0.1678022444 -0.0517838039 +0.0034836400
-0.3021732569 +0.0111951502 -0.0144293746
-0.2838010490 -0.0031997561 +0.0267024450
-0.0952387676 +0.0007523138 +0.0000001374
-0.0216093212 -0.4641436040 +0.0230773669
-0.0250774790 -0.3986373842 -0.0406104438

The red lines are switched but that's ok, I think, because
the bone names are switched and GOM has established that
anims are done by the bone strings. So is this another
basepose conflict? Will try changing the pose data for
bone_jaw and bone_eyebrow to EXACTLY match the basepose
bones as a first try.

(I know: to a man who has a hammer, every problem is a nail.
Give that man some duct tape, and FILL IN JOKE HERE.)

[KnightErrant]

No joy, it was really funny, though. On the charge the
janissaries changed into a bunch of butterflies (really, that's what it
looked like) until they switched into charge_attack. Too late for
more experiments, try again tomorrow.

[zxiang1983]

Oops, wait a minute. Re-read the post more carefully. zxiang1983
says he copied MTW2_Halberd_Secondary which doesn't have
a charge entry or a charge_attack or a charge_to_ready anim
command. It inherits? (sorry, OOP terminology) its parent anim
is the MTW2_2HSwordsman so is he overriding those commands?

Ya, it seems so. I just added those three charge related entry in my MTW2_Halberd_Secondary_zxiang anim type and it works Actually adding or changing walking, running, attacking, etc all work well.

On the charge the janissaries changed into a bunch of butterflies (really, that's what it
looked like) until they switched into charge_attack.

Really? Generally speaking, I think the animation is very much like those 2H axe units' charging(raising the halberd over their shoulders)

[KnightErrant]

@zxiang1983
Finally got some time to work on this. Too hard to see the
charge anim so I looked at the walk anim which is also nonstandard
and has missing data for eyebrow and jaw bones. Here's the pic
for the walk anim inserted into MTW2_Halberd_Secondary_sandy
(my anim family name):



Same "pigsnout helm" problem as the charge anim.
I then ran then .cas file through my newest animmerge to reorder the
data and to fill in the missing animation frames and then ran animextract
to recreate the .cas file in standard order with all the data filled in. Here's
a pic of the new anim:



"Pigsnout helm" problem gone. I'll convert over the three anims you are using
doing the animmerge/animextract procedure and check them to be sure that
they are alright then post them at twcenter. If this truly solves the problem
I can automate the process to correct all the .cas files in
new_2h_axe_halberd so they will be usable.

Thanks for the test case, this one was fun to track down.

[KnightErrant]

Took a bit, charge_attack broke my script. Try these here:

http://www.twcenter.net/forums/downl...o=file&id=1439

These should fix the "pigsnout helm" anim problem like the walk anim.
Let me know how it goes. This could be generalized.

[KnightErrant]

Hi GrumpyOldMan,

I think I've resolved zxiang1983's anim problem so this is a good
time to consolidate knowledge. We understand the data in the
meshes: vertices, triangles, and bones. We understand the data
in .cas files: rotations, animations, and pose or skeletons. We don't
know what the bounding sphere is exactly; is it a fight anim thing
or a spacing thing, or a projectile impact thing. My spider-archer
experiment from a couple of months ago didn't really elucidate things.
I guess if I has to put forth questions mine would be:

(1) What is the bounding sphere?

(2) How do we add extra bones? Your research indicates we add them
after the weapons/shields bones, I haven't modified my animmerge and
animextract for this, but I've studied it and it shouldn't be hard. Just
need to "continue" over bones containing "weapon" or "shield".

(3) Templates: Not sure if I'm thinking the same thing, but I see this
as bones, hierarchy data, and bone names for insertion into an animation
directory. (MTW2_Spear_tailsthatwag for instance). Or flying anim
families where wing bones are animated but are tied to an existing
mount. walk and run etc. become flying anims. If the game is truly
2D this is probably a non-starter.

(4) Are siege engines so different? Haven't looked at the anims.

There has been lots of good ideas on this but I haven't kept good notes
about it all. I would like to at least write up the .cas file format while I've
got the variations sort of in my mind. Vacation coming up so I'm under a
constraint there, good constraint that is.

Was bad, (or good), and spent my lunch hour writing help info buttons
for animationutilities. If I can get create_image to work like the
documentation says, I might even have an about box.

[zxiang1983]

Hi, KE. Just tested those charge anim file. They are perfect, great work !

And BTW, about their walking anim, I suppose you were using 2h_axe_walk.cas. That file is broken. Not only the face is twisted but the anim itself is just incontinuous. But obviously CA realized that problem so there's another file called 2HAxe_walk.cas which is as perfect as your charge anim

Thank you for your kindness.

[KnightErrant]

@zxiang1983
Glad to hear that. This means we should be
able to fix up other interesting animations even
if they're out of kilter with the regular ones. Now that
I've seen GrumpyOldMan's explanation of how the anims
work, I understand why the data had to be reordered since
it isn't just string look-ups. This is getting more and more
interesting!

[GrumpyOldMan]

Hi KE

Hi GrumpyOldMan,

I think I've resolved zxiang1983's anim problem so this is a good
time to consolidate knowledge. We understand the data in the
meshes: vertices, triangles, and bones. We understand the data
in .cas files: rotations, animations, and pose or skeletons. We don't
know what the bounding sphere is exactly; is it a fight anim thing
or a spacing thing, or a projectile impact thing. My spider-archer
experiment from a couple of months ago didn't really elucidate things.
I guess if I has to put forth questions mine would be:

(1) What is the bounding sphere?

I'm not really sure but the differences in radius(?) values between various weapon types seem to indicate something to do with fighting. I think until we know more about it, we should make any new figures human size and then use scaling to change size so we have examples of valid bounding spheres to use.

(2) How do we add extra bones? Your research indicates we add them
after the weapons/shields bones, I haven't modified my animmerge and
animextract for this, but I've studied it and it shouldn't be hard. Just
need to "continue" over bones containing "weapon" or "shield".

I've sat down and had a think about this and we'll have to site the weapon bones at the end of the figures, otherwise there will be a clash between bone index values in the mesh and anims. The anims will have a hole in the run of bone indices if we take the weapon bones out of the middle of a figure, this would lead to catastrophic if not amusing results. I'm not sure the engine can take it (I sound like Scotty in Star Trek ). I've had to put in an option for template creation from an ms3d to add weapon bones if not already included, the template creation from a basepose or anim cas has this done automatically. So weapon/shield bones will have to go at the end of any new meshes or else the bone hierarchy gets out of sync between the mesh and anims.

(3) Templates: Not sure if I'm thinking the same thing, but I see this
as bones, hierarchy data, and bone names for insertion into an animation
directory. (MTW2_Spear_tailsthatwag for instance). Or flying anim
families where wing bones are animated but are tied to an existing
mount. walk and run etc. become flying anims. If the game is truly
2D this is probably a non-starter.

Making a template for the meshes is fairly straightforward, basically extracting bone hierarchy, names and positions for making plug in bits for ms3d and mesh files. For the animation process it may be a bit more difficult if bones have been inserted into (or deleted from) a vanilla hierarchy. For example if you do have a lizardman that has tail bones inserted after the head type bones, you'll have to rely on string recognition to make sure that you're transferring the right translations/rotations to the right bone. You may have to come up with a convention that new bones can only be added at the end of vanilla hierarchy if you're going to be transferring existing anims to new skeletons. If bones have been deleted you'll have to rely on string recognition. The same would apply to flying skeletons if they are viable. Unfortunately we can't tie animated attachments or weapons with separate animations to skeletons with the current engine. I went over this with Caliban when I was working on the standard bearer and if we want to add any new animations they have to included in the overall anim cas. So wings would have to attached to the mesh and anim hierarchy, and animated to fit in with the separate anims. With the standard bearer I've had to retime the flag anim for cas' with frames from 11 to 217 frames. I'm about half way through at the moment.

(4) Are siege engines so different? Haven't looked at the anims.

I think the main difference for siege engines is that they have two sets of anims, one for normal and one for destroyed. Lots more adventures to go, KE.

There has been lots of good ideas on this but I haven't kept good notes
about it all. I would like to at least write up the .cas file format while I've
got the variations sort of in my mind. Vacation coming up so I'm under a
constraint there, good constraint that is.

Was bad, (or good), and spent my lunch hour writing help info buttons
for animationutilities. If I can get create_image to work like the
documentation says, I might even have an about box.

Sounds like a worthy way to spend your vacation, if you're working on the mtw2 stuff, try to not look as if you're enjoying yourself and moan and complain a lot, otherwise you'll be snatched away to work on something else. This is what usually happens to me

Cheers

GrumpyOldMan

[KnightErrant]

Ok, some success with adding extra bones to make a tailed unit.
Wrote a utility to reorder bones and put the weapon/shield bones at
the end with the new bones in front of them. Another utility exports
the new skeleton file and hierarchy tree to all the .cas files in a directory
putting in 0.0 0.0 0.0 1.0 quats for the new bone rotations and
0.0 0.0 0.0 for the new bone animations deltas and puts the new bones
in the pose data. Then used animmerge to pull the animation into the
.ms3d file and opened in Milkshape with the walk animation. Then animated
bone_tail1 in the keyframer. Here's the result:



I just assigned some vertices to bone_tail2 to make a fake tail using
the existing vertices in armored_sergeants. The red circle is bone_tail1
and the green is bone_tail2. The animation just wags the tail for 19 frames.

The problem is back converting. GrumpyOldMan's didn't work for me so I
tried the Python meshconverter which just uses the bones that are in
the .ms3d file. The only modification is the node numbers. I'm guessing they
should go like this:

bone_pelvis       0
bone_rthigh       1
bone_rlowerleg    2 
bone_rfoot        3 
bone_abs          4
bone_torso        5
bone_head         6
bone_jaw          7
bone_eyebrow      8
bone_rclavical    9
bone_rupperarm    10 
bone_relbow       11
bone_rhand        12
bone_lclavical    13
bone_lupperarm    14
bone_lelbow       15
bone_lhand        16
bone_lthigh       17
bone_llowerleg    18
bone_lfoot        19
bone_tail1        20
bone_tail2        21
bone_weapon01     22
bone_weapon       22
bone_weapon02     23
bone_weapon03     24
bone_shield01     24
bone_shield       24

Will try to make a new animation family and put it in descr_skeleton.txt
and see if the extra bones work in the game this weekend.

[GrumpyOldMan]

Hi KE, Zxiang et al

While we're working on the animations it might be useful for us to go over the logic and the flow of meshes and animations.

This is my understanding of it:-

The mesh is loaded and this sets the global positions of the vertices, sets up a partial hierarchy of bones in a bone table (just the names and indices, no parent/child relationships) and then attaches vertices to bones.

The basepose is loaded and this completes the hierarchy (parent/child relationships) and the global position of the bones. Once we have the global positions of the bones we can then establish the local position of vertices to their assigned bones - this is used for the matrix manipulation during animation.

During the game, various animations are called. The engine checks the base bone positions (by index!!!) in the anim cas against the basepose and makes any adjustments (hence the movement of vertices in Zxiang's discovered anims) and then applies translations and rotations to the vertices based on bone index.

So when we look at anims we have to make a coodinated whole with the mesh, the basepose and the anims, particularly hierarchy and indices. There is string text matching but this is used for attachment of weapons. A sword uses it's default basepose anim to attach itself to bone_Rhand, a bow to bone_Lhand, etc. But for the purposes of animation the hierarchy indices are basically set by the mesh. This is why the animations found by Zxiang can't be used 'as is' because of the clash with the mesh and the basepose, they have to be altered to fit into the overall hirearchy. This means altering the position of the jaw and eyebrow bones (together with any translations/rotations) data into the correct hierarchy slots. A clash between basepose and anims is also why there were all the problems with Bwian's dwarf. The base pose was setting long legs (and setting local vertex/bone values) , the anims were shortening them and scrunching up the attached vertices.

This is just my understanding of it, I have been known to be wrong before so don't hesitate to correct me if you do see any flaws, I promise to only sob quietly .

Edit:- KE, this is getting spooky, the number of times we cross post

Cheers

GrumpyOldMan