Havok strange behaviour when switching tabs on last versions

Bugs
1

Hi,

I’m encountering a rather weird bug with Havok. Switching tabs will apply random impulses to not currently sleeping physics objects.

You can see this happening here:

If you wait for the objects to be settled but not sleeping, switch tabs and the impulses will be applied, effect is bigger if items are stacked on top of each other.

This doesn’t happen when using version 6.49 (or at least doesn’t happen as often, still happens from time to time). You can switch the version on the playground and see

2 Likes
2

@riven04 , if you set _useDeltaForWorldStep to false in the BABYLON.HavokPlugin constructor, i.e.

new BABYLON.HavokPlugin(false)

does this issue go away for you?

I believe that when switching tabs or windows, deltaTime is still accumulating, so when you return to the BabylonJS window, it sends a large deltaTime to the Physics step calculation. This could be causing the impulse

I’m unsure why this impulse is seen on the latest 7.12.0 but not on 6.49.0

1 Like
3

This solves the problem, thank you!

Are there any downsides to not using delta time for havok?

4

If _useDeltaForWorldStep is set to false, then a fixed timestep of 1/60 seconds is used for every Physics step.

If you’re running Physics on the main thread (like in this case) and switch tabs, I believe that the tab process freezes (to some extent?) for browser performance, which freezes rendering and Physics. So when you return to the Babylon JS window, the Physics has 2 options:

  • Attempt to “catch up” to the current time by passing the large amount of time elapsed while you were on a different tab as deltaTime to the next Physics step calculation. You’ll see a transient speed-up in the Physics, e.g. an object falling 10X faster for a short period of time or an impulse
  • Forget about the time elapsed while you were on a different tab and just continue simulating Physics steps at a fixed timestep of 1/60 seconds

In summary:

  • _useDeltaForWorldStep: true is more aligned with rendering frames. But, if rendering is disrupted by switching tabs, then Physics will face a disruption too
  • _useDeltaForWorldStep: false can yield a smoother Physics simulation with less speed-ups and unexpected impulses, but is less aligned with rendering

Here’s a great article on this: Fix Your Timestep! | Gaffer On Games

2 Likes
5

Another drawback with a fixed timestep is the risk of Physics speeding up or slowing down depending on the user’s computer specs

For example: If a user’s computer is rendering frames at slower than 60 FPS, then the Physics will appear to be slower with a fixed timestep of 1/60 seconds. Conversely, if it’s rendering at faster than 60 FPS, then Physics will appear to be faster with a fixed timestep

1 Like
6

Thank you for such a detailed answer! This definitely helps when having a large amount of meshes and calculations and wanting to have a steady physics framerate.

That article is fantastic, this paragraph makes me think of what I’m experiencing without disabling dynamic physics delta:

Now consider that the majority of render frames will have some small remainder of frame time left in the accumulator that cannot be simulated because it is less than dt. This means we’re displaying the state of the physics simulation at a time slightly different from the render time, causing a subtle but visually unpleasant stuttering of the physics simulation on the screen.

For now I’ll stick with the fixed delta time for physics. I wonder if a web worker might help as it would run on the background

2 Likes