[BUG-11194] First frame of uploaded animations is triplicated #1426
Comments
Lex Neva commented at 2007-12-12T15:50:25Z 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. |
Dave Bellman commented at 2008-07-23T06:50:27Z 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. |
Lex Neva commented at 2008-07-23T15:15:17Z 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. |
Dave Bellman commented at 2008-07-24T06:09:06Z 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. |
Mare Novi commented at 2008-07-28T18:59:49Z 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. |
Medhue Simoni commented at 2008-08-12T03:30:17Z yep, i agree. Its getting worse as the viewers advance. |
Ashrilyn Hayashida commented at 2009-02-11T07:00:39Z I might have found a workaround.. at least it looks all right in the animation upload window, in a few tests. 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) |
Ashrilyn Hayashida commented at 2009-02-11T07:35:26Z Attaching a test animation I just made, "arm flap 17-frame 1fps.avm" and "arm flap 17-frame 1fps.bvh", with this post. 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. |
Dave Bellman commented at 2009-03-03T05:34:17Z : 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... |
Dave Bellman commented at 2009-03-05T09:06:16Z 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 |
Medhue Simoni commented at 2009-04-19T21:27:48Z, updated at 2009-04-19T21:28:08Z 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? |
Moon Metty commented at 2009-05-26T12:07:55Z The first frame isn't played 2 times, it's played 3 times! 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. |
Moon Metty commented at 2009-05-29T15:57:09Z 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 |
Moon Metty commented at 2009-06-29T15:54:20Z Please note: the workaround only works for animations when they are looping. |
Moon Metty commented at 2009-06-29T19:33:39Z Added repro steps to the summary, as requested by Soft. |
Dancing Lemon commented at 2009-07-08T15:16:12Z 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. |
Medhue Simoni commented at 2009-07-09T06:53:04Z, updated at 2009-07-09T06:55:17Z 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. |
Day Oh commented at 2009-07-10T08:57:52Z 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) |
Day Oh commented at 2009-07-10T10:33:54Z Question... in a two-frame animaton lasting two seconds, would you expect the second frame to last a full second, or be placed at the very end of the timeline? |
Moon Metty commented at 2009-07-10T13:08:55Z The way I see it, each frame in the BVH-file is a point on the timeline. 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) |
Stickman Ingmann commented at 2009-07-16T13:25:04Z As per Louise' request, confirmed the bug still exists in 1.23.4 and Snowglobe. Added them to affected versions. |
Q Linden (Inactive) commented at 2009-09-09T21:42:25Z 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? |
Stickman Ingmann commented at 2009-09-09T21:57:06Z 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. |
Q Linden (Inactive) commented at 2009-09-09T22:27:38Z 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. |
Stickman Ingmann commented at 2009-09-09T22:32:50Z 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. |
Dave Bellman commented at 2009-09-10T00:05:22Z 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 |
Jacek Antonelli commented at 2009-09-10T00:15:47Z 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. |
Medhue Simoni commented at 2009-09-10T00:29:21Z, updated at 2009-09-10T01:19:00Z 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 |
TigroSpottystripes Katsu commented at 2009-09-10T00:33:24Z Where was all this concern about breaking content when the megainvisiprim trick was "fixed" leaving no workaround avaiable at all? |
Q Linden (Inactive) commented at 2009-09-10T01:10:04Z 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. |
Osprey Therian commented at 2011-08-22T17:13:02Z What's the status, now, of this long-term and pernicious bug? |
Medhue Simoni commented at 2011-10-03T13:50:09Z It is pretty dang ridiculous that this bug has gone on for so long. As far as I'm concerned, LL should just make animation uploads free if LL refuses to fix a major bug for 4 years. It is hard to have faith in a company that allows this to go on for so long. |
Stickman Ingmann commented at 2011-10-03T20:46:31Z A "fix" to this bug could be to move away from the BVH format entirely and support native internal animation format uploads by way of creation of exporting tools for Max, Maya, Blender, Poser, or Daz3D. The BVH conversion done in the viewer is not clean, nor ideal, and has numerous other problems besides simply messing up looped animations. |
Coaldust Numbers commented at 2011-10-03T21:11:39Z, updated at 2011-10-03T22:21:09Z Someone has to write those exporting tools, and I suspect you're not offering to write them all. The best solution is to have the flawed importer corrected. While you could argue there are problems with the BVH format (e.g. assuming a hierarchical relationship amongst bones, not supporting location animation except for the root, and not supporting scale animation at all), they are not the cause of the importer's problems. BVH is a perfectly good format for what it's being used for right now. If you really want to upload .anim files you can do that with most any third party viewer (e.g. bulk upload in Phoenix or Firestorm). Given there are no widely available tools to produce them from commonly supported animation formats (e.g. BVH, FBX, COLLADA... that's all I can think of, with BVH being by far the most widely supported) you will be hard pressed to make them any way other than uploading a BVH file (remember the importer is broken, and thus produces bad data), ripping it with a viewer with inventory export, then editing it in a .anim editor and re-uploading. If you look hard enough you might be able to find a copy of a modified QAvimator that can produce .anim files from BVH files, but it does no optimization (a.k.a. lossy compression), and I have a feeling that if it becomes widely used, unoptimized animations will be blocked from downloading, in much the same way that large non-lossily-compressed JPEG2000 images are right now. Further, if we adopt the attitude that it's 'okay' for the BVH importer to be broken, what's to stop playback of animations from becoming broken? At what point should we expect buggy code to be fixed? |
Medhue Simoni commented at 2011-10-03T21:42:25Z, updated at 2011-10-03T21:49:02Z I don't have a problem at all with bvh files. I have a problem with constantly creating imperfect animations, for 4 gosh darn years, and redoing the same animations over and over again. IMHO, choosing bvh as the file format was genius on LL's part. If not for that, we would have had alot less motion capture in SL, and much less total animations. Personally, I'm just sick of us constantly getting the shaft. LL does absolutely no promotion of animation in SL, and we have had absolutely no bug fixes since the beginning, or at least that I can recall. We get tucked away under fashion. Yet, LL will put together teams of people to work on clothing layers. Look at how much time they spent on just that outfit creator, but we can't get a crucial bug that breaks all looping animations fixed. Is this not an animated world we are talking about here? |
Osprey Therian commented at 2011-10-04T05:19:58Z, updated at 2011-10-04T05:20:17Z BVH is great, just needs a bug fixed. Even I (who only make animations every so often) have made hundreds of animations. I'm sure any animation maker has made many thousands. Has everyone at LL been put to work on the new project? |
Medhue Simoni commented at 2011-10-04T05:58:22Z Animation is the 1 area where SL blows the pants off of every single game or world ever made. Yeah sure, the quality varies, but there is nothing that comes close to animation in SL. This is why it is frustrating to see LL completely neglect it. Any world can have lots of clothing, or a car, or weapons or whatever, but no world can compare in terms of animation. If it actually worked right, it would be a complete joy to use and to make. Right now, between the hands bug, the turning bug, some priority problems and this bug, it's mediocre, at best. Practically all of these issues are close to half a decade old now. |
Osprey Therian commented at 2011-10-04T08:55:25Z 'Animation is the 1 area where SL blows the pants off of every single game or world ever made.' I agree! |
Dave Bellman commented at 2011-10-04T15:18:44Z +1 |
Medhue Simoni commented at 2011-10-05T21:27:08Z Thanks Dan!!!! |
Moon Metty commented at 2011-10-05T23:02:32Z Aha! :D Now here's a question for SL's animators.
|
Coaldust Numbers commented at 2011-10-05T23:22:39Z, updated at 2011-10-05T23:40:20Z Currently there is no interpolation. The normal way to make a smooth loop for Second Life is to make the Loop In and Loop Out frames (and trying to hit those frames with percentiles :( ) identical. This is pretty easy in most animation tools, since you can cut and paste keyframes. So long as there is no interpolation, if the BVH importer worked correctly, there would be no pauses when looping (because it doesn't essentially play a frame twice). I consider this highly desirable. The alternative would be much harder to work with, and I'd consider it broken. I suppose I don't care if it's added so long as it's a option that can be turned off, though. |
Medhue Simoni commented at 2011-10-05T23:32:35Z I agree completely with Coaldust. |
Moon Metty commented at 2011-10-05T23:39:06Z Please see VWR-27098 |
Coaldust Numbers commented at 2011-10-05T23:44:26Z Imma vote for VWR-27098 (use frame-numbers instead of percentiles for loop-in/out) so hard my clicky finger hurts! I really should have made that JIRA first. ;) |
Coaldust Numbers commented at 2011-10-08T16:52:08Z This talk of how looped animation interpolation should be handled, and how Loop In and Loop Out aught to be specified, has made me realize there is another likely source of problems in the BVH importer. I think the first frame displayed (not the reference frame), the Loop In frame, the Loop Out frame, and the last frame need to be treated specially, and I don't think the current 'optimizer' (a.k.a. lossy compressor) does that. I don't believe the animation will start in the right position if the first frame is removed, assuming there is any significant movement (I realize this is per-joint) in the animation. I doubt the animation will loop properly if you remove the Loop In frame, unless there is no significant movement between it and the first frame displayed AND no significant movement within the loop body. I don't think the animation will loop properly if the Loop Out frame is removed, unless there is no significant movement within the loop body. I believe the animation won't end in the right position if the last frame is removed, unless there is no significant movement between it and the first frame displayed. The same frame could serve more than one of these roles. For example, in a one frame looped animation they're all the same frame. If any one of these roles would cause a frame to be preserved, it must be preserved. Unless I am mistaken about these things, this points to it actually being important to handle the loop settings as frames, not percentiles (as in the current user interface) or times (as in the internal format). The internal format need not be changed to correct this; it just needs to be quantized to a actual frame. The 'optimizer' destroying these frames might explain the loss of 'subtle movement' (VWR-2461) people sometimes complain about. I was unable to reproduce any problems with small movements being stripped under normal circumstances. I wrote a wiki page on this: http://wiki.secondlife.com/wiki/Animating_Breathing_and_Other_Subtle_Movements These bugs also make me question the usual way of calculating the percentiles for the loop settings. After looking at the internal code it appears that the loop settings are based on animation frames, not BVH frames. This would mean the 'first frame is triplicated' bug is why it appears that you need to adjust for the reference frame when uploading. I'm testing this now, and will adjust the wiki page I wrote on it when I know more. |
Coaldust Numbers commented at 2011-10-09T04:41:33Z I've spent most of the day uploading and playing BVH and Anim files and watching what happens in a viewer with Nym Rieko's patch applied (e.g. by looking at the contents of "motionp" in llfloateranimpreview.cpp). They noticed several problems and didn't fix them, instead choosing to work around them here and there. Aside from making the code overcomplicated and hard to understand, it's allowed some bugs to survive. The duration is still wrong until it's serialized. This prevents you from uploading full 30 second animations (see VWR-27044). Key frames start at the wrong time. For example, when uploading a 2 frame (a reference frame and a static pose) BVH file the internal animation format's first frame is at 0.06666666 seconds in instead of 0 seconds. They noticed this, but didn't consider it a problem. This needs to be fixed for perfectly smooth looping. I don't want it to sound like I'm ungrateful. Nym did almost all the hard work necessary to understand and fix this problem. I point the remaining problems out because I want it to be completely fixed. Nobody has mentioned the need to preserve the 'special frames' I mentioned before, as far as I know, and the patch doesn't address that concern. I did determine that the widespread habit of adjusting Loop In for the reference frame is due to this bug (First frame of uploaded animations is triplicated). The reference frame is not preserved in the internal animation format, and a Loop In of 0% starts at 0 seconds, not some time later. It reduces the visibility of the problem, but doesn't eliminate it, because it doesn't skip all the duplicated frames. I'll be fixing my wiki article on that soon. My apologizes to anybody I mislead by spreading this misinformation. Also, the cause of almost all our animation problems appears to be this bad BVH importer. There seems to be very few bugs in the animation playback code. The only one I've found is VWR-27045. This should quell any fears of breaking content. |
JeremyAtticusFinch commented at 2013-06-18T19:36:29Z I have just reached a point in my education about animations where this issue has become important to me. I am not familiar with how things work around here, or how you vote, so I will just say that both my partner and myself would like to vote in favor of fixing this issue as soon as possible. :) Thanks, |
Osprey Therian commented at 2013-06-18T20:16:20Z, updated at 2013-06-18T20:18:54Z Jeremy, have a look at BVHacker - it can fix loops. |
Medhue Simoni commented at 2013-06-18T22:08:10Z No offence Osprey, but nothing can fix this issue besides LL actually addressing it. BVHacker does not, I repeat, does not fix the loop. It routes the system around the problem, which makes the bug unnoticable by most users. No matter what an animator does, the bug is still there, and shows it's every single time the animation is initially played. In some cases, it isn't noticable. In every single case, barring some script hacks around it, if you try to put the character is any position other than standing, and then change to another animation that is not standing, you will see this bug. What seriously annoys me, is LL continuing to code overtop of this bug, instead of fixing it and then adding in other animation features. The animation system shows exactly how sloppily LL does things. We currently have this bug, which is major despite people thinking there is a fix, the spread hand bug, you can't walk and hold something using the default walk, and the default turn priorities have been too high for years now. Those are the major SL animations bug and if you ask any Linden, they won't know any of them exist. I'm sorry Osprey, but as an animator which thinks SL has the best animation system ever created and thinks it is crippled by all these bugs, I get quite annoyed when people keep saying there are fixes, when there are not. The Lindens can then think, "Oh look, there is a fix, so we don't have to address this bug". This bug directly affects 35% or more of the animation market. Actually, we can't even know, because things that could be made are being avoided by animators because they don't want to put out products where the avatar pops up at inappropriate times. |
Osprey Therian commented at 2013-06-19T01:22:21Z Medue, I agree with you 100%. I wish LL would fix this issue as custom animations are a huge strength of SL. On the other hand they haven't and I was just handing along a bit of info that has helped me. |
Dave Bellman commented at 2013-06-19T01:44:11Z, updated at 2013-06-19T01:44:46Z Just to agree with Medhue, bvhacker doesn't fix the problem, it works around it by adding a duplicate first frame. The first time the animation is played both of the duplicates seem to be played, but when the animation loops, the first frame is dropped. So the original problem of SL dropping the first frame is circumnavigated, as the second frame becomes the first frame and the animation plays smoothly from then on - I hope that makes sense! btw, the url for bvhacker is now http://www.bvhacker.com/. I've not posted 'http://davedub.co.uk/bvhacker/' anywhere for years now - you must have first tried it a long time ago!
|
Osprey Therian commented at 2013-06-19T01:59:18Z Re: link - I just googled for it when I made the post and that's what turned up. Yes, 'fix' was not the best way to state it, however it's helped me and all I was trying to do was pass on the information. |
JeremyAtticusFinch commented at 2013-06-20T18:40:42Z Okay, I don't disagree that there is a issue that occurs when an animation in uploaded, i.e., added frames. AND I don't disagree that BVHacker, might offer a "work around" but not a solution. But, I am not convinced that there isn't more going on here that is likely beyond the scope of this specific bug. So, is there a place where we could continue and perhaps "broaden" this discussion a little? My hope would be to identify a "common vocabulary" for animations in SL (like "reference frames") and the uploading process so I can more effectively communicate the puzzle parts that seem to be missing and constantly nagging me. Specifically, I would like to discuss the "orientation" of animations with respect to rotation around the 3 axis... During construction, upload, and finally application (with MLPV2 for instance). I think there is something missing from all of this and it is likely that I don't understand everything, but there may be something "elementary" missing as well. I just want to make sure. I am open to any discussion format you all prefer, just let me know the forum. |
Coaldust Numbers commented at 2013-09-14T09:39:17Z, updated at 2013-09-14T09:42:38Z [Double posting, sorry.] |
Coaldust Numbers commented at 2013-09-14T09:39:17Z, updated at 2013-09-26T13:04:49Z The only "work around" that actually works is not creating loops between the first and last frames. Animations with an "intro" that prevents the duplicated frames from being inside the loop will only stutter when the animation starts, not on every pass through the loop. There are many false beliefs about the animation system. Worse, most software for making animations for Second Life are based on these false beliefs. I've tried to document all the ones I'm aware of, along with the truth (gathered by testing and watching the relevant code in a debugger), at my links under: https://wiki.secondlife.com/wiki/Talk:How_to_create_animations The relevant link for this issue is: https://wiki.secondlife.com/wiki/Animation_Upload_Loop_Controls And now I've accidentally clicked the "Blocked" button. Hopefully I haven't prevented this problem from eventually getting solved. It's been a long wait so far. |
Vir Linden commented at 2016-01-08T14:58:31Z Just started looking at this, so apologies if I'm missing something from previous discussions. Is this a problem in playback, or a problem in the uploader? Has anyone seen it when uploading an animation as .anim, which bypasses a lot of processing done by the .bvh uploader? If it's just a bug in the bvh uploader, it should be feasible to fix. If it's a systemic problem with how we play back animations, then it's hard to see how we could fix it without breaking existing content that was originally designed to bypass the bug. |
Medhue Simoni commented at 2016-01-08T22:22:19Z Read Nym's post. Yes anim files also have the issue. Are you sure fixing it would break existing content? The work around is to simply choose a different start frame for the loop. The data is there. As long as the playback includes the new start and end frames, then old content should be fine. Not a coder here tho. |
Vir Linden commented at 2017-07-06T14:52:04Z Our apologies, it appears this jira has been a victim of a spammer. We've cleaned up the offending comments, sorry for the mess! |
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:
= Observed: The avatar's arm spends more time fully down than it spends fully up.
Attachments
Original Jira Fields
The text was updated successfully, but these errors were encountered: