|
|
|
[
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.
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 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. 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.
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), None of these values did anything more than reduce the problem slightly. None of them actually made the problem go away. yep, i agree. Its getting worse as the viewers advance.
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). 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: I'm getting kind of confused about why it works the way it does, but at least it seems 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. Testing a 1 FPS, 27 frame animation. 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) 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.  !
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... 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 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?
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) Remember, n is the number of frames of your original animation. 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. 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 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. Added repro steps to the summary, as requested by Soft.
All I seem to do is vote and then waah on about 2 year old Jira items that the Lindens haven't bothered to even assign, let alone address. No, I wont pay even a cent to get this fixed. Its got 32 votes from serious animators that contribute to SL and bring in vast somes of money for LL, through enriched content, tier, advertising and now SLX fees. This should have been sorted out a long time ago. Even a comment would be nice. Stop working on things that aren't broken like the pie menu (same old retoric I know - but same old issues) and fix some of the long standing issues that affect your high revenue clients.
Maybe, it's because the issue was rated NORMAL. Honestly, who thinks this should be normal? This is critical if you ask me. How can sl be commercially viable to any1 with a bug like this. Oh, and yes, the complete non response is what is soo frustrating.
Uploaded the result of serializing 2-frame-anim.bvh to the internal animation format. The result has 2 frames, but the duration is 3.0 seconds and the first frame is placed 2/3 into the timeline (AAAA). The other frame is placed at the 3 second mark (FFFF)
The way I see it, each frame in the BVH-file is a point on the timeline.
The time between two points is one frame-time, when the player does an interpolation from one point to the other. As soon as the last frame is reached, playback stops. So for a non-looped animation the total duration of playback should be: duration = (num_frames - 1) * frame_time ======= A looped animation has to find its way back from the end- to the start-frame. loop_duration = num_frames * frame_time ======= An exception is a 1-frame animation, which is technically more a pose than an animation. pose_duration = frame_time (Currently a pose uploaded with 1 second frame-time lasts 2 seconds) As per Louise' request, confirmed the bug still exists in 1.23.4 and Snowglobe. Added them to affected versions.
A question for you all: If we were to fix this, how much existing content would break, how would it break, and who would be upset by it? Given that a fix would mean that two different implementations would be live on the grid for a few months, how much of a problem is that?
So Q, you're saying the problem exists in the animation engine itself, rather than in the BVH parser? Is it a server-side thing or a client-side thing?
I don't see how this could break any existing content except for that uploaded with a workaround. I would hope those people that uploaded such animations are already watching this issue, though I doubt they all are. I'll ping the Avatar Maker's Guild about it. I haven't incorporated any workarounds myself, as I haven't been able to get them working to my satisfaction. Though I didn't expect a fix would actually involve a change that would repair how existing content is displayed. I thought it was a BVH parser issue, modifying the content before it was uploaded. Would like to hear other people's ideas about what content it might break. I'm not saying that – I actually haven't looked into the code yet, and was making assumptions based on not understanding it yet. But the point remains – if we change the way something works and people are depending on it, we could potentially be breaking content. I'd like to make sure the cure is not worse than the disease.
To the best of my knowledge there is nothing beneficial about this bug nor any content (except those that employed a workaround) that would be broken. I doubt anyone would be upset it were fixed.
I sent out the notice to the Avatar Maker's Guild, and I'm hoping the question will spread out to those that do animations, since I don't have authority to speak for everyone. As someone who has uploaded quite a few animations using the workaround, I'd previously assumed that a fix would not break existing content. It seems most likely to me that the bug is in the BVH parser, although this is just my best guess. I base my guess on the fact that when the bug first appeared existing animations did not get broken. I'm fairly certain this bug was not around when I first started animating.
Although the workarounds do work pretty well for animations that are looped from beginning to end, there is no workaround for animations that loop from any point other than the start and end. It is for these reasons that I think it would be a good idea to implement a fix and test it on the beta grid. I'd be happy to help out testing for breakages in existing animations etc. Dave Bellman If the cause is a bug in the playback code, then a fix could potentially break existing content. For example, if an animator has specified a loop-in value in order to skip the duplicate frame(s), and then playback is changed so that those duplicate frames are omitted but the loop-in value remains, there is a possibility that real, meaningful, non-duplicate frames would then be skipped instead. Depending on the length, framerate, and content of the animation, this could noticeably change the look of the animation. Slow, short, and/or precise animations would be most affected.
But even if it's a bug in the playback code, it may be possible to fix it in a way that doesn't affect existing content. On the other hand, if it's a bug in the way the BVH file is loaded, no existing content would change (break), only new uploads would be affected, and we'd all live happily ever after. I have my fingers crossed that this is the case. For me, this bug is a huge problem, just because of the kinds of things i make and the position i put avatars in. Over the past almost 2 years i have had to change tons of animation because of this issue, and then, we get a new mandatory viewer and now the problem got even worse. Not with this last viewer, i dont think. So whether the workaround works or not, animation keep getting broken anyways. The worse part about this bug is the transition from 1 animation to the another. Before this bug, all animations had smooth transitions. This becomes very important when some1 is trying to film a machinima and things like this, plus it is annoying to have anims jumping at the transitions. I've worked with quite a few machinima people and jumping anims and not good, as well as playing around with my own videos. I have literally thousands of animation products and aos out in the public, many bought b4 the bug, and i would rather deal with any problems now than continue purposely changing anims for a workaround that is reliant on a glitchy in%.
There is another jira that has to do with syncing animation it could very much be related. VWR-8793 Thanks Q Where was all this concern about breaking content when the megainvisiprim trick was "fixed" leaving no workaround avaiable at all?
I will not debate that issue in this JIRA. Please consider the possibility that as an organization we can learn and change. I reached out to try to have a useful debate. Remarks like that are both irrelevant and designed to keep me from reaching out next time. Please reconsider the tactic.
I appologize, I didn't meant to discourage interaction with that comment, much to the contrary. My goal with pointing out that occurrence was to put things on the scale, it was a commentary in favor of this being fixed. If in that case, breaking content, and without any workarounds to reproduce the altered behavior, the so called "fix" was still implemented and haven't been reverted so far, in this case, correcting the unexpected behavior would be beneficial for many content creators, while by the very nature of how animations work the abnormal behavior would still be easily achievable by content creators if desired. There is the small pontential of content that counted on the abnormal behavior being broken with this fix, but with just a few clicks on the animation editing program of choice and 10L$ more, content creators can get the abnormal behavior again if they so desire. If "fixing" the abnormal behavior in the case of the invisimegaprim was the choice made, in spite of so much reasons not to do it, in this case, most of the reasons aren't there, the little that is left can easilly be overcome by content creators, if in the first case that was considered the best choice, in the later it's the obvious way to go.
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Open
Normal
First frame of uploaded animations is triplicated
