Save and load bone animation to any file!!!

synthsin75 · Post by **synthsin75** » Sat Jun 28, 2008 9:49 pm

Good idea Mike! If the script had the option to generate the skeleton with its animation, this would save all the trouble of naming the new bones. Aside from excluding typos, you'd be guaranteed to have a compatible skeleton for any other animations you want to load (from that original).

Granted you could just import the original skeleton. I seems to me that you would need some sort of 'standardized' skeleton. At least if you import it, or the script generates it, you've got your own standard skeleton.

I don't know if this will ever solve the issue of transfering animation between very different rigs. But the save files would be easier to share a movement catalogue than perhaps the full project.

I don't really see how useful this may be to AS Standard users. Since they don't have actions, they'd need to load later in the animation (for any multiple loads). Although I guess they could always duplicate their characters in switch layers, but OMG the file size.

Just some thoughts.

mkelley · Post by **mkelley** » Sat Jun 28, 2008 10:00 pm

Well, not to try and tell Vern how to write stuff (hey, I've been there -- programmer for over 30 years. And now well retired :>) but what I had in mind was that it would duplicate the "correct" bone rig in the same place as the old one, using the same bone lengths in the same positions.

So I'm still saying you name the bones the same (so it knows which ones to replace) but the idea is that during the replacement whatever wonky things are going on with how you defined the bones in the first place are eliminated. See, I'm guessing what's happening is that somehow just drawing the bones out in a certain order is causing the issues (because I find it hard to believe that they would reverse themselves if they are just a little turned a different way).

I dunno -- I'm thinking about this *way* too much (when I should be animating) but I'd really like to get it to work for generic rigs. Not that my own don't need redoing (I know so much more now than I used to) but I still think there will always be certain times you need to do a custom skeleton no matter what (for example, you could define a four legged skeleton for a horse and then load in a walk cycle for a man on the front legs, and a bird walk cycle on the back legs).

I've got to get back to work -- but I hope Vern can lick these issues (as I said, I was never able to. Then again, I'm not the greatest when it comes to 3D space).

heyvern · Post by **heyvern** » Sat Jun 28, 2008 10:16 pm

Obviously if a bone is rotated on frame 0 significantly differently from the original saved bone the rotations are not going to be the same. This would be expected.

I just had a freaking brainstorm!!!

Add or subtract rotation values from frame 0. Think of it. The main reason there is rotation problems is due to differences with the base rotations of the bones ON FRAME 0. So do a bit of math to determine the value of CHANGE not the absolute value.

Follow me? Instead of exact rotation values, use the value of change from frame 0 to the key frame. that would make the saved files more universal.

If a saved file indicates a rotation "change" of "5 degrees" on frame 27, that is a big difference from sticking in an exact value of "238 degrees" or whatever the value is in radians.

This is EASY to do. I will try this tonight.

-----------

I have fixed the script so unnamed bones are ignored on import. They are flagged as unnamed on export and ignored on import... best I can do for now. For some reason I couldn't get it to skip the unnamed bones during the save. I also changed the word "booger" in the saved text file (that was embarrassing).

Don't forget that with the current script unnamed bones can mess things up.

I will upload a new version of the scripts after my birthday dinner (yesterday was my b-day).

Happy birthday to me.... Happy birthday to me.... I smell like a monkey aaaaand.... I look like one tooooooooo.

-vern

heyvern · Post by **heyvern** » Sat Jun 28, 2008 10:38 pm

but what I had in mind was that it would duplicate the "correct" bone rig in the same place as the old one, using the same bone lengths in the same positions.

Holy cow! that's not going to happen! No way! Too many variables. Yikes and a half! Oh my giddy aunt! If that's what you're expecting... you are barking up the wrong tree. phew! I might get dizzy and pass out!

If you want bone import just import a template bone layer and drag the vectors into it. Rebind everything by hand. I'm not scripting that no way now how.

these scripts are intended for one simple thing; saving out the bone animation of named bones, bringing it back in. Simple and sweet nothing fancy.

I've used Animation:Master for many many years. It has external action files BUT the same limitations as this. the EXACT same limitations. The bones have to exist in both files. they have to be in relatively the same positions and rotations. It's still cool as heck.

I plan to work out the rotation bugs and possible naming issues but this is intended to save out the animation of named bones for import into a "similar" bone setup, not "rebuild" a file from scratch. That's over the top. You will still need to keep things consistent between files to use these scripts.

-vern

mkelley · Post by **mkelley** » Sun Jun 29, 2008 12:00 am

That's okay -- I was just trying to suggest something that would workaround the inconsistency issues. If you can do a relative transfer based on the differences between frame 0 rotations then that's fine with me. So far in my (admittedly limited) testing of five or six files I've yet to be able to load in a usable animation from one rig to another due to these problems.

In my 3D software (Max) the bone rigs have to have identical structures -- that's not a limitation in my book. What is a limitation is that the structures need to be (so far, at least) created in more or less exactly the same way. I mean, my own rigs are consistent to some degree (same number of bones in same positions with same names) but don't work with this scripting most likely because my base characters are shaped somewhat differently from character to character (and, like I say, sometimes I build them facing left, and sometimes facing right -- probably my bad but that's the way I started and with 20 some odd characters it's a bit late to change things).

I'll be interested to see what you come up with. And happy birthday to you indeed.

heyvern · Post by **heyvern** » Sun Jun 29, 2008 2:58 am

I have a rough (not ready to post yet) version with "relative" rotations AND translations which seems to be working so far. I think this is a great idea and if it wasn't for your persistence I doubt I would have even thought of that so soon. Thank you for that.

Animation Master has a similar problem with bone setups having to be the same. It does have a function to "scale" walk cycles for different characters. That would be something I would need for this. A way to modify the imported action so it can be used for different characters.

Another "scaling" option I want to add would be for stretching or compressing the distance between key frames. You could import an action and scale it 10% or 20% or reduce it 20%. Change the tempo. I suppose this might be better done with the built in function but it seems to have issues sometimes.

Just so you know, the order of creation of the bones shouldn't matter only the names AND the parenting. For instance if a rig uses a strange parenting that isn't the same the bones will obviously rotate differently. For instance my rig example has "hip" bones for each side, parents of the thigh. Some rigs might not have the hip bones. If there is critical motion in that hip bone the action won't appear to have imported correctly and adjustments need to be made. Also the extra root bone. Some rigs have the hips parents of the back. rotating the hips rotates the whole body. Another thing that has to be considered.

I've found though that even if the action doesn't import exactly right, the tweaking to make it right is minimal compared to starting from scratch. In my case specifically I've been able to use these scripts 100% successfully and have already started compiling a bunch of action files for use with my character.

This script would also be great for "simple" things like bouncing balls, waving trees or the kind of animation that is tedious to set up but can be used over and over.

I would love to figure out some way to create a way to do walk cycles based on stride length. The absolute distance between the keys of each foot hitting a certain spot could determine the translation distance of the root bone. Then a walk cycle could be adjusted based on "math" to work with different characters.

That's for the future.

-vern

heyvern · Post by **heyvern** » Sun Jun 29, 2008 3:54 am

I need to know how you are saving the animation files. Do you leave it with the frame start at 0 or do you change it to 1? If you save frame 0 info that would replace all frame 0 bone properties when importing. I just want to make sure that isn't messing things up. I would recommend NOT importing at frame 0 unless you WANT those rotations and offset applied.

--------

I spoke too soon about the angular offset trick in the script. I was checking numerical out put and not "real world" examples.

Maybe you guys can help.

If you have a bone rotated for example, at 45º on frame 0, then you rotate to -28º on frame 20 then go back to frame 0 and rotate the bone from 45º to 62º the rotation on frame 20 DOES NOT CHANGE. It's an absolute value. It stays at -28º. Doe this make sense? I suppose it does. It should do this (in graph mode you could rotate all the frames).

This means that if a bone set up on a file is different on frame 0 then a saved animation file, the bones will rotate the same as the original but this might not work with the file because you would more or less depending on where the bone is on frame 0.

Here's the problem; if I put in the value of difference relative to frame 0 bringing the same animation file back into the original file will give a different result.

I think what needs to be done is compare the angles of the saved and import file bones on frame 0. Calculate THAT difference and apply it to the new key angles. If the value is the same on frame 0 for both files than nothing changes (importing to the same file). If it's slightly different it does change which would be correct for a slightly different set up.

Will have to play with this some more and keep you up to date.

-vern

DK · Post by DK » Sun Jun 29, 2008 3:54 am

Hi Vern

EDIT: It's ok.... The script works fine if you add bone constraints....just my teething problems. This script is fantastic!!!!!!

D.K

mkelley · Post by **mkelley** » Sun Jun 29, 2008 4:09 am

So far all I've been doing is saving out animations from frame 1 (not frame 0 -- I realized early on that wouldn't work) and loading them back into rigs that are parented and constructed the same. And they behave inconsistently -- like I said, sometimes the legs are fine and the arms are reversed, sometimes the whole thing is bolloxed up.

Also, I'm *only* loading in rotations, as that's all I'm keying. However, I did try checking all the boxes (and different combos) to see if it would have any different effect (and it did not, unsurprisingly).

The things are so screwed up it isn't possible to fix them -- it would require reposing all the arms on all the keys, for example. So it isn't just minor stuff. Now, I *did* successfully load back the animations into the same rig (just to see if there was something screwed up with my system somehow). So it's definitely related to building a different rig, even if that rig is constructed with the same names and same parenting.

Just to see if I weren't crazy, I created a simple bone rig (two bones, named one and two) and another identical rig (but angled differently) in another layer, and saved the first animation and tried to load it in the second. It's here in this file:

http://www.kelleytown.com/Shared%20File ... ewrong.zip

and you'll note it doesn't work properly (not even close) and can't easily be fixed (imagine multiplying this by ten bones or more).

I don't know how you've been able to get good results but it must be something else you're doing (perhaps you're loading in bones with constraints that are keeping them from misbehaving like this but pretty obviously not all or even most rigs will have such constraints).

DK · Post by DK » Sun Jun 29, 2008 4:25 am

Hmmm...that's odd! I am getting amazing results from the script. Using the base rig I have saved out several actions like jumping, hopping etc and it's been fine.

Hey..i'm the first person to upload a bone action for this rig

Please test it to see if it works.

http://www.wienertoonz.com/JUMP.zip

Only problem I'm having so far is that the keyrames import with Linear movement set on all keyrames.

EDIT: I have just tried to import a bone animation with the overlay selected and but it does'nt work. Instead just overwrites all keyframes with the imported keyframes.

D.K

heyvern · Post by **heyvern** » Sun Jun 29, 2008 5:25 am

mkelley wrote:
Just to see if I weren't crazy, I created a simple bone rig (two bones, named one and two) and another identical rig (but angled differently) in another layer, and saved the first animation and tried to load it in the second. It's here in this file:

You ARE NOT CRAZY!!!!!

I know what is happening now. It is a "shortest route" issue. the shortest distance from point A to point B. The rotation on frame 0 is just at a point that to get to the rotation key of the imported animation file it has to go the long way around. So it spins out of whack.

(I would like to have the other file as well to verify this. I need to see HOW the bones are different to know what is happening to rotation. However I am pretty sure this is the problem)

In the mean time I have uploaded a new version with rotation "offsets". it's the same link just download again. I included icons for the buttons.

This new version should fix the problem... I'm almost certain of that. Almost certain. Dang... I forgot to change the version number.... oh heck in basket. Do it next time.

This new version calculates the difference between the rotations of BOTH files (saved and import to) and then offsets the key rotation values accordingly. I think this should do the trick. I tested it and it works great.

For example if the bone is rotated 30º on frame 0 in file A, you save file A as an animation file. Open file B which has the same bone rotated 89º on frame 0. It subtracts B form A, and ADDS that value to all the rotation keys. This will of course "change" the rotations of that bone that is different but will maintain the orientation of the bones and eliminate the "spinning".

VERY FREAKING IMPORTANT!

This version saves an "extra" line to the file so the old files won't work with it. SORRY ABOUT THIS! Can't be helped right now. I promise to fix this ASAP so future versions with new features can read old files. Once I get the angle and translation offsets working I will "lock" that in and make the files more compatible moving forward. It shouldn't be hard to do but at this point it might be too soon to try that considering this is a major bug.

-vern

synthsin75 · Post by **synthsin75** » Sun Jun 29, 2008 5:30 am

The only problem with sharing these 'actions' is that we have no idea what sort of skeleton to match. I'll bet no ones naming conventions are exactly the same.

heyvern · Post by **heyvern** » Sun Jun 29, 2008 5:46 am

Forget for a moment what I wrote previously.

I see a bigger problem here that has to do with rotations period. In your problem file the rotation key for the spinning bone is -51º.

On frame 0 the rotation is around 245º. On frame 0 the rotations can't go over 360 or under 0. The rotation is always between 0º and 360º.

On frames ABOVE 0 you can have -567º or 897º. And to add to the problem if your rotation on frame 0 is "above" the rotation on a later key frame it goes all the way around to reach it.

In your problem file the rotation on frame 0 is 245. The next key is -51. The bone spins all the way around from 245 to -51 when it SHOULD rotate from 245 to -51 the OTHER way. Unfortunately AS DOES NOT USE THE SHORTEST DISTANCE! It uses the long way around ALL THE TIME. It's like winding a clock spring. The spring can't jump directly to a spot... it has to unwind all the way before reaching a spot.

This is either a problem with AS or... I don't know.

What I need to do now is figure out how to calculate a new angle on the frames if there is more than a 180 degree difference from frame 0.

The problem is going from 245 to -51. The new script sort of addresses this but not really. It stops the spinning but the bone now isn't anywhere CLOSE to where it should be. It's all bolloxed up.

This is a pickle. I will keep fiddling.

-vern

chucky · Post by **chucky** » Sun Jun 29, 2008 5:55 am

I just realised after plying with this rig you are using that, up till now I've been doing it all wrong. Thhis skeleton is soo much better than the stupid rigs I've been making, no wonder bone lock was messing me up.
Anyway, the one thing I don't still understand is why is there no toe bone, shoulders or Skull, separate to neck?
Maybe with these additions you could convert the script to quadruped rigs without to much hassle as well as getting that extra movement for bipeds.
Even though this rig is so much better than my upside down/ inside out mess, I don't know if I could live without toes shoulders and a neck.

Oh yeah , happy birthday Vern. For he's a jolly good feeeelloooooooooow.

DK · Post by DK » Sun Jun 29, 2008 5:56 am

The only problem with sharing these 'actions' is that we have no idea what sort of skeleton to match. I'll bet no ones naming conventions are exactly the same.

I'm just fitting Verns skeleton to one of my characters and leaving the naming exactly as is. Fitting the skeleton to a cartoon style character that has different body proportions to the base skeleton is a bit tricky but will be well worth it.

D.K