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?
Answer
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.
No comments:
Post a Comment