fine rotations not registering in SL

[RaptonX Zorger]

I am trying to do an animation where some parts only rotate a degree or two, but in SL it either registers half of it or none of it, it is a loop. Is there a threshold that it has to reach before it even registers at all?

 

I have used both avimator and quavimator, both have this issue, maybe a way around this

Animations are around 60 frames in ellengthnd about 30 fps.

[Kwakkelde Kwak]

My experience is you need at least a 2 degree difference from the base pose. Since the rotations in that base pose are not exactly 0 degrees (to my best knowledge), I usually go with a 3 degree minimum.

[OptimoMaximo]

It all also depends by which FPS rate you use. In pretty lowframerates animations 3 degrees would work, but the higher you set the FPS the higher the minimum rotation has to be set. Anyway, the minimal rotation for each joint can vary, from my experience, between 6 degrees when at 30FPS downto 3 degrees when at 6-10 FPS. Make sure that the rotation of each joint is set on all 3 axis, because the degree's gap which is calculated during upload to drop "unnecessary"data is calculated among all 3 axis. To clear up a bit this concept, assuming that at 30FPS you need a 6 degrees rotation difference between previous and next keyframe, if you split those 6 degrees among the 3 axis (+2 on x axis, -2 on y axis and +2 on z axis for instance, but any distribution would work) you save that data from being dropped.

[Domino Marama]

You can avoid the loss of fine detail in .bvh files by using Avastar and exporting in the native SL .anim format. You'll need to be using a 3rd party viewer that supports uploading these as well.

[OptimoMaximo]

Even if there won't be data loss using your product, so fine rotations wouldn't even be noticeable, causing an unnecessary overload of data normally dropped by the uploader, reason for it was designed with a clean up in the process. Too much data would result in a decreased animation efficiency (time to download from the server to be played in the viewer, strictly related to filesize) for long animations. I'm not for unnecessary burden on SL servers to stream unnecessary data. Furhtermore, using bvh files enables animators to sell their animations on other platforms like Animeeple, where people would be able to retarget the skeleton to a character for their own purposes.

[Domino Marama]

Well obviously they are noticable otherwise we wouldn't have this thread to post in. Also avatars are a completely different animal with the advent of mesh than when the bvh handling was designed. If you were doing a couples animation of say a giant ruffling a tinies hair, a couple of degrees could be the difference between a cute animation and a broken neck.

We support bvh export as well in Avastar. We are providing tools that give artists more choice and options, The data to store a keyframe on a joint is just 8 bytes - so for something like breathing (typical fine detail) which has probably a keyframe per second - on a one minute animation with two bones affected - that's just 8 x 2 x 60 - under 1Kb difference. And that's assuming there's no other animation on those bones that would normally result in a keyframe.

So an entire AO's worth of animation is going to increase network load by less than one 512 x 512 texture used when a 256 x 256 would do.. Use one 256 x 256 image instead of a 1024 x 1024, and you've saved more than a sim's worth of avatar AOs extra keyframes. And that's assuming the worst case that each and every animation has lots of extra keyframes. In actual use, that's just not going to be the case.

So I seriously think any network load effect from supporting these small movements is negligble and providing the artist with tools that allow them to decide when such fine detail is necessary or not is essential with the wider range of possible avatars.

You should also consider why that feature on bvh imports is there in the first place - I think it's for simplifying motion capture where it's likely every bone is keyframed every frame. In that case of course removing fine detail is the correct thing to do.

With the retargetting of motion capture to the avatar in Avastar, you can do this sort of simplification of data before saving the .anim or .bvh file. And obviously hand animated files are already going to have considerably less keyframes than motion captured data.

 

[Medhue Simoni]

Hmmm, It always does perplex me when a thread like this pops up, as I've never had an issue with any fine movement. Maybe I'm just not seeing what others do. I don't think it has anything to do with the program, as I've used almost all the different programs. It could be a missed keyframe tho. It might be good for me to remind any1 that if your animation is 30 fps and you are only seeing 20 fps in the viewer, you are not going to see all the data. On a similar note, most people can only see 24 fps, so there is almost never a need to make an animation over 24 fps. Personally, I try to keep my mocaps under 15 fps, unless they need more, and my hand made animations at less than 10 fps.

Another thing to consider, is that if you leave your axis at zero, then half way thru the animation you move that axis, I don't think you are going to see any movement at all, as the 2nd frame had no data, which would tell the uploader to not animate that part. Of course, i could be wrong, as I don't have this issue at all and always move my parts off zero, if I plan on animating that part.

As far as file size. Generally, a 10 second motion capture animation at 15 fps, is going to be around 175kb. An animation only gets into the high texture size range when you are talking about 30 second motion capture dances. A pose can be as little as 10kb or less.