Haha well if you already got it figured out![]()
So you already extracted the pack.dat? Why didn't you say?
Anyways, I'll have a look at the skeletons then.
Edit: By the way, does anybody have any resources on bone weigthing?
Well I have to start learning somewhere, so I wrote an extractor
to pull the cas's out of pack.dat using the offsets in the index file.
Pulled out 30 to look at. The first 5 bytes are the header where
the first short is the number of anim frames. The other 3 bytes are
14 00 14 hex or 20 0 20. The only question is what comes first,
quaternions or pose data. I saw some 0.0 0.0 0.0 1.0 values so that
answered two things: quats come first and CA uses the {q1, q2, q3, q4}
convention where q4 is the special one. I transformed them to Euler
angle using the 321 convention and got this for the first anim frame
for CR_spear_charge.cas:
The next block should be the position or pose data so its done asCode:Number of animation frames: 11 Remaining header: 20 0 20 Quaternion data and maybe Euler angles (using 321)? q1 q2 q3 q4 sum of squares yaw (deg) pitch (deg) roll (deg) ============ anim quaternion frame 0 ============ +0.2538955510 +0.1681092978 -0.0226481762 +0.9522412419 sum squs = +1.0000000095 +2.5657103993 +19.3696683429 +30.2967888994 -0.3953365684 -0.0070954142 +0.1987117827 +0.8967565298 sum squs = +0.9999999935 +21.4590405866 +8.3019773363 -46.0049588155 +0.1825654358 +0.0634186864 +0.0113932779 +0.9810800552 sum squs = +0.9999999497 +2.6276101260 +6.9081227284 +21.2413852449 +0.0005502258 +0.0181907974 -0.2293124646 +0.9731827378 sum squs = +1.0000000555 -26.5251008404 +2.0435025817 -0.4169129706 +0.0379701219 +0.0379873700 -0.0190575924 +0.9983747005 sum squs = +1.0000000050 -2.0214710134 +4.4332999853 +4.2777858328 +0.1421776563 +0.1788186878 +0.0416587740 +0.9726633430 sum squs = +1.0000000412 +8.0495681889 +19.6342635762 +18.0275697089 -0.2416000813 -0.3342688680 +0.0259645525 +0.9106149077 sum squs = +0.9999999436 +15.0756420060 -36.6006764153 -34.7298720077 +0.0000000000 +0.0000000000 +0.0000000000 +1.0000000000 sum squs = +1.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +1.0000000000 sum squs = +1.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 -0.0013705824 -0.0047476389 -0.0055176513 +0.9999725819 sum squs = +1.0000000275 -0.6315546125 -0.5448992324 -0.1540581944 -0.0002179843 -0.0194163416 -0.3695584238 +0.9290046096 sum squs = +1.0000000350 -43.3998593387 -2.0766736500 +0.7995938917 -0.0381897017 -0.6430811286 -0.0234443955 +0.7644858360 sum squs = +1.0000000244 +4.4177386253 -80.0780864235 -9.4322343545 +0.0172815081 +0.1676424295 -0.1667936444 +0.9714819789 sum squs = +0.9999999898 -19.7157479464 +19.3591213839 -1.3571896291 -0.0011378765 +0.0047027008 +0.0202233475 +0.9997837543 sum squs = +0.9999999494 +2.3170456268 +0.5414182810 -0.1194701201 -0.2264718562 -0.1660457850 +0.4406757355 +0.8526102304 sum squs = +1.0000000133 +56.0534307300 -4.7922679610 -32.3030476656 -0.0418538116 +0.8028841019 +0.0247014631 +0.5941508412 sum squs = +1.0000000070 +7.4251721953 +72.9670051832 +1.9701113044 +0.0022718122 +0.0688987225 +0.0323999561 +0.9970948100 sum squs = +1.0000000124 +3.7581457004 +7.8887411361 +0.5203097663 -0.3605583012 -0.4344316721 -0.1733115017 +0.8069881797 sum squs = +0.9999999651 +3.4140766971 -55.7042659859 -49.9541032693 +0.2243260294 +0.1274575591 +0.0513146892 +0.9647793770 sum squs = +1.0000000404 +9.2202763455 +12.8802680946 +27.2221190368 -0.0548719205 -0.0131644774 +0.1631041616 +0.9849938154 sum squs = +1.0000000151 +18.8304236382 -0.4603295875 -6.4533948925 ============ anim quaternion frame 1 ============
triples:
Code:Pose data: ================== anim pose frame 0 ============ +0.0000000000 +0.0000000000 +0.0000000000 +0.0952388272 +0.0007522855 -0.0000000016 +0.0225613043 -0.4644488990 +0.0143959904 +0.0241626762 -0.3995066285 -0.0316338763 -0.0000000072 +0.2124620080 +0.0000000010 -0.0002945314 +0.2115578204 +0.0000000317 -0.0000617032 +0.2349731475 +0.0000000667 +0.0003562687 +0.0108105456 -0.0034470414 +0.0016836965 +0.1178482845 -0.0744606182 +0.0132546313 +0.1300114095 -0.0273839347 +0.1653589308 -0.0517836995 +0.0034832763 +0.3022064567 +0.0111386590 -0.0137692019 +0.2838370204 -0.0030556649 +0.0263375491 -0.0102220755 +0.1300113946 -0.0273839198 -0.1678023189 -0.0517838039 +0.0034833569 -0.3021733761 +0.0111954454 -0.0144314468 -0.2838012874 -0.0032004488 +0.0267044865 -0.0952387974 +0.0007523632 +0.0000000220 -0.0216093566 -0.4641438425 +0.0230784863 -0.0250774939 -0.3986378312 -0.0406115353 ================== anim pose frame 1 ============
This looks right because it matches the standard skeleton:
(Don't worry about the signs on the x values, The standard skeletonCode:0.0 , 0.0 , 0.0 -0.095239 , 0.007520 , 0.0 -0.022561 , -0.464449 , 0.014396 -0.024163 , -0.399507 , -0.031634 0.0 , 0.212462 , 0.0 0.000295 , 0.211558 , 0.0 0.000062 , 0.234973 , 0.0 -0.000356 , 0.010810 , -0.003447 -0.001684 , 0.117848 , -0.074461 -0.013255 , 0.130011 , -0.027384 -0.165359 , -0.051784 , 0.003483 -0.302206 , 0.011139 , -0.013769 -0.283837 , -0.003056 , 0.026338 0.010222 , 0.130011 , -0.027384 0.167802 , -0.051784 , 0.003483 0.302173 , 0.011195 , -0.014431 0.283801 , -0.003200 , 0.026704 0.095239 , 0.000752 , 0.0 0.021609 , -0.464144 , 0.023078 0.025077 , -0.398638 , -0.040612
was made to work with Milkshape so there's always to x -> -x transform
for that.)
So far, so good. The problem is I still have 76 floats left over that look like
this:
For a big 4.5 second animation like CR_spear_die_galloping.cas it'sCode:What the heck are these data: We have 76 leftover floats +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0145724751 +0.0491957590 +0.0002147975 +0.0301976539 +0.1019454375 +0.0004450644 +0.0437174141 +0.1475874335 +0.0006442972 +0.0519736372 +0.1754599810 +0.0007659923 +0.0510471202 +0.1819434315 +0.0005802182 +0.0442738384 +0.1494659334 +0.0006524611 +0.0348668732 +0.0312059894 +0.0020629363 +0.0234865602 -0.0744927898 +0.0031001847 +0.0119119827 -0.0558995418 +0.0018968056 +0.0000000000 +0.0000000000 +0.0000000001 +0.5000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000001 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000 +0.0000000000
worse, I have 556 floats left over, mostly zeroes or repeating values
but no idea what they are. The pose data on the last anim frame
still looks ok, I don't think I've slipped data by miscalculating the
frame offsets.
Another GrumpyOldMan question is this:
If I have my rotation matrix parametrized by the quaternions as
Code:_ _ | | | q1^2 - q2^2 - q3^2 + q4^2 2 * ( q1*q2 + q3*q4 ) 2 * ( q1*q3 - q2*q4 ) | | | | 2 * ( q1*q2 - q3*q4 ) -q1^2 + q2^2 - q3^2 + q4^2 2 * ( q2*q3 + q1*q4 ) | R = | | | 2 * ( q1*a3 + a2*q4 ) 2 * ( q2*q3 - q1*q4 ) -q1^2 - q2^2 + q3^2 + q4^2 | | | |_ _|
and similarly for Euler's
is that Mete's convention or is it one of the other 11 sets?Code:_ _ | | | cos(psi) cos(theta) sin(psi) cos(theta) -sin(theta) | | | R = | - - cos(theta) sin(phi) | | | | - - cos(theta) cos(phi) | |_ _|
Last edited by KnightErrant; 04-12-2007 at 01:38.
Hi KE
I didn't quote your reply, so I hope I get everything clear for you.
The next lot of floats after the skeleton are global position vectors for the bones, so number of frames by number of bones by x, y, z. (I get a lot more than 76 floats hereare you sure you just haven't printed off the first three float values of each frame's worth??). Although the local positon value hasn't changed, you have to remember this is preprocesed to plug into the engine. The only significant one to worry about is the y value for the first bone this give the movement perpendicular to the ground plane.
Next there is number of frames by x and z 'incremental' movement for the first bone (pelvis). This shows you how much the figure moves parallel to the ground plane each frame.
Below is the function I'm using for Quat to Euler conversion :-
Don't worry about the QuatToEulerAccuracy, I thought it was a bit fancy-shmancy, so I just deleted the constant but haven't updated the function yet. Read it as '0'.Code:QuatToEuler(a4,a1,a2,a3);data read in from original file - a1,a2,a3,a4 Function QuatToEuler(w#,x#,y#,z#) Local sint#, cost#, sinv#, cosv#, sinf#, cosf# Local cost_temp# sint = (2 * w * y) - (2 * x *z) cost_temp = 1.0 - (sint * sint) If Abs(cost_temp) > QuatToEulerAccuracy cost = Sqr(cost_temp) Else cost = 0 EndIf If Abs(cost) > QuatToEulerAccuracy sinv = ((2 * y * z) + (2 * w * x)) / cost cosv = (1 - (2 * x * x) - (2 * y * y)) / cost sinf = ((2 * x * y) + (2 * w * z)) / cost cosf = (1 - (2 * y * y) - (2 * z * z)) / cost Else sinv = (2 * w * x) - (2 * y * z) cosv = 1 - (2 * x * x) - (2 * z * z) sinf = 0 cosf = 1 EndIf ; Generate the output rotation roll# = -ATan2(sinv, cosv) ; inverted due to change in handedness of coordinate system pitch# = ATan2(sint, cost) yaw# = ATan2(sinf, cosf) End Function
I wrote this code a while ago and it exports the animation but facing in the -z direction. Shouldn't take much to fix but the Menu/Tools/Mirror All fixes the orientation.
Now the results come out as calculated roll equalling pitch, calculated pitch equalling yaw and calculated yaw equalling negative roll. I've never got around to cleaning it up as long as I was getting the right numbers out![]()
.
If you want to take the language for a shareware ride I can pass the code onto you.
Cheers
GrumpyOldMan
Hi alpaca
You could have a look atOriginally Posted by alpaca
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
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.
a.k.a Lord hokomoko @ the Lordz Modding Collective
@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
Last 8 bytes always seem to be FF FF 0F 00 00 00 00 00, so maybe aCode: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
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.
@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
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.
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.
Last edited by SigniferOne; 04-13-2007 at 20:09.
Originally Posted by Ashdnazg on the previous page
Thank you for ignoring my posts :DOriginally Posted by KE
a.k.a Lord hokomoko @ the Lordz Modding Collective
@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.
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
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.![]()
Hi KE
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 :-Originally Posted by KnightErrant
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
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.
Bookmarks