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!
Hm, I'm not entirely sure if you're being sarcastic or not, but just in case, asking Bing about the menu I get this:
> Chez Panisse is a famous restaurant in Berkeley, California that serves seasonal and organic food1. The menu changes daily and is posted on their website2. Today’s menu for the restaurant (not the cafe) is:
> Fennel and leek salad with rocket, toasted almonds, and salsa verde
> Bomba rice cooked with clams and squid; with aïoli
> Becker Lane Farm pork loin roasted with Spanish paprika and green garlic; with > braised greens and wild mushrooms
> Meyer lemon sherbet with candied kumquats
> The price for this menu is $175 per person2.
People interested in this might also be interested in the release notes for The Grove (a Blender tree gen plugin), as they describe a number of modelled behaviours of trees in nature: phototropism, gravitropism, forking, behaviour of sapwood and heartwood, etc.: https://www.thegrove3d.com/releases/the-grove-release-8/
Yeah, dropping a seed in and growing a chair very quickly sounds like it is in the same ballpark, or at least further along the spectrum of efficient computation. That seed (program) would very tricky to produce, though. Contrary to the current practice of writing programs relatively easily, but the machines to run them are incredibly complex, both to run and to manufacture. With the seed, though, the machine would be nature, 1=1.
I agree that there is no need to bring quantum computing into the discussions, but it is higher on the efficient computing scale. It also requires a lot of effort to come up with programs that make sense, and they use more of natural phenomena (superposition, entanglement, etc) compared to classical computers. It’s something to look at for inspiration, at least?
Fascinating! Thank you for sharing, OP! Having recently gone down a similar rabbit hole [1], having references and starting points is incredibly useful for further exploration, as this stuff is very hard to search for.
There does seem to be a direct computational link between information and the universe - and the way we’re using this link now , with classical computers, is highly abstracted and inefficient (the article also compares current energy cost of computing vs the much much lower theoretical limit). Quantum computers come closer to the nature of that link, but still require many abstractions.
I wonder if it will be possible to eventually compute without abstractions, directly on the substrate of the universe. Though that might be equivalent to real magic ;)
Recently wrote about how surprisingly computationally intensive typing in it is (https://juretriglav.si/what-happens-when-you-type-a-single-l...), so it’s doubly surprising that it also doesn’t work as expected. But text editing on the web _is_ hard, and hard to
get right on deploy 1, so I’m sure they’ll iron out the kinks soon.
That certainly wasn’t the intention, the title is a bit of a mix of: the initial intent to list all open source collaborative text editors, and then realizing, as I state in the post, that it wouldn’t add much value to have a long shallow list, then deciding to limit the scope significantly, but not wanting to redesign the headline illustration, as so much effort already went into the post (both content and the code behind it) that I just needed to stop working on it and ship it :) Hope that makes sense!
It mainly has to do with familiarity with the framework. The focus of the work was on the collaborative server bits, not learning a new framework/ecosystem and I feel very comfortable in PubSweet, being its lead dev. The project also served as an app-building exercise, as we’re just now meeting in Cambridge to focus on that aspect and reusable components within PubSweet. And when all said and done, there weren’t any friction points with this approach, it all just sort of worked, from data model migrations to React frontend, so yay :) Hope that clears it up!