Moho Animation Forum

IT WORKED!

That was annoying... must look into this. I had to delete and replace the line break of the first line only. It was an "odd" line ender. AS was reading it as an unknown character causing the script to think it wasn't correct.

So, my line ender printing is incorrect somehow. It is printing "\n" for line returns. It works with all the stuff I've been doing... but I never tested across platforms until now.

Windows is "\r\n" and Mac is "\r", unix is "\n". I guess I may have to do some sort of platform test? <sigh>.

Maybe "\r" is the way to go.

-vern

Well, it's easy to see how exciting this concept is when the thread grows this quickly <g>.

And I hope you don't think I'm a PITA for pointing out issues, Vern. I've been down this road myself, and well understand the sort of problems you're dealing with (in 3D it actually drove me out of programming -- but then I had already retired a year earlier. It was just that I realized I'm too old to program stuff anymore).

With your new script I'm now experiencing something very odd (BTW, shouldn't the version be changing? It's hard to report problems if the script always says the same thing in the menu). It appears to save the data correctly for me, but I can't get it to load at all on my skeletons (yes, they have the same named bones). Indeed, I can't even get it to load back into the exact same rig I saved it from.

Now, I only saved from frame 1 to 49 -- do I need to save from frame 0 in this version? (By the way, defaulting to that each time as you do is a little confusing if that's not what you should normally be doing). And I'm only trying to load bone rotations (since that's all I'm keying). Oops, update just now. I trying loading in positions on a file and that worked fine -- still no rotations, though.

I'd be glad to send these files to you direct (I can't post them for all kinds of reasons).

Just tried saving from frame 0 and that did indeed bring in all the animation to the rig -- but screwed it up mightily (as expected). So there is something going on there but I haven't a clue.

No more time to play -- must get back to work today (yep, even on Sunday. However, I'm now 75% done on my project so pretty confident I'll make my deadline and even have time to polish it up before 7/8. However, if you get this working for my purposes I can still use it here, as I've left some of the harder animation stuff for last just in case I can import it from other files).

One more thing (really!): I'd strongly advise you to add a version number to your saved data file -- having it on the first line would immediately identify what version created it (and save you untold headaches as you keep changing how it's formulated) plus you can test this and avoid loading in versions that don't work.

I fixed the "frame 1" not loading problem.

I offset the loop because of checking for frame 0 data but neglected to read in the next line if there are no frames. This caused the script to fail if you started at frame 1 and a bone without any keys was hit.

Anyway new version is up. I have not put in a version number on the file format yet. It isn't a big deal at this point since I've deleting them as I go but I will work on it.

I will PM you with my eamil so you can send me the file you have trouble with.

-vern

New version now has a version number printed. It is currently 0.12 in the file format and 0.1b for the script... don't ask... I know nothing about version numbers.

-vern

New version is definitely better... but still failing for me on a rig.

I was at least able to load it successfully onto a rig facing the same direction (I had not been able to do this before). And in that case it worked perfectly. However, on a rig I had built in the other direction (facing left instead of right facing as the other two rigs were) it did the upper body animation correctly but reversed the lower body.

You've got to be *real* close here -- but the reversal is confusing to me. It's almost as if the lower limbs were just minus instead of plus, if that makes sense (or, more likely, 180 degrees versus -180).

I'd love to get this solved because, unfortunately, the characters I need to load actions on the most are all built the opposite of the characters with the actions I need (yeah, that was pretty stupid of me -- as soon as I'm finished with this project I'm going to rebuild them all, all facing the same way, all with your better bone rig -- but I built these all when I first got AS and there's just no time right now).

I'm beginning to suspect right now we're on opposite ends of the world (it's my daytime, for example, and I'm guessing you're asleep) but if and when you get around to it PM me and I'll send you these rigs for your own testing if you'd like.

I just got back from my family reunion. Barbecued chicken, potato salad, ice tea... mmmm.

Back on the job.

Yes, the angles can be reversed. I'm having a heck of a time figuring out how to fix that problem with a bone just around the "0" degree mark. When setting up a bone rig you can have bones that seem very close to the same rotation on frame 0 when in reality they are miles apart... or literally 360º apart.

The situation is this:

If you rotate a bone with the rotate bone tool on frame 0 it never goes below 0 and never goes over 360. No matter how far you spin it it is always with in 360º.
(However if you TYPE IN THE VALUES BY HAND on frame 0 you can set it to anything you want.)

This is not the case for later frames. On later frames if you rotate a bone it can go into negative values and values much higher than 360.

If a bone on frame 0 is rotated to 360º and on a later frame a key is set for it at 360º the bone will do nothing. As it should. The key on the later frame is the same as the 0 frame.

However, if the bone on frame 0 is rotated to 0 or 1 or 4 or anything that would be considered "below" 360 it will spin around to meet the key frame. This can happen very easily when the bone is "hovering" around that 0-360 mark. A tiny jostle with the rotate tool could push it over or under 0-360 degrees.

The key frame of the imported file must be changed to "match" the different value on frame 0 for a slightly different rotation on a bone of a different skeleton.

This is probably what is happening to your "flipped" characters. The bones are rotated just slightly differently and the imported keys need to adjust to handle that situation.

I have yet to get this fixed. I am trying to find a solution but it requires math and I am "math challenged". I will figure it out if it kills me. Which it might. Math can be very dangerous. I usually wear gloves and protective goggles when trying to do trigonometry.

-vern

I may not understand how scripting works here (what values you can get where) but it does occur to me if you can check the values at the first key to see if the bone tries to "spin" more than 200 degrees or so -- on any one of these rigs it's unlikely that such a first key would do that (you could even have this as a checkbox on the import -- like "check for wrong rotations" or something).

If it does try to go that far then you just reverse the bone key so it's facing the other way -- once again, without a complete language of understanding how this all works I may not be expressing something that can be done.

This is almost -- almost -- tempting me to start programming again, because I think I could handle 2D graphics (whereas 3D tested the limits of my trig skills -- had been many decades since I had to do cosine and tangent math, not to mention quadratic equations). But I'm way too deep in production to help you right now. If you don't get this licked by the time I'm finished, though, I might be willing to help (assuming you'd want a helping hand).

mkelley wrote:I may not understand how scripting works here (what values you can get where) but it does occur to me if you can check the values at the first key to see if the bone tries to "spin" more than 200 degrees or so -- on any one of these rigs it's unlikely that such a first key would do that (you could even have this as a checkbox on the import -- like "check for wrong rotations" or something).

If it does try to go that far then you just reverse the bone key so it's facing the other way -- once again, without a complete language of understanding how this all works I may not be expressing something that can be done.

This is almost -- almost -- tempting me to start programming again, because I think I could handle 2D graphics (whereas 3D tested the limits of my trig skills -- had been many decades since I had to do cosine and tangent math, not to mention quadratic equations). But I'm way too deep in production to help you right now. If you don't get this licked by the time I'm finished, though, I might be willing to help (assuming you'd want a helping hand).

You nailed the problem on the head. That is EXACTLY what I'm trying to do. Check if the angle of rotation on frame 0 for BOTH files (saved impot) is more than 180 degrees. That is what causes the spinning. Can't use the key frame because you may WANT a bone to spin on a later frame. the key to the issue is determining the difference with frame 0.

I got it to work... but... I get stuck trying to figure out negative and positive angles. I need a formula to determine if the difference is -180 or +180.

Once I get this value I can convert ALL the key frames to work with the bone rotation on frame 0.

If you know anything about radians and trig or geeky math stuff... I'm desperate. I know it will be simple once I figure it out.

-vern

Yeah, at one point I was a math minor so I kind of do understand radians and trig -- just have to dredge it up again (since I'm very old).

As I said -- way too busy for the next week but after that will have lots of time. If you're still stuck email me and we'll get it solved (he says, confidently :>)

I'm hoping to hear from my math guru and all around genius Genete! If he can't help me on one can!

-vern

Okay this is REALLY annoying. I don't know if it's a bug or not.

Frame 0 is different from any other frame regarding bone rotations.

Technically on frame 0 there should NEVER be ANY negative rotation values. NONE. If you set it by hand and rotate a bone with the rotate bone tool the number immediately reverts to the "non negative" corresponding value with in 0-360.

If you type in a value of -90, it would revert to 270. If you leave it at -90 it stays there but... this could cause all kinds of trouble with key frames.

In my mind the values should automatically change to the correct value and not be stored as the unchanged value if that is how it should work. I will have to look at the bone rotation tool to see if this can be changed. I think currently it is a bug.

Mkelly, can you check your files? Do you have negative values on frame 0 bone rotations?

Does ANYONE have negative values on bone rotations on frame 0?

The problem is if the crazy bone rotation tool worked the way it should I could fix this script without worrying about negative values. As it is I have to take into consideration the possibility that people would type in a negative value and not change it with the rotation tool.

I could have this script "fix" negative values on frame 0 when importing. Piece of cake. However this could cause even more issues.

I will get this working. Now that I have knowledge of this weird rotation bug I won't be getting weird results.

-vern

Don't desperate I'll take a look to the script.
Sometimes you're working on one piece of code for so long and don't see the obvious.

Give me a breath.

-G

Can you confirm that this is the last version?
http://www.lowrestv.com/anime_studio/sc ... mation.zip

It seems to be empty!

Can you provide a link to the last script? Thanks.