7 ms·

Particle Life simulation in browser using WebGPU

194 points by ibobev 1y ago

m-schuetz 1y ago
It's crazy how WebGPU has been a thing for years, yet it's still barely available accross devices and browsers.
- koolala 1y ago
  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 1y ago
    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 1y ago
      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 1y ago
        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.
        flohofwoe 1y ago
        There was a planned compute shader update for WebGL2, but AFAIK it has been abandondend in favour of WebGPU: https://groups.google.com/a/chromium.org/g/blink-dev/c/bPD47wqY-r8/m/5DzgvEwFBAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/bPD47... It would have made sense 5 years ago when it wasn't clear that WebGPU would be delayed for so long, but now that WebGPU support in browsers is actually close to the finish line it's probably not worth the hassle.
      - m-schuetz 1y ago
        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.
        deleted 1y ago
        [deleted]
      - flohofwoe 1y ago
        Treating a texture as a 'poor man's storage buffer' often works but is much more awkward than populating a storage buffer in a compute shader, and you're giving up on a lot of usage scenarios where WebGPU is simply more flexible (even simple things like populating a storage buffer in a compute shader and then binding it as vertex- or index-buffer).
    - flohofwoe 1y ago
      > like render passes Render passes in WebGPU are more like in Metal and Vulkan's Dynamic Rendering extension (which is pretty much a direct copy of Metal's render pass concept). The problem with Vulkan 1.0 render pass objects is that they are baked objects, and worse, that pipeline objects required a render pass object reference (although it didn't have to be an actual render pass used for rendering, just a 'compatible' render pass - still a pretty bad design wart). Metal-style transient render passes are actually a very good thing, especially for tiler gpus.
worldsayshi 1y ago
Arsiliath on twitter/x also has some really nice gpu life simulations and courses: https://x.com/arsiliath https://x.com/arsiliath
- whatnow37373 1y ago
  X is completely unusable and it saddens me people keep posting valuable content to it.
  - worldsayshi 1y ago
    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)?
    - whatnow37373 1y ago
      I’m European, so: heavy—ass regulation. Don’t trust the market. We don’t trust capitalism with all important bits of civilization: government, water and food quality, care, education, etc. I don’t see why it has to be let loose here. Social media has a special place in my heart. A hateful place. If it were up to me I’d ban it outright. It’s eroding the fundaments of society while contributing nothing of value. It’s like crystal meth in that regard.
  - falcor84 1y ago
    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 1y ago
      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.
bestouff 1y ago
Doesn't work on Firefox/Linux for me.
- rschiavone 1y ago
  change `dom.webgpu.enabled` in `about:config` from `false` to `true` by double-clicking on it
  - rschiavone 1y ago
    I was mistaken, it seems to work only in Nightly builds
- mendyberger 1y ago
  Firefox doesn't support WebGPU in stable yet. Chromium does support WebGPU in stable, but not on Linux.
- berkes 1y ago
  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 https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
- rypskar 1y ago
  Seems like we might get WebGPU support soon, maybe in FF 141 according to https://github.com/gpuweb/gpuweb/wiki/Implementation-Status https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
- pjmlp 1y ago
  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.
oliviergg 1y ago
Nice. The only downside, is that I can spend so much time looking at this system where something seems to emerge, but not quite ...
- pmx 1y ago
  Try looking at this system - lots of "lifeforms" emerge with several interesting behaviours https://lisyarus.github.io/webgpu/particle-life.html?particleCount=32768&speciesCount=18&friction=15&centralForce=0&symmetricForces=false&loopingBorders=true&seed=2913456392 https://lisyarus.github.io/webgpu/particle-life.html?particl...
airstrike 1y ago
This looks awesome. Is there a repo with a LICENSE from which I may bum some of this with permission?
baalimago 1y ago
I did something similar a few years back(press 'q' to see the individual particles move): https://lorentz.app/experiments.html 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 1y ago
> as a nice bonus, it actually runs in browser! It is called "Web" GPU after all.
- modeless 1y ago
  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 1y ago
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 1y ago
  > 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 1y ago
    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/ https://madebyevan.com/webgl-water/ Is there some reason WebGPU has difficulties getting implemented for Linux, like DRM features or so?
    - sspiff 1y ago
      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 1y ago
90s_dev 1y ago
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-state-diagram.html https://webgl2fundamentals.org/webgl/lessons/resources/webgl...
- jsheard 1y ago
  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 1y ago
  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/ 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/ 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).
andrewrn 1y ago
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 1y ago
Here's another WebGPU demo, a 3D commerce car configurator, for anyone interested: https://garage.cjponyparts.com/ https://garage.cjponyparts.com/
vojtechrichter 1y ago
this is awesome
franzwarning 1y ago
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-c290f7a38a4f https://wasm.wavedash.gg/b75d4697-4f78-45c2-a5e1-c290f7a38a4...
- edgeuser 1y ago
  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 https://github.com/animeshjha-unity/VikingVillageURP-2023? WebGL demo: https://vv-webgl-2023-3-0a12.netlify.app/ https://vv-webgl-2023-3-0a12.netlify.app/ WebGPU demo: https://vv-webgpu-2023-3-0a12.netlify.app/ https://vv-webgpu-2023-3-0a12.netlify.app/
astlouis44 1y ago
Here's an Unreal Engine 5 WebGPU demo: https://garage.cjponyparts.com/ https://garage.cjponyparts.com/
- throwaway314155 1y ago
  Gets stuck at 98% on initial load screen in Firefox, Safari and Chrome (all on MacOS).
  - dtgriscom 1y ago
    Same. Still downloading big data, though.
    - dtgriscom 1y ago
      Nope: wasn't patient enough. After about five minutes, started working (slowly).
olelele 1y ago
I spent a bunch of time now tweaking the parameters. Runs great on my m1 macbook air. Very cool!
magi-clip 1y ago
[dead]
magi-clip 1y ago
made this particle playground with a matterjs https://github.com/magical-paperclip/sics-ground https://github.com/magical-paperclip/sics-ground star it if possible
- mkesper 1y ago
  Include screenshots in your README, that will improve your chances of getting recognition many times.
joshcsimmons 1y ago
Just wanted to mention huge props for including a video in your post. Most people browse the web on mobile which makes most of these web GPU demos literally unwatchable.

194 points by ibobev 1y ago

m-schuetz 1y ago

It's crazy how WebGPU has been a thing for years, yet it's still barely available accross devices and browsers.

koolala 1y ago
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 1y ago
  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 1y ago
    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 1y ago
      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.
      - flohofwoe 1y ago
        There was a planned compute shader update for WebGL2, but AFAIK it has been abandondend in favour of WebGPU: https://groups.google.com/a/chromium.org/g/blink-dev/c/bPD47wqY-r8/m/5DzgvEwFBAAJ https://groups.google.com/a/chromium.org/g/blink-dev/c/bPD47... It would have made sense 5 years ago when it wasn't clear that WebGPU would be delayed for so long, but now that WebGPU support in browsers is actually close to the finish line it's probably not worth the hassle.
    - m-schuetz 1y ago
      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.
      - deleted 1y ago
        [deleted]
    - flohofwoe 1y ago
      Treating a texture as a 'poor man's storage buffer' often works but is much more awkward than populating a storage buffer in a compute shader, and you're giving up on a lot of usage scenarios where WebGPU is simply more flexible (even simple things like populating a storage buffer in a compute shader and then binding it as vertex- or index-buffer).
  - flohofwoe 1y ago
    > like render passes Render passes in WebGPU are more like in Metal and Vulkan's Dynamic Rendering extension (which is pretty much a direct copy of Metal's render pass concept). The problem with Vulkan 1.0 render pass objects is that they are baked objects, and worse, that pipeline objects required a render pass object reference (although it didn't have to be an actual render pass used for rendering, just a 'compatible' render pass - still a pretty bad design wart). Metal-style transient render passes are actually a very good thing, especially for tiler gpus.

worldsayshi 1y ago

Arsiliath on twitter/x also has some really nice gpu life simulations and courses: https://x.com/arsiliath https://x.com/arsiliath

whatnow37373 1y ago
X is completely unusable and it saddens me people keep posting valuable content to it.
- worldsayshi 1y ago
  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)?
  - whatnow37373 1y ago
    I’m European, so: heavy—ass regulation. Don’t trust the market. We don’t trust capitalism with all important bits of civilization: government, water and food quality, care, education, etc. I don’t see why it has to be let loose here. Social media has a special place in my heart. A hateful place. If it were up to me I’d ban it outright. It’s eroding the fundaments of society while contributing nothing of value. It’s like crystal meth in that regard.
- falcor84 1y ago
  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 1y ago
    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.

bestouff 1y ago

Doesn't work on Firefox/Linux for me.

rschiavone 1y ago
change `dom.webgpu.enabled` in `about:config` from `false` to `true` by double-clicking on it
- rschiavone 1y ago
  I was mistaken, it seems to work only in Nightly builds
mendyberger 1y ago
Firefox doesn't support WebGPU in stable yet. Chromium does support WebGPU in stable, but not on Linux.
berkes 1y ago
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 https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
rypskar 1y ago
Seems like we might get WebGPU support soon, maybe in FF 141 according to https://github.com/gpuweb/gpuweb/wiki/Implementation-Status https://github.com/gpuweb/gpuweb/wiki/Implementation-Status
pjmlp 1y ago
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.

oliviergg 1y ago

Nice. The only downside, is that I can spend so much time looking at this system where something seems to emerge, but not quite ...

pmx 1y ago
Try looking at this system - lots of "lifeforms" emerge with several interesting behaviours https://lisyarus.github.io/webgpu/particle-life.html?particleCount=32768&speciesCount=18&friction=15&centralForce=0&symmetricForces=false&loopingBorders=true&seed=2913456392 https://lisyarus.github.io/webgpu/particle-life.html?particl...

airstrike 1y ago

This looks awesome. Is there a repo with a LICENSE from which I may bum some of this with permission?

baalimago 1y ago

I did something similar a few years back(press 'q' to see the individual particles move): https://lorentz.app/experiments.html 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 1y ago

> as a nice bonus, it actually runs in browser! It is called "Web" GPU after all.

modeless 1y ago
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 1y ago

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 1y ago
> 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 1y ago
  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/ https://madebyevan.com/webgl-water/ Is there some reason WebGPU has difficulties getting implemented for Linux, like DRM features or so?
  - sspiff 1y ago
    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 1y ago

90s_dev 1y ago

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-state-diagram.html https://webgl2fundamentals.org/webgl/lessons/resources/webgl...

jsheard 1y ago
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 1y ago
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/ 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/ 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).

andrewrn 1y ago

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 1y ago

Here's another WebGPU demo, a 3D commerce car configurator, for anyone interested: https://garage.cjponyparts.com/ https://garage.cjponyparts.com/

vojtechrichter 1y ago

this is awesome

franzwarning 1y ago

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-c290f7a38a4f https://wasm.wavedash.gg/b75d4697-4f78-45c2-a5e1-c290f7a38a4...

edgeuser 1y ago
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 https://github.com/animeshjha-unity/VikingVillageURP-2023? WebGL demo: https://vv-webgl-2023-3-0a12.netlify.app/ https://vv-webgl-2023-3-0a12.netlify.app/ WebGPU demo: https://vv-webgpu-2023-3-0a12.netlify.app/ https://vv-webgpu-2023-3-0a12.netlify.app/

astlouis44 1y ago

Here's an Unreal Engine 5 WebGPU demo: https://garage.cjponyparts.com/ https://garage.cjponyparts.com/

throwaway314155 1y ago
Gets stuck at 98% on initial load screen in Firefox, Safari and Chrome (all on MacOS).
- dtgriscom 1y ago
  Same. Still downloading big data, though.
  - dtgriscom 1y ago
    Nope: wasn't patient enough. After about five minutes, started working (slowly).

olelele 1y ago

I spent a bunch of time now tweaking the parameters. Runs great on my m1 macbook air. Very cool!

magi-clip 1y ago

[dead]

magi-clip 1y ago

made this particle playground with a matterjs https://github.com/magical-paperclip/sics-ground https://github.com/magical-paperclip/sics-ground star it if possible

mkesper 1y ago
Include screenshots in your README, that will improve your chances of getting recognition many times.

joshcsimmons 1y ago

Just wanted to mention huge props for including a video in your post. Most people browse the web on mobile which makes most of these web GPU demos literally unwatchable.