3 ms·

Following the article, you build a simple 2D physic simulation (only for balls). Did by chance anyone expand on that to include boxes, or know of a different ap

Following the article, you build a simple 2D physic simulation (only for balls). Did by chance anyone expand on that to include boxes, or know of a different approach to build a physic engine in WebGPU? I experiemented a bit with it and implemented raycasting, but it is really not trivial getting the data in and out. (Limiting it to boxes and circles would satisfy my use case and seems doable, but getting polygons would be very hard, as then you have a dynamic size of their edges to account for and that gives me headache) A 3D physic engine on the GPU would be the obvious dream goal to get maximum performance for more advanced stuff, but that is really not an easy thing to do. Right now I am using a Box2D for wasm and it has good performance, but it could be better. https://github.com/Birch-san/box2d-wasm https://github.com/Birch-san/box2d-wasm The main problem with all this is the overhead of getting data into the gpu and back. Once it is on the gpu it is amazingly fast. But the back and forth can really make your framerates drop - so to make it worth it, most of the simulation data has to remain on the gpu and you only put small chanks of data that have changed in and out. And ideally render it all on the gpu in the next step. (The performance bottleneck of this simulation is exactly that, it gets simulated on the gpu, then retrieved and drawn with the normal canvasAPI which is slow)

tomsmeding 3y ago
> But the back and forth can really make your framerates drop - so to make it worth it, most of the simulation data has to remain on the gpu and you only put small chanks of data that have changed in and out. And ideally render it all on the gpu in the next step. In my (limited, cuda so not webgpu) experience, memory transfers are fast and computation is fast, the thing that is slow is memory transfer _latency_. Doing a memory transfer takes a long time, but if you're doing one anyway, might as well transfer the world. Is my recollection correct?
- hutzlibu 3y ago
  "Doing a memory transfer takes a long time, but if you're doing one anyway, might as well transfer the world." Not in my experience and experiments. But I am pretty much a beginner with WebGPU and might be missing a lot. Otherwise yes, latency is the big issue as well. Sometimes all is well, sometimes nothing happens for 20+ms.

tomsmeding 3y ago

> But the back and forth can really make your framerates drop - so to make it worth it, most of the simulation data has to remain on the gpu and you only put small chanks of data that have changed in and out. And ideally render it all on the gpu in the next step. In my (limited, cuda so not webgpu) experience, memory transfers are fast and computation is fast, the thing that is slow is memory transfer _latency_. Doing a memory transfer takes a long time, but if you're doing one anyway, might as well transfer the world. Is my recollection correct?

hutzlibu 3y ago
"Doing a memory transfer takes a long time, but if you're doing one anyway, might as well transfer the world." Not in my experience and experiments. But I am pretty much a beginner with WebGPU and might be missing a lot. Otherwise yes, latency is the big issue as well. Sometimes all is well, sometimes nothing happens for 20+ms.