6 ms·

A WebGPU implementation of Augmented Vertex Block Descent

150 points by juretriglav 6mo ago

Ciantic 6mo ago
AVBD also has this page https://graphics.cs.utah.edu/research/projects/avbd/ https://graphics.cs.utah.edu/research/projects/avbd/ I don't know how this implementation differs from the one they are demoing but this one by Jure Triglav feels much smoother to me.
- juretriglav 6mo ago
  The excellent 3D demo on that page is CPU based, serial.
zokier 6mo ago
Do you see "Offset Geometric Contact" paper fitting into this project somehow? https://graphics.cs.utah.edu/research/projects/ogc/ https://graphics.cs.utah.edu/research/projects/ogc/
- juretriglav 6mo ago
  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.
mjmdavis 6mo ago
This is really awesome. Great work. I aspire to build cool stuff like this in WebGPU. Very excited for the future of the web.
- juretriglav 6mo ago
  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-the-web/ https://juretriglav.si/surfel-based-global-illumination-on-t...
- Stevvo 6mo ago
  It can definitely be achieved with Claude. Even with no experience in graphics progammming, I've been able to replicate results of several papers in related to fluid simulation.
  - jackling 6mo ago
    Curious, when you do this, do you understand the math/reasoning of the paper and just have claude as do the coding? Not saying that matters if you just care about the end result, but I'm curious how much using an agent affects your understanding of what the papers are proving.
    - Stevvo 6mo ago
      I went in with limited understanding, gained some more as the agent worked through it. What can appear complex in the paper often turns out to be far more simple and elegant once you see the code written.
the-golden-one 6mo ago
Why do all physics engines still look so floaty?
- jackling 6mo ago
  Can you elaborate on what you mean? It could be a matter of perspective, For a stack of blocks, each 1 meters high, the stack can get quite high and your expectations on how it should look like IRL might not be correct, due to never experience a large tower of blocks being knocked over at that vantage point. Especially if the mass of the objects are strange (super light for their size or super heavy). I know in older games, the recommendation was to keep gravity low (~6 m/s^2 iirc) to help with simulation stability and make things look better, that might contribute to your idea of things being floaty. I don't find the examples in the git repo to be especially floaty, but I work with a lot of simulators so I might just be used to it.
- 10000truths 6mo ago
  One or more of: * Low gravity * Slow timestep * Unrealistic mass ratios of colliding bodies * Incorrect, or lack of, drag
  - fc417fc802 6mo ago
    The timestep effect is remarkable. I was quite surprised with a basic PBD simulation when I lowered the timestep into the nanosecond (IIRC, anyway it was really small and no longer ran in real time) range just to see what would happen and got lots of high frequency shivering effects that looked exactly like what happens IRL when metal objects are fed through a shredder.
    - jackling 6mo ago
      Never tried with that low of a timestep, wonder if that could start causing floating point issues which will lead to more instability.
      - fc417fc802 6mo ago
sho_hn 6mo ago
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.
- modeless 6mo ago
  > 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 I don't understand this complaint. What's worse about using WebGPU over using GLES? Seems like a strict improvement. You can use WebGPU anywhere, you're not required to "abstract" over Vulkan. If you're talking about using it outside of the web, you just choose wgpu or Dawn as your implementation, it's the same API and even the same implementation as you'd get in a browser.
- adfm 6mo ago
  What's holding it back? Is there something to be done to make it less frustrating? What would make "The Hardware-Accelerated Web" a breeze to use for developers?
- mellinoe 6mo ago
  Other than the fact that WebGPU sucks compared to modern Vulkan + extensions, there’s nothing stopping you from just using webgpu even in a native-only project, with no further abstraction
jackling 6mo ago
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.
spencer9714 6mo ago
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?
jmrgz 6mo ago
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?
- juretriglav 6mo ago
  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.
madbo1 6mo ago
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.

150 points by juretriglav 6mo ago

AVBD also has this page https://graphics.cs.utah.edu/research/projects/avbd/ https://graphics.cs.utah.edu/research/projects/avbd/ I don't know how this implementation differs from the one they are demoing but this one by Jure Triglav feels much smoother to me.

juretriglav 6mo ago
The excellent 3D demo on that page is CPU based, serial.

zokier 6mo ago

Do you see "Offset Geometric Contact" paper fitting into this project somehow? https://graphics.cs.utah.edu/research/projects/ogc/ https://graphics.cs.utah.edu/research/projects/ogc/

juretriglav 6mo ago
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.

mjmdavis 6mo ago

This is really awesome. Great work. I aspire to build cool stuff like this in WebGPU. Very excited for the future of the web.

juretriglav 6mo ago
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-the-web/ https://juretriglav.si/surfel-based-global-illumination-on-t...
Stevvo 6mo ago
It can definitely be achieved with Claude. Even with no experience in graphics progammming, I've been able to replicate results of several papers in related to fluid simulation.
- jackling 6mo ago
  Curious, when you do this, do you understand the math/reasoning of the paper and just have claude as do the coding? Not saying that matters if you just care about the end result, but I'm curious how much using an agent affects your understanding of what the papers are proving.
  - Stevvo 6mo ago
    I went in with limited understanding, gained some more as the agent worked through it. What can appear complex in the paper often turns out to be far more simple and elegant once you see the code written.

the-golden-one 6mo ago

Why do all physics engines still look so floaty?

jackling 6mo ago
Can you elaborate on what you mean? It could be a matter of perspective, For a stack of blocks, each 1 meters high, the stack can get quite high and your expectations on how it should look like IRL might not be correct, due to never experience a large tower of blocks being knocked over at that vantage point. Especially if the mass of the objects are strange (super light for their size or super heavy). I know in older games, the recommendation was to keep gravity low (~6 m/s^2 iirc) to help with simulation stability and make things look better, that might contribute to your idea of things being floaty. I don't find the examples in the git repo to be especially floaty, but I work with a lot of simulators so I might just be used to it.
10000truths 6mo ago
One or more of: * Low gravity * Slow timestep * Unrealistic mass ratios of colliding bodies * Incorrect, or lack of, drag
- fc417fc802 6mo ago
  The timestep effect is remarkable. I was quite surprised with a basic PBD simulation when I lowered the timestep into the nanosecond (IIRC, anyway it was really small and no longer ran in real time) range just to see what would happen and got lots of high frequency shivering effects that looked exactly like what happens IRL when metal objects are fed through a shredder.
  - jackling 6mo ago
    Never tried with that low of a timestep, wonder if that could start causing floating point issues which will lead to more instability.
    - fc417fc802 6mo ago

sho_hn 6mo ago

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.

modeless 6mo ago
> 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 I don't understand this complaint. What's worse about using WebGPU over using GLES? Seems like a strict improvement. You can use WebGPU anywhere, you're not required to "abstract" over Vulkan. If you're talking about using it outside of the web, you just choose wgpu or Dawn as your implementation, it's the same API and even the same implementation as you'd get in a browser.
adfm 6mo ago
What's holding it back? Is there something to be done to make it less frustrating? What would make "The Hardware-Accelerated Web" a breeze to use for developers?
mellinoe 6mo ago
Other than the fact that WebGPU sucks compared to modern Vulkan + extensions, there’s nothing stopping you from just using webgpu even in a native-only project, with no further abstraction

jackling 6mo ago

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.

spencer9714 6mo ago

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?

jmrgz 6mo ago

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?

juretriglav 6mo ago
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.

madbo1 6mo ago

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.