Search Unity

  1. Check out the Unite LA keynote for updates on the Visual Effect Editor, the FPS Sample, ECS, Unity for Film and more! Watch it now!
    Dismiss Notice
  2. The Unity Pro & Visual Studio Professional Bundle gives you the tools you need to develop faster & collaborate more efficiently. Learn more.
    Dismiss Notice
  3. Improved Prefab workflow (includes Nested Prefabs!), 2D isometric Tilemap and more! Get the 2018.3 Beta now.
    Dismiss Notice
  4. Improve your Unity skills with a certified instructor in a private, interactive classroom. Watch the overview now.
    Dismiss Notice
  5. Want to see the most recent patch releases? Take a peek at the patch release page.
    Dismiss Notice

linear movement stuttering

Discussion in 'Editor & General Support' started by Demion, Jul 7, 2012.

  1. Demion

    Demion

    Joined:
    Jul 7, 2012
    Posts:
    13
    Hi.

    I have problem with orthographic (2d) linear movement. Square (cube) is stuttering sometimes. Code is simple as that -
    Code (csharp):
    1.  
    2. void Update()
    3. {
    4.   transform.Translate(Input.GetAxisRaw("Horizontal") * 4 * Time.deltaTime, 0, 0);
    5. }
    It is stuttering just awful in game preview. In standalone / web player it is much better but still noticeably. Bigger fps helps but with vsync (60 fps) still stuttering. I`ve seen related threads but no solution.

    Thanks in advance.
     
    Last edited: Jul 7, 2012
  2. vladk

    vladk

    Joined:
    Jul 10, 2008
    Posts:
    153
    try using Lerp instead of Translate.
     
  3. Demion

    Demion

    Joined:
    Jul 7, 2012
    Posts:
    13
    Code (csharp):
    1. Vector3 target;
    2.        
    3. target = transform.position + new Vector3(Input.GetAxisRaw("Horizontal") * 4 * Time.deltaTime, 0, 0);
    4.  
    5. transform.position = Vector3.Lerp(transform.position, target, 1);
    Tried something like this. Same stuttering not perfect smooth linear movement.
     
  4. vladk

    vladk

    Joined:
    Jul 10, 2008
    Posts:
    153
    do you have camera hardly attached to your moving object or is it being controlled by another script?
     
  5. Demion

    Demion

    Joined:
    Jul 7, 2012
    Posts:
    13
    Camera is not moving at all.
     
  6. vladk

    vladk

    Joined:
    Jul 10, 2008
    Posts:
    153
    All I can say - try to make it not in the "Update", but in "FixedUpdate" and make it not "4", but "4f" so it's definitely a floating point value.

    P.S. Is this stuttering like a lot, or does it make a little "lag" from time to time?
     
  7. Demion

    Demion

    Joined:
    Jul 7, 2012
    Posts:
    13
    It makes a little "lag" from time to time just as you described. But it "lags" more in game view mode than in release (standalone / web player). And I cant notice any stuttering when 200+ fps (without vsync)
     
    Last edited: Jul 7, 2012
  8. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    31,873
    No, FixedUpdate is for applying physics forces, and certainly wouldn't help with stuttering, it would make in worse in fact since the physics framerate won't match the display framerate.

    That won't actually make any difference since the result is a float regardless.

    --Eric
     
  9. vladk

    vladk

    Joined:
    Jul 10, 2008
    Posts:
    153
    don't go hard on me mate, there were my ideas of despair :)
     
  10. Demion

    Demion

    Joined:
    Jul 7, 2012
    Posts:
    13
    Thank you for your answers. Have you any idea what is the reason of stuttering or in other words a little "lag" from time to time?
     
  11. vladk

    vladk

    Joined:
    Jul 10, 2008
    Posts:
    153
    my call - either unity fails to process the keyboard input correctly or it's just an OS (or even keyboard) that doesn't give a smooth key-repeating.

    P.S. On the other hand it maybe a rendering problem...
     
  12. Demion

    Demion

    Joined:
    Jul 7, 2012
    Posts:
    13
    I`ve remade input system with Input.GetKeyDown / Input.GetKeyUp and it works perfectly according to Debug.Log. Stuttering still exists. Looking for any solution. Thanks in advance.
     
  13. markTheDesigner

    markTheDesigner

    Joined:
    Sep 12, 2009
    Posts:
    14
    Check your drawcalls. This happened to me and my drawcalls were 70+. I'm prototyping so I have lots of bits floating around, I got my drawcalls down to 20 and the stuttering went away.
     
  14. Demion

    Demion

    Joined:
    Jul 7, 2012
    Posts:
    13
    I use clear project with orthographic camera and cube with script (only Update function). So "Stats" shows me only 1 draw call.
     
  15. markTheDesigner

    markTheDesigner

    Joined:
    Sep 12, 2009
    Posts:
    14
    Ok, only other thing I can suggest is that you print out some debug info and see the vectors/floats you are using and see if they are to blame. Print to the log if they are changing too quickly.
     
  16. Ippokratis

    Ippokratis

    Joined:
    Oct 13, 2008
    Posts:
    1,485
    One possible reason is a performance spike.
    Many little things can cause it and it is difficult to spot them without access to the project.
    From your description, the most probable is that you are not using a rigidbody with isKinematic checked, but there are many other possible causes.
    Also, other tasks computer performs at the same time (e.g. other programs activity) can create this behavior.
    Maybe you can upload a minimal scene that reproduces the described behavior.
    Kind regards,
    -Ippokratis
     
  17. Demion

    Demion

    Joined:
    Jul 7, 2012
    Posts:
    13
    Hi. Thanks again for answers.
    Firstly I thought that problem is in my hardware / software, but then I asked some friends to test on their computer and some of them also notice that "lag". To notice it you should watch carefully. For example, launch standalone with 1920 x 1080 resolution and move square to left side. Then hold "right" and let square move to opposite side. At 1080 pixels it "lags" 1 or 2 times. By "lag" or stuttering I mean it jumps some pixels back and then moves normally again. With high fps (200 or more without VSync) it is not noticeable.
    Here I attach clear project with problem as asked.

    https://dl.dropbox.com/u/59043948/test.zip
     
  18. Ippokratis

    Ippokratis

    Joined:
    Oct 13, 2008
    Posts:
    1,485
    Hi,
    I have tried for ~40 minutes, the stuttering motion remains despite using many approaches.
    Anybody else wanna try ?
     
  19. Demion

    Demion

    Joined:
    Jul 7, 2012
    Posts:
    13
    Could it be possibly related with coordinate calculation? Maybe processor fails with rounding coordinates some times?
     
    Last edited: Jul 8, 2012
  20. Demion

    Demion

    Joined:
    Jul 7, 2012
    Posts:
    13
    Last edited: Jul 9, 2012
  21. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    23,579
    Got profiler stats?
     
  22. Demion

    Demion

    Joined:
    Jul 7, 2012
    Posts:
    13
    I guess its pro only? Could you please check project attached some posts ago?
     
  23. Demion

    Demion

    Joined:
    Jul 7, 2012
    Posts:
    13
    Any help?
     
  24. Tbug

    Tbug

    Joined:
    Jul 10, 2012
    Posts:
    3
    HI,

    I have the same probleme with the free version, i tried some Transform and physics move method, but i think a part of the answers is in your previous link , the problem is link with the Time.deltatime and the computer activity, but I don't know how to reduce this lag effect.
     
  25. EvilNoodle

    EvilNoodle

    Joined:
    Nov 17, 2011
    Posts:
    26
    Hey

    If what you are seeing is a stutter like it is dropping a couple of frames on a regular pattern of every 1 to 2 seconds then I had this exact same problem.

    I had a movement judder every one to two seconds with just a cube moving in front of a static orthographic camera. I was scaling movement by delta time and also tried both the update and fixed updates, direct transform manipulation, physics movement etc. At one point I got so frustrated I made my own timer based on calculating the system up time manually, calculated frame time from that and scaled accordingly but yet the problem persisted.

    I abandoned work on my project and loaded up the Angry Bots demo. I had to take out the rain effects and a bunch more atmospheric stuff to see it but once the distractions were gone there it was - the dreaded stutter!

    This problem drove me nuts over about four weeks and even pushed me to re-install Windows to see if that was the issue! - NO JOY!

    I tried switching engines to see if it was Unity specific or a system level issue and noted that the same thing was happening with the JMonkey engine beta so I started looking at the rest of the system to try and identify the cause.

    In the end I traced it back to what appeared to be a discrepancy in the reported refresh rate for my monitor (dell 27").

    Windows was reporting it as 59 hertz while the NVIDIA control panel was reporting it as 60. I figured competing refresh rates could possibly introduce some kind of jitter especially as my jitter was about once every second or so. To test I manually set up a new custom profile for the monitor in the NVIDIA control panel at 59Hz to match the windows value and the problem suddenly vanished and has not returned since.

    I have no idea if this is what is happening to you and it is possible that this refresh discrepancy has absolutely nothing to do with it and it just fixed itself but if you have an NVIDIA card it might be worth trying this as it seemed to fix it for me! Now the NVIDIA control panel still reports 60Hz but the stuttering is gone.

    I really hope this helps but if not I would recommend checking out the angry bots project and disabling the rain etc (I manually switched the renderers off in the inspector during play mode) to see if it is happening there or is specific to your project and perhaps grabbing a copy of JMonkey or another engine and seeing if you get a similar jitter before treating it as a Unity specific issue.

    Regards

    EvilNoodle
     
    CarterG81 likes this.
  26. EvilNoodle

    EvilNoodle

    Joined:
    Nov 17, 2011
    Posts:
    26
    Following on from my last post I just downloaded your test project and checked it at 2560*1440 with visuals set to fantastic and from a build it is as smooth as silk. A slight judder is present in the editor but it is irregular and I find things run a little slower in the editor in general.

    EvilNoodle
     
    Last edited: Jul 11, 2012
  27. Demion

    Demion

    Joined:
    Jul 7, 2012
    Posts:
    13
    Thank you very much, EvilNoodle. Seems like setting 60 hertz (was 59 previous) in windows settings really helped.
     
    Last edited: Jul 11, 2012
  28. EvilNoodle

    EvilNoodle

    Joined:
    Nov 17, 2011
    Posts:
    26
    No problem, really glad it helped!

    This problem drove me nuts!

    Of course you will need to remember to inform your users somehow to do the same if they see a similar juddering in your end product so they don't think it is shoddy workmanship on your part.

    Happy coding

    EvilNoodle
     
  29. maxamundo

    maxamundo

    Joined:
    May 29, 2013
    Posts:
    1
    I had the juddering movement described here. The cause in my case was I moved the camera based on the player x position, so the camera moved a fraction after the player causing a flicker. If I put the camera as a child of the player the camera moved up and down with the jumping, I couldnt work out how to restrict child object movement in the y-axis. There is no flicker when the camera is a child of the player. So I guess the gameObject update() transform.position method works different than a child object.
    So I have made the camera only move when the player moves near the screen edges.

    hope this helps.
     
  30. StKiller

    StKiller

    Joined:
    Oct 23, 2014
    Posts:
    1
    So, after a half a week of researching, playing with displays' frequency (I have two, they run at most 60 Hz), trying all kind of stuff:
    http://answers.unity3d.com/questions/275016/updatefixedupdate-motion-stutter-not-another-novic.html
    http://forum.unity3d.com/threads/smoothmovementtest-should-help-eliminating-hiccup-sources.162694/

    I finally found solution for my issue on this thread, unrelated to Unity3d:
    http://www.tomshardware.co.uk/forum/386158-33-setup-rhythmic-stutter-vsync-enabled

    So, basically, f.lux application interferres somehow with the vsync. When I completelly close it - no more stuttering!
     
    Soilyman likes this.
  31. jasonthefish

    jasonthefish

    Joined:
    Jan 18, 2015
    Posts:
    5
    OMG @StKiller thank you so much for this tip. The stuttering in my game was driving me crazy, and closing f.lux completely fixes it. Thank you very much for posting the tip here!
     
  32. snlehton

    snlehton

    Joined:
    Jun 11, 2010
    Posts:
    95
    Hi,

    I was struggling with this same issue. About to shoot some clips for a game trailer with these settings: vblank on, 1280x720 fullscreen and 60 fps target.

    The framerate was just horrible: running 60 fps but constant jittering:

    upload_2015-4-22_12-11-11.png

    Then I tried without vblank but forced vsync on from NVIDIA panel (together with triple buffering). Jittering was still very noticeable. However, the profiler looked like this -- so in engine's perspective it was running smoothly.

    upload_2015-4-22_12-13-55.png

    Then I enabled the DX9/DX11 excluse mode and BOOM. All problems solved. The game was running super smooth (still with some super rare jittering, probably due to some loading/instancing etc):

    upload_2015-4-22_12-21-51.png

    upload_2015-4-22_12-18-13.png

    The warning you get is right. Alt-tabing away from the app made it stop responding.

    BTW I'm using MSI Afterburner to record the footage. The codec I'm using is NVIDIA's nvenc:

    upload_2015-4-22_13-9-4.png

    This allows me to capture 60 FPS videos in H.264 format (AVCHD, and only MKV is supported). We needed to re-encode the videos to proper h.264 format using VirtualDub in order to bring them into After Effects. But that is problem with AE not supporting the MKV/AVCHD. Otherwise the videos work just fine in Mediaplayer etc.

    Hope this helps someone...
     
  33. Hiti3

    Hiti3

    Joined:
    Jul 16, 2015
    Posts:
    7
    What about andoid / ios??? How to turn DX9/DX11 settings?
     
  34. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    31,873
    Only Windows uses DX9 or DX11; all other platforms use some kind of OpenGL or custom API.

    --Eric
     
  35. snlehton

    snlehton

    Joined:
    Jun 11, 2010
    Posts:
    95
    In the end we ended up doing frame by frame capture to PNG on disk and then stitch them to lightly compressed AVI's using VirtualDub and Lagarith codec. This was needed to get perfect, stutter-free 60fps FullHD video for our Greenlight trailer.

    On iOS/Android, I would use something like Elgato HD60: https://www.elgato.com/en/gaming/game-capture-hd60 or fake the video by capturing Unity standalone build (maybe with the same trick we did above)
     
  36. gsus725

    gsus725

    Joined:
    Aug 23, 2010
    Posts:
    250
    This happens to everyone but most people can't see it. I made an empty scene with a simple moving cube using the same code you gave and it still stutters in Windows Standalone. It's awful and only Unity has this problem. "Editor Stutter" is normal but we aren't talking about that.
     
  37. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    31,873
    It doesn't happen to everyone, and "most people can't see it" makes no sense.

    --Eric
     
  38. gsus725

    gsus725

    Joined:
    Aug 23, 2010
    Posts:
    250
    You can keep denying it or you can realize there are hundreds of people saying this is happening year after year
     
  39. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    31,873
    The denial here is on your part.

    --Eric
     
  40. stevensrmiller

    stevensrmiller

    Joined:
    Oct 20, 2017
    Posts:
    34
    Hi, long-time graphics guy, but new Unity user here. Very interested in this problem. As some have observed, it is the result of unsynchronized animation and video refresh updates. What happens is that a frame is computed for a time t0, then is later displayed at a time t1 = t0 + dt. If dt were constant and small, the animation would be smooth. When dt is not constant, the eye can detect that the motion on-screen is no longer in phase with the monitor update rate. dt becomes inconstant when the two update rates are different. For example, suppose your animation update computation takes 1ms, your video refreshes every 17ms (a little under 60 times per second, to keep the math simple) and your animation updates the transforms (and perhaps other parameters) of your GameObjects every 20ms. What happens can go like this.

    At t0 = 0.000s, you do an animation update and compute the parameters of your GameObjects. At some future time, less then 17ms later, a video refresh will occur and display your GameObjects as they are with those parameters. Let's say that happens 11ms later, at t1 = 0.011s. What the player will see on the screen is how your GameObjects were a short time into the past, at t0, 11 milliseconds ago. Not bad as latency goes. What happens next? Well, the next video refresh will happen at t1+17ms, or 0.028s. Before then, you will do another animation update, at t0+20ms, or 0.020s. Thus, at 0.028s, when the second video refresh occurs, the player will see the GameObjects as they were in the past, but not so far in the past as before. This time, they will be shown as they were 8 milliseconds ago. Note that the difference between t0 and t1, dt, is changing. It's getting shorter as the video refresh (which happens more often than the animation update) starts coming sooner and sooner after the most recent previously computed animation update. Eventually, two video refreshes will happen between successive animation updates, which means the player will see the same frame twice on their screen. The first will be only one or two milliseconds after it was computed, but the second, duplicate frame will then be 18 or 19 milliseconds old. This will appear as a "stutter" to the player as the previously smooth animation (which was playing very slightly faster than it was being computed) is duplicated over two frames, as a result of the refresh rate outpacing the update rate.

    Here it is as a short spreadsheet (times in milliseconds):

    Code (text):
    1. Animation    Video Refresh    Player sees
    2. Time        Time
    3. 0    
    4.             11                Frame 1
    5. 20
    6.             28                Frame 2
    7. 40
    8.             45                Frame 3
    9. 60    
    10.             62                Frame 4
    11.             79                Frame 4 again
    12. 80    
    13.             96                Frame 5
    14. 100    
    15.             113                Frame 6
    16. 120    
    17.             130                Frame 7
    18. 140    
    19.             147                Frame 8
    20. 160    
    21.             164                Frame 9
    22. 180    
    23.             181                Frame 10
    24.             198                Frame 10 again
    Now, it might appear that this problem can be dealt with by making the video refresh interval the longer of the two and recomputing the animation update more often. But it doesn't work. Here's the spreadsheet with the animation update set to every 17ms and the video refresh set to 20ms:

    Code (text):
    1. Animation    Video Refresh    Player sees
    2. Time        Time
    3. 0            1                Frame 1
    4. 17    
    5.             21                Frame 2
    6. 34    
    7.             41                Frame 3
    8. 51    
    9.             61                Frame 4
    10. 68    
    11.             81                Frame 5
    12. 85    
    13.             101                Frame 6
    14. 102    
    15. 119    
    16.             121                Frame 8
    17. 136    
    18.             141                Frame 9
    19. 153    
    20.             161                Frame 10
    21. 170    
    22.             181                Frame 11
    23. 187    
    24.             201                Frame 12
    Notice that, at time = 0.102s, Frame 7 is computed, but it is not displayed because the next animation update takes place at time = 0.119s, before the next video refresh. Frame 7 is lost before it gets displayed. One might think, "So what? My animation updates are faster than my video refresh. That's a good thing, right?" Not here it isn't. That's because, unlike the prior case, where the time difference between when the GameObjects have their parameters computed, and when they are displayed, got shorter with each frame shown on the screen, here that difference is getting longer with each frame shown until, in order to catch up with the faster animation update rate, the video skips Frame 7 and jumps directly from Frame 6, which was computed for time = 0.085s, to Frame 8, which was computed for time = 0.119s. From Frame 1 to 6, the display was showing frames computed for times each 17ms apart at a rate of one frame every 20ms. The video was falling behind, but at a constant rate that probably wouldn't bother the player for the duration of six frames. But, after Frame 6, 20ms later, the displayed GameObjects are going to be as they are 34ms after the previously displayed frame. In one video refresh interval, the displayed GameObjects are going to leap ahead by the changes accumulated in two animation updates. This will again appear to the player as a "stutter" in the animation. (In the extreme case, as the animation update rate approaches infinity, the size of the jump will get smaller, as a near-infinite update rate implies a near-zero update interval, which also implies that an ocassional doubling of that near-zero interval will still be near zero, but no one's computer is that fast.)

    This problem has been around long enough and been documented well enough to have its own name: the inconsistent animation resulting from unsychronized updates and refresh intervals is called "janking." Although it is about animating web pages, this YouTube video does a superb job of explaining the phenomenon.

    In Unity, it appears that the stutter is easy to see on Windows if you play your game in a window, even a full-screen window. But, when I play the same game in a full-screen exclusive window, I don't see the stutter. Windows does provide support for blocking on a signal from video display hardware that indicates a refresh has begun, but not all hardware supports this. Without that, you're sunk. My guess (and here's my Unity newness showing) is that Unity uses that signal in exclusive mode, possibly only calling the Update methods once for each video refresh. That would synchronize them beautifully. I'm still testing that, however, and having some problems with one of my machines, but I'll post again if I get more info worth sharing (if anyone with experience in exclusive mode would like to advise me, I'd be most grateful). (Also, if someone knows a better way to insert a table here than with BBCode code blocks, I'd be most grateful to know about that, too.)

    Sorry this was so long, but it's a subtle problem that takes some tedious arithmetic to deconstruct. Hope it was helpful.
     
  41. Ippokratis

    Ippokratis

    Joined:
    Oct 13, 2008
    Posts:
    1,485
    Nice explanation.
    I think there are two ways to improve this problem.
    - GPU based monitor syncing technologies - Freesync, G-sync.
    - Use of a temporal motion blur (one that uses data from previous frames to calculate the blur.
     
  42. zorksox

    zorksox

    Joined:
    Feb 21, 2014
    Posts:
    1
  43. Peter77

    Peter77

    Joined:
    Jun 12, 2013
    Posts:
    2,678
    Thanks for the video! Here are some thoughts...

    You can improve editor performance by not having the scene view and game view shown at the same time. You can dock the scene and game view onto the same panel, Unity brings one window in focus automatically, whether you're in edit or play mode; meaning either the game or scene view is visible, not never both at the same time. Using this layout causes the editor to run with double-performance for me.

    Not using a deltaTime makes it difficult to change/tweak the "Fixed Timestep" settings, because you'd have to change every piece of FixedUpdate every time you tweak "Fixed Timestep".