Window resizing and physics

I got a weird behavior having physics enabled.
The scene is a simple sphere lying on a plane.
When I resize the window this also impacts the physics.
I.e. I noticed that when I very fast resize the window with the mouse that the sphere begins to bounce.

Anyone knows where this comes from?

pinging @Cedric our physics expert

Hi @maziac

When resizing the window, the delta time between 2 frames is not constant. If that delta is too big, then a deeper penetration happens and the sphere bounces to compensate.

You can try 2 things to fix that:

I would love to test that but how can I set the ticks to a constant value. Didn’t find how to do it (CaonnonJs).
And for the sub steps: This doesn’t seem to be available in Cannon.

Here is the simple scene:
https://playground.babylonjs.com/#VFR71J#15

If I take the bottom border of the browser window with the mouse and move up down very fast nothing happens. I.e. the PG is behaving correctly even when the frame rate goes down.

But if I use exactly the same code in e.g. an Electron app then moving the bottom of the window (i.e. resizing the window) results in a bouncing ball.

The resizing code does nothing more than:


        // Listener for resize
        window.addEventListener("resize", () => {
            engine.resize();
        })

How can that be?

let me check …

Can you try to increase the iterations value in cannon constructor? Default is 10, try 30 or 50.

I tried with 50. Difficult to say. It seems harder but it is still possible to achieve the same effect.

are you using the delta for world steps? (first variable of the cannonjs plugin constructor)

I can’t seem to be able to reproduce this in the browser (and if i read correctly it only happens in an electron app). A simple solution would be to reset all velocities when the window resizes. It depends on the usecase of course. It could be catastrophical mid-game (well, depends on the game :-)), but in a scene like the one you show it will work correctly.

Another suggestions I have is to debounce (or better yet - throttle) the resize calls. window resize is triggered on each frame, and this could hurt performance (which in turn can cause these issues). Maybe if you run the resize code once every 200ms (or even 500ms) it will work better

1 Like

I experimented with the other parameter.
If _useDeltaForWorldStep is set to false it seems to do the trick. I guess this is what you meant with “fixed delta time”.

1 Like

Thanks very much for the help.