# Physics simulation methods for large delta times?

What physics simulation methods are most suitable for really big delta time (hours to weeks)?

In addition, would I face any problems combining different methods for big and small delta times?

• It largely depends on your target area. Hard to say anything without knowing more about you real goals there. Too broad. Dec 15 '14 at 6:40
• This question is related.
– Anko
Dec 15 '14 at 15:43
• In principle, the proper timescale depends on what the player experiences. Do you want it to be accurate on the timescale of weeks and have the player interact with it in real-time? That is much more difficult than getting it to work on the timescale of weeks that the player experiences at many times real-time (ie one second of player experience is one week of real-time). Dec 15 '14 at 23:42
• if you are simulating cloud motions, or thermodynamic variables in cells of hundreds of meter wide, with a dt of 10 minutes, its reasonable. but rigid body at usual scales, not too much. what is the application ? Dec 16 '14 at 5:18
• The application is a "catch up" mechanic where simulation since last load (of a part of the world) is run, game logic is all callback-based where callbacks are timers or collision callbacks, I want to be able run physics to the next timer callback efficiently, and have the physics simulation deal with calling collision callbacks. Collisions are relatively unlikely, but I'd like collision callbacks to have available game (physics) state at the time of the collision. Dec 16 '14 at 19:31

You'll likely be using constant acceleration for these large time spans (which could be zero acceleration). The derivative of constant acceleration with respect to time is 0. That means it doesn't change with respect to time, so it doesn't matter how large your delta time is.

This little integration with respect to time provides the equations you need.

a = a
v = at + v0
s = .5at^2 + v0*t + s0


Where: a=acceleration, v=velocity, v0=initial velocity, s=position, s0=initial position, t=time

Using this strategy you can use times spans from milliseconds to weeks if you wanted to. Combining them would be taken care of in the v0 and s0 parameters of the equation.

To handle collisions you'll have to implement strategies similar to those used for high speed small objects. First calculating the new position using the equation above, then sweeping between the old and new position for all objects. Since any one of those objects could have intersected each other (minutes or days before), this can get very complex. It's likely that since you have such large delta times, hopefully you'll have plenty of time to process these potential collisions.

• what about collisions? Dec 15 '14 at 2:58
• I've updated the answer to include strategies for handling collisions.
– House
Dec 15 '14 at 3:11
• this is false. Euler integration is known to deviate for constant integrations, while Verlet (or RK2, RK4) does not. Dec 16 '14 at 5:15
• @v.oddou Considering these simulations are for games, I don't think the accuracy you're requiring is necessary. The additional complexity and difficulty of adding collisions for Verlet makes Euler integration a superior choice.
– House
Dec 16 '14 at 5:44

Lets take an example with gravity.

In the below function, assume we have class member variables for position and velocity. We need to update them due to the force of gravity every dt seconds.

void update( float dt )
{
acceleration = G * m / r^2;
velocity = velocity + acceleration * dt;
position = position + velocity * dt;
}


As dt gets smaller and smaller, our simulation gets more and more accurate (although if dt gets too small then we can encounter precision errors when adding tiny numbers to large numbers).

Basically, you have to decide the maximum dt your simulation can handle to get good enough results. And if the dt that comes in is too large, then simply break the simulation down into smaller steps, where each step is the maximum dt that you allow.

void update( float dt )
{
acceleration = G * m / r^2;
velocity = velocity + acceleration * dt;
position = position + velocity * dt;
}

// this is the function we call. The above function is a helper to this function.
void updateLargeDt( float dt )
{
const float timeStep = 0.1;
while( dt > timeStep   )
{
update( timeStep  );
dt -= timeStep ;
}

update( dt );  // update with whatever dt is left over from above
}


So with this strategy, you can just adjust timeStep to whatever fidelity you need ( make it a second, minute, hour, or whatever is needed to get an accurate representation of the physics.

Most games tend to use the simple Euler method of forward integration (that is, integrate the velocity into the position over time, and integrate the acceleration into velocity). Unfortunately,the Euler method is only suitable for very small timescales and short runs.

There are more complex methods which are more accurate over very long time scales. The most popular and easiest to implement is perhaps Runge-Kutte-4. RK4 determines the position in the future by sampling four positions and velocities in the past and interpolating. It tends to be much more accurate than the Euler method over longer time-scales, but is more computationally expensive.

For instance, if you want to compute the physics of a real orbiting planet updating every few days of real-time, the Euler method will cause the planet to shoot off into space after only a few orbits due to numerical errors. RK4 will generally keep the planet orbiting in roughly the same shape many thousands of times before accumulating too much error.

However, implementing collisions into RK4 can be very challenging...