Chariot Development

[Bwian]

KE and my good self have been re-pondering the question of making chariots a reality in M2TW. We have divided up the tasks equally amongst ourselves, with me doing the pestering, and KE doing the clever stuff. Seems fair (ahem )

In between, we have done much tinkering, and there has been much quoting of the dead parrot sketch, discussions on Australian Tablewines, cheese, and the liklihood of me actually wishing to purchase a talking slug. Yes indeed ...

And now for something completely different!

First off, there was a need to make a chariot. Easy. KE has given us the tools to make new meshes for a mount, and also the ways to add extra bones and port that across to existing animations sets. Brilliant stuff.
So..I considered th epossibility of simply taking a stock horse, and tacking on some extra bones at the back to make a chariot pole, platom and axles which could then be animated to fit with the stock horse moves. After a few early tests, it became clear that I also had to phsically move the horse relative to the 'root' bone ( h_saddle for a horse )or else the thing would pivot around the root and the chariot would appear to drag itself sideways in a bizarre way when it turned. n short...I came up with this:


Now...I extracted a skeleton, and then applied that to the mesh to create a new animation set 'fs_chariot'.The new bones were indexed as '1', '2' and '3' in accordance with their position relative to the root. I manually edited the 'skeleton' file to do this, changoing them from 99. Ran it in game, and I noticed something VERY bizarre.In order to properly show it, here is a picture of the beast after animerge was run on the 'walk' animation.

Note..there are actually 2 horses side by side, but rigged to the same central skeleton. I tried it like this AND with just one horse. Made no difference

The vertices are all correctly assigned, and all definitely seems to be fine in the model department too. I also noticed in game that the chariot platform was messed up too. All that was visible was the front edsge of it. The rest appeared to vanish!

Now...I have been swapping PM's with KE and pondering this deeply. Today, I have run another batch of tests. We could not figure out if the problem lay with the horse/mount mesh converter, or if it was related to the extra bones which had not really been tested with anything other than human skeletons.

So...what I did was to re-run the whole process, moving the horse in EXACTLY the same way, but NOT adding the extra bones for the platform.

This was the starting point. The exact same process was done, and the thing WORKS.

Looks to me as though it was something to do with the extra bones mixed with the mesh converter that has hiccupped here. Ready to test more

[KnightErrant]

This presents an excellent opportunity for me to hone my
waffling skills. I did a quick rerun through the Python meshconverter (1.4)
as it relates to mounts since that is the question here. I can't eliminate
the converter as the culprit but I am inclined to think the problem is
really in the animation utilities for the following reason:
(1) There really is very little bone information in the mesh format, basically
bone striings and not much else. That said, there are the node numbers that
follow the bonestrings and that I never quite understood, it isn't really a
hierarchy string as the numbers just run up and then repeat in the weapons
/shields part. Maybe this is a problem but leave it aside for a moment.
Besides, mounts don't have weapons or shields.

Bone stuff is in the animations. Unfortunately, my only experiments were
putting tails on armored_sergeants which would not have exposed the problems
with turning extended skeletons around a pivot point. I don't have a series
of experiments for this other than what happens if a small extra bone is added.
Do the animations break down immediately? This would actually be a good
result since it would point immediately to a problem in the utilities and that
could be debugged. A bad result would be it only matters for large bones
like a following appendage meaning we don't really understand how the
animations work in the game engine. (Sorry, correction, meaning I don't
understand how the animations work in the game engine.)

Did not answer the question as posed but could you try one extra (small) bone
and see if the mechanics still work ok or does the process break down.
At least that might point to a part of the anim utilities to look at for bugs.

(This is a side note, I've got verts and tris into gmax. Questions:
(1) In 3dsmax is the vertical the z-axis like in gmax. So I can
keep the x-aixs to the user's right and swap z for y and make y -> -y
so it points into the screen? (And be right handed.)
(2) How do Milkshape groups translate in 3dsmax. Are they separate
meshes? That doesn't seem quite right but every try at selecting faces
and trying to make them a group seems to fail with a syntax error. I'm
probably just stumbling over jargon here; should I expect a 3dsmax "group"
to mean the same thing as a Milkshape "group".)

KE

[Bwian]

OK....I think I can see tonights first test

I will take a 100% standard horse mesh, and add a bone. If by adding an extra bone, I create a problem, we have an immediate guide that says the movement of the bones out of place isn't key to the problem, but adding bones is. I will start by adding a 'tail3' bone and see what that does. Ifit works OK, I will try moving the bone further away ( so it acts like a chariot pole. IF this still stays reliable, I could actually make a chariot stealing the tail from the models stock skeleton. Tail1 is the pole, tail2 is the platform, tail3 would then be the axle. I might even be able to get away with tail1 as the pole and tail 2 as the axle if we really can't get to grips with the adding bones. Would still like to be able to add extra bones to the horse skeleton...can I say 'pegasus' and not get people excited?

Anyway....

If I can get the stock unmoved skeleton to play ball with added bones, and it is tolerant of extended movement, then we have to point the finger at the animations not being correct.... but I am still not convinced! If you look at picture 2, the bones are in their correct location, but the SKIN has slipped! This points to some kind of problem with the way the bones movement is linked to the vertex assignments. Now...I have about as much idea how it all works as an Iron Age Shaman has about what made the sun rise ... but I do know if I sacrifice a chicken when the bright star shines over the tallest stone, the sun will rise. I do it every day, and the sun always rises... so I must be right!

Phew...took ages to clean up the chicken entrails, but rest assured...we will have daylight today!

Getting back on track:

Tonights testing:
1) Stock unmoved horse skeleton with new bone
2) Stock unmoved skeleton with new bone moved a lot
3) Stock unmoved skeleton with several bones

As another interesting side issue, I made an accidental discovery that might be significant. In the stock horse skeleton, there is a scale factor. It scales them slightly oversize. First time I redid the tests last night, I left the scaling in the skeleton.txt file, when it was not in place in the MESH def in modeldb. I got some odd stretching of the extremities that were slightly like the problem I have been fretting over. It wasn't exactly...but it was near enough to make me think! When I ran the animation utilities, I was setting the animation scale values to 1,1,1 ... since I have taken the scale element out of the MESH definition, I also set the values in the animation set as 1,1,1 not 1.16 of the stock skeleton. Is it possible that I need to add this back in? I could be forcing the skeleton into a smaller size than the mesh and getting wierd results as a consequence. Possible? Well..I think I have to test it as well!

Test 4) Replace original scale values in the mesh and descr_skeleton and re-run animations with the same scale value.

Lastly. Your other questions.

The co-ord system in Max is exactly the same as Max. The tool was created by cutting out a load of the higher level features of Max and the rendering engine, and tying up the file format. The plan was then to license plugins to software manufacturers to allow their game to be modded with GMax. Onlt hte very big players went for it though, and it died. Z is up.

Group wise, I am not 100% sure. I know that a seperate object is needed to export a model as 3DS and have it import as a group in MS3D. I assume that MS3D groups translate as seperate objects in return, but I cannot be sure. Logic says yes.... but then again...I am back to the chicken scenario. Definitely sure that a single object in Max when exported as 3DS and imported to MS3D makes 1 group. 2 objects makes 2 groups.

[KnightErrant]

Let me throw this in as well. Went and looked at the fs_horse
walk animation and pulled out the data to a txt file. For regular
human units animations the "footer" after the last of the data looks like

104 1  1  CaozSceneCustomAttribNode   1  0  1  0  0  +0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0  0  -1 0          0  1  16 2  0  0  16 3  0  0  16 8  0  0  16 10 0  0  12 5  0  12 12 0

The horse has extra stuff in the footer viz

170 1  2  CaozSceneCustomAttribNode   1  0  1  0  0  +0.00000 +0.00000 +0.00000 +1.00000 +0.00000 +0.00000 +0.00000 0  0  -1 0   Plane 1  0  1  0  0  -0.70711  +0.00000  +0.00000  +0.70711  +2.43048  -4.76820  -7.87057  0  0  0  0  2  16 2  0  0  16 3  0  0  16 8  0  0  16 10 0  0  73 5  1  0  +0.838 +0.612 +0.612 +1.000 +0.200 +0.200 +0.200 0  0  0  0  0  0  0    1 12 12 0

Never knew what any of this stuff was for but there are extra sections of
floats here. What I'm getting at is the question of the chariot not rendering
further back than a certain point. I wonder if any of this data has anything
to do with a rendering volume. Camels don't have any of this stuff so this
is probably a bad guess.

[Bwian]

Right...this is interesting...and frustrating in equal measures!

Test 1 - Stock horse with an extra bone.

This worked absolutely fine. The bone was added to the end of the tail, and named bone_tail3. The bone order was left with Tail1 as 1, but tail 2 was changed form 14 to 2, and Tail3 was made 3. The thing was created fone, and worked perfectly in game. Good

Test 2 -Took the output form test 1, and moved the tail bones radically into the positions I would need a bone to be in relative to the horse. This also worked fine. Also good.

Test 3 - Took the radically moved skeleton I had tested as above, and added the extra bone to the tail as in test 1. This ALSO worked fine. This was good, since it meant that the skeleton I had moved about had worked OK, and now the addition of 1 extra bone had not broken it.

Test 4 - Flushed with the success of test 3, I figured I would try something else here. I took the 3 tail bones I had, and moved them into EXACTLY the position I wanted for my chariot parts. Tail1 became the pole...Tail2 the platform, and my new Tail 3 as a central axle. This also appears to be working OK. I have a chariot skeleton that WORKED.

Now...I thought to myself...with all this working, WHY did my other one fail? I wondered if the bones were wrongly named, or if there was something in the steps I had missed. But no. Perhaps I added too many bones. Is there a bone limit? For a horse PLUS pole, platform and 2 bones for wheels... have I overdone it? TRied removing a bone or 2... but couldn't see a difference.

Hmm... I got something that works, but I don;t know what the difference is between what worked and what failed!! AArrgh. A disaster in terms of a diagnostic test.

edit... just tried to re-do the 'working' test..and it is broken. I do not seem to be able to duplicate it with ANY reliability...

[Bwian]

Now I am even more baffled.

I just re-ran the process with the moved bones only skeleton......one which ran perfectly yesterday ..and had it fail in exactly the same way. Now...I knew this was not likely to be a 'random' thing, so I did a bit of head scratching, and realised that I had previousely commented out the scale entry in descr_skeleton and put it BACK in to try something else. Took it back out...and as if by magic...it worked again.

So... one element that was screwing things up was scaling. Not completely the solution, because all the previous tests were done on a 1,1,1 scale, and not everything worked.... but I have found a way of deliberately creating the effect I have seen... and I did it by scaling the skeletons as well as the mesh... which seemed strange...but not so if the scaling factor in the skeleton was applied to something that was already scaled... if you see what I mean!


Anyway....

I have a horse which has gained some bones for a chariot, but lost it's tail in the process. Small price to pay! Now I just need to animate the former tail bones to make the chariot and wheels work properly!

[KnightErrant]

Say again, I think you are hitting on something here.
Two scalings, the 1.2 (or whatever) in descr_skeleton.txt and
the x, y, z, scalings you can put in when exporting an extracted
skeleton to an animations directory. Which combination seems to
be working ok? or, if not ok, at least better in some way.

I'm leaning more and more on the problem being a weird animations
interaction that hasn't been seen on more conventional guys (like
armored sergeants with small tails).

[Bwian]

In modeldb, there is the option to put a scaling factor in for the MESH file. This is essential if you want a scaled animation to work..otherwise it stretches the mesh. This has been the way of things since RTW, and fairly straightforward.

Also, in descr_skeleton, there is a scale factor. When I scaled up the Bone Giant, I scaled up the animations to make the big skeleton, and also put a scale factor in the mesh to match it. There was no need to make the thing bigger in MS3D, since this did it for me.

Now....there is also a scale factor in the animation utilities, which changes the 'framework' slightly, and puts a scaling factor in for the vertical position of the root bone, and the relative values for forwards/backwards and left/right movement.

In the stock horse, you have a 1.12 scale factor in the descr_skeleton text, AND a 1.12 scale in modeldb.

When I did the animations, initially I took out the 1.12 in the descr_skeleton text file. It was still there in the mesh ( causing underground feet! ) and the value in the animation utilities was 1,1,1.

This worked as long as I didn't add too many bones! With just one added, I got it to work. With 4 added I had a failure. Haven't fully tested this theory due to time shortages...but I am suspecting this!

When I re-ran it, I had put the 1.12 scale BACK into the skeleton text file, meaning the creation of hte animation packs would have included a command to scale the whole skeleton by a factor of 1.12. 1.12 was still in the mesh ( feet again) 1.12 was put in all the scaling factors on the animation utilities and I had my bizarre dislocated mesh and flying hooves!

Taking the 1.12 back out of the text file and reverting to 1,1,1 in anim utils fixed it again. Same mesh, same animations, smae everything else... just a change in a text file and a re-run of the CAS file building.

I don;t think it is the CAS file bit, becuase I was able to, again, revert that change and fix it.

Conclusion:
Putting a scaling factor in the descr_skeleton text, combined with a 1.12 value in the animation utilities broke the model. It is, also, the first time I have ever put a number greater than 1 in teh animation utilities scale. All the dwarf sets used 0.64!!!

[Bwian]

Another few tests ... and a hole heap more confusion!

I tried tweaking slightly the skeleton file I had which was working...and ended up with one that was broken again...but I don;t know why

I need to do some more considered testing this weekend, as time allows. There are many things I am still not sure about, and I have still not managed to get conmsistent results. There are some random factors in here that are still causing issues.

One bizarre one seems to hinge around the name of the model when I run it through the converter to make the mesh from the MS3D file. I get bad results when I completely change the name....possibly.

Anyway...I have kept the 'working version' and will go back to it to make some adjustments. I also need to get to grips with the scale and alignment things. With a scale factor of 1,1,1 the horse mesh is below the surface of the ground...so I am sure I need to enter a value of 1.12 for each...but I don't seem to be able to get it to work that way. Perhaps if I just set the vertical value to 1.12...that might work.

Lots to try! Going to go back to first principles and try to recreate the successful skeleton and see where that takes me. so far, I have yet to get the actual chariot mesh I have in game with the working skeleton...so there are still issues I have not understood or worked around. More updates to follow

[Bwian]

OK...one very diagnostic test...

I have been working on the skeleton, and when I had one that seemed fine, I put in a new model which I had planned to have as the finished product. Every time, though, I ended up iwth something broken.

Logic required that I go back and try to add this model to the unmodified horse skeleton... and sure enough....it breaks it!

I need to know a few things about the meshconverter.

1) Is it limited in the size of mesh it can handle

2) Does it matter what you call the MS3D file

[KnightErrant]

(1) No it should not be limited at all in the size of the mesh. To convert
back and forth that is, the game probably has its own limits but I've seen
people doing models with over 7000 tris so that shouldn't be it.

(2) Well, it's vital when converting a mesh to ms3d that the horse .mesh
file have mount_ to start the name and NOT have have camel or elephant
in the name otherwise the converter can't find the horse skeleton to use.
I.e. you can't use the extra meshes that aren't named in the modeldb file
but are in the models directory for horses. Going backwards from ms3d to
mesh it is still vital to have "mount_" in the name otherwise the converter
doesn't know to look for the 4 or 2 following the bounding sphere data
(check the model comment in Milkshape for this). This is because mounts
don't have a regular pattern for when the full tangent space basis is included
or not (4 means full basis, normals, tangents, and binormals, 2 means
normals only).

Sorry, long answer. If you are deriving from mount_fast_pony for example,
call your chariot mount_fast_pony_chariot and the converter
SHOULD do the right things. Good spot though, that could definately
cause a problem.

[Bwian]

Will try and do a few more tests on this front today. I have been more and more convinced as the testing progresses that there is no real issue with the animation utility and it's part in the process. The fact that I can create the same error with an UNMODIFED skeleton and animation set tells me the problem is elsewhere.

Since, also, I was able to make a stable and workable undead horse with the mesh converter, it also tells me that there is a workable tool there, but possibly one that is not all that 'forgiving'. I know I had some very bizarre results in my first few attempts there, and this might be related to that.

I need to refine and fix an exact and reliable process to put a model in for a mount that I am 100% sure is repeatable and reliable before I move back to the skeleton issue. Then I can be confident that any 'funny business' I see is animation related.

Back to the modding dungeon for more testing!

[Bwian]

OK ... this was a pretty conclusive diagnostic test, and I could REALLY do with someone else trying to duplicate what I did for a reference check.

1) I took a stock pony model, and converted it to MS3D.
2) Opened it up in MS3d and moved the mesh to the side so it was off the edge of the bones, but still rigged to them.
3) Converted back to MESH and ran in game
4) Instant breakage. Horse hooves flailing, and mesh disconnected from the skeleton. This is the error that has been plaguing me all along!

Back to first principles.

I checked through ALL my work, made sure the 1.12 scale factor was back in the descr_skeleton.txt file, placed a fresh copy of stock horse animations in the file, and rebuilt the animation files knowing that EVERYTHING was as stock as I could make it.

TEST 1: Just swapped the textures over, and created a mount_chariot_lod0 that was identical to the stock pony mesh. WORKS

TEST 2: Removed all the extra bits, leaving me just the basic single horse mesh, but otherwise as test 1. WORKS

TEST 3: Move the mesh off centre again, but now using a known good animation set. BROKEN

All I did for test 3 was to select the single group in the model, and move it sideways until the mesh was just off the bones. In theory, this should have no effect on the thing, since the vertices are assigned to a particular bone and move with it... but no. I don't understand why this should have the effect it does...or if there is any way of working around it... but at least I know now why I can make a chariot with a single horse...but have it fail every time I try my double horse mesh. HELP!

[Professor S]

I've finally started looking into this Bwian (Now that my slinger anim has stopped fighting back ).

The problem your having is just because you're effectively offsetting the mesh from the bones on the x-axis. This can't be done without changing the skeleton to match the offset. I'll give you an example:

Here's the GS slinger. as you can see I've offset the mesh horizontally.



Look what happens when I rotate his right upper arm:



The vertices assigned to the upper arm have to move in accordance with their position in the model. Because the vertices have been moved, they still have to move in relation to the bone they are assigned to, but now the distance is greater so they are rotating in a wider arc. If they didn't, then on the regular models, when a bone is rotated, all the verts assigned to it would move on thier own axis and just rotate in situ.

The reason the horses only appear to be broken at certain points is because the model isn't offset on the y axis. So, for example, I can rotate the offset-slinger's head to look up or down and it is fine, but if I rotate it to look either right or left then it now has to rotate on the offset x arc.



The bad news is that this is unavoidable.

I haven't worked with horses yet so I'll go with what I know: The only way I would be able to get two slingers working together as one model would be to have two human skeletons side by side, with different bone names... possibly with a master root-bone connecting both pelvis.' Then it would need a completely new 'siamese-twin' anim set to go with it.
Then I'd have to find a game engine to use it with because I'd have as much chance of getting it into M2 as platting fog

I apologise in advance but... we may be looking at a one trick pony.
Gah! I can't believe I just said that.

It may be a case of having to settle for the one horse. But hey that's a real achievement!

As a footnote. That slinger is working fine in the game now... except: Because I can't add an extra bone to the hand and get it to convert (and believe me I tried... even with a hex editor which I'm a total dolt with) the only way I could get it to 'sling' properly was to spin the entire right hand . Not an ideal solution but it works and looks ok. Better than no slinger at all.

Your one horse chariot may not be as you originally intended it, but it works and I'm sure will really add something to the game. So as Roy Rogers said to Trigger: "Why the long face?"

[Bwian]

Professor ... I know what you are saying about the offset...but htis isn't a problem with the horse, and definitely isnt what I am seeing.

The horse leg movements are not in a 'problem plane' since the horse legs pivot in line, and do not move outwards noticably.

Also.... what I am seeing in teh problem animations is parts of the body that are not moving in line with the bone in any way. The 'broken' picture in animerge has vertices in the hoof attached to the base leg bone... but swinging wildly away from the actual bone positions. Also...when you see it moving, you can see it is spinning around the hoof position in a wild way. It is clear when you see it in action that the vertices are NOT following the movement of any bone in the model at all. It doesn't show in still shots... but it's quite clearly not in synch with the animations. Ironically...the hoof is acting just like..er..a sling

I agree, though, about making a double skeleton. I would rather book myself in for root-canal treatment minus the anaesthetic than try that...

[GrumpyOldMan]

Hi Bwian

I've just called in to see what's happening after a long sojourn away playing with a dx9 dll. After you've moved the bones in Milkshape have you rezeroed the bones? Any movement of any bones screws up the angles and rotations for other bones. Just thought I'd throw that in to make sure that's not the problem.

Cheers

GrumpyOldMan

[Bwian]

GOM ... I hadn't re-zeroed the bones after I moved the mesh..I will give that a try tonight. If it works, it will be great! Every other element in the unusual skeleton department is working OK now, and KE is making big steps getting animation CAS files into Max along with MS3D models. That will make key-framing a lot easier for me, since Max lets you input a rotation angle, rather than forcing you to manually move.

If it fails, I will post back and give details. If oyu want any more data, just shout. I can PM you a whole raft of test stuff that KE and I have been batting back and forwards in an effort to understand why things work or don;t work here. The only bit left is to work out why, whem I move JUST THE MESH from a horse skeleton, the animations still work, but the mesh falls off the bones in really odd ways. In the MS3D file ( pre conversion ) the bones are not touched. I just moved the mesh to one side, leaving rigging, bones etc where they were. The Horse breaks when you do this.

I found this out when I tried to rig a new mesh with double horse models to a single horse skeleton. It broke as above. I couldn't figure out what was wrong....and ultimately I pinned it down to a model that was not sitting exactly ON TOP of the skeleton.

As soon as I started rigging vertices to a bone that the mesh wasn't sitting over, this happened. I suspected my model ... so I used a stock horse, and moved the mesh to one side to simulate what I had done with the complete mesh. I got exactly the same problem.
When I did the same to a camel or elephant..they were fine! Something in the horse data meant I could not do this. We have been trying to isolate what the problem might be ... so far without much success.

[GrumpyOldMan]

Hi Bwian

I had a look at the horse animations and the problem is that when the animations were originally done, the bones weren't zeroed so there are significant z-axis rotations which is why you're getting those weird gyrations of leg bones etc. If you have a look at the camel animations (in Model Information under Joints) you can see that in the walk animation for example there aren't any z-axis rotations which is why you can do the dual body - one skeleton trick with those. I haven't looked at the elephant yet but I imagine that it's the same as the camel.

Possible solutions:-

1.Get some maths whiz kid to work out how to change the rotations through the hierarchy to zero out the z rotations, I thought about it briefly - result -> got dizzy and had a beer instead .

2. Use two skeletons for two horses. (Still some difficulty here because if you move the horses away from the origin, you'll get spooky effects again because of the z rotations.

3. Import RTW horses and animations for chariot horses. I'll see if I can do anything to extract them.

Cheers

GrumpyOldMan

[Bwian]

That would explain a lot GOM .... if the animagtions are compensating for something very wrong from the outset. I am assuming also, from that, that I cannot cure it by making a brand new skeleton and then applying it to the existing animations using KE's animation toolkit.

When I say that...I mean I KNOW I can't because I tried it..but I would guess from what you are saying that the whole animation set for horses is broken, and when I made my new skeleton, the tools took it's starting point from the existing anims, and tried to modify them according to the original rotations and movements. All we were doing, in that case, was to take the initially wrong animations, and apply them to a good skeleton.

If KE's CAS-txt and txt-CAS can be made to work on RTW animations, it should be easy enough to convert across. It would give us the raw rotations and translations which would then be pastable into the existing M2TW text files in between the headers. IF the bones are different, it would..again...be easy to build a new skeleton to match the start positions and structure of the RTW one. Likewise, I reckon with KE's help, it would be easy enough to plug in the necessary bone heirarchy into the text file to build a suitable animation file that would work with a custom built skeleton.

I can think of several others who would like that! We could bring slingers back in, wardogs...all sorts!

Could this be light at the end of the tunnel?

[KnightErrant]

I see what GrumpyOldMan is talking about for the bone_rightfingerbase
in the fs_horse_walk.cas anim. The z-rotation goes to -90.456 degrees
in frame 11.

8 bone_RightFingerBase  quaternion data and Milkshape euler angles
-0.0779887289 -0.1073885784 -0.0089800796 +0.9911128879      -8.9917647499 +12.3726503324  +0.0616114479
-0.1303138584 -0.1061544269 -0.0108413538 +0.9857139587     -15.1015328870 +12.2455259978  -0.3690086806
-0.1829765886 -0.1076700017 -0.0122274384 +0.9771270156     -21.3116228426 +12.4090270662  -0.9097567582
-0.2359533161 -0.1057780981 -0.0129864430 +0.9659028649     -27.6099451820 +12.1499631136  -1.4554141677
-0.2890415192 -0.0952186882 -0.0120221730 +0.9524934888     -33.9398793443 +10.8559342564  -1.8755071937
-0.2587591410 +0.0429353416 +0.0138335815 +0.9648880363     -30.0125615527  -5.1644541612  -0.2574958105
-0.1024309471 +0.3177327216 +0.0515341386 +0.9412215948     -11.6392587703 -37.4934833355  -2.3055858496
+0.0586307459 +0.5197373629 +0.0761086121 +0.8489069343     +21.5291746130 -60.8670873546 -22.9924521426
+0.1693638861 +0.5997048020 +0.1321451068 +0.7708486915     +61.9752377361 -61.6185037859 -58.8641548711
+0.2640884221 +0.6532451510 +0.2382633239 +0.6684000492     +89.3914531400 -48.3667790791 -87.1526059225
+0.3193170130 +0.6120377183 +0.3588389754 +0.6282364726     +86.8065270675 -32.6728860835 -90.4568055562
+0.3707062900 +0.5287030935 +0.4013664424 +0.6495805383     +79.6113189278 -22.9104745047 -82.5924369534
+0.4278456569 +0.4554167092 +0.3857889175 +0.6787567139     +76.7742017806 -16.7453220711 -72.5269306075
+0.4465982914 +0.3973028064 +0.3353077769 +0.7281957865     +72.7096313376 -16.2084487118 -61.4154081110
+0.4254452288 +0.3505138457 +0.2590471804 +0.7931147218     +65.3912612268 -19.6074838145 -48.8343669994
+0.3305005431 +0.2934674919 +0.1529608369 +0.8838829994     +47.8876720446 -24.6878604814 -30.7369475104
+0.1914506853 +0.2179985493 +0.0388306379 +0.9561984539     +24.7309880034 -23.7052353165  -9.9196160665
+0.0118316673 +0.1142500341 -0.0464362763 +0.9922956228      +0.7573564014 -13.1698461067  +5.2711822703
-0.1296854466 +0.0035731215 -0.0947213545 +0.9870140553     -14.8754672858  +1.0035593746 +10.8324845095
-0.1261472106 -0.0616303608 -0.0685013607 +0.9877226949     -14.0704330157  +7.9917157723  +6.9467198812
-0.0779965445 -0.1073842421 -0.0089881262 +0.9911127090      -8.9925698584 +12.3722260069  +0.0624879800

I checked a couple of others, run is ok, charge is ok, but walk_to_run
has this for some frames for bone_leftfingerbase

12 bone_LeftFingerBase  quaternion data and Milkshape euler angles
+0.2791219354 -0.5516200066 -0.3478319347 +0.7048540711     +73.1354799720 +35.6934347911 +79.3956625350
+0.2405540794 -0.3864003718 -0.1402595639 +0.8792927265     +42.2207323922 +37.7370137304 +33.1593424015
+0.1333078742 -0.1071173251 +0.0529504418 +0.9838450551     +14.9254796385 +12.9964762687  -4.4517298977
+0.0685006306 +0.0543033816 +0.1191555858 +0.9890201092      +8.5723279556  -5.2263057930 -14.1315580861
+0.0373531543 +0.0381663032 +0.1160615236 +0.9918053150      +4.7690997601  -3.8437943965 -13.5089709754
+0.0092582554 +0.0241425186 +0.1266942769 +0.9916047454      +1.4041113361  -2.6097932972 -14.5940976430
-0.0561790243 +0.0279765017 +0.1478152871 +0.9870217443      -5.9058993701  -4.1193942370 -16.8219226427
-0.0938906819 +0.0073265801 +0.1350163519 +0.9863576889     -10.5670778725  -2.2813651451 -15.3778396521
+0.0517886393 -0.0631816983 +0.0335273631 +0.9960933328      +5.7261629421  +7.4315941566  -3.4833770534
+0.1858716011 -0.0830081105 -0.0025413027 +0.9790582061     +21.6683158116  +9.2994784323  +2.0809300422
+0.2259613276 -0.0410515182 +0.0615762360 +0.9713210464     +25.8769025008  +6.1756073187  -5.8346775725
+0.3319174051 +0.0109278215 +0.1042293161 +0.9374687672     +38.7074743284  +2.7915271286 -11.7076784827
+0.5893595815 +0.0557385311 +0.1071844921 +0.7987865806     +72.5841197814  +2.1372863599 -13.7154475940
+0.6391445994 +0.0721835792 +0.1483650208 +0.7511801124     +80.0296065428  +4.6579858158 -18.4340914660
+0.6423300505 +0.0960661620 +0.1536665410 +0.7446945310     +80.9905048760  +3.1143777910 -20.6588360504

It starts out with a z-axis rotation of +79.39 degrees in the first frame.
I'll look at some more anims tonight but if a lot of them are like this
it would be a lot of work to redo them.

[KnightErrant]

I first tried to fix up the right and left toebases in Milkshape's keyframer
but I just made it worse so I tried doing it with numbers. The idea was
make y and z rotations small where the z's were big, and make a reasonable
guess for the x rotation. Sort of heavy
handed but here are the modified frames for right and left toebases:

8 bone_RightFingerBase  quaternion data and Milkshape euler angles
-0.0779887289 -0.1073885784 -0.0089800796 +0.9911128879      -8.9917647499 +12.3726503324  +0.0616114479
-0.1303138584 -0.1061544269 -0.0108413538 +0.9857139587     -15.1015328870 +12.2455259978  -0.3690086806
-0.1829765886 -0.1076700017 -0.0122274384 +0.9771270156     -21.3116228426 +12.4090270662  -0.9097567582
-0.2359533161 -0.1057780981 -0.0129864430 +0.9659028649     -27.6099451820 +12.1499631136  -1.4554141677
-0.2890415192 -0.0952186882 -0.0120221730 +0.9524934888     -33.9398793443 +10.8559342564  -1.8755071937
-0.2587591410 +0.0429353416 +0.0138335815 +0.9648880363     -30.0125615527  -5.1644541612  -0.2574958105
-0.1024309471 +0.3177327216 +0.0515341386 +0.9412215948     -11.6392587703 -37.4934833355  -2.3055858496
+0.0586307459 +0.5197373629 +0.0761086121 +0.8489069343     +16.5291746130   0.8670873546  -2.9924521426
+0.1693638861 +0.5997048020 +0.1321451068 +0.7708486915     +19.8752377361   0.6185037859  -2.8641548711
+0.2640884221 +0.6532451510 +0.2382633239 +0.6684000492     +24.0914531400   0.3667790791  -2.1526059225
+0.3193170130 +0.6120377183 +0.3588389754 +0.6282364726     +25.5065270675   0.6728860835  -2.4568055562
+0.3707062900 +0.5287030935 +0.4013664424 +0.6495805383     +24.7613189278   0.9104745047  -2.5924369534
+0.4278456569 +0.4554167092 +0.3857889175 +0.6787567139     +23.6742017806   0.7453220711  -2.5269306075
+0.4465982914 +0.3973028064 +0.3353077769 +0.7281957865     +21.6096313376   0.2084487118  -1.4154081110
+0.4254452288 +0.3505138457 +0.2590471804 +0.7931147218     +20.9912612268   0.6074838145  -1.8343669994
+0.3305005431 +0.2934674919 +0.1529608369 +0.8838829994     +19.9476720446   0.6878604814  -0.7369475104
+0.1914506853 +0.2179985493 +0.0388306379 +0.9561984539     +17.7309880034 -23.7052353165  -9.9196160665
+0.0118316673 +0.1142500341 -0.0464362763 +0.9922956228      +0.7573564014 -13.1698461067  +5.2711822703
-0.1296854466 +0.0035731215 -0.0947213545 +0.9870140553     -14.8754672858  +1.0035593746 +10.8324845095
-0.1261472106 -0.0616303608 -0.0685013607 +0.9877226949     -14.0704330157  +7.9917157723  +6.9467198812
-0.0779965445 -0.1073842421 -0.0089881262 +0.9911127090      -8.9925698584 +12.3722260069  +0.0624879800

12 bone_LeftFingerBase  quaternion data and Milkshape euler angles
+0.2791219354 -0.5516199470 -0.3478319347 +0.7048541307     +22.6354731418 +25.6934347911  +9.3956488746
+0.3020104468 -0.4877605438 -0.3425080180 +0.7440212369     +20.9641696414 +23.2602629442  +8.2002676479
+0.3441262245 -0.4243847132 -0.3319616616 +0.7689448595     +19.8789183419 +21.0989900581  +7.4108330504
+0.3789862692 -0.3699323535 -0.3019785285 +0.7926716805     +18.7877866028 +20.9515489300  +6.8786262091
+0.3767482936 -0.3250544369 -0.2406673729 +0.8333544135     +16.7963466220 +17.1265486218  +6.5364307158
+0.2822917402 -0.2959881723 -0.1269130856 +0.9036567211     +12.9262741211 +14.5996333039  +6.1764829190
+0.1473697126 -0.2720256150 +0.0000681584 +0.9509385824      +9.1158211848 +11.1566284840  +5.3672680908
-0.0268405452 -0.2108599097 +0.0852945149 +0.9734179378      -5.5397269523 +13.9494777586 -11.1911872617
-0.1618822664 -0.0574169867 +0.0826872140 +0.9816619754     -19.1800983876  +4.9310559251 -10.4631736197
-0.1739860028 -0.0330636874 +0.0616591386 +0.9822595716     -20.2553016441  +2.4930724079  -7.6291957982
-0.1630186290 -0.0534575842 +0.0368328951 +0.9844849110     -19.0466945478  +5.3504598491  -5.1834933135
-0.1458995789 -0.0952253491 +0.0179769844 +0.9845416546     -17.1973866791 +10.5014832970  -3.6844354110
-0.1227545217 -0.1518784314 +0.0043208357 +0.9807372689     -14.6858800175 +17.2681969577  -2.7468275960
-0.1571276188 -0.1518213451 +0.0002056235 +0.9758386612     -18.7318723459 +17.2320072004  -2.8873856320
-0.2029475570 -0.1306011528 -0.0058808010 +0.9704231024     -23.9452788998 +14.8247719143  -2.4661386241
-0.1947324127 -0.1565718800 -0.0183768086 +0.9681047797     -22.9898993594 +18.0781002990  -1.5309406920
-0.0110646589 -0.3294922411 -0.0522234999 +0.9426479340      +0.9922093077 +18.4876583503  +6.6883696834
+0.0980595797 -0.4057742655 -0.1019175276 +0.9029642344     +12.8418188924 +15.4641160214  +6.0796144355
+0.1384247839 -0.4392346740 -0.1649249047 +0.8721876144     +14.6594880178 +16.0983127463  +7.1747411464
+0.1985810101 -0.5022994876 -0.2541397214 +0.8022928238     +18.3311505804 +14.8334129384  +8.9083188742
+0.2791212201 -0.5516203046 -0.3478331566 +0.7048535347     +22.6354799720 +15.6934108854  +9.3958332897

Then reconverted to a cas file with the animation utilities and
animerged with the horse. Offset the horse from the skeleton and
here's frame 11 where the rightfingerbase went kablooey before.



The animation plays ok with no oddities but you can just detect
the transitions on the fingerbases between my modded frames
and the frames I left alone. A little tweaking might smooth that out.

I've looked at about half of the fs_horse anims and leaving aside the
dying anims which will likely be a problem (dead horses fall on their
sides, a 90 degree rotation around z) I haven't seen too many bad
ones like the walk anim. The two other bad ones are fs_horse_walk_to_run
and fs_horse_run_to_walk which are transition anims and not continuous
ones. This might not be too bad to just band-aid them this way.

[Bwian]

I'm not overly worried about the transition of the death animations..it is rotating the root bone, and this didn't appear to be standing out as a bad animation in the test runs. Not like the walk sets were!

This definitely seems to be a cure for the problem. CA had clearly not zeroed the bones before they set up some of the horse animations! It looks as though they fixed it part way through, or did some re-work on the skeleton that ended up fixing the problem...just never went back to re-do the animations for those few steps. I suppose the thing worked fine for them...and only shows up as broken when we start doing silly things with their models!!!

Either way...we have a solution in the works, and this will mean we WILL have chariots! Three cheers for KE, and a suitably big pat on the back for GOM for nailing the root cause!

[Bwian]

OK....we have the last piece of the puzzle in place!

It was a struggle, but we have got there. I have just successfully taken an animation from it's original CAS form that was one of the broken horse ones. I have converted it to MS3D, and from there to an SMD format.

( see Alletun's tome of knowledge for the how to )

This was imported to Max as JUST a skeleton. You can import the mesh...but you really don't need it unless you want to really see the workings. Mesh and animations are imported seperately. No big problem.

Next...I corrected the erroneous feet on the horse, and removed any motion that would cause a problem when I create the chariot version.

The resultant thing was exported from Max... but ONLY the animation. No need to export any mesh.

Open up MS3D and open up the model that will form the actual mesh in the end. Import the SMD file, but ONLY check the skeleton box. We don;t want the triangles or renaming bones...no. NExt, you will notice a new bone is added called 'smdimport'. Delete that. It's not linked to any other bones, and is not a problem....just don't want it!

The animation is fixed.....nearly.

Professor S over at TWC came up with a good way to fix the nasty 'hidden' animation frame that would otherwise create a nasty 'kick' to a new animation. It basically involves reversing the animation, adding a new frame at the end which 'becomes' the bad frame. Remove the keyframe and delete the added frame by returning the last frame number to it's proper number. Finally...re-reverse. It screws up the mesh, but we only want the bones. Convert the messed up mesh back into a CAS file, and the job is done.

Just have to repeat the thing for the transitional animations around the walk, and modify the death animation so the horses don't hover in the air...and add in the extra bones and bits for a real chariot.Problems solved, and just a bit of hard work to go

Happy days.

Now I know all the process works, it's time to put all the things I have collected together to make myself a real chariot complete with a pair of horses to grace the battelfields ofthe Warhammer universe.

[Ashdnazg]

Cheers Bwian!
Make those Chariots rock'n'roll!

[rorarii]

have we given up on the M2TW chariot? .. or is someone else doing it?

R

[Icedie]

same question?

[Abokasee]

same question?

Bwian was working on it for the Warhammer Mod, but his been abscent for a very long time.