With physical simulations, you don't want to vary the time rate because what you most likely are using is a "Discrete" solver. What this means, is that it ignores the between state of objects between each "step". Sub-stepping and sweeping to check for tunneling also fall under the Discrete Solver umbrella.

Variable time-steps can only be faithfully used in simulations that use a "Continuous Solver", which involves extremely high-end mathematics and can't be used for real-time applications, games for instance.

For a Discrete Solver, think of time as flowing in chunks. It only advances when you call the "step" function. If you call step() 60 times a second, then time flows forward 60 chunks in one second of our time. If you call step() only 30 times per second, it advances only 30 chunks, and from our perspective it appears to be half as fast. But within the simulation, it does not see that.

If you vary the time between frames in the way you describe, what you are doing is actually causing the 'chunks' of time to become larger and smaller arbitrarily. It would be as though time in our reality got choppier then smoother, and it'd cause all sorts of problems for us.

As for how to set up the timestep, assuming you want the framerate to be 60...

int last_time = 0;
int recent_time = 0;
int times_executed = 0;
// ...

last_time = recent_time;
times_executed = 0;
recent_time = getTimeInMS();
while(recent_time + times_executed * 1000/60 < last_time + 1000/60){
    physics.step();
    times_executed += 1;
}

I haven't tested the above but it may help you get started

With physical simulations, you don't want to vary the time rate because what you most likely are using is a "Discrete" solver. What this means, is that it ignores the between state of objects between each "step". Sub-stepping and sweeping to check for tunneling also fall under the Discrete Solver umbrella.

Variable time-steps can only be faithfully used in simulations that use a "Continuous Solver", which involves extremely high-end mathematics and can't be used for real-time applications, games for instance.

For a Discrete Solver, think of time as flowing in chunks. It only advances when you call the "step" function. If you call step() 60 times a second, then time flows forward 60 chunks in one second of our time. If you call step() only 30 times per second, it advances only 30 chunks, and from our perspective it appears to be half as fast. But within the simulation, it does not see that.

If you vary the time between frames in the way you describe, what you are doing is actually causing the 'chunks' of time to become larger and smaller arbitrarily. It would be as though time in our reality got choppier then smoother, and it'd cause all sorts of problems for us.

As for how to set up the timestep, assuming you want the framerate to be 60...

int last_time = 0;
int recent_time = 0;
int times_executed = 0;
float time_step = 1000.0 / 60.0;
// ...

last_time = recent_time;
times_executed = 0;
recent_time = getTimeInMS();
while(recent_time + (times_executed * time_step) < last_time + time_step){
    physics.step(time_step);
    times_executed += 1;
}

I haven't tested the above but it may help you get started