World.step is buggy when attempting to account for variable framerate

When passing a timeSinceLastCalled value to the world.step method, the simulation performance quickly degrades beyond usability.

Example usage: Cannon demo

cannon.js issue 371

Article: Fix your timestep

Spectrum chat: World step does not adapt to framerate

Per Schteppe (schteppe#371):

Perhaps the number of substeps are maxed out? This could happen if you, for example, pass in deltaTime in milliseconds instead of seconds… or if you accidentally calculate the value wrong for the first frame (there is no “previous” time value). or if the first deltaTime values are too large (they usually are larger during the first frames while the JIT is warming up). What happens if you pass in 1000 substeps instead of 10? If you have implemented it correctly, changing the number of substeps should do nothing.

[Platane]

yes it seems so, although it also brings questionable features ( “timeSinceLastCalled = -1 instead of 0” )

I am not sure this address the cube freezing midair effect, I am looking into that.

[codynova]

~This looks good and is working well now except for the freezing cubes (no framerate degradation in my testing). We should wait to merge until that issue is resolved.~

I agree with Marco regarding API changes, we should strive to make as few API changes as possible, and maintain backwards compatibility where we can.

@Platane Great work on this so far, I think supporting variable framerate would be a huge feature.

EDIT: I spoke too soon regarding framerate performance