Page 2 of 2
Re: Physics determinism test
Posted: Fri Dec 17, 2021 4:30 pm
by pgimeno
Works the same in both. Interestingly, the result is different (chaotic, as expected) in versions 0.9 and 0.10, but it's unclear whether that's because of the PRNG or Box2D; using LuaJIT's math.random instead of love.math.newRandomGenerator might shed light on that. The final layout is also different in 0.9 vs 0.10.
Re: Physics determinism test
Posted: Fri Dec 17, 2021 5:38 pm
by grump
pgimeno wrote: ↑Fri Dec 17, 2021 4:30 pm
Works the same in both. Interestingly, the result is different (chaotic, as expected) in versions 0.9 and 0.10
Thanks for testing! I don't really care about the older versions, although it would be interesting to know what's causing the difference.
Here's another, more interesting one just for shits and giggles. I couldn't figure out a nice and easy way to draw circles in this one, so it's quads this time.
Re: Physics determinism test
Posted: Fri Dec 17, 2021 10:22 pm
by ReFreezed
Perfect. 10/10.
Re: Physics determinism test
Posted: Tue Dec 21, 2021 3:48 pm
by milon
Haha, nice!
Picture was perfectly coherent for me on Linux Mint desktop.
Re: Physics determinism test
Posted: Sat Oct 15, 2022 12:25 pm
by knorke
bumping this thread for a note:
I think this test is only deterministic because it updates the physics like this:
Code: Select all
local accum = 0
function love.update(dt)
accum = accum + math.min(dt, 1 / 20)
while accum >= 1 / 60 do
world:update(1 / 60)
....
Note how world:update() is called with a constant as parameter. NOT with the variable dt.
(The speed is limited by accumelating dt-timesteps only it is above a threshold and then update)
If
world:update(1 / 60) is replaced by
world:update(dt) then the program shows a different outcome on every run. (even on the same machine)
Re: Physics determinism test
Posted: Sun Oct 16, 2022 8:23 am
by pgimeno
knorke wrote: ↑Sat Oct 15, 2022 12:25 pm
bumping this thread for a note:
I think this test is only deterministic because it updates the physics like this:
[...]
Note how world:update() is called with a constant as parameter. NOT with the variable dt.
Duh. It's a chaotic process. Any minimal variation in any parameter causes radically different results. The test was for cross-platform reproducibility, i.e. whether identical inputs produced identical results in all platforms. Obviously you don't get identical inputs if your dt varies between frames.
I've made a modified version so that when pressing certain keys, a very slight variation is introduced in the simulation.
- Pressing space introduces a single frame with dt = 1/59.9999 instead of 1/60.
- Pressing return multiplies one of the random numbers by 0.99999 in one frame.
- Pressing an arrow key moves the obstacle 0.0001 units in the given direction.
If you press any of these keys early on, everything is different; if you press it when part of the image is already formed, anything after that is chaotic.