For reference Unity was explicitly called out for having subpar experience by Digital Foundry by having their fixed timesteps being lower than the actual logic update thus causing weird frame/camera hitching issues in multiple Unity games. Devs that then have camera logic that follows rigidbodies then will only update at 50hz instead of the game logic’s 60hz around the 33:50 mark. (Unity’s embed doesn’t support timestamps I guess so maybe click here)
One could say that this is the responsibility of the devs, but also something that should probably be looked at in Unity. I don’t think this value has changed the default in 8 years and maybe it’s time we at least push the fixed timestep up to 60hz so fewer devs make this mistake.
Physics updates by default at 50hz. GameObjects with rigidbody components update their position at that same 50hz if the interpolate setting is left at the default of “none”. If you change the setting to either “interpolate” or “extrapolate” then the position of the object is updated with every frame, either interpolating between the last 2 physics updates, or anticipating where the next physics update will place the object, depending on which you choose.
With the rise of variable refresh rate monitors, I don’t think just changing the default fixed timestamp to 60 is the right move. If you wanted to change a default, I’d argue setting the default of a Rigidbody’s Interpolate setting to interpolate would be the better move. But that does have a slight increase to CPU cost, probably felt most for mobile projects. If I were a mobile developer I’d hate this idea most likely.
Yes, I do know it’s configurable (hence the dev responsibility line) and is mentioned in the video but the problem is that many developers do not and it is causing problems for shipped games. I don’t think we should remove the fixed timestep configuration, but definitely something that I think Unity should consider updating to a higher timestep by default or drive the communication of this behavior to interpolate/extrapolate player’s rigidbodies when they are being used in camera following logic.
You can definitely have smooth camera and object movement when using FixedUpdate and rigid bodies in Unity, the problem is that the default values are set to “jittery mess”:
The default fixed update rate is 50 per second, which doesn’t line up with the ubiquitous 60Hz refresh rate.
Rigid body interpolation defaults to “none”, instead of the more sensible “interpolate”.
One the the games I’m working on has fixed update rate set to 20Hz for networking and physics performance reasons, but moves smoothly at whatever framerate your rig can pump out because everything that matters has interpolation enabled.
While it’s configurable, we don’t recommend that you change it. Changing it to 60 Hz will mask the problem on 60 Hz displays which will make it actually easier to introduce bugs into your game that mix up update vs fixed update and that will make the game look like crap on 75 Hz/144 Hz/165 Hz displays. Not to mention that you’ll still see slight stutter because almost no displays run at 60 Hz exactly: for instance, my screens run at 59.97 Hz, 59.94 Hz and 143.996 Hz. As @Joe-Censored said, you should be using interpolation on your rigid bodies which makes this a non-issue.
We actually had this discussion internally several days ago, and the conclusion was that making fixed timestep 60 hz will just plant land mines for devs to run into. We talked about making rigid bodies interpolated by default, and that seems like the direction we’re willing to go in.
Exactly… The problem is the default setup does not work surely?! So if the best solution is interpolated rigid bodies then why is this not the default?
It is better to make it work without jitter by default, than to have to have devs (particularly new ones) search for the correct way to fix a problem which is there from the start.
(Since interpolated rigid bodies is false by default, a 60 fps fixed update would probably have been better for most people by default as most people have close to 60hz monitors, but forget I said as still not perfect…)
Yes, most people who are on computers have that refresh rate, but once you step outside of computers that very quickly changes. High refresh rate phones are becoming both more common and more affordable with each year, high refresh rates now exist on the major consoles, etc.
In fact even Apple who has stubbornly stuck to a 60Hz refresh rate on their devices has started to introduce high refresh rate displays in a few products and I only expect that to become more common, and they’ve been awarded a patent for automatic switching between very high refresh rates.
Well, even there they only have approximately that refresh rate, as @Tautvydas-Zilys said. Just as in programming, we can’t rely on any two real* numbers being actually equal.
My monitor’s “Advanced” properties specifically show 59.940, 59.997 and 60.000 hz settings. This is in fact the first monitor where I recall seeing an “exact” 60hz setting. Elsewhere I’ve seen numbers like 60.001, so they can be over as well.
Because trying to find a one-size-fits-all default is like a dog chasing its tail. It’ll never get there.
If interpolation is made the default it’ll solve this problem, but then people will be complaining that it’s introduced lag to things where responsiveness should be the default**. Then in discussions about the lag people will suggest changing the interpolation to “none”.
Changing the defaults is a reasonable thing to do if it’ll suit more use cases, but it’s highly unlikely to suit them all. That’s why it was made configurable in the first place. If there was a single correct setting for all use cases then why make it optional? Just permanently set it to that.
With that in mind, the existing solution is fundamentally correct. These settings are configurable precisely because there is no one solution which ideally fits all use cases, so it’s up to developers to know how stuff works and configure things to fit their needs.
As in, non-integer numbers.
** And people already complain about input lag because that is also legitimately challenging to minimise.
Indeed. Two decades ago people had to write their own stuff to handle all of this, so they had to understand how it worked and usually learned how to solve these things along the way. These days our off-the-shelf tools do 95% of that for us, so people don’t have to understand how things work, and erroneously blame their tools for stuff.
It is making it work far better out of the box and for most cases - options to change are still there. Currently with interpolation off by default it does not work well out of the box for anyone does it?!
Interpolation disabled looks wrong 100% of the cases, though. The only valid use cases are games which use enforce a fixed delta time to lock the physics simulation to the frame rate, or disabling it for distant rigid bodies for performance.
Yes, it introduces “lag”, but that’s part of the fixed time step model, as per the original gaffer article and the Tribes simulation model which Unity is based on
This complaining about “kids these days” on a game engine forum is, frankly, ridiculous. Yes, let’s all go back to the old days of writing out physics engines from scratch.
I, for one, would love not have to change the damn interpolation setting on every damn single rigid body to make the game not look “like a Unity game” and have to waste my time writing scripts that detect when some other team member has forgotten to do so when pushing a prefab into the repository.
The job of physics engine is often “make that box fall”. Current setup performs that.
It’s not. The change resulted in larger number of people who lack competence. Those people ask questions. Answering those question is frequently not very interesting, which, in turn, can lead to information scarcity as many people don’t want to bother answering.
Also, I’m of opinion that if you’re messing with gamedev, you should be able to write a physics engine from scratch. At least a basic one.
–edit–
Interacting with someone (or assisting them) who has done their framework and have active mind capable of quickly solving problems and understanding solutions is a pleasure. Same deal with people who accumulated a lot of specialized knowledge and are willing to share it. Because in this case during the interaction both parties involved can grow. I’ll absorb their knowledge, they’ll absorb mine. Everybody wins.
The specialized knowledge doesn’t have to be programming, it couldb art, modeling, music, business, anything. Mutual benefit applies in all cases.
Some people these days are often incapable of using docs. Trying to help them often is a waste because when somebody doesn’t have what it takes, even if you assist them, in the end they’ll bail and your effort will be wasted.
So, yes, it is perfectly okay to complain about people not being able to write a physics engine or not bothering to learn how to use their tools.
No, it doesn’t “work okay”, because movement will be jittery on pretty much all situations. It’s less noticeable if the game is capped at 30fps, but it still judders.
What “change”? Are you seriously arguing default rigid body interpolation behavior should stay as it is, despise everything posted so far on this thread, because otherwise we’ll have to deal with a hypothetical mass of noob posts about why their game is now “laggy” instead of stuttery?
Take a chill pill and think a bit before angrily responding with “seriously?”. It is not exactly a deep philosophical thesis there, shouldn’t be that hard to infer any missing pieces from context.
I’m talking about people who are trying to make games. Now vs 20 or 30 years ago.
I’m more focused on actionable results, which are harder to get out from blaming everything on “kids these days”. Having bad defaults helps no one, specially when said defaults need to be changed on every individual object instead of project-wide.
