Search Unity

  1. Calling all beginners! Join the FPS Beginners Mods Challenge until December 13.
    Dismiss Notice
  2. It's Cyber Week at the Asset Store!
    Dismiss Notice

Impossible to get perfectly smooth motion with Unity?

Discussion in 'Editor & General Support' started by theremin, Jun 26, 2012.

  1. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,740
    Many of us who experience this problem, only experience this problem with Unity. At least I do anyway.
    If it were a problem with our setup, not Unity specifically, it would occur in other things. It does not.

    However, I'm not concerned with how it runs on my computer. I'm concerned with how it runs on my fan's. I'm concerned with bad reviews, happy gamers, satisfied customers, good reviews which don't mention any such problems- and most of all: I don't want to have to deal with tech support if the problem relies with them, but only with them + Unity. (Telling people it's their fault when they only have the problem with Unity is just stupid.)

    This reminds me of an argument I had with the developer of a popular indie game. He wrote a blog as well as argued to excuse his engine's flaws. The blog was blaming Nvidia/ATI and their bad drivers for their poor performance in their game engine / their bug or flaw. "It's not my fault my game is broken. It's the problem of the driver manufacturers!" He even had evidence to support his claim. Didn't matter. He was still a frothing idiot.

    Even if it were true that they develop bad drivers and the standard quality is pathetically low, it is inexcusable when all other competitors do NOT have the same problem with said 'bad drivers'.

    The same applies with Unity. Even if the problem lies in the monitor / gpu settings of individual systems, the simple fact this is an isolated problem with Unity and nothing else, and a significant amount of users have this problem but only with Unity games, it means it is a Unity problem.

    Just like the developer in my story, you can point fingers all you want, and you can even be right about blaming someone else. That still doesn't fix the problem, and in the end you will be blamed. Since your competition solved these issues and you're the only one left with the problem, you DESERVE said blame.

    There is no excuse when others don't share the same problems (or resolved them already). It just makes the dev look incompetent, and they look even worse when they blame someone else for their "incompetence". Even if they are competent and 100% right.

    Imagine releasing a game, and getting 1%-20% bad reviews because of this problem. How many of your consumers would accept the excuse, "It's Unity's fault. It's your fault. It's not mine."? None of them. They play other games just fine, and only have problems with yours (or specifically certain 2D Unity games).

    If you run it fine TwiiK, that is great. If a high % or even a low % of your users have this problem and find it annoying- that is a problem for you, not them. At least if the % is high enough to put a negative dent in your reviews.
     
    Last edited: Apr 10, 2015
    Frpmta likes this.
  2. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,740
    My bad, for some reason my browser flew up and so I thought the newest post was an older post. Didn't mean to reply to an older comment. Sorry.
     
  3. TwiiK

    TwiiK

    Joined:
    Oct 23, 2007
    Posts:
    1,640
    I completely understand what you're saying and I would agree with you if what you were saying was true. But you're the saying it's an incredibly common and game-breaking problem and I can't seem to locate any evidence to support your claim on this. But it's very easy for me to find evidence of the opposite. 4 of the top 5 pc games at the moment, according to metacritic, are Unity titles. Unity dominates the mobile market where performance is very important. There's millions of Unity developers and hundreds of millions of Unity gamers.

    I have 2 Unity games currently installed on my iPhone, Monument Valley and Powder, both of which run perfectly smooth. And these are complete games, if they were to show any symptoms of choppiness or hiccups it could be anything. The claims in this thread is that Unity can not even move a cube smoothly across the screen, which is blatantly false. It may not be able to for you, but in that case there's nothing we can do apart from say that it's a problem with your system. Submit a bug report and provide as much information as you can and you've done what you can do. If it's truly game-breaking and nobody is able to find a solution then I guess your only option is to switch game engines.
     
  4. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,740
    To you. To some of us, it is blatantly true...
    Remember, just because YOU don't see it doesn't mean others don't either.



    There is no point to argue. Multiple people consistently reporting this problem using the example project says it all.

    I tested Ori & Cities Skylines, and the latter has a very unsmooth camera. Who knows why though. The former I might have saw it, but so much less (it was pretty dang smooth) that it was hard to notice even when I was trying to look for it. I'm entirely convinced no one would even see it in Ori. The game just doesn't have those components that make it more obvious (it has a delayed follow camera, and is just overall very smooth movement for most everything but a few less noticeable background pieces).

    It's pretty hard to test this kind of thing with a released game. Much easier to see it in a unity project.

    I also never had this problem at all with one of my simpler projects (pixel art game) even though it also used Unity. Never noticed it anyway. That is because the camera rarely moved though in that game.
     
    Last edited: Apr 11, 2015
  5. jsip

    jsip

    Joined:
    Jan 25, 2015
    Posts:
    5
    I'll ask if you know that those games you mention use FixedUpdate to move objects and what their fixed time steps are?

    I'll re-iterate the problem:
    Framerate: Variable - empty scene, in Update():
    print (Time.deltaTime.ToString());
    See if that matches the fixed step of 0.02

    It won't unless the display is 50hz. Even then you will not see a 100% dedicated TTF (time-to-frame).

    The problem: 0.02 != framerate

    You will always have 50 physics steps per second, you will not always land an Update() at any given physics interval, causing phase shift between physics updates and framerate. Occasionally another Update() will happen at 60fps that did not have a physics step before it, carrying previous transform data through to the following frame, causing a momentary stutter to the end user, every second, for infinity.

    That's just how the physics steps work, to make sure all physics objects move at exactly the same speeds no matter what the framerate is. This is great for consistency, this is poor for frame-perfect smooth movement.

    You "can" set your fixed delta to 0.01666666 or 0.01666667 but you will still have a remainder with either or since 1/60 is not cleanly divisible as is 1/50. You will be smooth until the phase shift occurs, at which point, you will remain stuttering every other frame until the updates are partially in sync again, unlike 0.02 which occurs every second, but only for a few frames.

    The first order of business is knowing the best method of moving an object smoothly for your game which more than likely is per frame, not by a new vector, but by translate. This will give you ALMOST perfectly smooth movement when multiplying the vector by Time.deltaTime. You can create your own deltaTime, using an average of several frames but for console or mobile specific entries where you KNOW you will not deviate from a locked 60 - a single deltaTime is fine.

    Our PS4 game runs 60 100% of the time no matter what is on screen under all conditions - so we do not need to math an average. For PC, we do since we offer the option to unlock vsync. We use our own average here (not Unity's) and work our own math for spikes and drops to make sure movement remains smooth.

    We rolled our own 2D "physics" using translate and raycasts. It's not difficult, offers far greater control HOWEVER we have noticed some slight object speed decreases running above 600fps and into the 1k range on PC and have our own internal frame counter and global speed multiplier to compensate when vsync is off. Our game has a LOT of moving stuff, wall jump mechanics, platforming, pew pew and glorious custom particle physics explosions for everyone's face. Never an issue with smoothness using translate - always an issue with smoothness using FixedUpdate and Rigidbodies.

    Tested on PS4, Xbox One, Android, iOS, Mac, PC and Linux because I have them all here to test and are only a click away to build. My Linux and Windows systems are also separate rigs. So, no, it's not just one individual's system. UE has this issue but are rectifying some of it with sub-stepping to improve translation between physics step and framerate.

    It's how numbers work. When two numbers != and essentially repeating forvever, adding to itself with itself, you will have drift between two numbers. When one of the numbers is always cleanly delivered by time using a whole number at an evenly divisible interval, while the other is always inconsistent but feeds an exact number of additions in that same time frame, you will drop in and out of sync repeatedly over the course of every whole number.
     
    eighto and Todd-Wasson like this.
  6. Todd-Wasson

    Todd-Wasson

    Joined:
    Aug 7, 2014
    Posts:
    1,065
    Great post, Jsip. You nailed it.

    It also doesn't help that Windows or any multitasking OS is yanking time slices away from your app, sometimes a frame can take a lot longer than normal which is another thing that can lead to spiking of this nature.
     
  7. holdingjason

    holdingjason

    Joined:
    Nov 14, 2012
    Posts:
    89
    Arriving late to the party but I can attest this is still going on after about a week of banging on this. We are using jsip approach however I can repro this in a very very simple scene.

    Take just a camera and a few cubes, don't even need a light source. Set camera at say -5 to -10 on the z. Line up the cubes 1 unit apart so there is a gap between them (you can size them any size you like on x). Put in 10 to 20 whatever. Now just translate the camera inside of update as been suggested over and over. We are not even talking about trying to sync with another object ie rigidbody etc.

    Something like

    transform.Translate( Vector3.right * 5 * Time.deltaTime );

    But you can choose whatever method you would like to move that camera and believe me I have. You can try it in fixedupdate, lateupdate, update, calc your own timeDelta, force it to a specific framerate and then hard code deltatime. None of it matters. You will see little jitters every few seconds watching the cubes slide by on an Android device. Basically acting like it refused to sync up with the frame rendering on android devices, ie missing frames, dropping whatever.

    I have a ton of them and does not matter if its an S3, S4, S5, Nexus whatever you will see it at some point. Some of those devices are better then others but its consistent and it sucks.

    These is nothing to profile here, no garbage collection, nothing to increase speed, no texture to tweak on the cube (use default though tried all of that as well including various shaders for fun). Vsync 0,1,2 etc only makes it slightly better or slightly worse but never good enough.

    I see this in Unity 5 and last build of 4. Have not tried rolling back to previous versions yet.

    All outta ideas at this point. No way i can make this simpler. Can get it smooth as glass in windows build but not on Android.
     
  8. Rusfighter

    Rusfighter

    Joined:
    Jan 18, 2014
    Posts:
    60
    I got the same problem, although i have used Libgdx before, it had similar problem. Some popular games made by Unity like Crossy Road, Subway Surf have the same problem on android. I wish we could create games as smooth as Jetpack Joyride with unity. Other strange thing i am occuring on android (tested on Oneplus one, Nexus 4, Galaxy s2, Xperia U), is the max frame time and max cpu-timer are always above 20ms (this might be the problem, see pic). This already occurs if there is only a single camera. Unfortunately, i do not have pro so i cannot debug it with the pro profiler.
    Anyone else got this problem or might know a solution?

    profiler.png

    Ilija
     
  9. sirio21

    sirio21

    Joined:
    Mar 11, 2013
    Posts:
    114
    Readed all the thread,, so whats the problem? I too can't get a smooth translation. Change resolution,, frequency.
    Why Unity team doesn't take this thread and post some cubes moving (like the original posted sample) with the source as sample for us.
    I think that is a crucial problem that several developer can't reach to a solution and it was done a big effort. How can we report this thread to Unity team (and get an official answer).
    Tested in Win8, I5 4570 3.2 ghz, 8GB RAM. GTX770 ZOTAC AMP16. SSD240. TV SAMSUNG 32. CABLE HDMI. IN 60,59,24 HZ, 1024X768, 1920X1080.

    When motion is slow gfx.waitforpresent is at high percentage
     
    Last edited: May 16, 2015
  10. BrianND

    BrianND

    Joined:
    May 14, 2015
    Posts:
    75
    That sounds like an interesting bug. Just out of curiosity have you tried translating the camera OnPreCull? I might also give it a go and see what happens on my older android devices. Vsync probably only helps with screen tearing so you still will get hiccups.

    Does a purely physics based motion also cause this problem?
     
  11. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,740
    I checked out the OP's link on my new monitor (gaming monitor, really great response time, refresh rate, and FreeSync tech on) and I must say that it is significantly less noticeable.

    I'm not sure if it's the higher framerate (90hz), the better monitor overall (less ghosting), or what. It's still there (slightly worse in some settings than in others - most noticeable in a FixedUpdate) but overall not even close to noticeable compared to my past monitors.

    Also, with my new monitor I don't think I'd even see it except for the fact I already know what I'm looking for and know this issue well. (So I would say that with a gaming monitor, the problem kindof resolves itself.) Unfortunately most users don't have such a monitor.


    From what I see (especially considering how some see it and some don't) then it has got to deal with
    • The monitor you use.
    • Your eyesight.
    The "I don't see it!" almost reminds me of the 30 vs 60 argument. (30v60v120v144). I wouldn't be surprised if the sharper the eye to this kind of stuff, the more likely they'll see the skipping. The smoother the monitor, the less noticeable it will be. By "sharper eye" I don't necessarily mean better vision. Possibly some of us train ourselves to notice these imperfections while others don't care to notice them. Alternatively, perhaps our brains or eyes work differently. ("Is this dress blue and black or white and gold?!" hehe...)

    The only thing I find odd is that this seems to be limited to only some games. Outside of Unity, there are not very many 2D games that have this issue. However, this could also be due to:

    • How fast objects move.
    • How the camera follows (moves exactly with character, has a delay, lerps, etc.)
    • Color contrast or other similar things (White cubes on colored background moving at a certain speed may be more noticeable?)
    • What the game looks like.
    Combine it all, and even I wouldn't notice it in some games. At certain movement speeds, it's less noticeable. This makes sense when paired with better monitors doing better.

    We'd have to compare the exact same graphics moving at the exact same speed, with similar settings (Vsync, etc.) to see if this is a Unity problem or not.

    Unfortunately, not everyone has a super fast gaming monitor. Out of the 8+ devices I've used, only one of them (one of the most expensive) basically gets rid of this problem. I am also too lazy to try it without FreeSync or to mess with V-Sync on this monitor. (I keep it always off, since it sucks.)
     
    Last edited: Jul 7, 2015
    willpower likes this.
  12. BrianND

    BrianND

    Joined:
    May 14, 2015
    Posts:
    75
    I checked out the link also. It's jerky but once I go full screen it runs smooth. Maybe you can do webgl vs unity comparison also.
     
    CarterG81 likes this.
  13. yowwwork

    yowwwork

    Joined:
    Mar 4, 2015
    Posts:
    1
    BrianND, I checked that link too. And in my case in fullscreen mode it's jerks even more.
    Tested on Win7, i5-2450M, 2.5 ghz, 4GB RAM. AMD HD 6630M. IN 1366X768
     
  14. BrianND

    BrianND

    Joined:
    May 14, 2015
    Posts:
    75
    I tried on a mac so maybe there are some differences in the hardware. In any case if it doesn't run on all platforms it's a fail.
     
  15. Threepwood

    Threepwood

    Joined:
    Jul 23, 2009
    Posts:
    87
    >>Something like
    transform.Translate( Vector3.right * 5 * Time.deltaTime );

    Yup. Just blew an hour on this. Same code example. Super jerky in Unity full screen and in the window. Jerky as an OSX app. Didn't try Window. SMOOTH in Chrome. Go F***ing figure. Seems insane that something like the above code isn't perfect. Tried everything. VSync, Updated/Late Update, Interpolation on rigidbody. Nothing helps. Single character in scene moved via above code, with a box collider and rigidbody (removed both and same results). So, yeah...
     
  16. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,171
    Completely smooth as an OS X app here. Not quite 100% so in the editor, but nearly (not even remotely "super-jerky"), and there's a lot of editor stuff going on that's not in a build. All Unity games that I've played have been completely smooth, on 3 different machines. (Most recently Feist, and yes they finally finished it, for those of you who might remember that from the forums about 5 years ago.)

    --Eric
     
  17. Hiti3

    Hiti3

    Joined:
    Jul 16, 2015
    Posts:
    7
    What have you done to fix the problem. I have posted this problem on Unity answers page because I need an answer why is the jitter apparent on android device???

    http://answers.unity3d.com/question...er-when-moving-a-2d-ch-1.html#comment-1064969

    Im starting to basicaly just give up because this problem is just ridiculusly insane and will always produce jerky movement...
     
    CarterG81 likes this.
  18. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,171
    I've never had a problem so I didn't need to fix anything. I don't use Android so I can't comment on that.

    --Eric
     
  19. masterchafe

    masterchafe

    Joined:
    Oct 2, 2011
    Posts:
    58
    After changing the time/fixedtimestep to 0.01666667 instead of 0.02, and turning vSyncCount to 1, with a target fps of 60 - my 2dtoolkit tilemap in windows is running super smooth. No more once-a-second judders! I think the scene was maybe just running too fast?

    Thanks for all the tips in this thread! :)
     
  20. funshark

    funshark

    Joined:
    Mar 24, 2009
    Posts:
    225
    Exact same behavior here.
    But I don't understand because it's not the values that are suggested/recommended ( in Unity doc and by many other sources )
     
  21. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,924
    Doubt it. Most likely you weren't using any interpolation for rigidbodies (which update in fixedupdate), or doing things in fixedupdate instead of update with delta time.

    0.01666667 = 60fps fixedupdate rate instead of 50 which is the default and will naturally jitter. This has no relation or bearing on framerate jitter, it just means you aren't using Unity right, if changing that from 50 to 60 solved it (as interpolation or code in the correct loops with delta would be correct).

    Your scenario will break down if on a slow machine, fixedupdate has to fire more than once.
     
  22. funshark

    funshark

    Joined:
    Mar 24, 2009
    Posts:
    225
    What if you're moving a group ( hierarchy ) of gameobjects composed of non-rigidbody and rigidbody ones?
     
  23. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,924
    It's fine since interpolation adjusts the transforms in between physics updates. This is why with interpolation on, you'll read a different value from the transform.position as you would if you read rigidbody.position
     
  24. masterchafe

    masterchafe

    Joined:
    Oct 2, 2011
    Posts:
    58
    Oh I wasn't using any rigidbodies, I just put a script on the main camera that told it to move 0.1 on it's x axis and it would judder every second or so, regardless of Update/LateUpdate/FixedUpdate/Time.deltaTime/Time.smoothDeltaTime/etc. even at 300+fps. I was then wondering if was just the inaccuracy of floats, but I tried Mathf.Round-ing the values and that didn't help either, or even my graphics drivers, updated them - no change, or my monitor, hooked up a different one - same issue. My point is I tried a lot of other peoples solutions online for pixel perfect camera movement, smooth camera scripts etc, all claiming to help smooth movement, but the only thing that worked for me was what was said in this thread.

    There's no doubt, there's a lot of ways I'm not using Unity right :D - but there's very little in my test scene, basically just a 2dtoolkit tilemap wall with a camera, but I'm pretty happy with the result I'm looking at after changing to 0.01666667 and turning vSyncCount to 1 - what's the worst that could happen? (famous last words?) :p

    So it'll get worse problems on a slow machine? I mean I'd rather have it judder on a slow machine than on a medium speed machine, that's only a natural expectation, but I guess I should test it on an OUYA or some other older machine to check in case it completely breaks it or something. I'll let you know how my test goes.

    Thanks for the advice,
    Cheers!
     
  25. hippocoder

    hippocoder

    Digital Ape Moderator

    Joined:
    Apr 11, 2010
    Posts:
    25,924
    Well if you're happy and it's not a problem then it's not a problem :D if it becomes a problem we can work it out then.
     
  26. funshark

    funshark

    Joined:
    Mar 24, 2009
    Posts:
    225
    I would like to add some informations on the subject since I've run many tests lately on Android ( Nexus 5 ; 60 fps )

    First of all, any thing moved in Update, linearly, with Translate, has a smooth motion ( or at least enough smooth to be really acceptable for me )
    The problem appears with rigidbody2D in FixedUpdate.

    I've tried extrapolation, interpolation; in each case, I have not something as smooth as the one in Update + issues ( different speed, position not accurate )
    The movement must be in FixedUpdate since it's a kinematic rigidbody


    It is true that on Android ( which has a 60fps lock ), when moving 2D rigidbody (in FixedUpdate), the result is far better when the timeStep is 0.01666667. ( but It's still not as smooth as the Update motion )
     
  27. mostafa_berg

    mostafa_berg

    Joined:
    Jun 6, 2014
    Posts:
    3
    Just to add in my bit of experience with it, Using the exact same code, and building on two different machines, i get two different results, here's my experiment:

    Running in Editor :
    1-Run on Macbook Pro (i7): Silky smooth, no jitters at all
    2-Run on Windows PC (i7) : Out of phase jitter
    3-Run on i5 SurfacePro 4 : Out of phase jitter

    Building form editor, running on Android (LG G4 device) :
    1-Run on my Macbook Pro (i7): Out of phase jitter
    2-Run on my Windows PC (i7) : Out of phase jitter
    3-Run on my i5 SurfacePro 4 : Out of phase jitter

    Building form editor, running on iOS (iPhone 6) :
    1-Built from Macbook Pro (i7): Smooth
    2-Built from Windows PC (i7) : Smooth
    3-Built from i5 SurfacePro 4 : Smooth

    So it seems like it is mostly less visible or somehow resolved on the Macbook / iPhone, but is visible on Android and windows..

    The experiment was repeated one time with the Pro license activated, and one time with standard license.

    It would've made life a bit easier if we could get control over the internals of the RigidBody interpolation, i'll attempt to make some more experiments without rigid bodies but just translating transforms with a custom implementation and see if i can get this issue going anywhere.. if anyone has new updates/ideas just post :), would be nice to manage to somehow find a workaround for this out of phase jitters.

    but so far I have concluded this is just out of phase lags, and has nothing to do with the way things are moved and it's really hard to overcome it as it will eventually happen repeatedly on some machines
     
    Stardog likes this.
  28. funshark

    funshark

    Joined:
    Mar 24, 2009
    Posts:
    225
    Things go well ( but not in editor, obviously ) with velocity + interpolate + 0.02 on the fixed update time -> on android

    Which exact same code are you talking about?
     
  29. zelmund

    zelmund

    Joined:
    Mar 2, 2012
    Posts:
    381
    using windows
    never smooth moves
     
  30. Usman0007

    Usman0007

    Joined:
    May 27, 2016
    Posts:
    1
    What if we use OnGUI() function ... it works smoothly
     
  31. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,171
    OnGUI is for GUI code. It's generally called twice per frame, once for layout and once for rendering. Do not put non-GUI code in OnGUI, it's just a bad idea. It's not any more smooth than Update, which is always called once per frame.

    --Eric
     
  32. oxysofts

    oxysofts

    Joined:
    Dec 17, 2015
    Posts:
    34
    This is still not fixed in almost 2017

    Here is a clip of my game in development showing the bug caused by Unity
    https://a.pomf.cat/nokmka.webm

    Midway thru, I enable V-Sync which helps a bit, but still has major levels of stuttering

    Not using any kind of physics system. The code basically comes down to this

    Code (CSharp):
    1. public class UpdateDeltaScript : MonoBehaviour
    2. {
    3.     private Vector3 _targetPosition;
    4.  
    5.     void Update()
    6.     {
    7.         _targetPosition.x += 2.0f * Time.deltaTime;
    8.         transform.position = _targetPosition;
    9.     }
    10. }
    11.  
    as outlined by a poster in the first page.
     
  33. TwiiK

    TwiiK

    Joined:
    Oct 23, 2007
    Posts:
    1,640
    I'm sorry, but you're clueless, that's in no way caused by Unity, and that's "basically" not your whole code, AND that's not what this thread is/was about. People here were talking about micro stuttering which I'm almost 100% sure is caused by issues outside out Unity like your monitor, your graphics card etc. etc.

    If you were to report this as a bug you would have to put that code into a new project and reproduce the problem. Why don't you do that? Here, I did it for you:
    https://gfycat.com/FlawlessOrdinaryKinkajou

    That's your code on a cube in a new project. Looks perfectly smooth to me. There's not even a micro stutter.

    Edit: Attached the project if you wanted to look at it.
     

    Attached Files:

    Last edited: Nov 12, 2016
  34. oxysofts

    oxysofts

    Joined:
    Dec 17, 2015
    Posts:
    34
    Hi, it's definitely not a bug in my code. It does some calculations and interpolation to figure out a velocity from player input, but it comes down to exactly what was posted. I have my velocity vector upon which friction, deceleration and impulses are applied, and it's added to a position vector which is set to the transform at the end.

    If I make my code framerate dependant by getting rid of
    Code (CSharp):
    1. Time.deltaTime
    Jerky movement is gone altogether.

    I printed deltaTime to the console and the problem seems to be that the deltaTime returned keeps fluctuating for some odd reasons. It's obviously not the FPS going below 60, I inspected the statistics window and it's running at 150+. Enabling V-Sync makes the deltaTime fluctuate far less but introduces one frame of input lag, a standard side effect of V-Sync, and still does make deltaTime smooth. It's expected that it should return 1/60*1000 every frame since it's running capped at 60 and there are no dips below

    edit: I wrote a script which records the last second's deltaTime on every of the 60 frames and prints it

    Here is the log for 60 frames of playtime where the FPS was stable around 300-400, meaning it should never be above 16.666667ms

    Code (csharp):
    1.  
    2. 16.53075
    3. 100.4581
    4. 25.68351
    5. 16.64477
    6. 16.49116
    7. 17.0803
    8. 16.05233
    9. 16.56521
    10. 16.56778
    11. 16.69389
    12. 16.70233
    13. 16.30309
    14. 26.59159
    15. 16.91056
    16. 16.22317
    17. 16.79251
    18. 17.09496
    19. 15.81403
    20. 16.56595
    21. 16.56631
    22. 16.56631
    23. 26.86509
    24. 16.64147
    25. 17.04584
    26. 16.01933
    27. 16.56338
    28. 16.56485
    29. 17.33582
    30. 15.7968
    31. 16.56668
    32. 27.06452
    33. 16.97068
    34. 16.16414
    35. 16.56668
    36. 16.82771
    37. 16.30749
    38. 16.56668
    39. 16.56851
    40. 16.99928
    41. 27.48429
    42. 16.56705
    43. 16.56851
    44. 16.56961
    45. 16.56228
    46. 16.56631
    47. 17.27753
    48. 16.03436
    49. 16.38814
    50. 26.63375
    51. 16.56741
    52. 16.56888
    53. 16.56595
    54. 16.56631
    55. 16.59601
    56. 16.53662
    57. 16.56961
    58. 16.56668
    59. 30.58066
    60. 16.78885
    61. 16.49849
    62. 16.41344
    63.  
    Either this is a bug in Unity or my project is F***ed harder than Sasha Gray because this should not be happening. There is something very wrong happening here. I may open a new thread seeing as it appears to be a different issue than the one that was discussed in this thread earlier.

    I opened the JerkyMotion project posted in this thread and it is indeed fine and doesn't have any jerky motion as I'm experiencing, so something else in my project must be causing Unity's deltaTime algorithm to freak the F*** out
     
    Last edited: Nov 12, 2016
  35. TwiiK

    TwiiK

    Joined:
    Oct 23, 2007
    Posts:
    1,640
    I still don't believe you. :p

    And I don't understand how you can claim this is not caused by your code when I proved that the small piece of code you supplied is perfectly smooth. The jerky movement almost certainly comes from the other stuff you say you're doing, i.e. this stuff:

    Because what you show in your video looks so clearly broken it's almost 100% certain to me that your issue is caused by your own code, I will however accept that there's a tiny chance that you've stumbled upon some elusive bug, but I seriously doubt it.

    And you clearly don't understand how deltaTime or FPS works in praxis:
    If deltaTime worked like that we could just ditch it altogether. You're printing out deltaTime every frame and claiming that because your FPS was 300 then deltaTime shouldn't vary, but 300 FPS only means that in one second you had 300 frames, it doesn't mean that each frame happened at similar intervals, that's exactly why we use deltaTime, to ensure our games run smoothly independently of how long it took to complete each frame. Just like your data shows the time it takes to complete each frame varies, and most, if not all, framerate counters work by accumulating frames over a period of time to ensure a number that doesn't fluctuate widely.

    I'm by no means an expert on this, I just feel like the first thing you should always suspect is your own code, and if you're incapable of that then you'll never be able to fix your problems. I recently made a thread about what I claimed to be a glaring issue with Unity's new UI, but after sleeping on it I realized that my issue was not only caused by me using it wrong, but the example I provided for what I thought was the issue wasn't the issue at all. Pretty similar to your case, if I may say so myself. :)
     
  36. Eric5h5

    Eric5h5

    Volunteer Moderator Moderator

    Joined:
    Jul 19, 2006
    Posts:
    32,171
    I will say there is some slight variation from frame to frame in Time.deltaTime with vsync on, which theoretically shouldn't happen if deltaTime was recorded at the exact same point every frame. In practice the variation is small enough that it doesn't affect smooth movement that I've ever seen. My guess is that your code is magnifying the deltaTime variation somehow so that it becomes visible.

    --Eric
     
  37. grynur

    grynur

    Joined:
    Apr 22, 2015
    Posts:
    2
    Just adding my 2 cents here but in general I think getting a handle on how garbage collection is impacting the execution of a Unity game is extremely important. Having built massively scalable, C# services (in my other life :)) I have seen garbage collection bring processing throughput to its knees. This oftentimes would require taking control of garbage collection to essentially establish a regular cadence for managing the clean-up of heap that is experiencing large numbers of objects being created/destroyed on the heap. I found that the behavior of Garbage Collection is inconsistent and vast amounts of my time was lost trying to figure how to tune, control and optimize literally hundreds of instances of C# services under 24/7, 80% CPU utilization.

    So, the Unity Manual calls this out clearly here:
    https://unity3d.com/learn/tutorials...ion/optimizing-garbage-collection-unity-games

    Scroll way down...
    "The most obvious problem is that the garbage collector can take a considerable amount of time to run. If the garbage collector has a lot of objects on the heap and/or a lot of object references to examine, the process of examining all of these objects can be slow. This can cause our game to stutter or run slowly."

    My general interpretation of this is that the execution of any vanilla Unity game will battle garbage collection by default. I would image the above guideline that Unity is recommending is probably critical (is it really simply game optimization?). I would also argue that the title of the article "Optimizing garbage collection in Unity games" should be renamed to "Garbage collection best practices in Unity games" or something of that nature.

    I think the Unity team should take ownership over this and make sure their development community is provided with their recommendation and a path forward to kill the mysteriousness behind this once and for all. Perhaps the best practices (below) should be updated to include Unity's recommendation to ensure "Smooth Gameplay":
    https://unity3d.com/learn/tutorials/topics/best-practices

    I know I would prefer to simply implement a Unity-based recommendation instead of burning a bunch of time trying to figure this out.

    Nick
     
  38. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,740
    It's pretty ridiculous what you have to do to get stutter free in Unity.

    Unfortunately without source code, performance optimization is quite difficult due to one of Unity's bigger problems (transform updates).

    And boy what a lot of work they did just to achieve this...

    (forum is giving me errors for some dumb reason - see below post)
     
  39. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,740
    Unite 2016 - Tools, Tricks and Technologies for Reaching Stutter Free 60 FPS in INSIDE
     
  40. Johannski

    Johannski

    Joined:
    Jan 25, 2014
    Posts:
    593
    Just a small update on a finding of mine: No Vsync + targetframerate on Windows creates stutters.


    Just enable Vsync for Windows (If you're on Unity 5.5 and above at least). As for iOS this makes no difference because vsync is enabled by default.
     
  41. adehm

    adehm

    Joined:
    May 3, 2017
    Posts:
    4
    I found that by setting my framerate double to that of fixed created smooth movement. For example I use a fixed framerate of 60 and set my applications framerate to 120.
     
  42. CarterG81

    CarterG81

    Joined:
    Jul 25, 2013
    Posts:
    1,740
    Just remember to allow these changes as options the user can mess with, since every monitor is different. I mention this because I notice a trend, especially in Unity/Gamemaker games, for developers to not have such options. Some go as far as to not even allow remapping keys or changing resolutions... which is simply heresy... not to mention anti-disability.

    Options are vital.
     
  43. sledgeman

    sledgeman

    Joined:
    Jun 23, 2014
    Posts:
    374
    The OP ist from 2012. Long time ago. I have to say, i didn´t have that big issues with smooth movements in Unity 4.7. But now, in 2017....with Unity 5.6 i loaded my project again, and i recognized, it ist stuttering as hell, as all other users here described. Tested on some old Android Devices. There is no use of Physics3D or 2D. Simple transform animations.

    Does anyone know whats specificly changed inside unity 5.6 in comparison to unity 4.7. I guess i must be something deeply inside the engine-architecture (something with the android Player build). Or simply some bugs, that weren´t fixed yet.
     
    Last edited: Jun 23, 2017
    CarterG81 likes this.
  44. John-Silver-Long

    John-Silver-Long

    Joined:
    Feb 14, 2013
    Posts:
    10
    vsync only works for me when frames does not drop below screen refresh rate, i can only get smooth movement by using vsync and set my screen refresh rate to lowest frames.
     
  45. stevensrmiller

    stevensrmiller

    Joined:
    Oct 20, 2017
    Posts:
    180
    I'm new to Unity, but not to computers or video. I might be barking up the wrong tree, but I posted some thoughts on this nearby.
     
    CarterG81 likes this.
  46. Ryetoast

    Ryetoast

    Joined:
    Mar 8, 2015
    Posts:
    40
    Necro bumping this thread, since I still don't see a satisfactory answer to it and it's what showed up when I googled about hitching in Unity.

    I'm running nearly identical code in a self spun SFML project (open source wrapper for opengl), and a simple Unity project. Basically just WASD * deltaTime movement on a quad in Update. In the SFML project it's buttery smooth, and in Unity it's jittery garbage. Has anyone actually figured out how to prevent this from happening in Unity?

    I also tried debug logging Time.deltaTime, and it's always significantly more than what the Stats window shows my FPS/frame time is.

    In a simple scene getting consistently over 100fps in the stats window, and delta time is passing me randomly between 10ms to 30+ms. What gives?
     
  47. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,580
    The problem in Unity is that Time.deltaTime is bound to the frame generation time, not to the screen's frame rate. This was good enough up to Unity 4, but since Unity 5 and the new graphic APIs this is not good anymore. Other engines have solved it, but Unity has been left behind.

    Long but detailed and extremely interesting article explaining where the issue comes from:
    https://medium.com/@alen.ladavac/the-elusive-frame-timing-168f899aec92

    Sumarized and explained:
    https://forum.unity.com/threads/tim...afollow-and-jitter.430339/page-4#post-4173886
     
    sledgeman and CarterG81 like this.
  48. Ryetoast

    Ryetoast

    Joined:
    Mar 8, 2015
    Posts:
    40
    Thanks for the response Edy. That article is a great visualization of exactly what I'm seeing.

    It's sad that the TL;DR is basically "Unity's Update/Time.deltaTime is broken, and it's unclear whether they are working on a solution."
     
    Edy likes this.
  49. TwiiK

    TwiiK

    Joined:
    Oct 23, 2007
    Posts:
    1,640
    What are you guys talking about? What other engines have solved this and how? I recently read the linked article myself and for some reason I'm still being notified about this thread. :p Surely this is a hardware / graphics API shortcoming and not something that game engines could just fix on their own. It says so right there in the article:
    Wouldn't it be natural to assume that the author of that article fixed it in his engine rather than write an article about it if that was the case? After all he's the CTO at Croteam and most likely the person who knows the most about their own game engine.

    Having played games all my life and developed games in a variety of engines including Unity I can't say I've noticed any more stuttering in Unity than in any other engine.
     
  50. Edy

    Edy

    Joined:
    Jun 3, 2010
    Posts:
    1,580
    The perfectly smooth 60fps in this demo makes you cry:
    https://benchmark.unigine.com/valley?lang=en

    How? It's obvious that workarounds do exist. Why Unity still stutters? I don't know.
     
    Last edited: Jun 11, 2019
    sledgeman and CarterG81 like this.