Animations

[GrumpyOldMan]

Hi alpaca

Edit: By the way, does anybody have any resources on bone weigthing?

You could have a look at

http://www.chumba.ch/chumbalum-soft/...84&postcount=1

which is Mete from Milkshape's very basic instruction on using the bone weight editors. Have a look through the forum, I seem to remember there being other posts (by Wes H??) on working with bone weights on Sims2 figures.

Cheers

GrumpyOldMan

[Ashdnazg]

I couldn't see if this was seen earlier, so I post this anyway.
I had a wee look in Verc's script, and the second short in the header is the number of bones.
About the fifth byte, I think he actually skipped it.

[KnightErrant]

@GOM
Python is being unkind to me tonight and I can't find
my bug yet, but I still wanted to clarify two things:

(1) Went through the quaternion to yaw, pitch, and roll
and I think I'm following the same conventions. Meaning I
followed my quat vs euler matrices and worked through your
QuatToEuler function and I arrive at the same ATan2
relations for the angles. So I think
your code for rotations x, y, z -> roll, pitch, yaw is right
without having to interchange roll->pitch, pitch->yaw, and
yaw->roll. Does Milkshape really require this (excluding the roll
minus sign)?

(2) Byte counts: My example last night was for the CR_spear_charge.cas
which is a small one (7 KB) . If I count bytes this way

5                                 - header
nframes*NBONES*4*4     - quaternion block
nframes*NBONES*4*3     - pose block
nframes*4*3                 - global block  (only bone_pelvis)
nframes*4*3                 - relative block (only bone_pelvis)
40 final bytes, or 10 float - leftovers

Last 8 bytes always seem to be FF FF 0F 00 00 00 00 00, so maybe a
terminating signature.

This seems to square with the bytelength in the index file so I think
this is ok. For 11 anim frames I get 33+33+10=76 floats that I had last
night. So the global block and the relative block track the movement
of the single bone_pelvis to give the overall traversal of the model, and
the quaternions give the relative animation?

The game then seems to be, merge a .cas with a .ms3d and write the
anim stuff to the joint section, suitably merging the global and relative to
the pose data, since Milkshape doesn't have extra places for this, and
put the transformed quats into the rotation angles part. Reverse process
is separate the global and relative from the position vectors, reconvert
angles back to quaternions and write out a new .cas.

Is the jerky nature of the unpacked .cas files simply that the number of
bones in the standard skeleton for M2TW is different from RTW so the anim
frames aren't coming out right? Caliban has hinted that someone could
simply (simply?) change the MaxScript script to fix this but no one has
stepped to the plate.

Back to fighting Python, I can see the data I want in xvi32 put it won't print
out for me. This is finally the end for me, it's easier to simply read the data
in hex than it is to try to print it out.

[GrumpyOldMan]

@KE

I've just got to close down for a while before I throw the mouse through the monitor, getting very sick of looking at hex for RTW cas files.

It's terrible to see two old addicts in the clutches of their vice, isn't it?

The jerky movement is indeed just a matter of trying to cram RTW rotations onto a m2tw skeleton, it just requires a simple renumbering operation I imagine within the plugin/script - disregarding the cloak bones and taking into account the clavicles, jawbone and eyebrow.

Cheers

GrumpyOldMan

[KnightErrant]

I know the feeling... I think I'll slow down on anims and finish
writing instead. Hate leaving loose strings about. Thanks for
the info re jerky animations, that's what I thought from Caliban's
comments.

[SigniferOne]

By the way, Verc's animation script, though fantastic, was buggy at least in two respects:

1) it produced flickering animations for certain skeletons, wherein a bone would very quickly rotate 180 degrees back and forth. Sometimes hoplites would flicker their shields, and sometimes horses would flicker with their legs.

2) it could not modify most turn animations. The actual turn often proceeded in-game smooth enough, but the soldier would instantly turn back to his original position, and then turn back to his new direction again, and then back, etc etc. He couldn't complete turning back and forth, and you would have to order the entire unit to go elsewhere, upon which he'd stop and run with the rest of his unit. It's almost as if the script didn't register that the angle of the soldier's orientation was changed to the desired angle, and the engine kept trying to turn him; or it could be something else.

[alpaca]

C'mon guys, no turning back now

[Ashdnazg]

I couldn't see if this was seen earlier, so I post this anyway.
I had a wee look in Verc's script, and the second short in the header is the number of bones.
About the fifth byte, I think he actually skipped it.

Aargh, of course, missed that completely. I guess I don't
think in hex after all. So the 14 00 14 in the header after the initial short
count of frames is the bone count for what gets animated.
The variants I saw must have been strat map units which don't
have 20 animated bones... Got a better clue for looking at things
now, many thanks.

Thank you for ignoring my posts :D

[KnightErrant]

@Ashdnazg
You're absolutely right, I apologize. Went back and looked at
your post and there's the information staring me in the face.
I was so focused on fixing my script then my brain just wasn't
accepting new inputs. Please post any info you have; I promise
I'll pay better attention next time.

@GrumpyOldMan
Ok, got a reply from Caliban. He did the two experiments and none
of those "type files" or "skel files" exist with his unpacked setup.
So I think skeleton.dat/idx is supposed to stay packed and those
names are just look-up handles like you said. Looking at events.dat/idx
right now since Caliban had them unpacked. There's no names in
the index file so I think events and pack have to be unpacked together
since the .evt always matches the .cas path and filename. However,
the mapping is onto but not 1-1, not every cas file has a corresponding
evt file. If I'm seeing the header right, there's 1000 evt files for 2400
cas files.

[Casuir]

evt files look to be sound files so logically there wouldnt be one for every animation, a lot of the entrys in the skeleton.dat look to be just unit_march

[KnightErrant]

I think you're right, the data in events.dat seems to be file names for .wav
and .mp3 files in the sounds directory (although really in sounds.dat).
Looking at descr_skeleton.txt which seems to have much of the real
data in skeletons.dat shows the _basepose.cas, a lot of the _idle .cas's,
and the weapons entries with _Primary don't have evt associations.
I guess weapons and soldiers not doing anything don't need to make sounds.

[Casuir]

Aye and a lot of them would make the same sounds, looking at the engine evts a few of them are blank, if the game requires the evt files to run then theoretically you could get away with copying these and renaming to the required names. I do think they're packed in the skeleton.dat file sans headers, theres definitely stuff in there that matchs up with bits in the events.dat

[GrumpyOldMan]

Hi KE

@GrumpyOldMan
Ok, got a reply from Caliban. He did the two experiments and none
of those "type files" or "skel files" exist with his unpacked setup.
So I think skeleton.dat/idx is supposed to stay packed and those
names are just look-up handles like you said. Looking at events.dat/idx
right now since Caliban had them unpacked. There's no names in
the index file so I think events and pack have to be unpacked together
since the .evt always matches the .cas path and filename. However,
the mapping is onto but not 1-1, not every cas file has a corresponding
evt file. If I'm seeing the header right, there's 1000 evt files for 2400
cas files.

What we really need to see are a few examples of unpacked .evt files. The .evt files look like this in the skel .dat files :-

short - num of variations
short - 0
int - code for 'sound' type??
short - start frame
short - end frame
0 termed string - description/look up table entry??(some different cas use same event - explains number discrepancy)
then usually 10 bytes with 32 00 sometimes appearing and sometimes the start and end frame reappearing.

If we could get a hold of the evt files for one figure we could make a fist of decoding because the 'no_animdb' is sure not working without them. I'll ask Caliban and see if he can help.

I believe now that the two idx and dat files are made up from the folders within animation and that the skeletons we've been so intent on don't really exist. This is bad news for the fantasy people because this means that the skeleton positions are hardcoded and are added in at compiling those idx and dat files.

Cheers

GrumpyOldMan

[SigniferOne]

Guys, Jerome provided all of the .evt files for RTW 1.5, but putting them into the extracted animations folder, so they'd match up with their corresponding animation files, still didn't work, and still crashed. So, Caliban will really have to babywalk us through here, because Jerome spent a lot of time trying to get it happen for us in RTW, and it didn't work, in large part because I think the TW engine is not so successful at loading animations when extracted. It works wonderfully for other files, which don't have to be in packs, but seems to still be a buggy process with animations, and they have to be packed, unless Caliban's animdb switch was truly made to work this time.

Just briefly, if animations have to be repacked, does this mean descr_skeleton.txt is still pretty irrelevant as a file? The one inestimable advantage of getting unpacked anims working is that descr_skeleton.txt would become important, and then we could do a lot of stuff with animations that couldn't be done otherwise.

[GrumpyOldMan]

Hi SigniferOne

Guys, Jerome provided all of the .evt files for RTW 1.5, but putting them into the extracted animations folder, so they'd match up with their corresponding animation files, still didn't work, and still crashed. So, Caliban will really have to babywalk us through here, because Jerome spent a lot of time trying to get it happen for us in RTW, and it didn't work, in large part because I think the TW engine is not so successful at loading animations when extracted. It works wonderfully for other files, which don't have to be in packs, but seems to still be a buggy process with animations, and they have to be packed, unless Caliban's animdb switch was truly made to work this time.

From what Caliban is saying it seems that if no_animdb switch works (and we won't know that until we have the .evt files in place) the skeleton and pack idx and dat files are rebuilt on start from the descr_skeleton.txt file, and then the engine uses those repacked files.

Just briefly, if animations have to be repacked, does this mean descr_skeleton.txt is still pretty irrelevant as a file? The one inestimable advantage of getting unpacked anims working is that descr_skeleton.txt would become important, and then we could do a lot of stuff with animations that couldn't be done otherwise.

I don't think from what Caliban says that we'll be able to work with unpacked files, we'll just use them to create new idx and dat files. It was possible in RTW to get new skeletons and animations in and I think that eventually we'll be able to do the same, but in the meantime its fun to play with it

Cheers

GrumpyOldMan

[Casuir]

Guys, Jerome provided all of the .evt files for RTW 1.5, but putting them into the extracted animations folder, so they'd match up with their corresponding animation files, still didn't work, and still crashed. So, Caliban will really have to babywalk us through here, because Jerome spent a lot of time trying to get it happen for us in RTW, and it didn't work, in large part because I think the TW engine is not so successful at loading animations when extracted. It works wonderfully for other files, which don't have to be in packs, but seems to still be a buggy process with animations, and they have to be packed, unless Caliban's animdb switch was truly made to work this time.

If you re-read what the man said at the time the problem actually lies with vercs .cas extractor. He got it working perfectly with the original files and a retail version of the game, so the problems on our end, not theirs. Verc missed the ball on extracting the evt files from the dat, so its not implausible that something else is getting borked.
https://forums.totalwar.org/vb/showt...ighlight=bones

@gom, theres evt files in the animations/engines folder, not the exact same as the ones missing but you should be able to get the header and file structure from them.

This thread might be of interest as regards the skeletons
https://forums.totalwar.org/vb/showthread.php?t=53763
Be nice to if caliban could confirm that the skeletons are hardcoded, how does the engine know which one to use for a camel and for a man?