Uploaded image for project: 'Firestorm'
  1. Firestorm
  2. FIRE-3657

[PATCH] [VWR-16694] Avatar animations are faster at a distance.

    Details

    • Type: Bug
    • Status: Passed QA
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: Phoenix Firestorm 4.0.1, Phoenix Firestorm 4.1.1
    • Fix Version/s: Phoenix Firestorm 4.6.6
    • Component/s: None
    • Labels:
    • Environment:
      Windows 7 Home Premium

      Core i7 2650 2.00 GHz
      nVidia 560M GTX 2GB
      8GB DDR3 RAM
      2x 500GB 5400 RPM HDD's

      Laptop.
    • SL Avatar Name:
      xcreasybear Resident
    • Patch attached:
      Patch attached
    • Reported In:
      Firestorm 3.0.1.22566 Mesh Beta Maintenance Release

      Description

      Whenever I turn avatar impostor's off to improve visual quality, avatars somewhat far away from me with an animation override of any kind appear to move ridiculously fast; for example, if they are dancing, their dance animation will play at 5 times the speed it should. If I move the camera closer to them, they appear to move normal speed, but as distance increase, so does their animation speed. It isn't a game breaking issue but it's very aggravating, since I do not like impostors and turning them off causes little detriment to my system performance.

      Is there a setting I can change to fix this?

      EDIT (Whirly): https://jira.secondlife.com/browse/VWR-16694

      1. llmotioncontroller.default.patch
        8 kB
        Melancholy Lemon
      2. llmotioncontroller.final.11-jun.patch
        18 kB
        Melancholy Lemon
      3. llmotioncontroller.final.final.13-jul.patch
        18 kB
        Melancholy Lemon
      4. llmotioncontroller.for-whirly.patch
        8 kB
        Melancholy Lemon
      5. llmotioncontroller.use-this-one.patch
        10 kB
        Melancholy Lemon

        Issue Links

          Activity

          Hide
          nogardrevlis NogarDrevlis Lectar added a comment -

          There are not rally faster , only your framerate per second (fps) is better (higher) if you scroll out, so the animations seems to be faster.

          Show
          nogardrevlis NogarDrevlis Lectar added a comment - There are not rally faster , only your framerate per second (fps) is better (higher) if you scroll out, so the animations seems to be faster.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          This is an old bug thats in all viewers https://jira.secondlife.com/browse/VWR-16694

          Show
          whirly.fizzle Whirly Fizzle added a comment - This is an old bug thats in all viewers https://jira.secondlife.com/browse/VWR-16694
          Hide
          flip.idlemind Flip Idlemind added a comment -

          The root of this seems to be in llvoavatar.cpp, in updateCharacter(). After a comment that says "// change animation time quanta based on avatar render load". It seems that if time_step is anything other than 0, these "hyper-fast" animations are the result.

          Show
          flip.idlemind Flip Idlemind added a comment - The root of this seems to be in llvoavatar.cpp, in updateCharacter(). After a comment that says "// change animation time quanta based on avatar render load". It seems that if time_step is anything other than 0, these "hyper-fast" animations are the result.
          Hide
          thandi rhiadra Thandi Rhiadra added a comment -

          I am having this issue, as well. It's annoying that anyone outside of chat range (20M or so) seems to be dancing, walking, animating in some way, MUCH faster than normal. I've tried turning avatar imposters on, back off again, etc. Nothing changes this issue for me. It used to be just the opposite. If avatars were dancing in the distance, they were VERY slow for me. Now it's just the opposite. I'd like this to be fixed, as it makes no sense why the animations are going that fast. It takes no more/causes no less strain on my system to view the animations at fast speed than it does to view them at the proper speed. Please fix! Thanks in advance for your time and attention to this seemingly insignificant detail of SL.

          Show
          thandi rhiadra Thandi Rhiadra added a comment - I am having this issue, as well. It's annoying that anyone outside of chat range (20M or so) seems to be dancing, walking, animating in some way, MUCH faster than normal. I've tried turning avatar imposters on, back off again, etc. Nothing changes this issue for me. It used to be just the opposite. If avatars were dancing in the distance, they were VERY slow for me. Now it's just the opposite. I'd like this to be fixed, as it makes no sense why the animations are going that fast. It takes no more/causes no less strain on my system to view the animations at fast speed than it does to view them at the proper speed. Please fix! Thanks in advance for your time and attention to this seemingly insignificant detail of SL.
          Hide
          mobius Mobius Ryba added a comment -

          Fixed in 27047, changeset c91ab2b22a29

          Show
          mobius Mobius Ryba added a comment - Fixed in 27047, changeset c91ab2b22a29
          Hide
          lassie Lassie added a comment - - edited

          I'm still seeing this on Firestorm 4.1.1 (27115) Mar 29 2012 08:26:57 (Firestorm-LassieStorm)
          Tested at http://maps.secondlife.com/secondlife/The%20Galaxy/97/139/25

          Tested by walking closer to and walking further from the dance floor.
          Animation speed increased with distance.

          Tested by locking my camera on the center of the dance floor and moving my camera in and out.
          Animation speed increased with distance.

          Tested by locking my camera on the center of the dance floor, zooming out, then using ctrl-8 and ctrl-0 to change the amount of screen space the avatars on the dance floor took up on my screen.
          Animation speed increased with a wider field of view.

          Firestorm 4.1.1 (27115) Mar 29 2012 08:26:57 (Firestorm-LassieStorm)
          Release Notes

          You are at 216,929.0, 303,755.0, 25.3 in The Galaxy located at sim6112.agni.lindenlab.com (216.82.12.166:13001)
          Second Life Server 12.03.26.252149
          Release Notes

          CPU: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (2793.03 MHz)
          Memory: 4088 MB
          OS Version: Microsoft Windows 7 64-bit (Build 7600)
          Graphics Card Vendor: NVIDIA Corporation
          Graphics Card: GeForce GT 220/PCI/SSE2

          Windows Graphics Driver Version: 8.17.0012.8562
          OpenGL Version: 3.3.0

          RestrainedLove API: RLV v2.7.0 / RLVa v1.4.5a
          libcurl Version: libcurl/7.21.1 OpenSSL/0.9.8q zlib/1.2.5 c-ares/1.7.1
          J2C Decoder Version: OpenJPEG: 1.4.0, Runtime: 1.4.0
          Audio Driver Version: FMOD version 3.750000
          Qt Webkit Version: 4.7.1 (version number hard-coded)
          Voice Server Version: Vivox 2.1.3010.6270

          Settings mode: Firestorm
          Viewer Skin: firestorm (grey)
          Font Used: Deja Vu (96)
          Draw distance : 96
          Bandwidth : 1500
          LOD factor : 3
          Built with MSVC version 1600
          Packets Lost: 399/571,017 (0.1%)

          Show
          lassie Lassie added a comment - - edited I'm still seeing this on Firestorm 4.1.1 (27115) Mar 29 2012 08:26:57 (Firestorm-LassieStorm) Tested at http://maps.secondlife.com/secondlife/The%20Galaxy/97/139/25 Tested by walking closer to and walking further from the dance floor. Animation speed increased with distance. Tested by locking my camera on the center of the dance floor and moving my camera in and out. Animation speed increased with distance. Tested by locking my camera on the center of the dance floor, zooming out, then using ctrl-8 and ctrl-0 to change the amount of screen space the avatars on the dance floor took up on my screen. Animation speed increased with a wider field of view. Firestorm 4.1.1 (27115) Mar 29 2012 08:26:57 (Firestorm-LassieStorm) Release Notes You are at 216,929.0, 303,755.0, 25.3 in The Galaxy located at sim6112.agni.lindenlab.com (216.82.12.166:13001) Second Life Server 12.03.26.252149 Release Notes CPU: Intel(R) Core(TM) i7 CPU 860 @ 2.80GHz (2793.03 MHz) Memory: 4088 MB OS Version: Microsoft Windows 7 64-bit (Build 7600) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce GT 220/PCI/SSE2 Windows Graphics Driver Version: 8.17.0012.8562 OpenGL Version: 3.3.0 RestrainedLove API: RLV v2.7.0 / RLVa v1.4.5a libcurl Version: libcurl/7.21.1 OpenSSL/0.9.8q zlib/1.2.5 c-ares/1.7.1 J2C Decoder Version: OpenJPEG: 1.4.0, Runtime: 1.4.0 Audio Driver Version: FMOD version 3.750000 Qt Webkit Version: 4.7.1 (version number hard-coded) Voice Server Version: Vivox 2.1.3010.6270 Settings mode: Firestorm Viewer Skin: firestorm (grey) Font Used: Deja Vu (96) Draw distance : 96 Bandwidth : 1500 LOD factor : 3 Built with MSVC version 1600 Packets Lost: 399/571,017 (0.1%)
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Thanks Lassie,

          Going to reopen this one for further investigation.

          Show
          whirly.fizzle Whirly Fizzle added a comment - Thanks Lassie, Going to reopen this one for further investigation.
          Hide
          whirly.fizzle Whirly Fizzle added a comment - - edited

          Yeah something is strange here, but I think its with the Max avatars setting.

          • With avi imposters enabled & max avatars set at 1, far animations are normal speed.
          • With avi imposters enabled & max avatars set at 65, far animations are too fast.
          • With avi imposters disabled & max avatars set to 1, far animations are normal speed,
          • With avi imposters disabled & max avatars set to 65, far animations are too fast.

          Max avatars setting shouldnt affect anything when imposters are disabled as far as I know, yet it is.

          Show
          whirly.fizzle Whirly Fizzle added a comment - - edited Yeah something is strange here, but I think its with the Max avatars setting. With avi imposters enabled & max avatars set at 1, far animations are normal speed. With avi imposters enabled & max avatars set at 65, far animations are too fast. With avi imposters disabled & max avatars set to 1, far animations are normal speed, With avi imposters disabled & max avatars set to 65, far animations are too fast. Max avatars setting shouldnt affect anything when imposters are disabled as far as I know, yet it is.
          Hide
          jessica_lyon Jessica Lyon added a comment -

          Mobius, if you don't think you can fix this in time for 4.1.1, can you please move the fix version to 5.

          Show
          jessica_lyon Jessica Lyon added a comment - Mobius, if you don't think you can fix this in time for 4.1.1, can you please move the fix version to 5.
          Hide
          melancholy.lemon Melancholy Lemon added a comment -

          Fix attached. It's quite a big patch to llmotioncontroller.cpp, but it's actually pretty safe. The simple of case of an avatar that's visible and close by is unchanged. And the cases of an avatar far away or off screen have basically been completely broken in the LL codebase for a very long time anyway. So this could hardly make things worse (but try it and you'll see it actually makes things a lot better

          The code is also commented and (I hope) more readable than the LL code it replaces.

          mel

          Show
          melancholy.lemon Melancholy Lemon added a comment - Fix attached. It's quite a big patch to llmotioncontroller.cpp, but it's actually pretty safe. The simple of case of an avatar that's visible and close by is unchanged. And the cases of an avatar far away or off screen have basically been completely broken in the LL codebase for a very long time anyway. So this could hardly make things worse (but try it and you'll see it actually makes things a lot better The code is also commented and (I hope) more readable than the LL code it replaces. mel
          Hide
          melancholy.lemon Melancholy Lemon added a comment -

          BTW, Whirly, I was completely unable to reproduce your observation of max avatars having an effect when imposters are disabled - and looking at the code I really don't see how that could happen. What I would say is there are multiple problems with the LL code and the observed behaviour can be influenced by many factors - so perhaps it was just a coincidence?

          Anyway, would love to see if you or anyone else can see any problems with my patch applied - was out clubbing last night (in 4.0.1, but the attached patch here is tested against 4.1.1) at an open air beach club, and I cammed out, and just watched teeny tiny avatars dancing in the distance on the beach, at the correct speed, and maintaining sync. It was a beautiful sight

          mel

          Show
          melancholy.lemon Melancholy Lemon added a comment - BTW, Whirly, I was completely unable to reproduce your observation of max avatars having an effect when imposters are disabled - and looking at the code I really don't see how that could happen. What I would say is there are multiple problems with the LL code and the observed behaviour can be influenced by many factors - so perhaps it was just a coincidence? Anyway, would love to see if you or anyone else can see any problems with my patch applied - was out clubbing last night (in 4.0.1, but the attached patch here is tested against 4.1.1) at an open air beach club, and I cammed out, and just watched teeny tiny avatars dancing in the distance on the beach, at the correct speed, and maintaining sync. It was a beautiful sight mel
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Awesome, thanks Melancholy.

          Youre right about the max avatars, I cant consistently reporoduce that anymore, but its so hard to say as its erratic.
          Going to build with your patch now & test

          Show
          whirly.fizzle Whirly Fizzle added a comment - Awesome, thanks Melancholy. Youre right about the max avatars, I cant consistently reporoduce that anymore, but its so hard to say as its erratic. Going to build with your patch now & test
          Hide
          melancholy.lemon Melancholy Lemon added a comment -

          Actually, I've found a flaw in my patch, so if you want to hold off testing there will be a better version of the patch coming soon (hopefully this weekend).

          That said, there's no real reason not to apply the patch I've submitted - it works and gives much better results than the LL code (and I rather suspect the difference between the patch I've submitted and the corrected version will be subtle enough as to be pretty much invisible under real world conditions anyway).

          Show
          melancholy.lemon Melancholy Lemon added a comment - Actually, I've found a flaw in my patch, so if you want to hold off testing there will be a better version of the patch coming soon (hopefully this weekend). That said, there's no real reason not to apply the patch I've submitted - it works and gives much better results than the LL code (and I rather suspect the difference between the patch I've submitted and the corrected version will be subtle enough as to be pretty much invisible under real world conditions anyway).
          Hide
          melancholy.lemon Melancholy Lemon added a comment -

          Ok, just testing my new version now. Whirly, please let me know what you'd prefer I submit when I'm done - a replacement patch that applies against SVN, or one that applies against the result of the previous patch?

          The advantage of the latter is that if you've already build with my patch, you won't need to touch llmotioncontrol.h again - which means it's a quick recompile.

          Show
          melancholy.lemon Melancholy Lemon added a comment - Ok, just testing my new version now. Whirly, please let me know what you'd prefer I submit when I'm done - a replacement patch that applies against SVN, or one that applies against the result of the previous patch? The advantage of the latter is that if you've already build with my patch, you won't need to touch llmotioncontrol.h again - which means it's a quick recompile.
          Hide
          melancholy.lemon Melancholy Lemon added a comment -

          Replacement for llmotioncontroller.default.patch

          This is the patch against HG that you should use - it is more correct than the original patch.

          Show
          melancholy.lemon Melancholy Lemon added a comment - Replacement for llmotioncontroller.default.patch This is the patch against HG that you should use - it is more correct than the original patch.
          Hide
          melancholy.lemon Melancholy Lemon added a comment -

          Okay llmotioncontroller.use-this-one.patch is the version of the patch I'd prefer everyone to test or review. This is a replacement for the patch I first submitted, and is against Hg.

          Only for Whirly (and anyone else who has already built with the old patch) - you should be able to apply llmotioncontroller.for-whirly.patch to your working copy and you'll get the new code without touching llmotioncontroller.h (which hopefully means you won't have to rebuild pretty much all of newview again).

          mel

          Show
          melancholy.lemon Melancholy Lemon added a comment - Okay llmotioncontroller.use-this-one.patch is the version of the patch I'd prefer everyone to test or review. This is a replacement for the patch I first submitted, and is against Hg. Only for Whirly (and anyone else who has already built with the old patch) - you should be able to apply llmotioncontroller.for-whirly.patch to your working copy and you'll get the new code without touching llmotioncontroller.h (which hopefully means you won't have to rebuild pretty much all of newview again ). mel
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Heya Mel,

          Thanks! And yes, thats a looooong build

          Just done some quick testing with the initial patch.
          Fantastic! I notice no difference at all in animation speed on distant avatars whether avatar imposters are enabled or not.
          This bug was one of my pet hates. Im so happy! \o/

          Will rebuild with the add on & test again & keep an eye out for any undesirable side effects.

          Show
          whirly.fizzle Whirly Fizzle added a comment - Heya Mel, Thanks! And yes, thats a looooong build Just done some quick testing with the initial patch. Fantastic! I notice no difference at all in animation speed on distant avatars whether avatar imposters are enabled or not. This bug was one of my pet hates. Im so happy! \o/ Will rebuild with the add on & test again & keep an eye out for any undesirable side effects.
          Hide
          melancholy.lemon Melancholy Lemon added a comment -

          Actually, I was originally working not on this JIRA but on my pet hate which is that avatars dancing on a chim or HUD often get out of sync when camming. That is fixed too (though actually it's possible that Mobius's patch would have fixed that at least partially - I don't usually run 4.1.1 atm so I'm not sure).

          mel

          Show
          melancholy.lemon Melancholy Lemon added a comment - Actually, I was originally working not on this JIRA but on my pet hate which is that avatars dancing on a chim or HUD often get out of sync when camming. That is fixed too (though actually it's possible that Mobius's patch would have fixed that at least partially - I don't usually run 4.1.1 atm so I'm not sure). mel
          Hide
          melancholy.lemon Melancholy Lemon added a comment -

          Grr, found another problem (typo) while re-reviewing my (new) code, which didn't show up in my testing. The effects of this weren't visible in my testing, and I haven't seen any side effects (I'm running with this code in the 4.0.1-based viewer build that I use day-to-day). But still, I'm getting the first frame of the timestep wrong, and the argument to interpolate() will almost certainly be out of range.

          To fix, after patching to the new code, the line

          mPoseBlender.interpolate(mUpdateTime - (mAnimTime - mTimeStep) / mTimeStep);

          in indra/llcharacter/llmotioncontroller.cpp needs to be replaced with

          mPoseBlender.interpolate((mUpdateTime - (mAnimTime - mTimeStep)) / mTimeStep);

          I'll submit an updated patch against Hg over the weekend.

          Sorry 'bout that

          mel

          Show
          melancholy.lemon Melancholy Lemon added a comment - Grr, found another problem (typo) while re-reviewing my (new) code, which didn't show up in my testing. The effects of this weren't visible in my testing, and I haven't seen any side effects (I'm running with this code in the 4.0.1-based viewer build that I use day-to-day). But still, I'm getting the first frame of the timestep wrong, and the argument to interpolate() will almost certainly be out of range. To fix, after patching to the new code, the line mPoseBlender.interpolate(mUpdateTime - (mAnimTime - mTimeStep) / mTimeStep); in indra/llcharacter/llmotioncontroller.cpp needs to be replaced with mPoseBlender.interpolate((mUpdateTime - (mAnimTime - mTimeStep)) / mTimeStep); I'll submit an updated patch against Hg over the weekend. Sorry 'bout that mel
          Hide
          melancholy.lemon Melancholy Lemon added a comment - - edited

          I'm continuing to work on this but it seems silly to submit a new patch every few days so I'll just continue to poke at this - and please feel free to poke me if you want a patch in a hurry

          Current progress:

          I felt guilty about adding an extra call to LLPoseBlender::interpolate() to the timestep code. Even though it's probably barely significant, I don't like making changes that slow the viewer down. So I compensated by replacing an existing call to interpolate() with a new optimised replacement function.

          Also, the long standing problem is that this code is essentially impossible to test - which is why it's remained broken since forever: it typically only gets invoked on avies you can barely see. Up to now, I've mainly been testing it by hacking llvoavatar.cpp to set a fixed timestep for all avies. But that's very tedious to have to recompile the viewer to force a timestep so I finally got round to implementing a debug setting that allows you to easily force all avies to use a particualar timestep. There are lots of subtle edge cases that will always be difficult to test, but at least you can now easily test that timesteps at least vaguely work (and if this test was there before the old code would never have been accepted).

          Also, FWIW, I ended up refactoring this because I couldn't find a smoking gun in the old code - only lots of small things that weren't quite right. I think I have now spotted the smoking gun, but I'm really not that interested in trying to fix fundamentally broken code. If you really want a small change though, I can at least point you in the right direction - otherwise I'll just keep working on my code.

          Show
          melancholy.lemon Melancholy Lemon added a comment - - edited I'm continuing to work on this but it seems silly to submit a new patch every few days so I'll just continue to poke at this - and please feel free to poke me if you want a patch in a hurry Current progress: I felt guilty about adding an extra call to LLPoseBlender::interpolate() to the timestep code. Even though it's probably barely significant, I don't like making changes that slow the viewer down. So I compensated by replacing an existing call to interpolate() with a new optimised replacement function. Also, the long standing problem is that this code is essentially impossible to test - which is why it's remained broken since forever: it typically only gets invoked on avies you can barely see. Up to now, I've mainly been testing it by hacking llvoavatar.cpp to set a fixed timestep for all avies. But that's very tedious to have to recompile the viewer to force a timestep so I finally got round to implementing a debug setting that allows you to easily force all avies to use a particualar timestep. There are lots of subtle edge cases that will always be difficult to test, but at least you can now easily test that timesteps at least vaguely work (and if this test was there before the old code would never have been accepted). Also, FWIW, I ended up refactoring this because I couldn't find a smoking gun in the old code - only lots of small things that weren't quite right. I think I have now spotted the smoking gun, but I'm really not that interested in trying to fix fundamentally broken code. If you really want a small change though, I can at least point you in the right direction - otherwise I'll just keep working on my code.
          Hide
          melancholy.lemon Melancholy Lemon added a comment -

          Hi Whirly - I think I'm pretty much done but just want to do some more testing before I submit the final version of the patch. Any chance this can still make the next release if I'm quick?

          mel

          Show
          melancholy.lemon Melancholy Lemon added a comment - Hi Whirly - I think I'm pretty much done but just want to do some more testing before I submit the final version of the patch. Any chance this can still make the next release if I'm quick? mel
          Hide
          melancholy.lemon Melancholy Lemon added a comment -

          Hi Mobi,

          I've attached llmotioncontroller.final.11-jun.patch

          It's clear that the LL timestep code had never been tested (actually it's clear that it had never been code reivewed either).

          But then testing is hard because mainly it's only used on distant avatars. I wanted to make my code testable so I add two debug settings.

          DebugAnimTimeStep allows for easy testing of the timestep code. When negative (default) you get the normal viewer behaviour but if you set it to a positive value or to zero you force all avies (except your own) to use that timestep. (Your own avie is always immune to timesteps as per the LL code, and zero means no timestep, again as per the LL code – so setting the debug setting to 0 effectively disbles use of timesteps.)

          What this means is that you can set DebugAnimTimeStep to something high (like 1) and really see that smooth interpolation between calculated frames one second apart is happening as you'd expect. You can also set it to more reasonable values, and you should see smooth animation.

          Also, I wanted to be able to convince myself (and others) that I hadn't 'fixed' things simply by inadvertently preventing timesteps from ever being used, hence InterpolateAnimTimeStep. Defaukts to TRUE, but if you set it to false interpolation of timesteps will be disabled - yo uwill only get one avatar update per time step.

          This allows you to see that distant avatars really are using timesteps by default. Note, you need a really busy sim, like London City (busyiest sim on the grid) for timesteps to be long enough for it to be obvious - but at least you can test this.

          mel

          Show
          melancholy.lemon Melancholy Lemon added a comment - Hi Mobi, I've attached llmotioncontroller.final.11-jun.patch It's clear that the LL timestep code had never been tested (actually it's clear that it had never been code reivewed either). But then testing is hard because mainly it's only used on distant avatars. I wanted to make my code testable so I add two debug settings. DebugAnimTimeStep allows for easy testing of the timestep code. When negative (default) you get the normal viewer behaviour but if you set it to a positive value or to zero you force all avies (except your own) to use that timestep. (Your own avie is always immune to timesteps as per the LL code, and zero means no timestep, again as per the LL code – so setting the debug setting to 0 effectively disbles use of timesteps.) What this means is that you can set DebugAnimTimeStep to something high (like 1) and really see that smooth interpolation between calculated frames one second apart is happening as you'd expect. You can also set it to more reasonable values, and you should see smooth animation. Also, I wanted to be able to convince myself (and others) that I hadn't 'fixed' things simply by inadvertently preventing timesteps from ever being used, hence InterpolateAnimTimeStep. Defaukts to TRUE, but if you set it to false interpolation of timesteps will be disabled - yo uwill only get one avatar update per time step. This allows you to see that distant avatars really are using timesteps by default. Note, you need a really busy sim, like London City (busyiest sim on the grid) for timesteps to be long enough for it to be obvious - but at least you can test this. mel
          Hide
          mobius Mobius Ryba added a comment -

          Assumption that animations are never synchronized on timestamps needs checking
          Need to test multiple avs playing synchronised anims: thriller dance ball thingy etc

          Show
          mobius Mobius Ryba added a comment - Assumption that animations are never synchronized on timestamps needs checking Need to test multiple avs playing synchronised anims: thriller dance ball thingy etc
          Hide
          melancholy.lemon Melancholy Lemon added a comment - - edited

          If you're talking about the comments in LLMotionController::setTimeStep() I think maybe I didn't express myself clearly.

          The point is that the timestep code isn't normally used - it's only used for avatars that are far away. In the normal case, when there is no timestep, the animation code is simply called when its called.

          When we have a timestep, all I do is call the animation code with the value of mAnimTime I want to animate to (which is all that happens in the normal case). This is the same animation code that normally runs, I'm just calling it for a different time.

          For some reason, the old code inexplicably decided to round off things like the start time and stop time to multiples of the time step, but this basically achieves nothing and makes no sense. The animation code has no such requirements as it clearly works fine in the absense of any time step. Besides, given this will potentially be called repeatedly with different timestep values each time, this just leads to increasing errors in the values of the start and stop time.

          Does that explanation make more sense?

          Show
          melancholy.lemon Melancholy Lemon added a comment - - edited If you're talking about the comments in LLMotionController::setTimeStep() I think maybe I didn't express myself clearly. The point is that the timestep code isn't normally used - it's only used for avatars that are far away. In the normal case, when there is no timestep, the animation code is simply called when its called. When we have a timestep, all I do is call the animation code with the value of mAnimTime I want to animate to (which is all that happens in the normal case). This is the same animation code that normally runs, I'm just calling it for a different time. For some reason, the old code inexplicably decided to round off things like the start time and stop time to multiples of the time step, but this basically achieves nothing and makes no sense. The animation code has no such requirements as it clearly works fine in the absense of any time step. Besides, given this will potentially be called repeatedly with different timestep values each time, this just leads to increasing errors in the values of the start and stop time. Does that explanation make more sense?
          Hide
          melancholy.lemon Melancholy Lemon added a comment -

          As for avatar synchronisation, I tested that fairly extensively, but by all means test again

          Show
          melancholy.lemon Melancholy Lemon added a comment - As for avatar synchronisation, I tested that fairly extensively, but by all means test again
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Note: The first fix for this at rev 27047 (http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/c91ab2b22a29) is getting backed out for the 4.1.1 release.

          It was found to be the cause of FIRE-6839

          Can you check if your fix also produces the issue in FIRE-6839 Mel?

          Show
          whirly.fizzle Whirly Fizzle added a comment - Note: The first fix for this at rev 27047 ( http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/c91ab2b22a29 ) is getting backed out for the 4.1.1 release. It was found to be the cause of FIRE-6839 Can you check if your fix also produces the issue in FIRE-6839 Mel?
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Further info from testing the issue in FIRE-6839:

          Steps to repro it running a build containing rev 27047:

          • Work together with a testing partner
          • Stand facing each other and both do some shouting (make sure "Play avatar animations such as shouting" is ticked under Prefs -> Chat -> General)
          • Observe you see each others avatars play the shouting animation and mouths return to normal
          • Now, walk some distance away from each other and stand facing away from each other, and again, do some shouting
          • Walk back to each other and observe you see the other avatars mouth stuck in the shout animation, but your own avatar looks correct on your screen
          • Note: We had some strange results here sometimes. I was testing with Lassie. He would always see me stuck in a shouting animation, but at first, I didnt see him stuck shouting. I had to TP to another region and back and then I could reproduce as above. (Really not sure why this was. Lassie could repro right from login. I couldnt. I had to leave the region and come back. But once I did this, the repro was 100% of the time)
          • Now, when you see your testing partner stuck with a shoutmouth, doing the following will fix it
          • Setting draw distance to zero and back
          • Flying up to 1000ish metres and back down
          • Clearing visible cache (using one of the scripted gadgets you sit on that shoots you to high altitude and back down)
          • TPing to another region and back (this one only worked sometimes)
          • Running a build with rev 27047 backed out, observe that when you have both shouted while facing away from each other, if you cam on your testing partner, you will see them stuck in shoutmouth until you are facing each other. Once you face each other, the shoutmouth instantly goes away.
          Show
          whirly.fizzle Whirly Fizzle added a comment - Further info from testing the issue in FIRE-6839 : Steps to repro it running a build containing rev 27047: Work together with a testing partner Stand facing each other and both do some shouting (make sure "Play avatar animations such as shouting" is ticked under Prefs -> Chat -> General) Observe you see each others avatars play the shouting animation and mouths return to normal Now, walk some distance away from each other and stand facing away from each other, and again, do some shouting Walk back to each other and observe you see the other avatars mouth stuck in the shout animation, but your own avatar looks correct on your screen Note: We had some strange results here sometimes. I was testing with Lassie. He would always see me stuck in a shouting animation, but at first, I didnt see him stuck shouting. I had to TP to another region and back and then I could reproduce as above. (Really not sure why this was. Lassie could repro right from login. I couldnt. I had to leave the region and come back. But once I did this, the repro was 100% of the time) Now, when you see your testing partner stuck with a shoutmouth, doing the following will fix it Setting draw distance to zero and back Flying up to 1000ish metres and back down Clearing visible cache (using one of the scripted gadgets you sit on that shoots you to high altitude and back down) TPing to another region and back (this one only worked sometimes) Running a build with rev 27047 backed out, observe that when you have both shouted while facing away from each other, if you cam on your testing partner, you will see them stuck in shoutmouth until you are facing each other. Once you face each other, the shoutmouth instantly goes away.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Note: rev 27047 (http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/c91ab2b22a29) will need a backout of default branch

          Show
          whirly.fizzle Whirly Fizzle added a comment - Note: rev 27047 ( http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/c91ab2b22a29 ) will need a backout of default branch
          Hide
          melancholy.lemon Melancholy Lemon added a comment - - edited

          FWIW, my patch actually does back out 27047, although it ends up achieving something similar in a slightly different way.

          I can kinda see how the test scenario relates to 27047, since the code patched there is only triggered for avatars that are not visible and for imposters - which explains why you need to turn away from each other to repro.

          But I can't quite see why it would cause that - I fear we might be triggering another bug in the animation code which was previously hidden by the broken handling of avatars that are off-cam. (In which case chances are my patch will have the same effect.)

          Sorry, will not have time to test this weekend, though - RL stuff.

          Show
          melancholy.lemon Melancholy Lemon added a comment - - edited FWIW, my patch actually does back out 27047, although it ends up achieving something similar in a slightly different way. I can kinda see how the test scenario relates to 27047, since the code patched there is only triggered for avatars that are not visible and for imposters - which explains why you need to turn away from each other to repro. But I can't quite see why it would cause that - I fear we might be triggering another bug in the animation code which was previously hidden by the broken handling of avatars that are off-cam. (In which case chances are my patch will have the same effect.) Sorry, will not have time to test this weekend, though - RL stuff.
          Hide
          melancholy.lemon Melancholy Lemon added a comment - - edited

          For the benefit of anyone else who has the time/inclination to test, I've uploaded llmotioncontroller.final.final.13-jul.patch

          This is the same as the previous 'final' patch but modified to apply cleanly to a build that has had 27047 reverted.

          If that doesn't apply cleanly, let me know what branch you're applying to and I'll fix.

          mel

          Show
          melancholy.lemon Melancholy Lemon added a comment - - edited For the benefit of anyone else who has the time/inclination to test, I've uploaded llmotioncontroller.final.final.13-jul.patch This is the same as the previous 'final' patch but modified to apply cleanly to a build that has had 27047 reverted. If that doesn't apply cleanly, let me know what branch you're applying to and I'll fix. mel
          Hide
          whirly.fizzle Whirly Fizzle added a comment - - edited

          Heya Mel,

          The patch doesnt apply cleanly to default branch (I guess because 27047 isnt backed out yet on default branch)

          Applying to 28764:
          C:\phoenix-firestorm-lgpl>hg import --no-commit llmotioncontroller.final.final.13-jul.patch
          applying llmotioncontroller.final.final.13-jul.patch
          patching file indra/llcharacter/llmotioncontroller.cpp
          Hunk #7 FAILED at 967
          1 out of 7 hunks FAILED – saving rejects to file indra/llcharacter/llmotioncontroller.cpp.rej
          patching file indra/newview/app_settings/settings.xml
          Hunk #1 FAILED at 17410
          1 out of 1 hunks FAILED – saving rejects to file indra/newview/app_settings/settings.xml.rej
          abort: patch failed to apply

          All work is being done on default branch now.

          Show
          whirly.fizzle Whirly Fizzle added a comment - - edited Heya Mel, The patch doesnt apply cleanly to default branch (I guess because 27047 isnt backed out yet on default branch) Applying to 28764: C:\phoenix-firestorm-lgpl>hg import --no-commit llmotioncontroller.final.final.13-jul.patch applying llmotioncontroller.final.final.13-jul.patch patching file indra/llcharacter/llmotioncontroller.cpp Hunk #7 FAILED at 967 1 out of 7 hunks FAILED – saving rejects to file indra/llcharacter/llmotioncontroller.cpp.rej patching file indra/newview/app_settings/settings.xml Hunk #1 FAILED at 17410 1 out of 1 hunks FAILED – saving rejects to file indra/newview/app_settings/settings.xml.rej abort: patch failed to apply All work is being done on default branch now.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Note again: rev 27047 (http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/c91ab2b22a29) will need a backout of 4.2.0 default branch

          Show
          whirly.fizzle Whirly Fizzle added a comment - Note again: rev 27047 ( http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/c91ab2b22a29 ) will need a backout of 4.2.0 default branch
          Hide
          melancholy.lemon Melancholy Lemon added a comment -

          Sorry, Whirly, been busy

          Not forgotten this though

          mel

          Show
          melancholy.lemon Melancholy Lemon added a comment - Sorry, Whirly, been busy Not forgotten this though mel
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          No worries Mel!

          Show
          whirly.fizzle Whirly Fizzle added a comment - No worries Mel!
          Hide
          spiritlapis Spirit Lapis added a comment -

          Happening still in: Firestorm 4.3.0 (30600) Oct 11 2012 03:24:02 (Firestorm-private-devW7x64)

          setup details....

          Firestorm 4.3.0 (30600) Oct 11 2012 03:24:02 (Firestorm-private-devW7x64)
          Release Notes

          You are at 230,776.0, 242,832.0, 753.3 in Remembrance located at sim6436.agni.lindenlab.com (216.82.11.7:13005)
          Second Life Server 12.10.08.265664

          CPU: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz (2294.81 MHz)
          Memory: 3994 MB
          OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601)
          Graphics Card Vendor: NVIDIA Corporation
          Graphics Card: GeForce GT 630M/PCIe/SSE2

          Windows Graphics Driver Version: 8.15.0010.2712
          OpenGL Version: 4.2.0

          RestrainedLove API: RLV v2.7.0 / RLVa v1.4.7a
          libcurl Version: libcurl/7.21.1 OpenSSL/1.0.0d zlib/1.2.5 c-ares/1.7.1
          J2C Decoder Version: KDU
          Audio Driver Version: FMOD version 3.750000
          Qt Webkit Version: 4.7.1 (version number hard-coded)
          Voice Server Version: Vivox 2.1.3010.6270

          Settings mode: Firestorm
          Viewer Skin: firestorm (grey)
          Font Used: Deja Vu (96)
          Draw distance: 96
          Bandwidth: 500
          LOD factor: 4
          Built with MSVC version 1600
          Packets Lost: 50/213,885 (0.0%)

          Show
          spiritlapis Spirit Lapis added a comment - Happening still in: Firestorm 4.3.0 (30600) Oct 11 2012 03:24:02 (Firestorm-private-devW7x64) setup details.... Firestorm 4.3.0 (30600) Oct 11 2012 03:24:02 (Firestorm-private-devW7x64) Release Notes You are at 230,776.0, 242,832.0, 753.3 in Remembrance located at sim6436.agni.lindenlab.com (216.82.11.7:13005) Second Life Server 12.10.08.265664 CPU: Intel(R) Core(TM) i3-2350M CPU @ 2.30GHz (2294.81 MHz) Memory: 3994 MB OS Version: Microsoft Windows 7 64-bit Service Pack 1 (Build 7601) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce GT 630M/PCIe/SSE2 Windows Graphics Driver Version: 8.15.0010.2712 OpenGL Version: 4.2.0 RestrainedLove API: RLV v2.7.0 / RLVa v1.4.7a libcurl Version: libcurl/7.21.1 OpenSSL/1.0.0d zlib/1.2.5 c-ares/1.7.1 J2C Decoder Version: KDU Audio Driver Version: FMOD version 3.750000 Qt Webkit Version: 4.7.1 (version number hard-coded) Voice Server Version: Vivox 2.1.3010.6270 Settings mode: Firestorm Viewer Skin: firestorm (grey) Font Used: Deja Vu (96) Draw distance: 96 Bandwidth: 500 LOD factor: 4 Built with MSVC version 1600 Packets Lost: 50/213,885 (0.0%)
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Heya Spirit,

          The patch isnt in the repository yet so you will still be seeing this behaviour.
          Once this issue is marked Resolved -> fixed then the fix will be in the repository to test.

          Show
          whirly.fizzle Whirly Fizzle added a comment - Heya Spirit, The patch isnt in the repository yet so you will still be seeing this behaviour. Once this issue is marked Resolved -> fixed then the fix will be in the repository to test.
          Hide
          hugsalot HUGSaLOT Valkyrie added a comment -

          I'm currently seeing this on 4.4.0.33674 while this doesn't really bother me, I recall we smoke-tested a fix on this subject some time ago. This issue seems to reoccur every time the dev team re-merges LL's code with Firestorm's code.

          Show
          hugsalot HUGSaLOT Valkyrie added a comment - I'm currently seeing this on 4.4.0.33674 while this doesn't really bother me, I recall we smoke-tested a fix on this subject some time ago. This issue seems to reoccur every time the dev team re-merges LL's code with Firestorm's code.
          Hide
          ansariel.hiller Ansariel Hiller added a comment -

          The fix has been backed out because it was bugged.

          Show
          ansariel.hiller Ansariel Hiller added a comment - The fix has been backed out because it was bugged.
          Hide
          ziree Zi Ree added a comment -

          What's keeping us from removing / disabling the timestep thing altogether? It's not doing what it's supposed to do anyway, and in a quick test I see no problems without timesteps at all.

          Show
          ziree Zi Ree added a comment - What's keeping us from removing / disabling the timestep thing altogether? It's not doing what it's supposed to do anyway, and in a quick test I see no problems without timesteps at all.
          Hide
          ziree Zi Ree added a comment -

          http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/341612f0cb47

          Added experimental debug setting to test disabling timesteps entirely.

          Show
          ziree Zi Ree added a comment - http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/341612f0cb47 Added experimental debug setting to test disabling timesteps entirely.
          Hide
          greatfox snowpaw Futashy added a comment -

          With my testing of this so far, it looks good. Animations play at their proper speed from all distances, and I haven't seen any ill side effects yet.

          Show
          greatfox snowpaw Futashy added a comment - With my testing of this so far, it looks good. Animations play at their proper speed from all distances, and I haven't seen any ill side effects yet.
          Hide
          eve.greymoon Eve Greymoon added a comment -

          I'm having this issue since I installed the new viewer, doesn't matter whether avatar imposters is checked or not.

          Firestorm 4.6.5 (40833) May 5 2014 06:27:24 (Firestorm-Releasex64) with OpenSimulator support
          Release Notes

          You are at 195.4, 80.7, 22.2 in Breakwater Beach located at sim8972.agni.lindenlab.com (216.82.41.148:13023)
          SLURL: http://maps.secondlife.com/secondlife/Breakwater%20Beach/195/81/22
          (global coordinates 133,315.0, 398,161.0, 22.2)
          Second Life Server 14.05.09.289913
          Release Notes

          CPU: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz (3201.92 MHz)
          Memory: 16327 MB
          OS Version: Microsoft Windows 8 64-bit (Build 9200)
          Graphics Card Vendor: NVIDIA Corporation
          Graphics Card: GeForce GTX 780/PCIe/SSE2

          Windows Graphics Driver Version: 9.18.0013.3750
          OpenGL Version: 4.4.0

          RestrainedLove API: RLV v2.8.0 / RLVa v1.4.10a
          libcurl Version: libcurl/7.24.0 OpenSSL/1.0.1g zlib/1.2.6 c-ares/1.10.0
          J2C Decoder Version: KDU v7.3.2
          Audio Driver Version: FMOD Ex 4.44.32
          Qt Webkit Version: 4.7.1 (version number hard-coded)
          Voice Server Version: Not Connected
          Settings mode: Viewer 3
          Viewer Skin: Starlight (Silver Pink)
          Font Used: Deja Vu (96)
          Draw distance: 168
          Bandwidth: 1100
          LOD factor: 3
          Render quality: High (5/7)
          Texture memory: 512 MB (1)
          Built with MSVC version 1600
          Packets Lost: 180/190,014 (0.1%)

          Show
          eve.greymoon Eve Greymoon added a comment - I'm having this issue since I installed the new viewer, doesn't matter whether avatar imposters is checked or not. Firestorm 4.6.5 (40833) May 5 2014 06:27:24 (Firestorm-Releasex64) with OpenSimulator support Release Notes You are at 195.4, 80.7, 22.2 in Breakwater Beach located at sim8972.agni.lindenlab.com (216.82.41.148:13023) SLURL: http://maps.secondlife.com/secondlife/Breakwater%20Beach/195/81/22 (global coordinates 133,315.0, 398,161.0, 22.2) Second Life Server 14.05.09.289913 Release Notes CPU: Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz (3201.92 MHz) Memory: 16327 MB OS Version: Microsoft Windows 8 64-bit (Build 9200) Graphics Card Vendor: NVIDIA Corporation Graphics Card: GeForce GTX 780/PCIe/SSE2 Windows Graphics Driver Version: 9.18.0013.3750 OpenGL Version: 4.4.0 RestrainedLove API: RLV v2.8.0 / RLVa v1.4.10a libcurl Version: libcurl/7.24.0 OpenSSL/1.0.1g zlib/1.2.6 c-ares/1.10.0 J2C Decoder Version: KDU v7.3.2 Audio Driver Version: FMOD Ex 4.44.32 Qt Webkit Version: 4.7.1 (version number hard-coded) Voice Server Version: Not Connected Settings mode: Viewer 3 Viewer Skin: Starlight (Silver Pink) Font Used: Deja Vu (96) Draw distance: 168 Bandwidth: 1100 LOD factor: 3 Render quality: High (5/7) Texture memory: 512 MB (1) Built with MSVC version 1600 Packets Lost: 180/190,014 (0.1%)
          Hide
          Immor Frek Bauman added a comment -

          That experimental debug setting sounds good. Where do i get it?

          Show
          Immor Frek Bauman added a comment - That experimental debug setting sounds good. Where do i get it?
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Frek, would you like to try a test build of Firestorm containing this fix?
          If so, please let me know in a comment here and also give your operating system and if Windows or Linux, whether it is 32 or 64bit.

          Show
          whirly.fizzle Whirly Fizzle added a comment - Frek, would you like to try a test build of Firestorm containing this fix? If so, please let me know in a comment here and also give your operating system and if Windows or Linux, whether it is 32 or 64bit.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Leaving this as 4.6.6 for triage - it would be nice to get Zi's fix in for release - maybe default it to off until we are more sure of possible side effects.

          Show
          whirly.fizzle Whirly Fizzle added a comment - Leaving this as 4.6.6 for triage - it would be nice to get Zi's fix in for release - maybe default it to off until we are more sure of possible side effects.
          Hide
          Immor Frek Bauman added a comment -

          I may be a bit late, but i'd be happy to use that build as main viewer because it still is an annoying issue.
          My OS: Windows 7, 64bit

          Going to check back more often now, sorry about that.

          Show
          Immor Frek Bauman added a comment - I may be a bit late, but i'd be happy to use that build as main viewer because it still is an annoying issue. My OS: Windows 7, 64bit Going to check back more often now, sorry about that.
          Hide
          panterapolnocy Pantera Północy added a comment -

          Changing UseAnimationTimeSteps to FALSE by default and exposing it in Prefs -> Advanced in rev. 42359: http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/a4fb93022670 - as requested.

          Show
          panterapolnocy Pantera Północy added a comment - Changing UseAnimationTimeSteps to FALSE by default and exposing it in Prefs -> Advanced in rev. 42359: http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/a4fb93022670 - as requested.
          Hide
          Immor Frek Bauman added a comment -

          Sounds good, thanks.

          Show
          Immor Frek Bauman added a comment - Sounds good, thanks.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Testing on Firestorm 4.6.6 (42364) Jul 11 2014 23:43:08 (Firestorm-FizzlefireAVX) with OpenSimulator support

          • On default settings, UseAnimationTimeSteps is FALSE - so Zi's fix is enabled by default currently.
          • When UseAnimationTimeSteps is FALSE
            • When Avatar Imposters are enabled, distant avatars animate at the correct speed.
            • When Avatar Imposters are disabled, distant avatars animate at the correct speed.
          • When UseAnimationTimeSteps is TRUE (old buggy behaviour)
            • When Avatar Imposters are enabled, distant avatars animate slightly too quickly.
            • When Avatar Imposters are disabled, distant avatars animate much too quickly.

          So for the next release, we will have "Enable the use of animation timesteps (experimental)" disabled under Preferences -> Advanced, so everyone will be using the fix by default.

          Show
          whirly.fizzle Whirly Fizzle added a comment - Testing on Firestorm 4.6.6 (42364) Jul 11 2014 23:43:08 (Firestorm-FizzlefireAVX) with OpenSimulator support On default settings, UseAnimationTimeSteps is FALSE - so Zi's fix is enabled by default currently. When UseAnimationTimeSteps is FALSE When Avatar Imposters are enabled, distant avatars animate at the correct speed. When Avatar Imposters are disabled, distant avatars animate at the correct speed. When UseAnimationTimeSteps is TRUE (old buggy behaviour) When Avatar Imposters are enabled, distant avatars animate slightly too quickly. When Avatar Imposters are disabled, distant avatars animate much too quickly. So for the next release, we will have "Enable the use of animation timesteps (experimental)" disabled under Preferences -> Advanced, so everyone will be using the fix by default.
          Hide
          whirly.fizzle Whirly Fizzle added a comment -

          Resolving this issue to go to QA.
          Fix looks good and we have a preferences option to revert back to old behaviour if side effects arise on release.

          Show
          whirly.fizzle Whirly Fizzle added a comment - Resolving this issue to go to QA. Fix looks good and we have a preferences option to revert back to old behaviour if side effects arise on release.

            People

            • Assignee:
              panterapolnocy Pantera Północy
              Reporter:
              zeruel Chase Dailey
            • Votes:
              4 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: