[#VWR-3783] First frame of uploaded animations is triplicated

1. Second Life Viewer - VWR

First frame of uploaded animations is triplicated

Created: 10/Dec/07 07:04 PM Updated: Monday 02:33 PM

Component/s:

Avatar/Character

Affects Version/s:

1.18.5.3

Fix Version/s:

None

File Attachments:

2-frame-anim.bvh (4 kB)
2.

arm flap 17-frame 1fps.avm (12 kB)
3.

arm flap 17-frame 1fps.bvh (12 kB)
4.

female_poser_walk_8fps.bvh (8 kB)
5.

tick_tock.bvh (5 kB)

Image Attachments:

1. animation_loop.png
(20 kB)

Issue Links:

Duplicate

This issue is original of duplicate:

~~VWR-12879~~ The Animation Uploader is not viewing and uploading animations correctly. Seems to be adding a frame at the beginning or end.

Relates

This issue is related to by:

VWR-1909 Animation Upload - Looping IN and OUT values not correct

MISC-2325 Meta Issue: Character Animations

Linden Lab Issue ID:

DEV-15185

Description

« Hide

Repro to show the first frame is there 3 times:

-Upload the attached animation "2-frame-anim", not looped, with ease-in = 0, and ease-out = 0. The BVH is set at 1 frame per second.
-Play the animation.

Observe: The animation lasts 3 seconds. The first 2 seconds it is stuck in frame 1. The third second you see the actual movement from frame 1 to frame 2.
So it plays like this: 1 - 1 - 1 - 2

Expected: the animation should last 1 second, playing like this: 1 - 2

=======

Repro to show there is no interpolation between end- and start-frame when looping:

-Upload the same animation, but now looped, with In(%) = 0 and Out(%) = 100
-Play the animation.

Observe: After frame 2 is reached, the animation suddenly jumps back to frame 1, there is no smooth movement between frame 2 and frame 1.
The animation plays like this: 1 - 1 - 1 - 2/1 - 1 - 1 - 2/1 - 1 - 1 - 2/1 - ...

Most people would expect the animation to loop like this: 1 - 2 - 1 - 2 - 1 - ...

=======

Partial workaround to correct looped animations:

Suppose you want the above animation played like this: 1 - 2 - 1 - 2 - 1 ...

-In your animation program, copy the first frame, and paste it after the last frame.
-Upload the animation with In(%) = 200 / (n + 2)

Where n is the number of frames of your original animation (n = 2 in this example, that gives In(%) = 50%)
The start of a loop, or non-looped animations can't be fixed using this workaround.

=======

When uploading an animation, the first frame of animation is played for 2 frames. (When I say "first frame of animation", I'm referring to the second motion entry in the file; the first entry is usually considered to be a reference, against which the other frames are compared, and isn't supposed to be played.)

This bug has been around for a long time; it's visible to a keen eye in animations dating back over a year, perhaps even longer. But since animations are often a few hundred frames at 30 frames per second, this bug usually only manifests itself as a very brief pause as the animation loops.

In animations at low framerates, the effect is more noticeable. I've created a sample animation that's plays at 1 frame per second to help repro this issue. The animation has 4 frames of animation, not including the reference position. Frames 1 and 4 have the left arm in the down position. Frames 2 and 3 have the arm in the up position. So, played in a loop, the arm should spend an equal amount of time in either position. But with the bug, it spends one second longer in the down position. (I've attached an image to help make sense of this.)

Repro:
1. Upload the attached animation for uploading (tick_tock.bvh) with Priority 4, Looping, and 0 ease-in and ease-out. (If you don't want to spend the L$10, you can just watch it in the animation preview.)
2. Play the animation.
= Observed: The avatar's arm spends more time fully down than it spends fully up.

Expected The avatar's arm should spend the same amount of time in the down position as in the up position.

Description

Repro to show the first frame is there 3 times: -Upload the attached animation "2-frame-anim", not looped, with ease-in = 0, and ease-out = 0. The BVH is set at 1 frame per second. -Play the animation. Observe: The animation lasts 3 seconds. The first 2 seconds it is stuck in frame 1. The third second you see the actual movement from frame 1 to frame 2. So it plays like this: 1 - 1 - 1 - 2 Expected: the animation should last 1 second, playing like this: 1 - 2 ======= Repro to show there is no interpolation between end- and start-frame when looping: -Upload the same animation, but now looped, with In(%) = 0 and Out(%) = 100 -Play the animation. Observe: After frame 2 is reached, the animation suddenly jumps back to frame 1, there is no smooth movement between frame 2 and frame 1. The animation plays like this: 1 - 1 - 1 - 2/1 - 1 - 1 - 2/1 - 1 - 1 - 2/1 - ... Most people would expect the animation to loop like this: 1 - 2 - 1 - 2 - 1 - ... ======= Partial workaround to correct looped animations: Suppose you want the above animation played like this: 1 - 2 - 1 - 2 - 1 ... -In your animation program, copy the first frame, and paste it after the last frame. -Upload the animation with In(%) = 200 / (n + 2) Where n is the number of frames of your original animation (n = 2 in this example, that gives In(%) = 50%) The start of a loop, or non-looped animations can't be fixed using this workaround. ======= When uploading an animation, the first frame of animation is played for 2 frames. (When I say "first frame of animation", I'm referring to the second motion entry in the file; the first entry is usually considered to be a reference, against which the other frames are compared, and isn't supposed to be played.) This bug has been around for a long time; it's visible to a keen eye in animations dating back over a year, perhaps even longer. But since animations are often a few hundred frames at 30 frames per second, this bug usually only manifests itself as a very brief pause as the animation loops. In animations at low framerates, the effect is more noticeable. I've created a sample animation that's plays at 1 frame per second to help repro this issue. The animation has 4 frames of animation, not including the reference position. Frames 1 and 4 have the left arm in the down position. Frames 2 and 3 have the arm in the up position. So, played in a loop, the arm should spend an equal amount of time in either position. But with the bug, it spends one second longer in the down position. (I've attached an image to help make sense of this.) Repro: 1. Upload the attached animation for uploading (tick_tock.bvh) with Priority 4, Looping, and 0 ease-in and ease-out. (If you don't want to spend the L$10, you can just watch it in the animation preview.) 2. Play the animation. = Observed: The avatar's arm spends more time fully down than it spends fully up.

Expected The avatar's arm should spend the same amount of time in the down position as in the up position.

Show »

All

Comments

Change History

Sort Order:

[ Permlink | « Hide ]

Lex Neva added a comment - 12/Dec/07 09:50 AM

Now that I read your succinct description of this problem, I know I've seen it before. I think it also throws off calculations of percentages for loop in/out values.

[ Permlink | « Hide ]

dave bellman added a comment - 23/Jul/08 01:50 AM

To demonstrate this bug I have produced a short movie clip showing how it makes it impossible to make a low fps walk animation loop smoothly - this bug actually forces animators to use the highest fps possible to reduce it's effect! For these reasons I believe the bug's priority should be increased from 'Normal'.

The movie is available here: http://www.davedub.co.uk/downloads/too_many_frames.avi
The bvh file is also available here: http://www.davedub.co.uk/downloads/female_poser_walk_8fps.bvh

The attached bvh file is a loop of exactly one second without it's reference (t-stance) frame. When the first frame (t-stance) is added, the length becomes 1.125 seconds. I would expect the SL animation uploader to ignore the first frame when calculating the length of the animation. However, on upload we see that the uploader reports the animation length to be 1.13 seconds long instead of the expected 1.0 seconds. When the animation is played in SL, the first (or maybe last?) frame appears to be played twice, producing a break in the otherwise smooth animation.

Steps to reproduce using the attached animation (female_poser_walk_8fps.bvh):

Verify the animation length is exactly one second long + one frame (125mS for the t-stance) using any bvh file editor.
Upload into SL - note the reported animation length at the top of the uploader
Play the animation - note the complete loss of fluidity!

[ Permlink | « Hide ]

Lex Neva added a comment - 23/Jul/08 10:15 AM

Dave's video made me realize something else: When I've made looping animations in the past, I've chosen a total number of frames that led to an even whole-number percentage for each frame. For example, I'd choose 20 total frames (including the magic first frame), and then when looping, I'd set the "in%" to 5%. Without skipping that first frame, I'd see exactly what dave has shown.

[ Permlink | « Hide ]

dave bellman added a comment - 24/Jul/08 01:09 AM

Update: After reading Lex's comment, I tried uploading the same file using various In(%) and Out(%) values.

I tried:

In(12.5%) (i.e. skip first frame, 100/8),
Out(87.5%) (i.e. skip last frame 100-100/8),
In(14.286%) (i.e. skip first frame, 100/7),
Out(85.714%) (i.e. skip last frame 100-100/7),
In(11.111%) (i.e. skip first frame, 100/9),
etc
etc

None of these values did anything more than reduce the problem slightly. None of them actually made the problem go away.

[ Permlink | « Hide ]

Mare Novi added a comment - 28/Jul/08 01:59 PM

I'm noticing this problem also in 1.20.15 (92456). I do animations for mermaids, which I want to look smooth. Instead, I get a momentary pause or jump on each loop of the animation, as described.

[ Permlink | « Hide ]

medhue simoni added a comment - 11/Aug/08 10:30 PM

yep, i agree. Its getting worse as the viewers advance.

[ Permlink | « Hide ]

Ashrilyn Hayashida added a comment - 11/Feb/09 01:00 AM

I might have found a workaround.. at least it looks all right in the animation upload window, in a few tests.
Someone else please try it out. I will try uploading and playing at least one on an avatar very soon.

One of my test animations was 14 frames long (this includes the count of the reference frame, frame 1).
Frame 14 is an exact copy of frame 2, on purpose. (I usually do that, as I found it greatly reduces looping stuttering if I do this and alter the loop settings accordingly. However, it seems I've been using the wrong In % values all along, but I digress.)

My intent is to loop frames 3-14 (if frame 1 is the reference, and frame 2 is the actual first frame of animation. Frame 14 is the exact copy of frame 2.)

So, what I did to get this looking right is:
14 total frames (including reference frame 1 in that count of 14). So I do (in Windows calculator)
100/14 = 7.1428571428571428571428571428571
Then I subtract 1 from the frame I want to loop to. Instead of 3, I use 2.
So, 2 * 7.1428571428571428571428571428571 = 14.285714285714285714285714285714 ... manually rounded up to 14.29.
In other words, 100/14*2 gives me my loop in %.
I set my in % to 14.29, and it appears to loop without problem.
That was with a 1 FPS animation, as well..

I'm getting kind of confused about why it works the way it does, but at least it seems to work..
I guess it would be that 0% = frame 1 (reference frame), 7.142 (100/14*1) would be frame 2, and 14.29 (100/14*2) frame 3, etc.
For some reason I need to lower my loop-in frame's number by 1 when calculating the in %, basically, as if the reference frame doesn't exist. Yet I keep the total number of frames the same when doing the calculation. And it appears to work..?

I found my 13-FPS version of a different 14-frame animation looks better when setting the In % to 14.29 instead of what QAvimator told me, 21%. There must have been a stutter I didn't notice. Oops. So I've been uploading animations with incorrect settings all this time.
Likewise with a 1-FPS version of the same animation. 14.29 looks okay to me. The feet did not jitter at all when looping.
The animation was made the same way in QAvimator. Frame 1 is the reference. Frame 14 is an exact copy of frame 2.

Testing a 1 FPS, 27 frame animation.
Again, frame 1 is the reference frame. Frame 27 is an exact copy of frame 2. I'm looping from frame 3 to 27 (if you count the reference as frame 1).
100/27 = 3.7037037037037037037037037037037
2 * 3.7037037037037037037037037037037 = 7.407407407407407407407407407406 (rounded to 7.407)
In short, 100/27*2.
So I set loop in % to 7.407, and it appears okay.

Note, I am testing this in the release candidate. I have only viewed these animations within the upload animation preview window. I have not yet uploaded them to see if they loop properly when played on an avatar.

Second Life 1.22.8 (109366) Feb 1 2009 13:13:47 (Second Life Release Candidate)

CPU: AMD (Unknown model) (3001 MHz)
Memory: 3328 MB
OS Version: Microsoft Windows XP Service Pack 2 (Build 2600)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: GeForce 8800 GT/PCI/SSE2/3DNOW!
OpenGL Version: 2.1.2

[ Permlink | « Hide ]

Ashrilyn Hayashida added a comment - 11/Feb/09 01:35 AM

Attaching a test animation I just made, "arm flap 17-frame 1fps.avm" and "arm flap 17-frame 1fps.bvh", with this post.
Frame 1 is the reference frame, of course. Frame 17 is an exact copy of frame 2.
I used 100/17*2 to find my in %, 11.764 ...my intent being to loop to frame 3, skipping frame 2.
I cannot notice any jitter in the looping.. even after uploading it and testing it on my avatar. It appears smooth to me.
This is while testing with Second Life 1.21.6 (99587) Oct 14 2008 17:42:25 (Second Life Release)

I wouldn't mind giving out the animation if someone else would like to try it on their avatar as well. It may not be ideal for testing, since I didn't override anything but the shoulders, upper arms, forearms, and hands.
Note that the arm lifting is only halfway done when it loops, so any jitters should be more noticeable at such a point. The arm lowering is done nowhere near the loop point.

[ Permlink | « Hide ]

dave bellman added a comment - 02/Mar/09 11:34 PM

Thank you Ashrilyn - this works!

I just tried it with the previously attached file - I manually copied frame 2 to the end, making a 10 frame animation (including the reference frame)

I had to experiment a little with your formula - may I suggest writing it as:

(100/10) * 2 or (100 / num_frames) * 2

Which gave me a In(%) value of 20%. I uploaded the animation, and it is as smooth as in my editor, no glitch whatsoever.

Having given it some thought, I can see how the fix works. For my (altered) file, the uploader now reports an animation length of 1.25 seconds. Given that we do not play the first 20%, that means the actual animation length is 1.0 seconds, as expected. Put simply, the uploader bug messes with the first two frames. This fix ignores the first TWO frames. Ignoring the reference frame is no problem, as we don't want that to play anyway. By adding frame 2 to the end the original animation is recreated. Job done!

I am guessing that Ashrilyn's fix will also help the Lindens understand and then fix the bug. I still think the cause is that the reference frame is taken into account in the overall animation 'play length' somewhere in the code...

[ Permlink | « Hide ]

dave bellman added a comment - 05/Mar/09 03:06 AM

Update - I have created a modified version of my bvhacker software that will apply this fix automatically. You can download the beta version here: http://www.davedub.co.uk/bvhacker/

To use, load you animation into bvhacker, ensure you have a reference frame (i.e. t-stance) and hit the 'Fix Loop' button. The fix will be applied to your data, and the In(%) value required for upload will be displayed and put on your clipboard ready to be pasted into the SL animation uploader. Save your file and upload!

:-Dave

[ Permlink | « Hide ]

medhue simoni added a comment - 19/Apr/09 04:27 PM - edited

Again, this is getting worse. So now all the workarounds need to be reconfigured. Can some1 at Linden Lab address this. How many people have to vote?

[ Permlink | « Hide ]

Moon Metty added a comment - 26/May/09 07:07 AM

The first frame isn't played 2 times, it's played 3 times!
Then when you loop the animation, there is no interpolation between the last and the first frame. It jumps abruptly, so the animation lasts one frame-time shorter again.

Normally an animation-program would show a 4-frame (not including reference-frame) looped animation like this:

1 - 2 - 3 - 4 - 1 - 2 - 3 - 4 - 1 - 2 ...

But SL loops the animation like this:

1a - 1b - 1c - 2 - 3 - 4/1a - 1b - 1c - 2 - 3 - 4/1a - 1b - 1c - 2 ...

(Where "-" marks an interpolation, and "/" marks an abrupt jump)

=======

The loop in(%) and out(%) are taken from the total duration between the first and last frame. That's one frame-time too short because of the missing interpolation. But there are 2 extra first frames, so in the end the total time is taken from one frame-time too much (compared to the original animation without reference-frame).

=======

Workaround.

Suppose you made an n-frame animation, not including reference frame:

-Copy frame 1 to frame n + 1 (Append the first frame after the last frame, this will take care of the missing interpolation)
-Upload the animation in SL with loop-in(%) = 200 / (n + 2)

Remember, n is the number of frames of your original animation.

[ Permlink | « Hide ]

Moon Metty added a comment - 29/May/09 10:57 AM

To show the first frame is there 3 times, I attached "2-frame-anim". It is set at 1 frame per second.

-Upload the animation not looped, with ease-in = 0, and ease-out = 0.
-Play the animation.

Observe: The animation lasts 3 seconds. The first 2 seconds it is stuck in frame 1. The third second you see the actual movement from frame 1 to frame 2.

So it plays like this: 1 - 1 - 1 - 2

Expected: the animation should last 1 second, playing like this: 1 - 2

[ Permlink | « Hide ]

medhue simoni added a comment - 09/Jun/09 09:47 PM - edited

Seriously, I will pay some1 at LL to fix this. Well, I already do, but i mean extra. Really, $500 US cash. Maybe some others will pitch in also, really, Im serious. Please! If this is not enough, give us the price. We'll find a way to come up with it. Im beggin here!

[ Permlink | « Hide ]

Moon Metty added a comment - 29/Jun/09 10:54 AM

Please note: the workaround only works for animations when they are looping.
The start of a looped animation, or a non-looped animation can't be worked around.

[ Permlink | « Hide ]

Moon Metty added a comment - 29/Jun/09 02:33 PM

Added repro steps to the summary, as requested by Soft.