As the title says, I’m having a hard time understanding the Fixed Timestep and the Maximum Allowed Timestep. Let’s say my Fixed Timestep is set to 0,02 (Default), this means it will take 20ms for each frame. When my Maximum Allowed Timestep is set to 0,333 (Also default) this will make sure if a frame takes longer than 33ms before it proceeds to the next frame as far as I understand.
Now in the docs I see the following image:
Now here we see that the Fixed Timestep is set to 0,02 (default), which is 20ms per frame. And the Maximum Allowed Timestep is set to 0,1 10ms. But wouldn’t this mean that the Fixed Timestep is never able to finish and Unity will try to proceed onto the next frame after 10ms?
And here are some general questions I can’t seem to get answered;
Why is it, that Fixed Timestep is written like 0,02 (20ms) and Maximum Allowed Timestep is written like 0,333 (33ms)?
Is it ok to change the Fixed Timestep and if you do so are there boundaries like a minimum and maximum.
Why is the default set to 0,02 (50fps), this just seems odd?
If you change the Fixed Timestep do you also need to change the Maximum Allowed Timestep and what would be the formula?
Let’s say you build a game without any physics calculations, would changing the Fixed Timestep hurt performance?
If my Fixed Timestep is set to 0,01667 (60fps, 16.7ms) and my Maximum Allowed Timestep 0,167 16.7ms this would mean a frame can never take longer than the Fixed Timestep, would this hurt performance at all and is it a smart thing to do?
I hope someone could help me out on this topic, and it would be amazing if someone from Unity @MelvMay could elaborate a bit more!
If you use a ridiculously low fixed time step it means that for each actual frame rendered, physics and code in FixedUpdate will run many many times and probably cause performance problems.
If maximum allowed timestep is that low, it means that if for whatever reason performance drops below 60fps, time will start to slow down for your game, since a frame might take 33ms to produce (or whatever) but Unity will treat it as if 16ms have passed.
Maybe it’s the way you’re describing it only but I thought it worth mentioning that this isn’t some hardware or thread-based based time-slicing that’s strictly enforced. I mean, you cannot abort rendering a frame or calling user-scripts so they’ll take as long as they take.
All this is doing is saying that Unity will attempt to call fixed-update, on average, this many times per-second but it’s not some guarantee that it’ll be called this many times in realtime. It’s not some hardware based periodic callback. Just a software based attempt to do so.
Let’s take this to the extreme which I think helps clarify what’s really going on. Let’s say you’ve asked for the fixed-update to happen at 60hz (1/60 sec) or 16.6667ms . Let’s say the first frame that renders takes a crazy amount of time, say, 10 seconds! What this means then is that the fixed-update time is actually at least 10 seconds behind “game time”. What then needs to happen is for the fixed-update to be called many times until it has caught up with “game time”. In this case it’ll result in 60 * 10 seconds = 600 calls to fixed-update happening. Anything hooked into that would be called this many times so physics would perform a simualtion step of (1/60) but 600 times. By the end of that, you’d end up with the same result even if it had called that over a real-time period of 10 seconds and this is the point of fixed-update, at least for physics; ensure that the same results occur even if real-time is delayed, typically by rendering or by user-scripts.
The major problem here then is that you took 10 seconds to render a frame but because of that you then had to perform 600 fixed-update step which itself takes a lot of time and puts itself even further behind “game time”. This is a spiral of death that cannot be recovered from.
The Maximum Allowed Timestep is a limit that stops extreme situations like this from causing serious problems. I mean 10 seconds delay is unrealistic and certainly an extreme case but this is why the maximum allowed time-step is 0.1 so 1/10th second (100ms). If you hit this maximum threshold then the excess time is ignored and effectively lost. The price is lost time for the benefit of not dragging everything down into a spiral loop of death.
@MelvMay this clarifies it alot. Does changing the Maximum Allowed Timestep hurt performance like changing the Fixed Timestep does? And is having the same Fixed Timestep and Maximum Allowed Timestep a smart thing to do?
If you read above what it does, you can see it’s only used to limit serious situations when you’re doing excessive work and the fixed-update set-up you want just cannot be met. You’re already in a “hurt performance” situation. All this is doing is say, we got into a bad situation, at what point should we stop making it worse.
Nothing apart from the fixed-update loop looks at this. It has no effect on any systems that do real work.
The main concept to come out of this should be the understanding that FixedUpdate is about keeping up with “game time” which is time that starts from when you hit play or first start. It’s not about “real time” calling of “fixed update” although it’s obviously going to try to do that.
A crude example of this is in the API docs for Physics.Simulate showing you manually calling a physics simulation at a fixed-update period. This is all it really is. That code however has no threshold to check if we’ve gone beyond a certain level of time. It’ll blindly step as many times as it needs to “catch up”.
@MelvMay ah sorry about that, so if I understand this correctly Maximum Allowed Timestep isn’t there to solve something, it’s just preventing a bad situation from getting any worse. Since the Fixed Timestep can’t be met performance is already hurt?
Pretty much yes. It’s like writing a loop in code where you’re trying to calculate some value and expect to find it with 10 iterations but to be safe, you set a threshold which is a maximum number of iterations. You do that to limit the amount of time you will take by sacrificing accuracy and also stopping from potentially hitting some infinite or feedback loop which keeps getting worse. This is that threshold. The penalty here is loosing a bit of game time i.e. time which is far better than always trying to catch up (by performing multiple fixed-updates) to game-time and it getting worse and worse.
The reason why this can be acceptable is because it’s a game and not a scientific simulation with perfect accuracy. In the end, just some smoke and mirrors with safety levels.
