I’ve been trying to find a solution to why the hell my 2D game is stuttering for a few days now. Spent more than 40 hours just trying to remove the stuttering.
I’m using Rigidbody2Ds with interpolation put on. This is supposed to eliminate any stuttering in movement, but in fact the interpolation (extrapolation too) makes the stuttering worse!
See the video below (the green dude is using interpolation, and he has more stuttering than any of the other dudes). Play it at 0.25 speed and you will be able to follow the stuttering really well.
This video was filmed in a totally new project, vSync off, all quality/graphics settings set to as low as possible, 1000 FPS in the profiler WITHOUT any peaks. I’ve tried with different Time settings and Physics2D settings… nothing seems to remove the stuttering!
I’ve tried using FixedUpdate, Update and also LateUpdate to no prevail.
I’m on a 970 GTX (Asus) and an Intel 2500K i5 with 16GB RAM on Windows 7 64 bit.
I found out that some things will break Unity’s Rigidbody.interpolation, at least pre Unity 5 where i did the Tests:
Setting position or rotation of the Transform or Rigidbody
overwriting velocity may also induce stutter
What i did to avoid this:
CharacterObject holding the Rigidbody has no visible parts
A child or a different Object without a Rigidbody holds all visuals
inter- or extrapolate the visual Object manually based on the Rigidbody’s velocity
For a source you can check my old Testbuilt, but it is very old and the webplayer somehow drops one frame per second on my devices:
To see this in effect in action you can check my old shooter project in my signature, the last time i checked it worked flawlessly. This game also contains a lot of Debug-Stuff in the Menu where you can show the actual rigidbody Collider and how its position differs from the visuals:
Of course it will. When you add a Rigidbody2D, you’re tell it to take control of the Transform which is why you shouldn’t touch the transform. Interpolation simply updates the transform during the intermediary frames between fixed-updates from the old rigidbody position to the new one. If you override the transform position directly (stomping on what interpolation is doing) then interpolation is turned off until the next fixed update as it has to be.
I don’t see how changing the velocity of the rigidbody would have any effect on interpolation at all. Obviously if you’re changing the velocity all over the place then the speed will be constantly changing but interpolation is only based upon the old rigidbody position to the new one.
I wasn’t intending to say that modifying the Transform shouldn’t break the Interpolation, it was just an observation i had at the time i wrote the linked thread since people generally did just that (including myself, as i first stumbled upon this issue). Maybe a side-note in the docs would do good (or is there one already?).
I mentioned velocity because, while not breaking the Interpolation, may induce stutter in the very case you mentioned.
Thanks for the tips. I’ll check out your file right now and come back with a comment!
I don’t change the velocity every frame and if you watch closely even the non-interpolated 2D characters have stutter; so I’m starting to think that the interpolation just magnifies the stutter that is actually created by something else! I’ll try to compile a test scene that you can test to use if you also have the stutter. Maybe it’s hardware specific?
I’ll try your tips and see if it helps! Currently I have the rigidbody2d and spriterenderer on the same object, so maybe that could be the culprit? But I don’t understand why the Unity folks would do something like that. Sounds like that’d become really problematic easily!
Oh yea. I never tamper with the transform.position directly; only through changing the velocity.
Marrt! I tried your smoothness testing application and it has exactly the same stuttering that my application has! I’m starting to think that this is based on my hardware. Any ideas what could fix this? I have high frame rate in your application too, and I don’t see anything in the profiler. I don’t have any stuttering in other games than those in the Unity engine. I’ll test a few other Unity games and see if the hiccups persist.
Profiler you say? Do you test this in the Editor? You shouldn’t expect Smoothness in the Editor, test smoothness in standalone if you didn’t do that already.
Yep. I’ve tested building the game. Exactly the same behaviour but somewhat less noticeable. I’d describe the problem as “micro stuttering”. It’s just mini stuttering that appears on the whole screen.
In the video above you can see the red dudes micro stutter now and then, that’s exactly what I’m experiencing when I build the game.
A the old micro stutter. I’ve no idea what causes it other than it appears to be a unity thing that’s always stuck with Unity. Possibly an issue with unity source I’m afraid. Best thing to do is post bug reports.
Dammit! I see some videos on Unity games running flawlessly but I’ve never experienced it myself - I guess it’s hardware, driver or OS dependent!
I started to think it had something to do with garbage collection, but after testing abit I got the feeling that the garbage collector should be detectable in the profiler. I started doing garbage collection every frame, and this didn’t really change anything at all.
Unity devs - if you read this, give me a PM or mail if you want me to help pinning this stuff down.
I think this is the same issue I’m getting since upgrading to 5.1. I’m using a project that I know was working before the update, but with 5.1 it’s almost like it’s not applying interpolation anymore. In fact as you noticed, with interpolate turned off it runs better - it’s like they reversed.
I’m going to install 5.0 tomorrow and see if it’s working there.
All this talk leads nowhere without seeing the actual implementation. Whether you see if its working or not tomorrow has a small impact on what the community could do or learn about it. Just post a zipped dumbed down project file that shows the issue.
Broken smoothness is such a multisource-problem that we should at least have a common project file where everyone agrees upon that it should work, while it does not
I’ve reduced stutter by manually interpolating/extrapolating inside update between fixed updates to compensate for times when fixed update running repeatedly or not enough times.
It’s ham fisted, but the stutter was driving me mad and I personally dislike using delta time for classic precision style games. Compensating for delta time is erratic as there is no way to know what the next sequence of frame rate will be, only the previous sequence of frames. So say for in example, a precision platformer sometimes the character will jump further/shorter depending on what sequence of delta times were multiplied with the speeds and if it’s not happening at a consistent interval, it will always be sloppy.
I actually prefer older games slowing down than behaving erratically, as the results were at least deterministic without microstuttering or fluctuations. It’d be nice if unity could have a rock solid method of capturing any sort of movement with a camera (transform, rigidbody, anything), but at this point it must have some kind of architectural design that makes this difficult. I am not sure which shift caused this to happen, as I don’t really recall microstuttering being a noticeable thing until the last half of a decade or so. Framerates were either good or bad. Slowdown in the old days, choppy in the latter days. But no matter how slow or choppy things got, it always seemed like an accurate representation of the game at that time.
So to summarize your post in one Statement: “You want to have no separation between Physics-Frames and Render-Frames”
which equals to: keep your game at vsync-rate or you will fuck up the timescale.
If you only manipulate Actors in FixedUpdate() you will end up being (pretty much) deterministic.
I made a testbuild a while back: http://marrt.elementfx.com/index.html?page=3
If you only ever press “reset match” you will see that everytime the first goal will happen at exactly the same time
(exceptions of that i think to be floating point inaccuracies and my faulty implementation of the “match reset”)
Edit: “(pretty much) deterministic” is a bad phrase but in this context i just mean that you will never ever notice a difference in terms of jumping distance in an ordinary platformer caused by non-deterministic physics (except you do perfect TAS-Speedruns on that platformer). Btw “delta time” is not used in FixedUpdate() since the delta is always the same: Time.fixedDeltaTime (if the timeScale is constant)
I see some videos on Unity games running flawlessly but I’ve never experienced it myself - I guess it’s hardware, driver or OS dependent!