The simulation runs too fast

[TheDiagnosed9mm]

The simulation runs too fast

[jrouwe]

Hello,

This is a known issue. Currently the sample app uses the VSYNC to display frames but it uses a fixed time step of 60 Hz to simulate physics. I didn't want to implement any interpolation to go to a higher frequency as then you wouldn't see the exact output of the physics engine anymore and I also didn't want to support a variable delta time since that messes with the determinism of the simulation.

In the menu "Physics Settings" / "Update Frequency" you can set the fixed tick rate and if you match it to your monitors refresh rate you should get a simulation that runs normal.

I think I will implement a change that just delays the rendering of the next frame until 1/60th of a second has passed since the last frame to fix things for high frequency monitors.

[cuppajoeman]

I have a limited understanding about how the samples work, keep this in mind.

From what I can tell the driver to all the samples is the class SamplesApp located in Samples/SamplesApp.cpp, in this file we have the following method:

JoltPhysics/Samples/SamplesApp.cpp

Line 2374 in b622c59

void SamplesApp::StepPhysics(JobSystem *inJobSystem)

Open this up, and go down a few lines, you'll see that they define delta_time as 1/mUpdateFrequency and use that to update the physics system.

which uses mUpdateFrequency which is defined in the header file:

JoltPhysics/Samples/SamplesApp.h

Line 90 in b622c59

float mUpdateFrequency = 60.0f; // Physics update frequency

Thus from what I've seen you're correct about these samples being frame rate dependent. In order to fix this we would need to a method to come up with a dynamic delta_time based on how much time has passed since the last physics update.

When scrolling through SamplesApp.cpp I thought I might have seen code which can control the update frequency with a slider. If this is true, then perhaps you can use a slider to choose an update frequency which will make the samples not "fast" on your computer. Otherwise you can always hardcode a value for your update frequency and recompile.

If you actually wanted frame independent simulation Glen has a good article on this: https://gafferongames.com/post/fix_your_timestep/ and I have an implementation of this on my site here: https://cuppajoeman.com/toolbox/game_dev/game_loop/.

Not sure what your experience is with contributing and c++, but I think the best case could be to have an option which can enable frame independent simulation in the samples app, which could be contributed via a pull request.