What is a timestep?

Physics simulation gives you snapshots of simulated system.

"Step" is a process of calculating system's next state. "Timestep" is the time interval for which simulation will progress during next "step".

Many physics equations will come in a form like: "Velocity 1 second from now = Velocity right now + The velocity that 1 second worth of acceleration will generate" (and most equations which don't fit this form can be converted somehow...)

The "1 second" part is the time step. A game that changes the world at regular intervals performs lots of these kinds of calculation, and to keep things working right needs to evaluate all of those physics equations with a consistent time step value.

Games frequently use a time step close to the period between each rendered graphical frame, or an ideal time between graphical frames such as 0.01667 seconds, but this is not required. Some games like BeamNG.drive will calculate physics much more frequently than the game can render in order to generate a smoother physical approximation. Other games will calculate physics less frequently and blend the position of what's rendered between each point. It's up to each game what their approach will be.

This random picture off the internet shows it much better (ignore the text):

The blue curve is real life physics.
The pink "staircase" are the simulated physics. The more steps you do (i.e. running a simulation at 120hz) the closer you get to the real curve (i.e. it will look like the one from the left). The less steps you do (say 4hz) then big distortions can happen (like the graph from the right).

With a different analogy: it's like approximating a circle with a polygon (yet another random pic off the internet):

The more steps you do, the closer it looks the polygon to the actual circle. You can see that at n=4 it does not look like a circle at all (it's a diamond). But at n=30 you can get something very close to a circle (in the eyes of a normal human being). A physics timestep is the same.

So, in code:

float frequencyInHerz = 60.0f;
float timestep = 1.0f / frequencyInHerz;

while( !bExitApp )
{
     //Update the position every frame, at 1 / 60 intervals/steps.
     position = position + velocity * timestep;
}

The position is updated at regular intervals, at timesteps. In real life the position is a continuous value. This means between step 0 and step 1, there was step 0.1, and also step 0.11, and also step 0.111 and also step 0.1111... and so on. There's an infinite number of steps between two steps (or seemingly infinite? leave that question to quantum physics). But in our simulation, it's been subdivided in discrete steps. Between step 0 and step 1, there is no other step. That's why it's discrete.

In graphics we also know the frequency as frames per second. Though we often may want to update physics at a given fixed framerate, while rendering graphics at a different, variable framerate.

Hope this gets you kicked in the right direction.

Timestep defines how small the time interval is inbetween physics simulations. In game engines this reflects how often functions() need be run.

Physics(simulations) uses mathematical models to predict the future. These simulations output the path between the present and the future, the models predict the direction towards the future while we calculate the path. How accurate the direction is depends on the models input value which is time. The lower the time value you give the model, the more steps in can take in total until the simulation reaches it's goal. This time value is also known as timestep or dt.

model(time, position) = new_position

Wow, thanks guys. Nice detailed responses, especially you Mathias Goldberg.

Just to be clear would you guys say that a timestep has two functions:

* To provide regular consistent update intervals for a physics simulation

* To provide as many steps as possible for accurate real world physics.

To provide as many steps as possible for accurate real world physics.

This is usually limited by floating point precision problems. So its not as many steps as possible its enough steps.

edit- well not really you'd need a minuscule timestep to encounter precision problems.

* To provide as many steps as necessary for accurate real world physics.

Fixed.
You should always use the largest (slowest) time step possible for a robust simulation. There is no need to run physics every millisecond unless you are in a super-high-end reflex racing game.
Once every 30-40 milliseconds is typically fine.
Fixed-Time-Step Implementation


L. Spiro

One other thing youll likely come across, is that there are multiple methods of advancing from step n to step n+1 when approximating a seemingly continuous system with a discrete one.

In physics engines this 'method' is called the "integrator" - its job is to attempt and sum up all the changes between the nth and n+1th steps with minimal error and acceptable performance.

The most basic integrators make assumptions like "acceleration is constant" when for example calculating velocity (v1 = v0 + a0*dt) even if its known that its not. And so on. More complex ones use some carefully derived polynomials and whatnot to more closely capture the details.

The importance of these becomes apparent when working with feedback and little dampening - think springs, objects orbiting a planet, pendulums...

The tiniest error will easily accumulate due to the feedback and soon its all messed up (spring ends up with 10x more energy out of nowhere, orbiting object reaches escape velocity, the pendulum stops without there being any friction...)

You dont often think about an 'integrator' outside a physics simulation, but its still very relevant - without a proper one, changing the time step might change the behavior completely. So think about this every time you have some time dependent quantities, especially if they also depend on OTHER time dependent quantities. This is also why a variable time step it more difficult than a fixed one - you can completely ignore the issue with a fixed time step as long as it doesnt change (well, to the extent that the game will always behave the same, doesnt mean it behaves correct...).

Great responses.

Thanks everyone for the help.