Jump between each animation

[Chaz Longstaff]

On some sets of sequenced anims that I see from certain animators, the first time through the set I see hops / jumps between each animation. The second time through, I don't see the jumps, I guess it's cached. But anyone who doesn't go through the cycle a second time (as in most users who won't have any reason to hang around and run it twice) will leave with the experience of the hops. Does anyone else experience this on their screen? I'm using Firestorm v 4.4 maybe it's a Firestorm thing.... Several other people confirm seeing the hopping as well btw.

[Sassy Romano]

You're correct in your assumption that it is because it is cached. Not much that can be done about it.

[Chaz Longstaff]

I'm curious, why does it happen in the first place?

[Sassy Romano]

Because just like every other asset, they have to be downloaded before being rendered. The more data the animation has in the file, the longer it will take.

 

This is the same effect you see when a particle spammer starts, you will see particle grey squares before the texture for the particle is downloaded. Textures can be pre cached via various methods, animations not so easy.

[Chaz Longstaff]

Thanks for your answer, much appredicated. I understand the caching. I should maybe have been more direct in my question, because that doesn't really explain what I'm seeing. I'm seeing it *only with certain animations*, and *not with others*. And I handle hundreds upon hundreds upon hundreds of animations a year.

The jumping is starting to appear recently (this year) with animations from some animators who have (a) never had that issue before in their animations in 7 years of licencing from them; and (b) in animations that they are producing meant to be used in sequences. It's not appearing with animations meant to be used in sequences from most other animators.

Thanks Sassy!

 

[Sassy Romano]

---

Chaz Longstaff wrote:

Thanks for your answer, much appredicated. I understand the caching. I should maybe have been more direct in my question, because that doesn't really explain what I'm seeing. I'm seeing it *only with certain animations*, and *not with others*. And I handle hundreds upon hundreds upon hundreds of animations a year.

 

 

---

I did answer it here "The more data the animation has in the file, the longer it will take."

If someone uploads a full 60 second animation with lots of BVH data, that can be quite a large file (relatively speaking) and will take longer depending on the other load in the region at the time, when compared with an animation that has been optimised, less keyframes and subsequent smaller file size.

The only way that I know to pre-cache animations is to try to load them all and mush around with timings and/or priorities but there just aren't enough priorities to work with for multi-segment animations and fiddling with timings and priorities would require a script to have knowledge of this need.  It's not going to work well for say couples dance balls that just have them in a list.

No solution really.

[Chaz Longstaff]

Thanks Sassy,

That was the kind of more detailed information I'm looking for: "full 60 second animation with lots of BVH data". That might explain why the issue is only occuring with animations from a few animators, and not the rest. I spend about L$ 500,000 linden a year licencing animations so needed to understand the issue more in depth. I remember now some animators polling in the year whether to do 60 second ones or not. The jumping results in user complaints. I can and do explain the technical cache thing to them, they listen patiently, and then reply, "but it jumps."

Those same animators (the ones with whom the issue is demonstrating itself) -- are recommending using AVSitter now instead of MLP "to avoid jumps." Do you have any sense of how using AVsitter would help? Or does it require custom scripting (I'm a scripter) to introduce precise starts and stops for these larger 60 second animations?

Thanks for your taking the time to help me understand this issue; I really appreciate it.

[Medhue Simoni]

I'll try to tackle the issues you are seeing. In the last year, or so, the total length of animations was extented, which can result in more data. We have also had a big change in what is rendered when, meaning the cache system has gotten an upgrade. This could have something to do with what you are seeing. You may also want to check your cache size. If your cache is very small, then it will drop animations that you have already seen, causing you to have to redownload them. You might want to check your environment also. If your environment is vastly different, which causes you to hold more in your cache, then you'll be dropping animations also. Keep in mind that if you buy a game, it likely holds around 6 gigs of data, or more. If you compare this with SL, your cache really needs to be over 3 gigs to not cause a problem with constantly reuploading things.

[Chaz Longstaff]

Thanks Medhue, that sounds like quite a lot to explain to customers though, they aren't always very technical are they?

[Medhue Simoni]

Well, pretty much everything I mentioned can be fixed by a larger cache. So, you could just ask them to check it and raise it, if necessary.

[Sassy Romano]

---

Chaz Longstaff wrote:Or does it require custom scripting (I'm a scripter) to introduce precise starts and stops for these larger 60 second animations?

---

Ah well if the scripting is within your scope, you might be able to solve this.  If you start animations of the same priority, each will override the previous one so in order to stand any chance of caching them, if you have say 4 animations that would normally run in sequence 1, 2, 3, 4 then you could try

llStartAnimation(4); llStartAnimation(3); llStartAnimation(2); llStartAnimation(1)

I haven't tried this though and don't know if it will be obvious at the start?  Certainly sync *might* be off if it's a couples animation. 

This method will leave you with animation 1 running first and then you'd probably have to play around with stopping and starting the others appropriately. 

It's not elegant, I did say it's not easy to solve in a tidy way. :matte-motes-dont-cry:

[Sassy Romano]

---

Medhue Simoni wrote:

Well, pretty much everything I mentioned can be fixed by a larger cache. So, you could just ask them to check it and raise it, if necessary.

---

It doesn't matter what size the cache is, the first run through the animations will still be an issue since they're not downloaded to cache at that point.  The cache would have to be in the order of a few KB for recently downloaded animations to be purged due to insufficient cache size.

[Chaz Longstaff]

Thank you Sassy and Medhue, I really appreciate you both taking the time to help me understand this important issue.

I'll ask the animators in question why they thought AVSitter would avoid the jumping.

 

Cheers and thanks again, much appreciated.

[Incoherendt Randt]

One trick is start with a filler animation with the joints forced to priority 6, then trigger and stop the rest of the animations running at a lower priority while that is running. That hides the preloading and makes it look like you know magic.

 

[Medhue Simoni]

---

Sassy Romano wrote:

---

Medhue Simoni wrote:

Well, pretty much everything I mentioned can be fixed by a larger cache. So, you could just ask them to check it and raise it, if necessary.

---

It doesn't matter what size the cache is, the first run through the animations will still be an issue since they're not downloaded to cache at that point.  The cache would have to be in the order of a few KB for recently downloaded animations to be purged due to insufficient cache size.

---

That's not what I was arguing. There is no easy way to avoid the first jump, but he was saying that he was seeing the jumps after the animation was originally played. That likely means that the animation was dropped from the cache.

If your cache is small, animations will generally be the first thing that gets deleted from the cache. This is because the objects and textures take up much more space, and there can be many more of them. Heck, I've seen single avatars that use up a gig. Plus, the objects are being seen, while the animations are waiting to be seen.

If Chaz is talking about dancing animations, this is even more likely what is happening. Dance animations are played in clubs. Any decently popular club in SL is easily going to have 20 avatars in it. Just the hair alone is going to use up a gig or more of cache space. When you add in 60 second dance animations that are 30 fps, you are talking quite a bit of data. This is because you can't really optimize dance animations. The movements are so fast, you need, at least, 25fps, and they will likely need keyframes on almost every frame. I don't generally do dance animations, but I have made some. Fight anims also need a very high fps, and walks, but pretty much everything else can get away with less than 10 fps and keyframes well optimized.

[Cerise Sorbet]

That's not how the cache works. Animations go into a part of the cache called VFS, which contains most assets that aren't textures or sounds. VFS is strictly first in, first out.

Ugh fixed a typo that wasn't there.

 

 

 

[Medhue Simoni]

---

Cerise Sorbet wrote:

That's not how the cache works. Animations go into a part of the cache called VFS, which contains most assets that aren't textures or sounds. VFS is strictly first in, first out.

 

Ugh fixed a typo that wasn't there.

 

 

 

---

That's news to me, but it still doesn't invalidate what I said. If VFS holds meshes, it could easily get filled quickly. First in and first out, doesn't mean much when you are seeing all the meshes and the animations are sequenced.

[Cerise Sorbet]

VFS doesn't age out all that fast, even with the default cache size. If there are persistent skips within a single login, something else is wrong.

Even the largest animation assets with the new updated limits are only 120K apiece. Mesh assets in LL's format are generally not all that large either. It's a mystery why anyone is talking about BVH, that's only a viewer input format that is never uploaded to the grid.

[Medhue Simoni]

---

Cerise Sorbet wrote:

VFS doesn't age out all that fast, even with the default cache size. If there are persistent skips within a single login, something else is wrong.

Even the largest animation assets with the new updated limits are only 120K apiece. Mesh assets in LL's format are generally not all that large either. It's a mystery why anyone is talking about BVH, that's only a viewer input format that is never uploaded to the grid.

---

Well, without more info, this is all speculation. The data size for any 1 thing, is somewhat irrelevant, when you are talking thousands of items. You can't know the amount of things, so saying it can't be this because animation files are small, or mesh data is small, is assuming quite a bit.

Probably the first relevent question should be, do the animations play without the problem jumps for him in an area where there are few objects around him?

[Cerise Sorbet]

There is an actual bug with animations where avatars can jump around between animations, and I'm absolutely positive it's not a matter of having a big enough cache.

AVSitter is definitely not a cure, in fact I've seen it most often on furniture that uses it.

The root positioning information gets lost somewhere, while the rest of the animation seems to play normally. It seems to trigger more often if public chat or other actions that trigger built-in anmations are in use.

Several months ago I saw it happen in any viewer, lately I've only noticed it happen when stuck on Firestorm.

 

[Medhue Simoni]

---

Cerise Sorbet wrote:

There is an actual bug with animations where avatars can jump around between animations, and I'm absolutely positive it's not a matter of having a big enough cache.

AVSitter is definitely not a cure, in fact I've seen it most often on furniture that uses it.

The root positioning information gets lost somewhere, while the rest of the animation seems to play normally. It seems to trigger more often if public chat or other actions that trigger built-in anmations are in use.

Several months ago I saw it happen in any viewer, lately I've only noticed it happen when stuck on Firestorm.

 

---

Yes, there is a bug that will triplicate the first frame. This bug has been around for years and years now. I've probably been the largest complainer about this bug, as it shows itself more with animations that put the avatar closer to the ground. When you upload an animation, you have to adjust the in% to make the animation loop perfectly with this bug. This bug is not generally visible with animations that have the avatar standing. Here is the bug. It could very well be the bug that messes up AVSitter tho.

Just a few months ago, I attempted to get a bug fixed with a built in animation. The walk_adjust animation's priorities are too high. Because I didn't know exactly what the problem was, as I only saw it with my turn animations, the jira was closed by LL, before I figured out what the culprit was. Notice how I had to be the 1 to figure it all out, and LL was not interested in actually fixing the bug, only that my initial observation was wrong. My AO uses rotation to know when to turn. This results in a much faster response than overriding the default turn animation. The problem is, that the walk_adjust will only turn off when you replace the default turn animations. Because turns work right when the default is overriden, LL closed the jira. I'd have to create another jira and fight with LL again if I want the walk_adjust priorities fixed, but I give up with LL, and will just override the animation with an anim file. This bug will only present itself when the avatar moves tho, and has nothing at all to do with this topic. Here is that bug jira.

I have seen bugs related to typing overides when you are sitting. Again tho, this is not what Chaz is describing.

[Chaz Longstaff]

First noticed the issue with some sequences from some animators in the spring. Filed them away for the summer break from work. In meantime have cleared cache, changed SL browsers, etc. Now back to work. The jumps are occuring still with the sequence sets in question; and, are now noticeable in newly-licenced (this fall) sets from one or two other animators.

Have tested in several sims, with several AV's and got other people to watch and explain what they say on their computers in other computers. The jumps occur even in areas where there are few objects around.

The hopping and jumping only ceases after you have gone through the set of animations once. They will stay smooth, until you clear your cache, then you see them jump and hop again until you have gone through them again.

Will they "age" out of the cache? That I have failed to notice, as in, having paid attention to that if it happens -- am just getting back into the fall groove of work.

Thanks for your help all, I think I have a better understanding -- that it's the 60 second animations, if I'm understanding that correctly.