Animation not even close to Poser

I created an animation that has the feet planted on the floor while the hips move. This was done using IK in Poser. If you stand on the floor and shift your hips around, note how your legs bend to accomodate. That's pretty much all this animation does. In Poser.

In SL, the hips barely move, while the legs bend and the feet slide around.

I expect there to be differences. Perhaps large differences. But this isn't even close. It looks quite dumb. Perhaps SL is re-calculating around the center of mass or some such crap that I didn't ask for.

Is there a way around this?

This is a problem with the way that Second Life "optimizes" animations when you upload them.

In short, Second Life ignores movements for certain joints if Second Life doesn't think they have enough movement from frame to frame. What you are seeing is essentially Second Life skipping frames for selected joints. The hips may be moving each frame, but the legs might be moving every two or three frames.

This problem is frequently posted about in these forums. A recent one, with some ways to cope with the problem, is here:

/52/c4/261307/1.html

And you'll probably find others if you search the forum on "optimization."

Thank you, Amity. There seems to be two things happening.

First, the optimization is, indeed, killing the animation. I disabled the optimization in the code and the anim is much improved. The avatar no longer "kicks" her feet out, and the sliding in one dimension has been totally eliminated. Hey, the anim has just three stinkin' keyframes. I'm entitled to light treatment in the optimization, no?

However, the sliding in the direction the hips are traveling is still there. I think what's happening is the animation is happening around the center of mass. That is, the hips move forward some and the feet slide back some.

I'll try to solve the optimization in a more elegant fashion than disabling it, but I don't know if it's worth the effort to find the other problem. If it turns out to be a bug I understand it's an exercise in frustration getting a fix included in the official viewer.

I think both problems have to do with the Second Life optimization. I know exactly what you are describing, I've had that same problem before (and posted my own question on it here a few months ago).

When Second Life is storing the animation, it's not reading the keyframes you used in Poser; it's storing frame-by-frame information. If you haven't taken a close look at your joints frame-by-frame in Poser yet, you may want to so you can see exactly how it's going frame-by-frame. Keep in mind that if you are using the default spline interpolation in Poser, joint movement does not occur evenly over each frame between your keyframes. The movement is more sublte near the keyframes, and more exaggerated in the middle.

In fact, one of the things that might help is using more keyframes in Poser (which will reduce the interpolation curves when using spline interpolation). Though in working with this problem, I've had my best success with just using linear interpolation for the whole IK chain.

The second problem persists even when no optimization is done.

Gearsawe, the optimization clearly doesn't do what it's supposed to do (granularize the movement). I don't intend to start uploading unoptimized animations, as I don't want my animations to be larger than anyone else's. I'm trying to figure out what's wrong with animations, and maybe fix them.

It did occur to me, however, that the standard way of dealing with it (moving things for the sake of avoiding the optimization) accomplishes about the same thing as not optimizing, except that it also results in an animation you didn't want and which took longer to create. So, I'm not even sure that disabling the optimization would be any worse than what everyone else does, anyway.

I found that, as a zero-effort fix, reducing the threshold for recognized changes by a factor of ten has about the same visual effect as not optimizing at all, though it still throws out a great many movements.

Grrr. Trying to figure out exactly what threshold to use for best results I determined that I can set the threshold all the way back to where I started and still get "good" results. I'm working with the 1.18 client. So, I compared 1.18 to 1.19 and found 1.18 uploads anims just fine (problem 2 persists but problem 1 is not evident) and 1.19 screws them up (problem 1 trashes the anim).

Ugh!

I'll try in a 1.20 release but it looks like I'm going to have to start my tests all over.

Edit: More ugh! I got the version numbers wrong, and updated the post. It's 1.19 that's screwing up, and 1.18 that is okay. Haven't tried 1.20 yet.

Crap. Sorry for the alarm, but this is yet another error on my part. I did not, in fact, un-do all the optimization changes I made to 1.18. When I did, it created crap anims, too.

I dug in the code for hours and could not determine why problem 2 (feet sliding in opposite direction from hips) was happening, but it looked like the error was about 100%. Feet sliding about the same distance that the hips moved. So I decided to just scale the movement on import by a factor of 2, and...ta dah! That fixed it perfectly.

That is, the hip movement needed to be scaled up by 100%. SL assumes the units in the BVH file are inches, so I looked for confirmation. I could find no reference claiming Poser outputs units of inches. In fact, I could only find mention that Poser's units are just weird; not metric and not imperial. Apparently anyone importing Poser-generated BVH files has this problem with any application.

I don't know if all BVH files coming from Poser will have the same scaling, so I've added to my viewer the ability to scale the hip movement by any number I want, defaulting to 2.