You could read the link I posted, which explains exactly what fixing the timestep means, including interpolation. Just saying.

You could read the link I posted, which explains exactly what fixing the timestep means, including interpolation. Just saying.

Nice article. I wish I'd had time to read it earlier. Work is inconsiderate like that.

Your exponential form will give you timestep independent behaviour.

However, it's not correct for (what's usually called) friction, since the dry frictional force is independent of velocity. You'd normally call a force or acceleration that's proportional to the velocity, damping (e.g. a damped spring, and your equation is exponential damping). Aerodynamic drag results in the force/acceleration normally being approximately proportional to the velocity squared.

If you want more realistic friction - e.g. for one object sliding on top of another, then calculate:

- The force normal to the contact plane, Fn

- The maximum force that can be generated by friction Fmax = Fn * frictionCoefficient

- The force that would bring the relative tangential velocity v to zero in the following timestep dt: F0 = m * v / dt if your object is a point mass, or if you're apply the frictional force at its centre of mass, assuming you're using Euler integration.

Then you apply minimum(Fmax, F0) - though you need to get the signs right! Comparing Fmax with F0 means that the friction won't cause oscillation when the velocity is very small.

Fixing your time step will solve all of your problems, but only if done correctly.

I disagree If your code is written correctly, and implements good approximations to the real world, then it will handle variable timesteps, to within the approximations. It won't behave exactly the same with different sized timesteps, but the difference will just depend on how good your approximations are. It might be that you find that the variation in frame to frame of the approximation is just too much to put up with, in which case you can, if you wish, decide to use a fixed timestep and run multiple physics steps per render frame*. However, I'd maintain that it's better to start out with a physics system that is capable of handling a variable timestep (because that will likely expose incorrect implementations - like the OP saw), than to start with a system that is locked to one timestep (because that will cover up incorrect implementations).

Also, fixing the timestep won't solve the problem, if the problem is that the friction model is wrong!

Some games use a fixed timestep, and some a variable timestep. There are advantages and disadvantages to both choices.

* Another option might be: If you find your physics goes bad when dt > maxDt, you could split your physics update into N iterations such that dt/N < maxDt (choose N as small as possible!). This will result in the physics sim staying within the good-approximation range, without having to do interpolation between physics frames, or having the physics update time != render update time.

A variable timestep introduces stability issues (as in numerical stability). Especially if there is any sort of collision involved...

Only if you're solving collisions with spring-dampers (but nobody really does that these days, do they?). In a rigid body simulator, handling collisions with impulses, I don't see any reason why a variable timestep would lead to numerical instability*, as the collisions get handled outside of the integration of the equations of motion (because collisions introduce a discontinuity, and the response is independent of timestep).

Large timesteps can lead to jitter/approximation problems, but that's not numerical instability, or the same as variable timesteps.

Explicit spring/dampers are unstable at large timesteps (depending on the spring/damping values), but that's not the same as saying they're unstable with variable timesteps. Implicit formulations should be stable at large timesteps.

Fixed and variable timesteps have both got advantages and disadvantages - I'm just saying it's best to understand them rather than saying one is always better than the other, or saying that one always leads to problems, or that one will solve all your problems.

* Small timesteps can lead to problems if using Baumgarte stabilisation, where solver errors are corrected by introducing a bias that looks like error/timestep. This can be especially bad with a variable timestep: if a large timestep on one frame results in poor solver convergence, which is then "corrected" on the next frame with a small timestep, leading to excessive correction velocities. However, there are ways to fix this.

I don't think it has been mentioned, but fixed timesteps allow easier reproduction of the results of the simulation, which can be really helpful in debugging. I imagine it also makes synchronization in multi-player games much easier, since there is a common discretization of time, although I don't have any real experience with that.

I can't think of any disadvantages of fixed timesteps. You mentioned something about using a fixed timestep masking problems, but I can't see that as a real problem. MrRowl, do you care to provide other disadvantages?

fixed timesteps allow easier reproduction of the results of the simulation

Indeed!

I can't think of any disadvantages of fixed timesteps. You mentioned something about using a fixed timestep masking problems, but I can't see that as a real problem. MrRowl, do you care to provide other disadvantages?
[/quote]

Here are some:

1. If you use a fixed physics timestep but a variable render frame time (or a render frame time that isn't a multiple of the physics timestep), but don't interpolate the physics results, then a smoothly moving physics object will not move smoothly across the screen, as sometimes it will experience N updates, and sometimes N+1 (for a fixed render frame time).

2. If you do interpolate between physics frames

2.1 that's an additional cost (which might be significant if you've got a lot of objects),

2.2 Also there's some "uncertainty" about where the object is - so when a user shoots an object, where is the impulse applied?

2.3 Debugging might be fun if your debug points etc don't match up with the interpolated object positions

2.4 If the ratio between the physics timestep and render timestep is such that sometimes you run 2 physics steps, and sometimes 1 (for example), and the physics simulation time is significant, then the frame rate can jitter from frame to frame (a lower, but rock steady, framerate is likely better than a high but variable framerate). If there's a spike in the render frame time (e.g. due to disk access), then a fixed physics timestep will result in a spike in the next frame time etc.

3 If the game allows running in slow motion (bullet time) you need to handle at least two, possibly very different timesteps, and the transition between them, otherwise either (a) you always update at the normal timestep, and the effects of interpolation will become obvious, or (b) you always run at the reduced timestep, with a cost that's excessive when running at the normal rate.

In my current home project (a flight sim for mobile devices), a smaller timestep always results in better physics quality. I just clamp the frame time to a max value (something like 0.1s), and always use N physics steps per frame. The user can choose N as a simulation quality setting - it's always at least 3 (or so). This way I get a constant physics simulation cost, so a really steady frame rate (depending on other stuff!), and I can check that everything will at least remain stable at the the maximum physics step time (0.033s). Faster devices get slightly better physics quality. This was originally my quick placeholder before moving to fixed physics timestep and interpolation (which I've done before), but actually I think it works great so don't intend to change!

I know some big commerical games use fixed, and some variable physics timesteps. There are problems to solve whichever way you go!