linear movement stuttering

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.

 

try using Lerp instead of Translate.

 

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.

 

do you have camera hardly attached to your moving object or is it being controlled by another script?

 

Camera is not moving at all.

 

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?

 

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)

 

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

 

don't go hard on me mate, there were my ideas of despair

 

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?

 

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...

 

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.

 

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.

 

I use clear project with orthographic camera and cube with script (only Update function). So "Stats" shows me only 1 draw call.

 

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.

 

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

 

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

 

Hi,
I have tried for ~40 minutes, the stuttering motion remains despite using many approaches.
Anybody else wanna try ?

 

Could it be possibly related with coordinate calculation? Maybe processor fails with rounding coordinates some times?

 

None have any idea? Here is releated topic - http://answers.unity3d.com/questions/275016/updatefixedupdate-motion-stutter-not-another-novic.html but no solution as I understand.

 

Got profiler stats?

 

I guess its pro only? Could you please check project attached some posts ago?

 

Any help?

 

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.

 

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

 

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

 

Thank you very much, EvilNoodle. Seems like setting 60 hertz (was 59 previous) in windows settings really helped.

 

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

 

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.

 

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!

 

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!

 

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:



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.



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):





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:



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...

 

What about andoid / ios??? How to turn DX9/DX11 settings?

 

Only Windows uses DX9 or DX11; all other platforms use some kind of OpenGL or custom API.

--Eric

 

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)

 

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.

 

It doesn't happen to everyone, and "most people can't see it" makes no sense.

--Eric

 

You can keep denying it or you can realize there are hundreds of people saying this is happening year after year

 

The denial here is on your part.

--Eric

 

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.

 

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.

 

If anyone is still having trouble with this stuttering issue, I made a video that compiles every fix I know of. It's really short and I hope it help a few of you.

https://www.youtube.com/watch?v=FrgZzrtZe_4&feature=youtu.be&hd=1

 

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".

 

this is a bit of an old thread but I had to dig up some knowledge, theres a fair bit of understandable frustration and attempts at things that basically have no effect. If you're looking to fix stuttering 2d movement, simply use this code:

Code (CSharp):

1.     void Start()
2.     {
3.         Application.targetFrameRate = 60;
4.         QualitySettings.vSyncCount = 1;
5.     }

 

I'm not sure that's going to have the effect you want it to. From the documentation on Application.targetFrameRate: