Wouldn't it be great if we had a lossless animation upload?

Oh boy. I've worked for nearly seven weeks on 5 new couples cuddle animations. They turned out great, but they were so hard to make. Tonight I finished the job and I'm very happy too. But especially slow movements are almost impossible to make. Yes, I've turned down the framerate and made the movements big enough to be 'seen' by the import. I also made sure that every relevant limb in frame 2 is different from frame 1 and don't have too many frames in between movements. Etcetera...

But it's still a drag.

I can understand that the sl import cannot be too precise, just like importing textures makes lower resolution images. But can't it be a little bit more? Just like sculpties seem to get their (sort of) lossless import? Would that stress the grid too much? I really wonder why animation import is so rigid and unpredictable.

I imagine it's because when you play your animation the server has to transmit it to every person who is in your area and they want it to be as small as possible. I agree that it would be great if we could do that.

Heck yeah, it's really a bummer having to compromise nice animations to make (previously) subtle motions exaggerated enough for the uploader to not just toss them out.

But like Bree suggests, it's about the bandwidth (a Linden actually stated this somewhere on the forums years ago, but I have no link and I'm too lazy to search). Sculptie images can be quite small files, but a 30 second bvh can easily run upwards of 400 KB, double that for a pair of animations for a couple. Probably more, I'm just looking at my own animations that tend to run at 20 fps. I doubt LL will do anything any time soon that increases bandwidth usage and stress on the asset server, Would be nice though.

While we're dreaming, how about a new script function llPreloadAnimation(string animation, key avatar) ?

*gazes dreamily off into space*

What are you still doing here? Off to the JIRA site with you, put in the request! And let us know here so we can vote for it.

Oh no, it would be horrible if we had a non-optimized anim upload wouldn't it? Imagine if every pose and animation took many times longer to show up? Right now, when everybody using a danceball on a dance floor just stands there until the next dance loads... Imagine how laggy things would be in crowded sims as that info is sent to all our avatars plus neighboring avatars who have their draw distance turned up? Then when packet loss causes someone just to appear sitting? If it took longer to send the anim, might that happen that many more times as often?

Worse might be what would be gained from it? Sure, we get sucked into the minutiae and details when we are creating animations, but none of that is seen on tiny avatars on the screen anyway! Okies, yes, if you zoomed in and ctrl-0'd a bunch of times so just part of that one person fills the screen, but how often is that compared to how much less efficient it would be?

Oh! And how many people in SL would see your subtle details anyway? What is the typical viewer's FPS? So what is the FPS of half of residents???

Might I offer an alternative suggestion? Perhaps create your animations more dramatically instead of so subtly? You might even find you can create better quality animations in less time and will hopefully be less frustrated later?

The memory that a 64x64 sculpted prim texture uses is much smaller than an animation with lotsa movement in lotsa frames.

(uncompressed) 64x64 texture needs (64*64)*(8*4) bit.
Its save to assume that any change in a joint needs at least 3*32 bit (float vector) for uncompressed gestures. That would be 682 joint changes in an uncompressed gestutre to be as big as an uncompressed sculpted prim.

But sculpred prims are compressed (gif-lossless), easily, a lot! And animations are harder to compress lossless, so they chose a lossy compression.

Some good points and I'm now won over by those advocating the need for efficient animations even though my requirement is for long slow movements. Now here's the thing!

The animation preview screen is rather small and I find myself thinking all is well and coughing up my 10L only to find that once in SL a vital movement is dropped. Now this could just be down to me being a noob animator and admittedly I'm getting better at it. Could the preview somehow highlight and make the user aware of the fact that a movement has been dropped thus avoiding frustration and allowing correction at the earliest opportunity.


Visit Selene Castle
http://slurl.com/secondlife/Gavello/212/10/78
http://www.slexchange.com/modules.php?name=Marketplace&MerchantID=120047
http://www.slexchange.com/modules.php?name=Marketplace&MerchantID=65377

Those few extra bits do add up...

I didn't realize at first you can zoom into the preview with the same camera control movements you use in world, so maybe zoom closely in on the parts you want to check before uploading?

You can also upload to the beta grid without spending a cent, or three cents as the case may be...

Test your anims on the Beta grid! It's not real $L, so it's free. However, make an alt or two if you're going to be doing LOTS of uploads, so they have some $L to give you in beta grid if you run out.

It seems avs get geta $ given to them periodically, because my main has more money in beta grid than my alt.

discussion is old.
answer is no.

"no" as an answer is not helpful. If you can point to the discussions that would help.

The reasons suggested above aren't quite valid. Lossless compression of animation files using Zip reduces file size by 90% to 95% on the ones I've tested.

Folks, please vote for the JIRA entry!

http://jira.secondlife.com/browse/VWR-2461
http://jira.secondlife.com/browse/VWR-2461

Thanks!

What does your BVH file size have to do with the amount of information they would have to send to the viewers? You do know that during upload the anim is converted to their own internal format? A quick search found this if you want more info:

OTOH, is optimization the same thing as compression? Off course not!

Optimization is wonderful. Wouldn't it be fabulous if textures were optimized too, so we'd never have 512x512's on tiny prims never seen big? Think how much less lag there would be!

Thanks for that link! I had been very curious about that at one time, and had never found that information.

The point of this optimization is reducing the amount of data to transmit. Therefore, in this case, the "optimization" is a "data compression technique". Why split this hair?


True, but not if it "optimized" them to the point of looking awful. In fact, textures are highly optimized, by asset ID (so they only get loaded once per texture) and image data compression. There's no solution to the problem that people load down a build with unnecessary textural complexity.

My goal is to reduce the amount of effort required to produce smooth animations. If we had more information about the optimization process, I could write a script to convert a BVH file into the SL equivalent, so we could view the effect without going ingame. And perhaps I could write a filter program that would minimize the damage done by SL's optimization.

Wouldn't it be fabulous if we could make nice smooth animations, that don't add to lag?

I'd be much happier if I didn't have to guess what optimization would do to my animation.

If nothing else, I'd like some documentation on how the optimization process works, so I can anticipate what it is going to do to my animation. I could save so many, many hours of needless work based upon revision caused by the effect of optimization that I couldn't predict.

I don't necessarily see a great value in more "realistic" animation. Second Life doesn't have realistic graphics, and I'm happy with animations being suggestive of movement rather than precise in movement.

On the other hand, when it comes dividing up my computer's limited resources among various kinds of content, I'd rather see more resources allowed to better animations than to, for example, glorious landscapes. Animations are a much more salient part of my Second Life experience than, say, watching the Second Life sunset.

When it comes to the Second Life eye candy, the things that are more a part of my experience- avatar appearance and animations- seem to lag behind those things that are low on my priority list, such as a realistic sunset. I'd rather see my computer's computation go first to avatar appearance and animation, and then what's leftover can be dedicated to the sunsets.

The more fundamental problem when it comes to how user-created content affects Second Life performance is that the methods of encouraging residents to optimize content were poorly chosen. Upload fees and simulator usage limits would be more effective, I'd guess, if tied to file size or the strain that content caused on processing speed.

Have you seen the section on optimization?

I have read that, and it's not helpful, at least when it comes to optimization.

I can appreciate the fact that the formula may be complex, but surely someone familiar with the optimization formula can provide a little bit more useful information upon what it does.

(I suspect however that technical documentation has become something of a lost art.)

Kitty Barnett posted a pointer to the code on a related thread:

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

I'll be looking it over carefully. I'll keep you posted!

I've analyzed the "optimization" code, which is basically an application-specific data reduction (i.e. compression) technique. I'm conviced that the "optimization" is *only* for the purpose of data reduction and not reducing client processing load (since it doesn't affect the number of animation frames to be calculated, it simply reduces the number of points on the linear interpolated function for each joint angle).

I'm going to tackle this. Please forum-PM me if you're willing to help. I'll want help from programmers and mathematicians, and I'll need help from animators with typical BVH files for testing.

I'll start another thread when I have more specific things to say, but basically, my plan of attack is this:

1) create a standalone program from LL source that processes BVH files so we can see the results of optimization in our animation programs.

2) find a better optimization method, which preserves the data format between client and server, uses little or no extra data to send typical animations, but preserves movements better.

Rally around if you're interested.

A standalone program to preview animations would help.

However, what would be of most value to me is if you could explain how optimization works so that I can keep it in mind when I'm planning the animation and doing my initial posing. If you can explain it in a way that someone who can't read code can understand, I would greatly appreciate it.

On a total lark, I found the optimization code this morning. I was all excited, then I found out that y'all already been talking about it. I'll be going over it as well, but will be kind of slow going for me.

Seems to be weighted not only by changes in rotation on a frame-by-frame, but changes over extended frame counts. Anyways...

Personally, I would really hate to see entire animations completely and totally un-optimized. I would much rather see un-optimization on a joint-by-joint and frame-by-frame basis. "Don't drop any changes on this joint between these frames, but go ahead an optimize the rest."

Un-optimization in moderation.

Absolutely, Abu. I'm investigating.

Basically, the problem is that the bvh format loses the "keyframe" information. SL can't tell which frames were specifically arranged by the anim maker and thus can't preserve them. Instead, it simply drops joint-frames where the amount of motion is small, and can drop several in a row, leading to problems, when the intended movement was smooth. The problems are either jerky movement (and I'm not quite sure why yet) or complete loss of certain motions. Of course, for things like motion-captures, there are no "key frames" to preserve, and it's important for this to work well in either case.

As far as I can tell, the intent of the optimization code is simply data reduction, and it's a pretty good attempt at an application-specific lossy method. What I'd consider good work for a software team with tons of things to do (as all are).

I'm hoping that with more thought and motivation, we can come up with an algorithm that meets the goals but does a better job of preserving the range of motion in an animation.

One track that I'm considering at the moment is to do a segmented linear approximation for each joint-angle separately. One problem is that the internal representation is by joint, not joint-angle. Another problem is that I'll have to figure out how to approximate an arbitrary curve as a sequence of linear segments, but I'm betting I can find some good candidates using google.

There's another thread on this forum discussing the same topic. As soon as I get some serious traction I'll post a new one discussing specific solutions, and I'll need help from people such as example animations (as bvh files) to measure the differences in file sizes between the current optimization and different trial ones.

I'll also be delighted with any math help I can get. I'm rather rusty on my math, and quaternions make my head hurt.

However, I'm kinda overbooked at the moment with RL stuff, so progress may be slow at first.

hmmm, I suspect the jerks that I see are due to not considering the movement between the last looped frame and the first looped frame. I'll have to see, in my anims where SL added jerks, if there's just one at the end of each cycle.

The optimization algorithm completely ignores looping.

Sorry to necropost, but as it turns out, the biggest animation at 30 FPS is a bit over 100K on upload. When I first read this post, I knew less about the animations are uploaded. Each joint parameter is sent as a 16-bit value, and there are 60 parameters per frame, so about 120 bytes per frame. (There's some per-frame overhead, but not much.)

So, a better "optimization" would be to simply delete every other frame for any animation over 15 or 20 FPS, and simply disallow any over 30 FPS. The max upload size would then be about 50 or 66K, and most anims would look far, far better.

Another option would be to discard all frames that are linear interpolations from neighboring frames. This would essentially discard all but the original keyframes, so it would be optimal and ideal for the way many of us make animations, in Qavimator and Poser.

IMHO, there's rarely a need to use more than 10 FPS. SL interpolates between animation frames, so they don't look jerky.