8 ms·

Show HN: WASM and WebGL Fluid Simulation

86 points by Birch-san 5y ago

smerik 5y ago
Looks amazing!
LinguaBrowse 5y ago
> Built with box2d-wasm's liquidfun release. Very nice! How does this relate to the Google official release of Liquidfun, and the mainline release of Box2D?
- Birch-san 5y ago
  Liquidfun [0] diverged from Box2D at v2.3.0, circa November 2013. liquidfun-wasm [1] is my effort to rebase the liquidfun contributions onto latest Box2D, v2.4.1 (October 2020), and to distribute it in WebAssembly with TypeScript typings. this work is detailed in liquidfun-wasm's first release notes. [2] I've also enabled WASM SIMD acceleration (via LLVM's autovectorizer) on supported devices. Haven't yet measured what performance difference this makes. [0] http://google.github.io/liquidfun/ http://google.github.io/liquidfun/ [1] https://github.com/Birch-san/box2d-wasm/releases/tag/liquidfun-v6.0.4-lf.1 https://github.com/Birch-san/box2d-wasm/releases/tag/liquidf... [2] https://github.com/Birch-san/box2d-wasm/releases/tag/v4.0.0-liquidfun.0 https://github.com/Birch-san/box2d-wasm/releases/tag/v4.0.0-...
zbendefy 5y ago
Awesome! Does it use wasm-simd? If it does do you know how much impact it has on the performance?
- Birch-san 5y ago
  yes, I compiled with -msimd128 to enable LLVM's auto-vectorization. I distribute both SIMD and non-SIMD, and the entrypoint picks whichever distribution your browser supports. for box2d-wasm, SIMD acceleration resulted in a 0.6–0.9% performance boost [0] when simulating a pyramid of boxes. liquidfun-wasm is a fork with additional algorithms for performantly simulating particles. I have not yet built a benchmark to measure the particle code, but do intend to. I am optimistic that liquidfun's particle code could auto-vectorize better than the general Box2D code. the Google engineers considered how to take advantage of SIMD, to the extent that they even ship a NEON SIMD algorithm[1]. I don't believe my compiler config will use that NEON algorithm (and will instead fallback to the general algorithm [2]). that's probably not a missed opportunity; many NEON features are not supported[3]. but since the engineers were thinking about SIMD, hopefully the non-NEON algorithm will try to make good use of the CPU and memory layout too, and auto-vectorize well. [0] https://github.com/Birch-san/box2d.ts/pull/1 https://github.com/Birch-san/box2d.ts/pull/1 [1] https://github.com/google/liquidfun/blob/master/liquidfun/Box2D/Box2D/Particle/b2ParticleAssembly.neon.s https://github.com/google/liquidfun/blob/master/liquidfun/Bo... [2] https://github.com/google/liquidfun/blob/master/liquidfun/Box2D/Box2D/Particle/b2ParticleSystem.cpp https://github.com/google/liquidfun/blob/master/liquidfun/Bo... [3] https://emscripten.org/docs/porting/simd.html#compiling-simd-code-targeting-arm-neon-instruction-set https://emscripten.org/docs/porting/simd.html#compiling-simd...
Zababa 5y ago
It looks really good! Gravity, drag and temporal blend make nice visual effects.
dumindaxsb 5y ago
This is cool!
mrspeaker 5y ago
This looks great - I like how the "simple shader" version gives a sense for how it works under the hood. Is the implementation of it related to real-world mechanisms, or is it all smoke-and-mirrors that happens to look like real-world liquids? (Or, is the distinction non-important?!)
- kitd 5y ago
  is the distinction non-important?! Interesting. A kind of universal "Turing test" :)
- Birch-san 5y ago
  it's all modelled using physical laws; see slides 16 onwards of the "Inside Liquidfun" presentation: http://docs.google.com/presentation/d/1fEAb4-lSyqxlVGNPog3G1LZ7UgtvxfRAwR0dwd19G4g/edit?usp=sharing http://docs.google.com/presentation/d/1fEAb4-lSyqxlVGNPog3G1...
VinLucero 5y ago
I worked on this at Google! We built another open source example app called Voltair based on LiquidFun: https://github.com/google/VoltAir https://github.com/google/VoltAir
- ranguna 5y ago
  Your landing page returns a 404
- Birch-san 5y ago
  wow! thanks for your contributions. :) would you mind giving some background on how LiquidFun came into existence? is it a 20% time project, or a weekend thing made by Googlers? was there ever a business case for it?
  - VinLucero 5y ago
    So LiquidFun was spun out of a full time “Google Games” team where I helped out as producer and level designer in a 20% role. VoltAir was the game where we wanted to showcase a few new technologies: how to build a game using tech other than Unity (which still dominates mobile game dev), first party Android TV and controller support examples, and of course LiquidFun which also powered LiquidFun paint. https://youtu.be/MjqB0OPcwh0 https://youtu.be/MjqB0OPcwh0 The longer term business vision was what you now know as Stadia which evolved from Chromecast and Android TV experiments like these.
kitd 5y ago
Very impressed by how well this works on mobile.
Kiro 5y ago
Is this faster than a regular JS+WebGL version?
- Birch-san 5y ago
  yes. the fastest "regular JS" version achievable would be via asm.js, and WebAssembly can go faster[0]. you can compare the performance of this demo's Wave Machine mode against the one used on the liquidfun.js frontpage[1]: in my crude measurement just now, a `Step()` took liquidfun.js 3.9–5.52ms, whereas it took 3.6–3.7ms in liquidfun-wasm. take with a pinch of salt since I just sampled a few random frames of each experiment at random CPU temperatures. [0] https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-... [1] http://google.github.io/liquidfun/ http://google.github.io/liquidfun/
Birch-san 5y ago
Author here. This demo showcases liquidfun-wasm[0], my effort to revive liquidfun[1] (a fork which adds fluid simulation and soft-body physics to Box2D[2]). to make liquidfun-wasm, I repurposed my existing box2d-wasm[3] and pointed it at a different release of Box2D — a commit obtained by rebasing liquidfun over 7 years of upstream Box2D changes[4]. the end result is that liquidfun is now distributed in WebAssembly and with TypeScript typings for the first time. The TypeScript typings are generated from WebIDL bindings via my webidl-to-ts[5] compiler. this demo in particular aims to bring to the Web the shaders from the liquidfun EyeCandy demo[6], and show how fast JS can run if you avoid incurring the garbage collector (the main loop tries not to allocate objects). the demo repurposes gravity and drag calculations that I'd used previously in my Lunar Survey experiment[7] (a Mario Galaxy homage). [0] https://github.com/Birch-san/box2d-wasm/releases/tag/liquidfun-v6.0.4-lf.1 https://github.com/Birch-san/box2d-wasm/releases/tag/liquidf... [1] http://google.github.io/liquidfun/ http://google.github.io/liquidfun/ [2] https://github.com/erincatto/box2d https://github.com/erincatto/box2d [3] https://github.com/Birch-san/box2d-wasm https://github.com/Birch-san/box2d-wasm [4] https://github.com/Birch-san/box2d-wasm/releases/tag/v4.0.0-liquidfun.0 https://github.com/Birch-san/box2d-wasm/releases/tag/v4.0.0-... [5] https://github.com/Birch-san/box2d-wasm/tree/master/webidl-to-ts https://github.com/Birch-san/box2d-wasm/tree/master/webidl-t... [6] https://github.com/google/liquidfun/blob/master/liquidfun/Box2D/EyeCandy/engine.cpp https://github.com/google/liquidfun/blob/master/liquidfun/Bo... [7] https://birchlabs.co.uk/lunar-survey/ https://birchlabs.co.uk/lunar-survey/
semi-extrinsic 5y ago
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/
faeyanpiraat 5y ago
It works on iphone 7 but the page does a refresh 2 seconds in to a fallback page then again to s “problem occured” page
Loeffelmann 5y ago
Could you train a ML model that fills in the gaps in the fluid simulation like they do in ray tracing?
Loeffelmann 5y ago
Could you train a ML model that smoothes out the fluid simulation like they do with ray tracing?
- Birch-san 5y ago
  yes, I think so! some examples here[0][1]. [0] https://www.youtube.com/watch?v=2Bw5f4vYL98 https://www.youtube.com/watch?v=2Bw5f4vYL98 [1] https://www.youtube.com/watch?v=atcKO15YVD8 https://www.youtube.com/watch?v=atcKO15YVD8
TazeTSchnitzel 5y ago
http://madebyevan.com/webgl-water/ http://madebyevan.com/webgl-water/ is a decade old but still impresses me. The water caustics are particularly neat.
- Birch-san 5y ago
  yes, that demo has very impressive shaders. it models the physics in a more simple way though (i.e. as waves), rather than as thousands of particles, so it can't generalize to more complex scenarios.
inDigiNeous 5y ago
Nice to see such a high performance demo running on web technologies, gives me trust that we can finally do more complex and jitter-free graphics on web-applications. Thanks for sharing and creating this.
_448 5y ago
What is the total size of the webpage that is downloaded to the user system?
- Birch-san 5y ago
  network inspector says 2.1MB. but that's dominated by a 1.3MB image. the main assets of the library are: - Box2D.simd.js (422kB) - Box2D.simd.wasm (266 kB) a minimal demo that uses the library can be created in just a few kB: https://github.com/Birch-san/box2d-wasm/tree/master/demo/modern/public https://github.com/Birch-san/box2d-wasm/tree/master/demo/mod...

86 points by Birch-san 5y ago

Looks amazing!

> Built with box2d-wasm's liquidfun release. Very nice! How does this relate to the Google official release of Liquidfun, and the mainline release of Box2D?

Birch-san 5y ago
Liquidfun [0] diverged from Box2D at v2.3.0, circa November 2013. liquidfun-wasm [1] is my effort to rebase the liquidfun contributions onto latest Box2D, v2.4.1 (October 2020), and to distribute it in WebAssembly with TypeScript typings. this work is detailed in liquidfun-wasm's first release notes. [2] I've also enabled WASM SIMD acceleration (via LLVM's autovectorizer) on supported devices. Haven't yet measured what performance difference this makes. [0] http://google.github.io/liquidfun/ http://google.github.io/liquidfun/ [1] https://github.com/Birch-san/box2d-wasm/releases/tag/liquidfun-v6.0.4-lf.1 https://github.com/Birch-san/box2d-wasm/releases/tag/liquidf... [2] https://github.com/Birch-san/box2d-wasm/releases/tag/v4.0.0-liquidfun.0 https://github.com/Birch-san/box2d-wasm/releases/tag/v4.0.0-...

zbendefy 5y ago

Awesome! Does it use wasm-simd? If it does do you know how much impact it has on the performance?

Birch-san 5y ago
yes, I compiled with -msimd128 to enable LLVM's auto-vectorization. I distribute both SIMD and non-SIMD, and the entrypoint picks whichever distribution your browser supports. for box2d-wasm, SIMD acceleration resulted in a 0.6–0.9% performance boost [0] when simulating a pyramid of boxes. liquidfun-wasm is a fork with additional algorithms for performantly simulating particles. I have not yet built a benchmark to measure the particle code, but do intend to. I am optimistic that liquidfun's particle code could auto-vectorize better than the general Box2D code. the Google engineers considered how to take advantage of SIMD, to the extent that they even ship a NEON SIMD algorithm[1]. I don't believe my compiler config will use that NEON algorithm (and will instead fallback to the general algorithm [2]). that's probably not a missed opportunity; many NEON features are not supported[3]. but since the engineers were thinking about SIMD, hopefully the non-NEON algorithm will try to make good use of the CPU and memory layout too, and auto-vectorize well. [0] https://github.com/Birch-san/box2d.ts/pull/1 https://github.com/Birch-san/box2d.ts/pull/1 [1] https://github.com/google/liquidfun/blob/master/liquidfun/Box2D/Box2D/Particle/b2ParticleAssembly.neon.s https://github.com/google/liquidfun/blob/master/liquidfun/Bo... [2] https://github.com/google/liquidfun/blob/master/liquidfun/Box2D/Box2D/Particle/b2ParticleSystem.cpp https://github.com/google/liquidfun/blob/master/liquidfun/Bo... [3] https://emscripten.org/docs/porting/simd.html#compiling-simd-code-targeting-arm-neon-instruction-set https://emscripten.org/docs/porting/simd.html#compiling-simd...

Zababa 5y ago

It looks really good! Gravity, drag and temporal blend make nice visual effects.

dumindaxsb 5y ago

This is cool!

mrspeaker 5y ago

This looks great - I like how the "simple shader" version gives a sense for how it works under the hood. Is the implementation of it related to real-world mechanisms, or is it all smoke-and-mirrors that happens to look like real-world liquids? (Or, is the distinction non-important?!)

kitd 5y ago
is the distinction non-important?! Interesting. A kind of universal "Turing test" :)
Birch-san 5y ago
it's all modelled using physical laws; see slides 16 onwards of the "Inside Liquidfun" presentation: http://docs.google.com/presentation/d/1fEAb4-lSyqxlVGNPog3G1LZ7UgtvxfRAwR0dwd19G4g/edit?usp=sharing http://docs.google.com/presentation/d/1fEAb4-lSyqxlVGNPog3G1...

VinLucero 5y ago

I worked on this at Google! We built another open source example app called Voltair based on LiquidFun: https://github.com/google/VoltAir https://github.com/google/VoltAir

ranguna 5y ago
Your landing page returns a 404
Birch-san 5y ago
wow! thanks for your contributions. :) would you mind giving some background on how LiquidFun came into existence? is it a 20% time project, or a weekend thing made by Googlers? was there ever a business case for it?
- VinLucero 5y ago
  So LiquidFun was spun out of a full time “Google Games” team where I helped out as producer and level designer in a 20% role. VoltAir was the game where we wanted to showcase a few new technologies: how to build a game using tech other than Unity (which still dominates mobile game dev), first party Android TV and controller support examples, and of course LiquidFun which also powered LiquidFun paint. https://youtu.be/MjqB0OPcwh0 https://youtu.be/MjqB0OPcwh0 The longer term business vision was what you now know as Stadia which evolved from Chromecast and Android TV experiments like these.

kitd 5y ago

Very impressed by how well this works on mobile.

Kiro 5y ago

Is this faster than a regular JS+WebGL version?

Birch-san 5y ago
yes. the fastest "regular JS" version achievable would be via asm.js, and WebAssembly can go faster[0]. you can compare the performance of this demo's Wave Machine mode against the one used on the liquidfun.js frontpage[1]: in my crude measurement just now, a `Step()` took liquidfun.js 3.9–5.52ms, whereas it took 3.6–3.7ms in liquidfun-wasm. take with a pinch of salt since I just sampled a few random frames of each experiment at random CPU temperatures. [0] https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-than-asm-js/ https://hacks.mozilla.org/2017/03/why-webassembly-is-faster-... [1] http://google.github.io/liquidfun/ http://google.github.io/liquidfun/

Birch-san 5y ago

Author here. This demo showcases liquidfun-wasm[0], my effort to revive liquidfun[1] (a fork which adds fluid simulation and soft-body physics to Box2D[2]). to make liquidfun-wasm, I repurposed my existing box2d-wasm[3] and pointed it at a different release of Box2D — a commit obtained by rebasing liquidfun over 7 years of upstream Box2D changes[4]. the end result is that liquidfun is now distributed in WebAssembly and with TypeScript typings for the first time. The TypeScript typings are generated from WebIDL bindings via my webidl-to-ts[5] compiler. this demo in particular aims to bring to the Web the shaders from the liquidfun EyeCandy demo[6], and show how fast JS can run if you avoid incurring the garbage collector (the main loop tries not to allocate objects). the demo repurposes gravity and drag calculations that I'd used previously in my Lunar Survey experiment[7] (a Mario Galaxy homage). [0] https://github.com/Birch-san/box2d-wasm/releases/tag/liquidfun-v6.0.4-lf.1 https://github.com/Birch-san/box2d-wasm/releases/tag/liquidf... [1] http://google.github.io/liquidfun/ http://google.github.io/liquidfun/ [2] https://github.com/erincatto/box2d https://github.com/erincatto/box2d [3] https://github.com/Birch-san/box2d-wasm https://github.com/Birch-san/box2d-wasm [4] https://github.com/Birch-san/box2d-wasm/releases/tag/v4.0.0-liquidfun.0 https://github.com/Birch-san/box2d-wasm/releases/tag/v4.0.0-... [5] https://github.com/Birch-san/box2d-wasm/tree/master/webidl-to-ts https://github.com/Birch-san/box2d-wasm/tree/master/webidl-t... [6] https://github.com/google/liquidfun/blob/master/liquidfun/Box2D/EyeCandy/engine.cpp https://github.com/google/liquidfun/blob/master/liquidfun/Bo... [7] https://birchlabs.co.uk/lunar-survey/ https://birchlabs.co.uk/lunar-survey/

semi-extrinsic 5y ago

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/

faeyanpiraat 5y ago

It works on iphone 7 but the page does a refresh 2 seconds in to a fallback page then again to s “problem occured” page

Loeffelmann 5y ago

Could you train a ML model that fills in the gaps in the fluid simulation like they do in ray tracing?

Loeffelmann 5y ago

Could you train a ML model that smoothes out the fluid simulation like they do with ray tracing?

Birch-san 5y ago
yes, I think so! some examples here[0][1]. [0] https://www.youtube.com/watch?v=2Bw5f4vYL98 https://www.youtube.com/watch?v=2Bw5f4vYL98 [1] https://www.youtube.com/watch?v=atcKO15YVD8 https://www.youtube.com/watch?v=atcKO15YVD8

TazeTSchnitzel 5y ago

http://madebyevan.com/webgl-water/ http://madebyevan.com/webgl-water/ is a decade old but still impresses me. The water caustics are particularly neat.

Birch-san 5y ago
yes, that demo has very impressive shaders. it models the physics in a more simple way though (i.e. as waves), rather than as thousands of particles, so it can't generalize to more complex scenarios.

inDigiNeous 5y ago

Nice to see such a high performance demo running on web technologies, gives me trust that we can finally do more complex and jitter-free graphics on web-applications. Thanks for sharing and creating this.

_448 5y ago

What is the total size of the webpage that is downloaded to the user system?

Birch-san 5y ago
network inspector says 2.1MB. but that's dominated by a 1.3MB image. the main assets of the library are: - Box2D.simd.js (422kB) - Box2D.simd.wasm (266 kB) a minimal demo that uses the library can be created in just a few kB: https://github.com/Birch-san/box2d-wasm/tree/master/demo/modern/public https://github.com/Birch-san/box2d-wasm/tree/master/demo/mod...