[HN Gopher] Particle Life simulation in browser using WebGPU
___________________________________________________________________
Particle Life simulation in browser using WebGPU
Author : ibobev
Score : 154 points
Date : 2025-05-26 12:28 UTC (10 hours ago)
(HTM) web link (lisyarus.github.io)
(TXT) w3m dump (lisyarus.github.io)
| worldsayshi wrote:
| Arsiliath on twitter/x also has some really nice gpu life
| simulations and courses: https://x.com/arsiliath
| whatnow37373 wrote:
| X is completely unusable and it saddens me people keep posting
| valuable content to it.
| worldsayshi wrote:
| If we could just have a workaround to network effects that
| would be great.
|
| Edit: Any suggestions for how to actually solve the network
| effect problem (long term)?
| falcor84 wrote:
| I'm not a big fan of it, but that's quite an exaggeration. If
| it were "completely unusable", then people wouldn't be using
| it, and it wouldn't have been an issue. The fact that the
| situation isn't what we want it to be, but nevertheless is
| still tenable makes it a much harder problem to deal with.
| worldsayshi wrote:
| It's really why enshittification can be a thing. Network
| effect-ed services can do random walks in quality or
| degrade significantly while still keeping staying power.
|
| Enshittification, as described by C Doctorow and others is
| just one potential, but likely path for a popular service
| to take.
| jekude wrote:
| Also https://x.com/ciphrd
| bestouff wrote:
| Doesn't work on Firefox/Linux for me.
| mendyberger wrote:
| Firefox doesn't support WebGPU in stable yet. Chromium does
| support WebGPU in stable, but not on Linux.
| berkes wrote:
| Nor Chrome(ium)/Linux.
|
| WebGPU is experimental in Firefox all platforms, but especially
| on Linux. Chrome on linux should have it, but I've not gotten
| it to work - might be chromium, might be a flag, or something
| else.
|
| Here's more info on the status of WebGPU:
| https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
| rypskar wrote:
| Seems like we might get WebGPU support soon, maybe in FF 141
| according to
| https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
| rschiavone wrote:
| change `dom.webgpu.enabled` in `about:config` from `false` to
| `true` by double-clicking on it
| rschiavone wrote:
| I was mistaken, it seems to work only in Nightly builds
| pjmlp wrote:
| WebGPU is currently only a Chrome API available across macOS,
| Android and Windows.
|
| Everywhere where Chrome runs is an experimental API.
|
| On Firefox and Safari, who knows when they will ever get out of
| preview API, and in what platforms, especially on Firefox's
| case.
|
| WebGL 2.0 took about a decade to reach a wide enough audience,
| and WebGPU isn't yet widely available since the whole effort
| started in 2016.
|
| This is why most companies are either doing native or streaming
| for 3D content.
| sroussey wrote:
| Yeah, I forgot I turned on the flag for webgpu on my iPhone.
| Seeming works well, and this simulation is fun to watch!
| oliviergg wrote:
| Nice. The only downside, is that I can spend so much time looking
| at this system where something seems to emerge, but not quite ...
| airstrike wrote:
| This looks awesome. Is there a repo with a LICENSE from which I
| may bum some of this with permission?
| baalimago wrote:
| I did something similar a few years back(press 'q' to see the
| individual particles move): https://lorentz.app/experiments.html
|
| It's much simpler in design though. Each particle has a constant
| forward speed, and varying move-angle. For each step, it can
| either change it's turn-angle to be more left, or more right. The
| turn angle then determines how strong the 'glow' of a particle
| is. If it turns strongly to the left, the glow is strongly red.
| Vise versa for blue and right.
|
| Then, for the upcoming iteration, the underlying point of the
| particle is evaluated by colour. If the colour the particle is
| under is red -> become more red. If it's blue -> become more
| blue. So this way, it's a dynamically shifting system where
| particles turn from blue to red depending on it's surroundings.
|
| All calculations are made on the GPU. The positions are encoded
| into textures (last 3 positions to calculate current moving
| angle), then also the previous step's render.
|
| Often particles becomes very isolated due to it's high turn,
| there are clusters. But then a huge pack of opposite-turners may
| come and disrupt this. Sometimes one colour wins.
| tantalor wrote:
| > as a nice bonus, it actually runs in browser!
|
| It is called "Web" GPU after all.
| modeless wrote:
| You would be surprised how many people make a WebGPU or even
| WebGL demo and don't provide a link to run it in browser...
| Aardwolf wrote:
| It says "Browser doesn't support WebGPU" in both Chrome and
| Firefox in Linux
|
| What's the situation of WebGPU, is it supposed to work in Linux
| or not?
|
| I'm sure that I've seen other GPU-like things (water simulations
| etc...) run in my browser before so I'm not sure what's wrong
| this time, or how many different GPU-like API's exist for
| browsers other than WebGPU (like WebGL).
|
| I sometimes enable and/or disable "hardware acceleration" in
| Chrome and/or Firefox because sometimes one or sometimes the
| other causes video problems (sometimes having hardware
| acceleration on can make videos slower despite what you'd think).
| Is this hardware acceleration setting related to WebGPU?
| jsheard wrote:
| > What's the situation of WebGPU, is it supposed to work in
| Linux or not?
|
| Chrome officially supports WebGPU on all platforms _except_
| Linux for now, you can force it on with a flag but it 's
| obviously not meant for prime time yet. Firefox has yet to
| officially ship WebGPU at all but it's supposed to be coming in
| version 141, due at the end of July. Safari is still dragging
| its feet with no indication at all of when they'll get around
| to shipping.
| Aardwolf wrote:
| I see, I thought 3D graphics in browsers already existed and
| worked in Linux for a very long time so this must be a new
| one then... what's the difference between WebGPU, and WebGL
| that allowed demos like this one since long ago?
| https://madebyevan.com/webgl-water/
|
| Is there some reason WebGPU has difficulties getting
| implemented for Linux, like DRM features or so?
| sspiff wrote:
| Different API, WebGPU is supposed to be a safe common
| denominator for Vulkan, DirectX 12 and Metal.
|
| WebGL is that, but for OpenGL ES 2.0, and WebGL 2 is that
| but for OpenGL ES 3.0. WebGL is OK for graphics, but pretty
| hard to effectively adapt for compute / simulations.
| danjl wrote:
| If I had to guess, the reason WebGPU is not implemented in
| Linux is because nobody is paid to add features to Linux.
| This means that new features are delayed by several years.
| WebGL is old, and well supported. WebGPU is newer, and has
| less support.
| modeless wrote:
| Google cares about Chrome Linux support and pays people
| to work on it, for two reasons. One is Chrome OS, and the
| other is that most Google engineers use Linux desktops
| for work.
| brulard wrote:
| Do they? I thought they would mostly be on MacBooks.
| modeless wrote:
| Most Google engineers have both. Or at least they did
| when I was there. And Chrome developers in particular do
| their development primarily on Linux.
| erwincoumans wrote:
| that's a pretty WebGL fluid demo, it runs even well on
| iPhone.
| jakkos wrote:
| > what's the difference between WebGPU, and WebGL
|
| WebGL has a bunch of limitations, but a big one is that you
| can only use the gpu to move around triangles vertices
| (vertex shader) and color them in (pixel shader).
|
| If you want to do something like that cool water simulation
| you have to do some painful hackery to pretend all your
| data is actually vertices or colors in a texture. Even with
| hackery, there's still lots of things you simply can't do.
|
| WebGPU supports compute shaders which let you read and
| write whatever data you want.
| modeless wrote:
| Huh, disappointing that it hasn't shipped in Chrome on Linux.
| There's no pressure for other browsers to implement it when
| it's not even on all of Chrome's supported platforms yet.
| AStonesThrow wrote:
| Are you using Chrome, or Chromium?
|
| Chromium is typically the bundled browser, but around 2019
| Google restricted certain aspects of Chromium under Linux, and
| in order to continue using things like browser login under
| Ubuntu, I needed to install Chrome instead.
|
| Hardware acceleration perks seem like another feature that may
| have a Chrome/Chromium divide.
| 90s_dev wrote:
| I never knew WebGL or OpenGL, my first experience was learning
| WebGPU, because I planned to use it for the drawing of 90s.dev
| which is meant to be future-first. But WebGPU is just not there
| yet. And from what I read about it, it looks like it has only
| slightly better performance than WebGL2, being the common
| denominator to all post-2015 native GPU frameworks. So it's
| disproportionately harder to write, doesn't have nearly all the
| same features as native would, and all this to be only slightly
| faster. Which is why I switched to WebGL2 as the graphics backend
| (WIP). Now I have to learn how all the GL state functions work
| (ugh), I admit that was easier to reason about in WebGPU, mainly
| because it's easier to deeply digest and understand APIs when
| they have clear ins/outs that link together clearly and cleanly.
| Which GL doesn't. At all. Just a buncha confusing globals. But
| this helps, kinda:
| https://webgl2fundamentals.org/webgl/lessons/resources/webgl...
| jsheard wrote:
| Yeah, GLs global state is awful. The least-bad way to deal with
| it is to build your own pipeline abstraction on top, similar to
| the native pipeline constructs of newer APIs like WebGPU, so
| most of the messy global state manipulation is centralized in
| your "bindPipeline" function. Then the rest of your codebase
| can mostly pretend it's running on a sane (albeit dated) API
| instead of a giant ball of spaghetti.
| flohofwoe wrote:
| Shameless plug: sokol_gfx.h has an API quite similar to WebGPU
| and has a WebGL2 backend (most notably WebGPU-style immutable
| pipeline objects which on WebGL2 use a state cache to avoid
| redundant calls into WebGL2), I'd say that the API is even
| easier to use than WebGPU, but of course I'm biased ;)
|
| https://floooh.github.io/sokol-html5/
|
| ...or with the WebGPU backend (which gives you a couple more
| options, like storage buffers/images and compute shaders):
|
| https://floooh.github.io/sokol-webgpu/
|
| ...this is only an option if you're comfortable with C or Zig
| though (for native build targets you'd have more language
| options), although I keep rolling the idea around the back of
| my head to eventually add JS/TS to the language bindings
| generator.
|
| PS: You're spot on with the performance comparison. It's
| baffling that WebGPU in some areas isn't any faster or even
| slower than WebGL2 (but tbf, D3D11 - which WebGL2 uses on
| Windows - is hard to beat when it comes to raw throughput - I
| wonder if a WebGPU D3D11 backend would beat the current D3D12
| backend).
| koolala wrote:
| From everywhere I've seen performance is actually worse than
| WebGL2. Especially on mobile devices.
| modeless wrote:
| While WebGPU is supposed to be more efficient, the real appeal
| is that it supports new features like compute shaders, in a
| form that Apple will actually agree to implement (they refuse
| to implement newer versions of OpenGL due to legal disputes
| with Nvidia). And we care whether Apple ships it because of
| their monopoly on iOS browser engines. Of course, Apple hasn't
| _actually_ shipped it yet either...
| andrewrn wrote:
| My laptop was having absolutely none of that, basically couldn't
| run it at all. Pretty cool idea, though.
|
| For those on brave, you need to set the experimental WebGPU flag
| in here to try it: brave://flags/#enable-web-usb-on-extension-
| service-worker
| edgeuser wrote:
| Here's another WebGPU demo, a 3D commerce car configurator, for
| anyone interested:
|
| https://garage.cjponyparts.com/
| m-schuetz wrote:
| It's crazy how WebGPU has been a thing for years, yet it's still
| barely available accross devices and browsers.
| koolala wrote:
| It runs worse but it being new made everyone believe and hope
| it would be an overall improvement and perform better. Graphics
| is extremely performance bound.
| m-schuetz wrote:
| It runs just fine and adds important functionality that is
| entirely absent in WebGL (storage buffers and compute
| shaders). But I disagree with a lot of the design decisions
| that made me eventually give up on WebGPU. Like, what's the
| point if it's still 10 years behind current desktop
| capabilities, just like WebGL when it came out. And it
| adopted way too much of Vulkans needless complexity, some of
| which is not even necessary in Vulkan anymore but still in
| WebGPu, like render passes.
| koolala wrote:
| Storage buffers are 32bit blocks of memory so why not just
| use a 32bit texture as a storage buffer? With their
| implementation is it actually different?
| m-schuetz wrote:
| You can't do random writes to textures in WebGL, which is
| required by the vast majority of algorithms. Some hacks
| exist, all of which come with severe limitations and
| performance penalties.
| m-schuetz wrote:
| But at this point I'm thinking that it would have been
| way better if they had just added storage buffers and
| compute shaders to webgl.
| vojtechrichter wrote:
| this is awesome
| franzwarning wrote:
| Really cool! We're building a marketplace for high quality webgpu
| games @ Wavedash. We made this little demo of unity's viking
| village you can see how it runs on your comp and if it uses webgl
| or webgpu (also optimizing load times rn sorry bout that). Press
| "c" to walk around
|
| https://wasm.wavedash.gg/b75d4697-4f78-45c2-a5e1-c290f7a38a4...
| edgeuser wrote:
| That's cool and all, but both WebGL and WebGPU builds of that
| Unity demo were already done 2 years ago by someone... so your
| post doesn't offer anything new or groundbreaking, sorry to
| say. See the links below:
|
| Github link: https://github.com/animeshjha-
| unity/VikingVillageURP-2023?
|
| WebGL demo: https://vv-webgl-2023-3-0a12.netlify.app/
|
| WebGPU demo: https://vv-webgpu-2023-3-0a12.netlify.app/
| astlouis44 wrote:
| Here's an Unreal Engine 5 WebGPU demo:
| https://garage.cjponyparts.com/
| olelele wrote:
| I spent a bunch of time now tweaking the parameters.
|
| Runs great on my m1 macbook air.
|
| Very cool!
___________________________________________________________________
(page generated 2025-05-26 23:00 UTC)