Upload bug? Small hip movements change during upload!

I am doing some animated stand poses in Poser 4/Artist, and I seem to be running into an upload issue. The poses were all made with inverse kinematics on, to keep the feet stationary, but when I upload, any hip movement seems to drag them around. This movement does NOT show when I play the anim in Poser.

I have my reference frame as frame 1 and I have not used the whole body. Strangely - the lead-in and lead-out to the pose involve a larger hip movement, and that seems to work fine. In the pose, however, I want a subtle hip roll to keep it from being a statue - and that is causing the feet to swing in a little circle on the floor.

Any ideas about what I am doing wrong??

Thanks!!
-Jamie

You probably aren't doing anything wrong. There are two possible issues here, one which is a bug, and one which is a normal part of how the upload works. The normal thing to keep in mind is that the upload optimizes the animation data to streamline sending the animation from the server to client. Among other things, very small subtle movements are optimized out. Thus, if the legs movements are very slight, they may be removed entirely on upload. The way to test for this is make the hip move more (and thus the legs move more) and see what happens.

The bug here is a known bug involving feet. Basically, the feet always jitter some with uploaded animations, they don't hold perfectly still. This is definitely a bug and not just a side-effect of the optimizing, since I see the feet jitter in animations where the legs don't move at all, just other body parts.

It's not so much optimization that eats fine movements, it's that the format LL uses has really low precision. It cannot store small movements. It does do a little optimization so it does eat some types of small movements. So it's really a format limit then an optimization bug.

and it prolly could be the hip bug that has been going around (again) since august.

I think I'm having the same problem with an animation of mine where the hips move sideways, then back to center. works fine in poser but when uploaded the feet move more then the hips and they should be stationary. Funny thing is I messed around with the file in poser and saved it with inverse kinetics off then the preview screen seemed to display the animation right when I uploaded it, but it had the same problem when I used it.

let me know if you work out any way to avoid this problem.

Max,

Strife, can you elaborate?

I wrote a program that filters animations to make them smoother. The resulting anims look great at 15 IPS in Qavimator, but are jerky when uploaded to SL (and jerky in a perfectly reproducible manner, so it's not display lag). Some joints lose movement entirely -- ones where the original keyframe movement was relatively small.

I'd like to adjust my program to minimize the effect of this compression or optimization, and any clues about the details would be very helpful. Of course, I do know about the importance of differences between the T frame and first frame, so no need to go into that.

Thanks!

You would need a custom animation compiler and uploaded to increase precision, it would have to use V1 of the animation format instead of V2... and it would double the size of the asset. Good luck.

Strife, the problem isn't the precision for the rotations. They pack the float values into 16-bit integers where the full 16-bit rage represents 360 degrees of rotation. That's way more precision than necessary to produce very fluid and subtle movements.

The problem is entirely the joint optimization. I'm trying to understand the full reasoning behind this optimization. If it's simply to reduce the amount of data exchanged between server and client, I strongly suspect there are better ways (more data reduction with less data loss).

If it's to optimize the client, then I don't fully understand the reasoning. It simply changes the number of points (per axis per joint) on a linear interpolation. If each point caused significant additional processing, then yes reducing the number of points would speed up the client when animating lots of avatars. I have a hard time believing that it would matter. The animation engine has to linearly interpolate between two points for every display frame anyway. Why would it matter how close together (in time axis) the two points are? The extra amount of processing per point is trivial compared with the rest of the work the animation engine must be doing.

I say this as someone who's never seen the inside of an animation engine, so take it with a grain of salt, of course.

The code is here:

http://svn.secondlife.com/trac/linden/browser/release/indra/llcharacter/llbvhloader.cpp#L1081

The serializing code is the last function in the file.