1
\$\begingroup\$

I am trying to integrate a physics engine (Bullet) into my game engine, but I immediately found that I do not know how big should I make the simulation step. I think of 2 options:

  1. Use a fixed step size of 1/60. This way I have consistent simulation. Bullet allows making multiple steps when this time is exceeded. I think this is good for consistent simulation but I think it has a big flaw and that is that position of objects will not update when my framerate is higher than 60FPS. Right now I have around 1000 FPS but it will drop significantly to around 150 I expect because I use simple materials and not many objects plus the simulation time is not included yet. Is it possible to interpolate between steps so that 2 frames are always different but check for collisions only when 1/60 of a second passed?

  2. Update physics every frame but when frame time is longer than 1/60 then use substeps. This way I should be able to get more precision but it would lower framerate because the step is performed more than 60 times per second. I definitely get the new position of the object in every frame.

Which is a better approach and why? Is there a standardized way to go about it?

I know that when slow-motion footage of CSGO is taken in every frame the position of the object change but the tick rate is just 64. Which would not update the position in every one of the 240 frames monitors can handle and duplicate frames would be created. I know that animation can be sampled at any point in time but not the position of the objects. How is that achieved?

\$\endgroup\$
6
  • 1
    \$\begingroup\$ It's all in here. \$\endgroup\$ – Vaillancourt Mar 27 at 11:15
  • \$\begingroup\$ Thanks, that is really useful. Does it mean I am technically one simulation step back? Because it seems that I interpolate between previous physic state and actual physics state even though I should interpolate between actual and future state? \$\endgroup\$ – Vít Gardoň Mar 27 at 12:14
  • \$\begingroup\$ I've haven't been able to implement it myself (unfortunately), but yes, I understand it is one frame late too. Does it really show? I don't know. \$\endgroup\$ – Vaillancourt Mar 27 at 12:43
  • \$\begingroup\$ I remember there was a (kind of) heated discussion about this in the now removed discussion on the page, where a user said so and the author said no, but I can't remember what the arguments were. \$\endgroup\$ – Vaillancourt Mar 27 at 12:54
  • \$\begingroup\$ Ok, thank you very much. You really helped a lot. \$\endgroup\$ – Vít Gardoň Mar 27 at 13:03
1
\$\begingroup\$

To close this question I will take what Vaillancourt said in the comment. This article perfectly describes how to handle physics steps.

And to clarify my other question whether we interpolate between actual and previous physic state then yes we do. It is nicely explained in this post.

Edit:
Because those links can expire I will summarize the most important information here. First, how big should the steps be? They should always be the same size. You can choose whatever number you want but the smaller the more precise it will be in exchange for computing time. But the trick is that you do not want to match frames with steps. I think this code is quite explanatory:

double t = 0.0;
const double dt = 0.01;

double currentTime = hires_time_in_seconds();
double accumulator = 0.0;

while ( !quit )
{
    double newTime = hires_time_in_seconds();
    double frameTime = newTime - currentTime;
    currentTime = newTime;

    accumulator += frameTime;

    while ( accumulator >= dt )
    {
        integrate( state, t, dt );
        accumulator -= dt;
        t += dt;
    }

    render( state );
}

We do as many steps as we can until we would exceed the current time. Which is easy to implement.

The second link explains how to have objects moving even between steps. We cannot extrapolate the movement because we could experience stutter when a collision accures. That is why we have to interpolate between actual physics state and the last physics state using linear interpolation. This allows for smooth motion in exchange for 1 step delay. But because steps are usually 1/60 of second long we do not percieve it much.

\$\endgroup\$
2
  • 1
    \$\begingroup\$ This is currently a link-only answer. If those two links rot, then a future user won't be able to glean anything from this post. Can you edit the answer to summarize the key points that helped you from these sources? \$\endgroup\$ – DMGregory Mar 27 at 13:41
  • 1
    \$\begingroup\$ Good point. I will summarize my finding and I will edit the answer. I will also mark it as solved but I can do that only after 2 day it said \$\endgroup\$ – Vít Gardoň Mar 27 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.