How to implement deltaTime with blender's physics engine?

Question

From my experience, it doesn't seem that deltaTime is implemented with blender's physics. I may be wrong as testing this was extremely difficult. Please let me know if I'm wrong and deltaTime is implemented.

---

Why does deltaTime matter?

Generally, games don't lock your framerate in order to have your game run as quick as your PC is able to. If the framerate is locked, the game will run at different speeds if your framerate is under the cap. To fix this, we uncap the framerate and we implement deltaTime into our code. This way, the game runs at the same speed, and you can run the game at any framerate. If we uncap the framerate and don't use deltaTime, then the game would run faster when your framerate is high.

Why is this a problem?

If deltaTime isn't implemented in blender's physics, then the results would be different at difference framerates. For example, friction wouldn't work properly as someone playing with 120 framerate would take friction twice more than someone playing with 60.

Do I have any idea as to what we can do?

Ofcourse, we can simply have blender implement deltaTime into its physics. Alternatively, (what I tried to do), we can remove blender's physics and code our own physics engine. I've ran into a million problems with this, and I don't think it would make sense to go this way.

Answer 1

I was not able to come up with a solution (yet), but I'd like to share some progress I made. Maybe framerate-independent realtime physics is not possible, but let's keep the mindset "There is a way, we just haven't found it yet" for now.

Testcase

blackhole mentioned, that it's extremely difficult to test whether Blenders Bullet Physics run in RealTime or not. So I looked for a simple real-world example which could serve as a reference for comparing an expectation vs. what Blender is doing. I have choosen a simple free-falling cube, which is placed at a height above an object so that it should hit the ground after exactly 2 seconds (no friction, air resistance or other fancy stuff).

Here's the setup (*blend below):

When pressing "SPACE", you can observe the framerate dropping - I put some sleep in a Python controller.

Parameters of Interest

The first four of the following list are new since 2.77 as far as I know.

• bge.logic.getClockTime()
• bge.logic.getFrameTime()
• bge.logic.getRealTime()
• bge.logic.getTimeScale()
• Objects "Timer" properties
• Render -> System -> "use Frame rate" Checkbox
• World -> Phsyics -> "FPS" value

There are several versions of Time available, which I personally find confusing. I used getRealTime (system clock) to measure the time of collision of the falling cube.

Observations

Some of them are obvious to more experienced BGE users (than me), but I'd like to write them down nevertheless. The time of collision

1. was at least one frame delayed. (2.016 seconds at 60 FPS)
2. went down (=cube fell faster) by a factor of 2 in case I put 30 FPS in physics and uncecked "Use Frame Rate" - the simulation was running at 60 FPS then.
3. went up once I added some expensive logic which let the framerate go down (sleep, triggered by SPACE)
4. varied with the "margin" setting in the objects collision bounds settings.

Whatever I tried so far, I did not find a solution which let the cube hit the ground after 2 seconds when I let the framerate drop by the sleeps. In case frame-independent realtime physics are possible in Blender, there should be a way of making that happen. The new setUseExternalClock and setClockTime might be an option. Maybe my *.blend helps along the way.