A SPH solver for the GPU written in Rust.
WGPU was chosen as it seems pretty versatile, and I could turn this into a WASM component and host it in a website if I wanted. It also seemed like the most mature library out there for GPU computing with Rust.
The CPU folder contains everything one might need to run a simulation in the CPU, except for the rendering, which in the early stages of this project was handled by Macroquad, later, this was changed to run primarily in the GPU (see the GPU section).
This project started in the GPU because it was too big of a problem for me. I didn't know anything about GPUs and graphics programming, and I knew even less about CFD techniques, let alone SPH.
I would say, if you want to the raw logic, without the preparation and meticulosity of passing the data through a buffer to the GPU, the CPU folder looks much friendlier, more on the Improvement section for this.
The GPU folder, as you might imagine, contains everything one might need to run a simulation in the GPU.
Here you will find things you won't be able to find in the CPU folder, particularly, the context.rs file the pipelines.rs file and the shaders folder. The specific explanation for what each thing does is documented in each file.
To start, I tried using macroquad and wgpu together, but as it turns out macroquad uses its own version of wgpu which is pretty old, and so I was getting conflicts in the build. So I changed to raw winit with wgpu, for the little parameters window I used egui-winit.
Since WGSL doesn't natively support sorting, one often resorts to writting their own sorter, in this area, people had done a better job than I could, or had the patience to, so I used someone else's. Unfortunately, wgpu evolves quickly and this library was also out of sync with the wgpu version being used, for that reason I forked and raised a PR to update their sorter the forked version can be found here.
There are several areas of improvement that this project would benefit from, some of which I might indeed do at some point. Here are some:
- Optimisations. I am sure there are a ton of optimisations I could make to increase the number of particles that one can run here.
- Viscosity. The obvious next step here in terms of physical quality of the simulation would be to use the Navier–Stokes equations to simulate viscosity.
- Boundaries. Right now there are some clear problems with the boundaries which look pretty unnatural i.e. there is a layer of particles that just stays there and gets pushed up through the sides.
- Go 3D.
- As it is with SPH the parameters are super finnicky, and I would like to find a way to make them more stable.
- I would like to make the simulation more stable in relation to FPS, I tried a bunch of methods, none of them worked really well.
- Some tests...
- Some kind of more graphics based work to make the fluid look like a fluid.
This project wouldn't have happened without Sebastian Lague's famous Coding Adventure: Simulating Fluids. Here are some papers and sources I went through throughtout this journey: