# Box2D recommended step, velocity and position iterations

Here in this article there is a nice explanation that velocity iterations and position iterations settings affect the way bodies will react when they collide, and step affects on speed and how gravity acts. So the precision is hidden behind position and velocity iterations, whereas you need to have the world step to advance the time in physics world. I also know that step should be constant to be able to have consistent and debug-able game physics. Hence I do this (where dt is FPS delta time):

if (m_world.GetBodyCount() > 0)
{
static const double step = 1.0 / 70.0;
static double accumulator = 0.0;

// max frame time to avoid spiral of death
if ( dt > 0.25 )
dt = 0.25;

accumulator += dt;

while (accumulator >= step)
{
m_world.Step(step, VELOCITY_ITERATIONS, POSITION_ITERATIONS);
accumulator -= step;
}
}


So I guess the step should not be less then FPS minimum value to avoid discrete simulation (cutting effects). Usually FPS is 1/60.0 hence I have chosen 1/70 as a step to have the best performance. And as Velocity and Position iterations I use 6 and 2 respectively which turned to be enough for collisions till today. Is my logic correct or I miss something? Is there a way to optimize more? What are the recommended values for this parameters for mobile games (considering that the game should work on week devices too). Should I use non-constant velocity iterations and position iterations reducing them when FPS drops?

First of all, if you want to avoid aliasing problems, you need to respect the Shannon rule. So you need to take 120FPS or more.

Secondly, you don't really need to care, you can simulate at 40 if you want, just be sure to linearly interpolate all of your matrices, the frame presentation time is the t, and your physics simulation always have to run some amount of frame ahead of the graphics frame, to be able to interpolate.

Thirdly, stability also depends on the integrator, apparently Box2d uses some modified Euler:
http://www.box2d.org/forum/viewtopic.php?f=8&t=1609 (symplectic Euler)
for which I would recommend not to go under 50.

Fourth, non constant integration is just a pathway to horrible explosions and weirdish problems that only your user will experiment, because of Muphy's law.

In Fifth, as you most certainly have seen in the doc your 6/2 numbers are recommended for simple simulations so they surely will do. They just indicate how many sub-iterations the constraint solver will take to clean the impulses of each body when they are in contact with multiple others.

• 1. By saying Shannon rule do you mean Nyquist–Shannon sampling theorem? If yes, then this is about sampling, what connection it has with Box2d simulation? If I would do a spring simulation, and my spring frequency would be 100Hz, then I would have to do at least 200 steps in a second. According to Erin Catto: Semi-implicit Euler will eventually blow up if you take big time steps. A general rule is to take at least 4 time steps per period of oscillation. (Erin Catto's GDC 2011 - Box2D pdf) Oct 30 '14 at 5:54
• 2. According to the doc you point out: The suggested iteration count for Box2D is 8 for velocity and 3 for position. Oct 30 '14 at 5:59
• 1. Nyquist-Shanon yes. This applies everywhere in life. you are doing sampling of a continuous phenomenon when you do stepped physical simulation. And display freq vs physics freq creates aliasing. 1,2. this rule is just a large version of Nyquist-Shanon, but related only to body behavior (e.g. rotationals etc). 2. yes but just the next line he says "in this simple case 6/2 are enough." 3. very welcome Oct 30 '14 at 6:20
• I like the idea to find the smallest period in your game (no matter it is a period of a spring, or rotation of a ball or other thing...), and set step at least 2 times smaller! Oct 30 '14 at 6:41