The AAA games that use surfels combine the with probes to get the immediate light information while surfels haven't accumulated enough (the black spots when camera moves), since surfel generation is driven by screen space placement. Surfels have better light leak properties and their dynamic resolution (more of them when you get close to a surface) provides higher quality lighting, which is why they are preferred/the first option. The issue with a surfel + light probe system on the web, specifically, is that you run out of storage buffers = the current system is right on the limit, which is 10 storage buffers for the integrator pass.
I think there's some discussion to up that limit on adapters that support it, but right now we're stuck at 10. It would be SUPER beneficial to raise that limit, for a wide variety of projects. Two specifically that I'm working on now are WebGPU implementations of Alber's Markov Chain Path Guiding paper, and the ReSTIR PT Enhanced paper, and they are both similarly handicapped by the storage buffer limit.
I managed to run the 64k block example, i.e. 64 10x10x10 stacks at about 40 fps a little while back, before I included the joints and springs support in the solver, so I'm positive that number can be made to run smoothly in real-time if you're laser focused on rigid bodies and optimize the pipeline specifically for it.
With everything enabled though, I think about 10k bodies is the reasonable limit on my M3 Max. I do want to attack performance next, since I was mainly focused on stability and good support for various modes of physical interactions.
Thanks! Never been easier to start than right now. This physics engine is a bit opaque in terms of how it works, but I recently wrote about a global illumination approach that uses surfels - I break it down into small manageable pieces, with plenty of interactive visualizations, and it's also in WebGPU! If you have some time, maybe take a look at that and start taking it apart: https://juretriglav.si/surfel-based-global-illumination-on-t...
I actually have an implementation of that too, since I was fascinated by the twisting cloth example, but need to figure out how best to incorporate it, or if it’s better in a standalone experiment.
These examples are amazing, though compute heavy and built with WebGL, which is less than an ideal fit for it. This website and project have been around for a couple of years, and the web's graphics capabilities have grown since, bumped up significantly by the introduction of WebGPU. And since Firefox introduced support for it in 141 on Windows, and 145 on macOS (see wiki tracking implementation here: https://github.com/gpuweb/gpuweb/wiki/Implementation-Status), it now also enjoys broad cross-platform support (Windows, macOS, Android, iOS, with Linux trailing a bit behind).
After this experiment (and some that are in progress), and some very recent movement on raising the bound storage buffer limit in Chrome (https://issues.chromium.org/issues/366151398), I can't help but feel that we're on the cusp of an AAA-level experience built exclusively on the web. I'm super excited for the future of computer graphics right in your browser.
Thanks! Absolutely, dig in, the code is MIT :). I bet your previous experience would lead to significant speedups/quality improvements somewhere in the bowels of the pipeline. Contribs very welcome, too!
Can we use WebGPU to compute real-time global illumination with surface patches called surfels? Does it look good enough? Is it fast enough? And can we finally construct viable compute-heavy rendering pipelines right here on the open web? Join me on this journey and let's find out!
Hasn’t been mentioned before: try this on a phone. It uses the gyroscope for control and it quickly becomes second nature to balance/guide the square around the screen. Also a very nice and rewarding discovery process, as it starts out with squares speeding by, until you realize it’s the tilt of your phone that is causing it. Congrats, super fun!