Poser BVH oddity

I've recently made the switch from QAvimator to Poser 7, and I'm highly impressed with it. Nothing against QAvimator, but using Poser's like getting off my bike into the driving seat of a luxury car. However, after doing a few poses and animations for SL I've run into a problem that's got me very baffled.

I was working on a back-rub animation which involved quite fine-tuned movements of the right arm, and all was going well. Having finally got the arm right, I began working on other body parts, adding small amounts of head and leg movement to bring the animation to life.

Suddenly, the arm movements began looking strange when exported to BVH and imported into SL, despite looking fine in Poser. The upper arm, which would normally go to positions A-B-A-B-A, suddenly stopped doing the last B, so it was A-B-A-A-A. The other joints carried on the second A-B-A of the loop, but the upper arm stayed where it was.

The movement isn't just affected by in-world events such as other animations - it can be seen in the upload preview too. Yet loading the BVH into QAvimator, it looks fine in there too.

I checked and double-checked everything - made sure that all interpolation was linear, the exact XYZ angles of each joint at each stage (only one axis changes for each arm joint), that every joint was changed in frame 1-2, etc, and gradually removed all the additional movements until I was back with just the arm movements. Yet the problem persists.

I know I could start again, and rebuild the loop from scratch, adding in the angles numerically to recreate the thing precisely, but I'm concerned that I don't understand what went wrong, and worried it might happen again.

I've checked it with the SL viewer and with Hippo, in both Second Life and OpenSim/OSGrid, and it's faulty with all.

Does this sound familiar to anyone? Any idea what maybe causing this glitch?

If anyone would like a copy of the PZ3 file to check it, please let me know and I'll gladly send it along.

Many TIA

Sounds like frames are being dropped due to quantization. If variations in movement are too small, they get dropped. Compression to save on bandwidth.

Some where in the SL source code there is the weighting algorithm for which frames get sent. That is, the BVH is re-keyframed based on several things like last keyframe, position in the hierarchy, and rotation delta. Stuff like that. I've glanced it over, but I haven't really torn it apart.

That's what it sounds like to me, but could very well be something else.

Unfortunately small movements can get optimised out as Abu says. To try and avoid this make your animations at 15 fps or less - the default Poser value of 30 fps is not necessary for SL. Sometimes you may need to exaggerate small movements to get the result you want in SL - a difference of 3-4 degrees may not be noticed, but 6-7 degrees will.

Thanks to both of you. I didn't realise you could use a lower FPS, which is worth knowing.

I wouldn't have thought that the movements were small enough to be ignored, but then again I don't have any better theories! The joint with the problem moves 8 deg then 15 deg between keyframes on the should-be-moving axis, then reverses it.

Anyway, I'll save the keyframe positions and put together a new anim at 15FPS, and see how that goes. Many thanks again for the pointers - if nothing else, I'm learning!