3 ms·

Compared to the original liquidfun tests, e.g. the wave tank, this looks a lot more unstable and has more of a tendency to form solid-like crystal structures in

Compared to the original liquidfun tests, e.g. the wave tank, this looks a lot more unstable and has more of a tendency to form solid-like crystal structures inside the liquid, which damp out total momentum faster than you want. I suspect you could improve the realism quite a bit by tuning either time step size (downwards) or the particle interaction strength. Or there is a bug introduced somewhere in the rebasing process.

Birch-san 5y ago
yeah, I've played around with a few approaches for running the timestep and for some reason I don't feel like I get the same results as liquidfun.js. their loop [0] is pretty simple; it's scheduled by `requestAnimationFrame`, advances time by 1/60th of a second, and runs their default of 3 particle iterations. it completes the physics simulation within 3.9–5.5ms, which is easily in time for the 16ms deadline. the rendering is WebGL, which I assume fits easily into that 16ms budget too. my loop [1] is more complicated; I don't hardcode the timestep to 1/60 seconds, because requestAnimationFrame may be scheduled less frequently than that. so instead I advance time by the time elasped since I was last scheduled. hm, I think there's a mistake there — `lastMs = nowMs` is probably on the wrong side of the physics calculation. there's an additional technique I use: I put a `Math.min()` over the simulation interval, so that I don't attempt to simulate more than 20ms (this can happen if you get scheduled infrequently due to hot CPU or backgrounding the app) — simulating too much time will make us fail our frame deadline anyway. furthermore, if we are calculating more than 1/60th of a second, I employ more particle iterations (i.e. 3 particle iterations for every 1/60th of a second that passes). this gave me good results, but turns out it is based on incorrect assumptions (iterations are unrelated to timestep)[3]. moreover, I may be making mistakes in my decision of whether to round this fraction up/down. if too few particle iterations for a timestep: the particles will bounce. if too many: the particles will look too incompressible[4]. I think that's the "solid-like" structure you're describing. the main reason I complicated this is because the last one I did[5] made me feel motion-sick. I think if "every 1/60th, or 1/30th, or 1/20th of a second: you simulate a 1/60th of a second of time": the result (if you're not scheduled consistently) is that the world speed keeps changing. I think liquidfun.js's approach should be vulnerable to this, but for some reason it looks fine to me. maybe they get scheduled more consistently than me (even though by my measurements, my physics runs slightly faster, so should be able to achieve similar results). I think I need to remind myself of what happens if I program the timestep in the simple way that liquidfun.js did. will try that out at some point. [0] https://github.com/google/liquidfun/blob/master/liquidfun/Box2D/lfjs/testbed/testbed.js#L165 https://github.com/google/liquidfun/blob/master/liquidfun/Bo... [1] https://github.com/Birch-san/liquidfun-play-2/blob/master/src/loop.ts#L247 https://github.com/Birch-san/liquidfun-play-2/blob/master/sr... [2] https://github.com/Birch-san/liquidfun-play-2/blob/master/src/demo/gravity.ts#L331 https://github.com/Birch-san/liquidfun-play-2/blob/master/sr... [3] http://google.github.io/liquidfun/Programmers-Guide/html/md__chapter02__hello__box2_d.html#stw http://google.github.io/liquidfun/Programmers-Guide/html/md_... [4] http://google.github.io/liquidfun/Programmers-Guide/html/md__chapter11__particles.html#stw http://google.github.io/liquidfun/Programmers-Guide/html/md_... [5] https://birchlabs.co.uk/box2d-wasm-liquidfun/ https://birchlabs.co.uk/box2d-wasm-liquidfun/
Birch-san 5y ago
okay, have another look now[0]. I've updated it to use a consistent number of particle iterations regardless of how much time is being simulated. in fact, you've caught that it was using as many as 16 iterations (my intention was 3), so this change should make it substantially more performant and less stiff. moreover, I found that some objects were being allocated by my perf-measurement code. ironically making it slower. fixed now. if it needs to simulate large stretches of time: I now split that into multiple 1/60th-second world.Step() calls, instead of attempting to scale up the time and number of iterations. as a result of these changes: Wave Machine now looks a bit more like the original liquidfun.js demo. Gravity looks a bit more stable now (doesn't bounce when the scheduler throttles us). I've also added a safeguard to help underpowered devices. if we determine that we're not simulating fast enough to finish in a timely manner: we settle for simulating just 1/60th of a second (i.e. even if 1/20th of a second elapsed since we were last scheduled). this admittedly results in slow-mo, but is preferable to exacerbating the perf problem (and has a chance of getting us back-on-track). [0] https://birchlabs.co.uk/liquidfun-wasm/ https://birchlabs.co.uk/liquidfun-wasm/

Birch-san 5y ago

yeah, I've played around with a few approaches for running the timestep and for some reason I don't feel like I get the same results as liquidfun.js. their loop [0] is pretty simple; it's scheduled by `requestAnimationFrame`, advances time by 1/60th of a second, and runs their default of 3 particle iterations. it completes the physics simulation within 3.9–5.5ms, which is easily in time for the 16ms deadline. the rendering is WebGL, which I assume fits easily into that 16ms budget too. my loop [1] is more complicated; I don't hardcode the timestep to 1/60 seconds, because requestAnimationFrame may be scheduled less frequently than that. so instead I advance time by the time elasped since I was last scheduled. hm, I think there's a mistake there — `lastMs = nowMs` is probably on the wrong side of the physics calculation. there's an additional technique I use: I put a `Math.min()` over the simulation interval, so that I don't attempt to simulate more than 20ms (this can happen if you get scheduled infrequently due to hot CPU or backgrounding the app) — simulating too much time will make us fail our frame deadline anyway. furthermore, if we are calculating more than 1/60th of a second, I employ more particle iterations (i.e. 3 particle iterations for every 1/60th of a second that passes). this gave me good results, but turns out it is based on incorrect assumptions (iterations are unrelated to timestep)[3]. moreover, I may be making mistakes in my decision of whether to round this fraction up/down. if too few particle iterations for a timestep: the particles will bounce. if too many: the particles will look too incompressible[4]. I think that's the "solid-like" structure you're describing. the main reason I complicated this is because the last one I did[5] made me feel motion-sick. I think if "every 1/60th, or 1/30th, or 1/20th of a second: you simulate a 1/60th of a second of time": the result (if you're not scheduled consistently) is that the world speed keeps changing. I think liquidfun.js's approach should be vulnerable to this, but for some reason it looks fine to me. maybe they get scheduled more consistently than me (even though by my measurements, my physics runs slightly faster, so should be able to achieve similar results). I think I need to remind myself of what happens if I program the timestep in the simple way that liquidfun.js did. will try that out at some point. [0] https://github.com/google/liquidfun/blob/master/liquidfun/Box2D/lfjs/testbed/testbed.js#L165 https://github.com/google/liquidfun/blob/master/liquidfun/Bo... [1] https://github.com/Birch-san/liquidfun-play-2/blob/master/src/loop.ts#L247 https://github.com/Birch-san/liquidfun-play-2/blob/master/sr... [2] https://github.com/Birch-san/liquidfun-play-2/blob/master/src/demo/gravity.ts#L331 https://github.com/Birch-san/liquidfun-play-2/blob/master/sr... [3] http://google.github.io/liquidfun/Programmers-Guide/html/md__chapter02__hello__box2_d.html#stw http://google.github.io/liquidfun/Programmers-Guide/html/md_... [4] http://google.github.io/liquidfun/Programmers-Guide/html/md__chapter11__particles.html#stw http://google.github.io/liquidfun/Programmers-Guide/html/md_... [5] https://birchlabs.co.uk/box2d-wasm-liquidfun/ https://birchlabs.co.uk/box2d-wasm-liquidfun/

Birch-san 5y ago

okay, have another look now[0]. I've updated it to use a consistent number of particle iterations regardless of how much time is being simulated. in fact, you've caught that it was using as many as 16 iterations (my intention was 3), so this change should make it substantially more performant and less stiff. moreover, I found that some objects were being allocated by my perf-measurement code. ironically making it slower. fixed now. if it needs to simulate large stretches of time: I now split that into multiple 1/60th-second world.Step() calls, instead of attempting to scale up the time and number of iterations. as a result of these changes: Wave Machine now looks a bit more like the original liquidfun.js demo. Gravity looks a bit more stable now (doesn't bounce when the scheduler throttles us). I've also added a safeguard to help underpowered devices. if we determine that we're not simulating fast enough to finish in a timely manner: we settle for simulating just 1/60th of a second (i.e. even if 1/20th of a second elapsed since we were last scheduled). this admittedly results in slow-mo, but is preferable to exacerbating the perf problem (and has a chance of getting us back-on-track). [0] https://birchlabs.co.uk/liquidfun-wasm/ https://birchlabs.co.uk/liquidfun-wasm/