"Poping up" between animations

Hey all! I have encountered a strange new problem/phenomina and despite my best efforts I have not been able to make it go away.

I am working on a series of animations but the problem has come when I go to test them. I have put them into multiple AOs from different sources even including one I wrote. What happens is when you go from stand to walking or walking to standing, for a brief second you see the basic "T" pose. It is like the AO just stops playing any animation for a moment as the avatar exits the previous animation, goes into the T pose and then starts the next animation.

When you play the animations alone they work fine and you never see any T-pose. The problem has been consistent across several different AOs scripted by different people. I've tried numerous tricks with uploading the animations, cutting off massive %s from both ends just in an attempt to make the flicker of the T-pose go away and that has not worked. There is simply no T pose in either animation! I have no idea why this is happening or where it is coming from! Can anyone give me a clue?

Eeeps, I've seen the default poses show before the animation gets sent to the viewer, but not the T pose, except when someone is first being drawn in and still Ruthed before their shape and pose gets loaded.

Are you experiencing more packet loss than before maybe?

Wait, so this only happens with your animations? Others work fine in the AOs?

Um, the percentages only affect what is looped, they don't "cut off", or shorten an animation I believe, so the beginning all plays, then the looped part in the middle while it's looping, then finally the ending.

Which animation software are you making them in?

heyas;

make sure your ease in and ease out are both set to zero. otherwise, the animation will try to 'ease through' the default animations when switching.


also check for a recent thread about animation priorities, and my sorta addendum on mission-critical ao's. 'pop up' usually refers to tiny or quad or other massively-different-from-normal animation positions. to make a long story short, i discovered you pretty much have to make ALL those animations priority 4 to avoid pop up. ::sigh::

Ease in and out are both 0.

I use Qavimator.

There is no T pose at any point in the animation (.avm file key frames) except for the very first frame, which I cut off.

All of my other animations work fine and don't have this problem nor do animations by anyone else.

Packet loss was fine and I tried it in a number of sims just to make sure.

Wouldn't it be nicer to have a longer ease in and out, so you don't unnaturally suddenly appear in a new position like magic, but smoothly transition from the previous animation? I find the default ease amounts far too short, and have never set anything to zero. One of the silliest things I see in SL is animations, like dances, with no ease!



How did you "cut off" the first frame? (QAvimator can only save from the 1st frame on, are you saving a .bvh and doing something else with it before uploading to SL?)

In your .avm file, do you definitely have keys on the second frame for every body part that has a key later on?

What is the FPS of your animation? Is it particularly low? http://jira.secondlife.com/browse/VWR-3783

Yup. I cut out the ease in just to see what would happen as I have tried to upload it with several different settings. I have tried no ease and long ease. You can cut down where the animation starts and stops at by setting the start and end%.

In the second frame of the animation I have moved/made keys of everything that will be animated and then start the animation in the 3rd frame.

This not the first animation I have ever made and uploaded, not by several hundred. It is the first one I have ever seen with this problem. When I put it into an AO and the animations change, it's like SL does not know what to do or what animations to load, not even the standard SL animations which sometimes bleed through AOs in very laggy areas. Even when I tinkered and set the 1st, 2nd and 3rd frames all identical and completely eliminated the T pose from the animations, it still showed up. And yes I am on the current viewer and yes I have tried other viewers as well.

heyas;

crystal: easy in/out may be good for 'normal' animations, but are not used for other animations. a tiny easing from a tiny stand to a normal stand to a tiny sit is NOT good. although, truth be told, i never tried easing with this type of animations, since the nci class i took told me this zero easing information. i learned a lot from that class.


shard: okay, you need a frame one for your bvh file. normally, it is the default t-pose, but it doesnt have to be. what does have to happen is that whatever you want to move has to be in a different position in frame 2 than it is in frame 1.

so, for example, if you wanted to make a t-pose... your frame 2 would be the default t, and frame 1 would have to be something with each limb not in its default position. you see what i mean?
whatever changes from frame 1 is animated. whatever doesnt change is not.

note that the hip is one exception to this. no matter where you stick the hip or how you rotate it in frame one, the hip will consider that to be its zero-rotation starting point.


the t-pose, btw, is what avatars are standing in when no animations are running. i would suspect your tinkering with trying to remove start frames is somehow getting sl to think there's no animation running. or something.

Okies, I hope I don't offend anyone, but there is a lot of wrong info here I'm afraid... Hopefully we can clear it up?



Eeeps! No, I'm afraid that is not the case. If you mean the Loop start % and the loop end %, those don't "cut down" the animation at all!

Those specify the portion of the animation that should loop. Animations will start playing from the beginning (frame 2 of the BVH) and play up to the time of the loop end percentage, then jump to the time given by the loop start percentage, and keep doing that until stopped, when they will play from wherever it is all the way to the end of the animation.



That might be your problem? And other animations might not have revealed it as much? Try moving your keys from the 3rd frame to your 2nd frame?

The first frame T pose is used as reference, but not displayed by SL. Your animation starts on the 2nd frame. (Is your FPS better now than it used to be? Maybe you just never saw the glitch before?)

Here is a simple example that will demonstrate both these things...

Open QAvimator with no animation and turn off joint limits for the moment. Change the number of frames to 41 and set the FPS to 15. Select the right shoulder and on frame 2, change it's Y rotation to 5 (so it's 0, 5 and 0). Now go to frame 40 and make a key there as well. On frame 11, make Y -180 and Z 75. On frame 31 make the Y +180 and the Z 75.

If you preview that in SL with loop start set to 25% and loop end set to 75% you will see it plays from the beginning to 31, loops 31-11, then when you click stop plays past 31 to the end!



This is a bit off topic, but pertains to the theme I guess...

I'm sorry you learned misinformation from that class? Although why would you want to go from a tiny stand to a normal stand? Or a normal stand to a tiny sit? Why play a normal stand in there at all???

My tiny animations ease wonderfully from one to another. I've never understood why so many animations didn't take advantage of this wonderful feature, maybe that is why?

Obviously your tiny torso has to match from animation to animation. If you are playing a lot of animations (dances come to mind?) from other places, that you don't know how they were made, it might look better to not ease out to them though, since you don't know if they folded the body front or back?

Tiny anims have special considerations, but just because they have fewer moving limbs doesn't mean they can't look better or more natural!

The only time I've seen easing not work well, was with an animation of arms behind the head, think of a girl doing her ponytail, or a guy with his hands clasped behind his head? From some poses when her arm is back too much, the arm would move backward (looking unnaturally broken) instead of coming front to reach up behind the head. That would be easily fixed by starting the animation with the arms in front of the body, to ease to that, and setting the loop start percentage after.

Well I still have not solved the issue yet. Time permitting I have been playing with some of my older animations and creating a new one trying to see if I can't re-create this problem intentionally.

Bloodsong- Along the lines of what you are saying, last night I had I tried tinkering with an AO to make sure that the animation was playing over the default walk and not that it had stopped all animations.

For those of you don't quite follow that, when you wear an AO it plays your walk animation (at priority lvl 3+) over the default SL walk (at priority lvl 2). What this means is when your AO lags out or glitches or whatever, you drop back into the newbie shuffle. If the AO had stopped the SL walking animation the when the AO failed to load the walking animation you would slide along in the unanimated T-pose.

Now on the topic of easing, you need to have an appropriate length of ease in and out relative to your animation keeping in mind what other type of animations it will be used with. A good example could be a sprinting animation. Your stand pose is the runner in a crouch, ready to leap forward. This transitions into a walk (or run) when you start moving. A long intro delay will have your sprinter slowly stepping off the block while a very short intro will have them explode into action.

//rant

I understand all about the frame one and moving things and I'm getting a bit tired of hearing about it. Every time I bring up the topic of having an animation issue it is the first thing everyone wants to go over. Alas, I simply don't have any friends in-world with more animation experience than I, so I am usually the go-to person. (insert metaphorical reference) So it really frustrates me when I ask a question and people respond like "well let's start with Beginning Intro to Animations 101" when I am like working in Advanced Animations 406. <sighs exasperatedly>

//end rant

Well, when you say you are starting your animation on the "3rd frame" (not likely a typo as 2rd makes no sense and it wasn't "3nd frame" and having a T-pose show up...

Or claiming to "cut off" parts of an animation, when there is no feature that does that... Or expecting a setting to do something entirely different from what it actually does...

Meanwhile you claim to have eliminated the AO as the problem, as your animation behaves the same in others, and other animations play fine in the AOs.

I am sorry you are frustrated, but we both use the same software and I have yet to have a T pose appear!

Cyrstal, thanks for the help but it seams I may need to clarify something about the animation's current state.

Frame #1: A completely protected frame and by default, a Key Frame
Frame #2: A Key Frame in which I move every joint that will be moved during the course of the animation. This frames looks like a person wadded up into a ball, and is not a T frame.
Frame #3: A Key Frame and the actual first frame in which I start the motion I am trying to animate.

Since I have managed to test and rule out the various AOs I have been using I was wondering if perhaps SL was actually animating the first frame. So I bent the avatar every which way in the first frame and... T pose! Sure enough as soon I tried it again, there it was. No T pose in any animation being run by the testing AO (which is only two animations, a walk and a stand) and with the default SL walk is playing underneath. Tried playing it in different Sims and using different viewers too.

I met with Shard in world, and she showed me the issue. It is very odd. On the one hand she has these animations she had uploaded previously to SL, many months before, and they work fine. Now, on uploading the exact same, unmodified, BVH, the new resulting Animation has the issue she describes. She gave me the AO to try, and It had the same issue for me. I tried moving the animations into my own AO (A ZHAO), and it still happend. So it is something to do with the animations themselves. I don't know that she is using the correct terminology for what is happening though. I don't see a T-Pose, but rather the Avatar is not transitioning between animation changes smoothly, for a second between going from stand to walk, or walk to stand, the Avatar jumps into the default stand. Because the animation is a Crawl (think Neko), the jump to default stand is very pronounced. The fact that the very same BVHs worked without issue in months past is puzzling. But there definitely seems to be something odd going on.

*rubs her eyes*

You make tiny poses?

/me giggles as Wilde rubs here eyes, will the wonders never cease?

Actually, I need to do a tiny walk and finish that AV, it's sitting there in a tiny corner of my inventory for months.

Coolies Darien, so I just spent far too long on the beta grid after downloading that viewer, LOL So we are still thinking it's something with those animations then, but during upload maybe?

I uploaded five animations of my regular "natural stands" AO poses that have been sold and used in world for months now (and by me for over a year), actually, the StandCross BVH was 11/06 now that I look at it, the other was last August. They were made in different QAvi versions too.

I uploaded two at priority 2 with 1 second ease in and out. I uploaded the same ones with no ease in or out. I uploaded one at priority 3 with no ease also, to replace the walk.

Although I have a copy of the ZHAO, I have never used it (have enough hud clutter and never need to see my AO for anything anyway) and since Ziggy just added a hud to the FRanimation script and Shard had problems in any AO, I figured the franimation would be an OK test?

First I just let the new uploaded stands run, and they happily eased or suddenly jumped from one to another without ever showing the default stand. 'kay, now how about walking to stand and stand to walking?

From just standing, holding the forward cursor key, usually there was no change (I had the same animation, with no ease, in both parts of the AO so I could easily see, name different or the ao doesn't stop/start the other copy) visible in the AV unless the AO didn't catch the walk and I walked in the default walk, BUT, the default stand never showed up.

When stopping walking, no matter what, the pose appeared flawlessly (either from the default walk or the overriden animation, the default stand never was played for me).

However! Fairly consistently, when walking backward toward the camera, upon releasing the down cursor key, when the "walk_adjust" plays, I saw that between my animations. But that seems obscure and walking backwards wasn't mentioned in any of this thread...

And then my laptop battery suddenly ran out, shut off and I had to restart everything, LOL

I checked turns too, both standing in place and walking, but except for when the AO didn't catch the change (which is why with my Naga tail, the pose for a bridal bouquet and things like that, I don't use a regular AO at all, but an entirely different script) everything looked like what I would expect.

Shard, would you be willing to share the .avm and .bvh files so maybe I could try uploading them too, or seeing in QAvi?

Although it may be something more sinister, I've found that a lot of AOs (all?) suffer from this - and the laggier it is, the worse it'll look. A slight SL hiccup and the default animation will play before yours has chance to kick in.

You don't notice it much with 'human' AOs, because they're already standing and the 'pop' back to default isn't much different from what you're expecting to see. Quadruped anims, crawls etc make it more obvious because of the visual difference between your pose and the default.

I bought a scripted treadmill over the weekend (to motivate me in my RL exercise regimen) and it appears to exhibit the problem described here any time you switch between the various animations. I mention it, because it's my understanding this was a newly-released product. Could something be up with the animation uploader, and folks just haven't noticed it yet because it only affects newly-uploaded anims?

That is the feeling I'm starting to get. As Erin correctly pointed out, it's not very noticable with human upright animations, but was painfully obvious with Shard's Crawling animation. I myself don't have any test case animations to try, having been previously uploaded some time ago and able to re-upload now. It would be helpful if anyone has such a test case for comparison between 'then' and 'now' to give it a try and see if they see a difference in how the animations behave.

See my post above? (From November 2006 to now, different versions of QAvi and SL...)

So actually Shard did send me a couple .avm files, which I played with in all sorts of varieties on the beta grid a couple days ago, then an hour or two ago she sent me two of her "older" animations that supposedly didn't show problems.

Unfortunately, they did for me.

I just sent anims of hers, that I uploaded from her .avm's, to her in world, we'll see what she sees tomorrow? (Sorry Shard, not to talk about you in the 3rd person! ;P )

So far it doesn't seem anything has actually changed, AOs have always not kept up with changes and glitched, which is far worse in laggy areas or with packet loss or my slower connection (which is why my Naga AV doesn't use a traditional AO, but entirely different script, but I've seen it glitch too, just less).

Wilde, it sounds to me like your treadmill is scripted to stop the previous animation before playing the new one, which is sad. Wouldn't it be nicer if it worked the other way around? Especially if it eased? Of course lag, or not having the anim in your cache makes a big difference too.

(You often see that at clubs when everyone is dancing from one ball and suddenly they all are just standing there doing nothing, although they see themselves dancing, you won't until that anim arrives to your viewer, then next rotation will be fine since your viewer already knows about it.)

One issue that came up again here, is the same as in the AO priority thread, the SL walk is BOTH priority 3 and 0, despite what is listed via Animation Info and other sources. The pelvis and legs are 3, while everything else is 0...