Making new animations .... how is it done!

**Bwian** · 05-01-2005, 21:17

Would the unpack/repack of skeleton.dat allow the actual creation of a new skeleton with re-positioned bones ? If I were able to make a skeleton ( using the same number and names of the bones ) with the pivots positions moved around a lot, that would be REALLY useful. I could make the legs on the Heavy Walker a lot shorter, and the 'shoulders' a lot wider. I could also make a couple of units with longer arms....

**SigniferOne** · 05-10-2005, 18:51

Verc, are you absolutely sure that there are bone positions in skeleton.dat? Is that why deleting those two files and relying on descr_skeleton.txt didn't work? Is that why AnimPacker doesn't work properly, because I looked at the code and it doesn't seem to be writing any bone data into the files?

**Bwian** · 05-10-2005, 19:52

From 'empiric' experimentation, it is clear that the animations are only actually recording the rotations applied to each bone, not the bone positions. It can only really be the DAT file that is holding the necessary information.

Each bone would need to be named, and the basic skeleton structure defined somewhere. If it is in the CAS file, then it would be possible to make new shapes by moving the bones in the CAs file, but it isn't. Also, if you translate a bone position, rather than rotate it, the effect is ignored.

As to why the game won;t run without the DAT files...well...I think it is possible something more than just the animations. I suspect the game is just designed to run that way :D

**Vercingetorix** · 05-10-2005, 20:50

Originally Posted by dsyrow1

Verc, are you absolutely sure that there are bone positions in skeleton.dat? Is that why deleting those two files and relying on descr_skeleton.txt didn't work? Is that why AnimPacker doesn't work properly, because I looked at the code and it doesn't seem to be writing any bone data into the files?

Yes I am sure... If you look at the code that scales skeletons it scales the bone positions.

I was thinking so time ago and realized that the .rum files do not contain any skeleton information unlike the .cas files. Aha I said I'll just delete the .rum files so it uses the .cas files and then it'll load the skeleton from the first .cas file like Jerome said... It was a good thought but it turns out not to have worked.

**SigniferOne** · 05-10-2005, 21:43

Wait but my two questions remain unanswered:

1) If the bone positions are stored in the DAT, is that the conclusive reason why simply relying on descr_skeleton.txt will not work?

2) When AnimPacker creates a new skeleton, how does it deal with those bone positions of the old skeleton, copy them to their respective places in the new one? Is this why AnimPacker's buggy (I noticed that it only has problems creating skeletons, cos updating existing animations seems to work perfectly).

And here's a new question:

3) Earlier you said that it would be a very good idea to make a program that compiles descr_skeleton.txt into skeleton.dat/idx -- but how can this be done, given what you said? Where will the compiler get the bone position data? (btw, please check your gmail email, I sent you something to this extent as well)

**Vercingetorix** · 05-11-2005, 07:16

1) It's a good bet.
2) The Animation editor just copies the base skeleton.
3) Well you could simply have it ask for a .cas file for it to extract the bone positions from for each skeleton.

As to answer your email question, If I were to add support for extracting skeletons from skeleton.dat it would extract all the skeletons into a separate binary file. It would not turn skeletons.dat back into descr_skeleton.txt or anything like that...

**SigniferOne** · 05-11-2005, 19:56

Verci, so far the discussion has focused on two mutually exclusive alternatives:

1) either we continue to use skeletons.dat and force ourselves to work through the binary format, or

2) spend an incredible amount of time making a compiler/decompiler which extracts text info from skeletons.dat into descr_skeleton.txt, and then constructs a whole knew skeletons.dat from that text file.

If we go with option 2, why do we have to worry about bone positions stored on skeletons.dat? Why not simply extract the text content of skeletons.dat, then have that information easily editable in text format, and then again reinsert it into skeletons.dat? That would work for all cases, I think, except for when you create a whole new skeleton. But then you could just have some sort of prog, similar to what you already created, which simply copies the old base skeleton... I really don't think that'd be a lot of work, hmmm...

**Bwian** · 05-11-2005, 20:36

Not that I really understand exactly how all this works...but... ;)

The suggestion from Vercingetorix that we could 'supply a CAS file for it to get the bone positions from' sounds like an interesting concept if it means what I think it means.... Please correct me if I am wrong!

If the builder wanted to make, say, and Ogre type creature. It would have longer arms by proportion, a broader set of shoulders and shorter legs.

Currently, you could make the mesh, but you could not actually animate it with the stock skeleton. It would only allow human proprtions, and would force the skeleton into that shape.

When you modify an animation, it only takes into account the rotations you make on the joints, so even if you re-site the joints by translating the pivots, when the CAS file for the animation is exported, nothing but the rotations are saved.

When creating an animation from scratch, you have to start with the model in the reference 'arms out' pose and make the first frame by moving the model into the start pose. This gives the game the data to start the animation.

If we could build a CAS file as the basic model and use that to reference the relative positions of the pivots for the DAT file, that would allow us to make ANY body shape we wanted, provided we kept to the stack number and structure of bones. A 'human' based skeleton would have joints at 'wrist', 'elbow' and 'shoulder' but we would be able to choose where these joints were, rather than being tied strictly to the stock layout....which, I have to say, makes for rather puny people! Is this feasable.....can it be done....would be absolutely AMAZING if we could do that! I want to make some models which are somewhat Non Human :D