Drifting in animations

Hi,

I have just started doing animations and I have observed some rather annoying things with SL animations.

One of them is that it is quite difficult to do any animations in which there is none or very little movement within an extended amount of frames such as for example in sitting animations where you want the motion to look very smooth. I have been doing some experiments and here is what I gathered so far:

Using Poser 6
At 15 FPS
It seems that I need, at least for arms, about 5 degree motion in about 20 frames in order to get any visible effect and not break the animation when imported into SL

It seems to me that this is a problem of scaling, floating point approximation, or a combination of the two. As for scaling, it could be that applying a multiplier to the coordinates when exporting, brings the values to or very close to zero. If you have lesser floating point precision, which I believe is the case of SL, those numbers close to zero become zero.

That is not really the worst problem. I can live with the precision problems and as a matter of fact I just want to be able to have the character stay static. The real problem comes from a resident drifting that happens when the parts of the body are not moving. It drives me insane when I am trying to make the animation loop and not have a jerky movement every time it loops.

I have been trying to remove the drifting by applying a small motion. But when you have to move 5 degrees every 20 frames in order to get SL to accept the change in motion, it makes the task of pretending to be static rather impossible.

Has anybody come up with a work around to this? Has SL been looking into the issue? From a programming perspective, this seems to be a real simple problem to fix.

Thanks in advance.

Troy

The first part is because of Optimization, not scaling.

8. Optimization
SL's BVH importer does optimization of animation data prior to upload into SL. Joint rotations with very slight changes from keyframe to keyframe will be interpreted as *not* changing and thus aren't stored. This is done intentionally since custom animation data is stored on our servers and downloaded to each viewer as it is needed in real time, and needs to be fairly terse.
The potential side effect of the optomization is what you have observed; joints with very subtle movement might have their animation data dropped entirely on upload. The threshold formula is complex(at least to my non-programmer eyes) and involves comparing all three axes of data per joint, the distance moved between keyframes, as well as the joint's position in the skeletal hierachy. The design is *supposed* to allow for subtle motion to come through intact, so there may be a couple bugs.---by Xenon Linden

As for your second one, well.. I haven't come across drifting, but I think the same work around that I use for the optimization would work. I like to make my sitting animations far more subtle then optimization would allow. So I had a script written that does a transition for the different animations based on a time that I set. Then I number them the way that I want in the contents so they run in order..

Example: (30 seconds timed)
30 second Anim ->
standard looped 2 frame pose that is the same as the last frame of previous anim ->
30 second Anim (2nd frame same as the pose) ->
Standard looped pose (2nd frame same as the last frame of previous) ->
ect.. ect..

More uploads and I have to time things right, but it's worked thus far. This also helps me escape the message that my anim is too long

The only other drifting I can think of is the bug we had until recently that made uploads wonky. As far as I can tell with mine and other people I have talked to, it was fixed in the last patch.