UPDATE: I've added a "hacker mode" for you all! You can now specify a userUpdate function and it will run it each frame. See my twitter post for a demo of it.
https://x.com/kotsoft/status/1806362956294189299
Thanks! With 3D the main challenge might be visualizing the layers separately. Ideally each of the phases would have some kind of metaball effect and also be transparent and even refract. Will be pretty tough to do and will have to fight with uncanny valley effect.
Sometimes for sandbox I feel like 2D can be more fun because people can target particles they interact with better.
Hi, I've updated the home page on my site (https://grantkot.com) with links to my other socials, like the YouTube and itchio pages. Twitter for more casual frequent updates, and YouTube for longer summary updates. The itchio demos need to be optimized for a wider variety of machines.
Yeah agree. The objective was more to make a physics toy that would run on single core on a phone than something for actual scientific or industrial use. I could add additional iterations or do pressure projection but then there would be complaints about it being slow & choppy.
There are also some large density ratios between the materials which further increased the difficulty, and would also increase the number of pressure projection iterations on a grid. I tried to simulate buoyancy without cheating (e.g. giving different materials different acceleration to gravity)
If you use WebGPU, for your acceleration structure, try to use the algorithm here presented in the Diligent Engine repo. This will allow you not to transfer data back and forth between CPU and GPU: https://github.com/DiligentGraphics/DiligentSamples/tree/mas...
Another reason I did it on CPU was because with WebGL you lack certain things like atomics and groupshared memory, which you now have with WGPU. For the Diligent Engine spatial hashing, atomics is required. I'm mainly using WebGL because of compatibility. iOS Safari still doesn't enable WGPU without special feature flags that user has to enable.
Yeah, pretty much this, I've experimented with putting on the GPU a bit but I would say particle based is 3x faster than a multithreaded & SIMD CPU implementation. Not 100x like you will see in Nvidia marketing materials, and on mobile, which this demo does run on, GPU often becomes weaker than CPU. Wasm SIMD only has 4 wide but the standard is 8 or 16 wide on most CPUs today.
But yeah, once you need to do graphics on top, that 3x pretty much goes away and is just additional frametime. I think they should work together. On my desktop stuff, I also have things like adaptive resolution and sparse grids to more fully take advantage of things that the CPU can do that are harder on GPU.
The Wasm demo is still in its early stages. The particles are just simple points. I could definitely use the GPU a bit more to do lighting and shading a smooth liquid surface.
You actually can adjust the settings for this. In settings>simulation, instead of sameRestDensity being 8 make it 0 and make it higher for diffRestDensity. I recommend doing it with low gravity as well (you can get zero g by clicking enable accelerometer on computers without accel)
Thanks! I am definitely working on bringing more to the WASM world. I'd begun experimenting with 3D and multithreading and then last week decided to circle back to the 2d demo and polish it up a bit more.
Yes, the previous one is: https://news.ycombinator.com/item?id=40429878
There are some new features since then and some major speed improvements from using SIMD.
I do still see complaints about the compressibility so I still need to work on some improvements for that.
(dev)
This is still the same kind of simulation, based on the Particle-based Viscoelastic Fluid Simulation paper. I updated it to use Wasm SIMD more fully with the help of Clang Vector Extensions, Compiler Explorer and Wasm Analyzer. Compiler explorer to play around with patterns and Wasm Analyzer to double check the final compilation.
Thanks. It's a WebAssembly simulation so mostly CPU and very light on the GPU because it's just drawing points. It will actually run on mobile too with multitouch.
I'm not sure if the between layers thing might be a similar thing to when bubbles show up on the sides and bottom of a glass of water. Some of the bubbles are also staying because once it's settled down, there isn't enough action to cause them to pop. The constant associated with the surface tension in the sim can also be turned down.
Hi, I made this demo. This is actually all from the paper Particle-based Viscoelastic Fluid Simulation (Simon Clavet, Philippe Beaudoin, and Pierre Poulin). It is an SPH type (particle-particle interactions), not MPM (particle-grid-particle). I do a lot of MPM nowadays, and I have a multi-grid thing to help with incompressibility, but this was me re-implementing the first fluid sim paper I ever implemented.
I did the implementation in JS to help other people reading the paper, and tried to keep everything as similar as possible to the pseudocode from just this single paper. Maybe it would be cool to integrate an additional grid on which incompressibility is enforced better but I didn't want to make the source confusing.
It is also a little difficult to do density ratios with just what is shown in the paper, here the masses are set to (1, .8, .6, .4). This is what causes the lightest particles to get launched so violently in the air. Probably would be useful to integrate some ideas from the paper Density Contrast SPH Interfaces (Barbara Solenthaler, Renato Pajarola).
I started revisiting SPH because I have some new ideas to combine it with an MPM/FLIP grid for closeups. I'm trying to do a multi-scale MPM simulation that can handle better surface tension droplets in closeups while also doing extremely large scale scenes. You can see some larger scale parallel sims on my YouTube: https://www.youtube.com/c/GrantKot