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.
Awesome work, what always prevents me from implementing more solvers is the amount of math required. While the implementation always seems simple, understanding the different optimization strategies for each solver gets confusing.
It's really impressive that the author was able to implement rendering papers and physics sim papers with such regularity. It really is a feat. Makes me curious to see what their background is.
The direction seems very interesting indeed. Using optimization algorithms such as Augmented Vertex Block Descent in WebGPU marks a step towards doing proper numerical computations right in the browser and not just visualizations and/or ML inferences.
Perhaps, more importantly, this development makes optimization approaches more accessible by eliminating the need for special environments (CUDA, native compilation, and alike).
I am very interested in comparing the performance of these optimizations in comparison with native GPU implementations, especially in terms of memory throughput and precision limits.
I'm super frustrated by the state of 3D on web right now as an app developer. I wish we just had Vulkan on the web ...
Right now your options are basically having a GLES renderer that you can restrict to WebGL2 (so no compute shaders, etc. and other things that make desktop OpenGL acceptable for writing a modern renderer) or having to abstract over Vulkan/WebGPU yourself, which are similar but different enough to increase your code complexity considerably.
There's abstractions like wgpu and bgfx you can commit to, and of course you can just use game engine middleware and have it all done for you, but overall things fall short of just being able to "write once, run anywhere" a renderer, sadly.
Great work on the AVBD implementation! I’m building a decentralized GPU compute platform (using Node.js/WebGPU). Since the solver uses a 'coloring' approach for parallelism, how do you handle compute preemption or state recovery if a worker/tab is closed mid-solve? Is it feasible to serialize the solver state efficiently for a distributed queue?
Really impressive that this runs entirely in the browser with no native plugins. Is there a rough estimate on how many rigid bodies it can handle before framerate drops significantly?
24 comments
It's really impressive that the author was able to implement rendering papers and physics sim papers with such regularity. It really is a feat. Makes me curious to see what their background is.
Perhaps, more importantly, this development makes optimization approaches more accessible by eliminating the need for special environments (CUDA, native compilation, and alike).
I am very interested in comparing the performance of these optimizations in comparison with native GPU implementations, especially in terms of memory throughput and precision limits.
Right now your options are basically having a GLES renderer that you can restrict to WebGL2 (so no compute shaders, etc. and other things that make desktop OpenGL acceptable for writing a modern renderer) or having to abstract over Vulkan/WebGPU yourself, which are similar but different enough to increase your code complexity considerably.
There's abstractions like wgpu and bgfx you can commit to, and of course you can just use game engine middleware and have it all done for you, but overall things fall short of just being able to "write once, run anywhere" a renderer, sadly.
I aspire to build cool stuff like this in WebGPU.
Very excited for the future of the web.