Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Liquid Layers

grantkot.com

Post reply on HN
Print view View original

51–58 of 58 posts

Re: Liquid Layers

#51

Post by kotsoft »

pornel wrote: post #11
BugsJustFindMe wrote: post #8

Are there compressible liquids? I'm seeing the whole thing bounce like the layers are compressing.

This is a common and difficult problem when simulating fluids using particles. It's possible to simulate using a grid instead, and that computes pressure very precisely, but it has a downside of adding inaccurate viscosity. And there are tricks that combine both approaches to balance out the errors.

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)

Re: Liquid Layers

#52

Post by lukan »

kotsoft wrote: post #50
lukan wrote: post #46

Earlier quoted context omitted.

"Collision detection is usually a tree search" Yes, because of the very limited numbers of CPU cores. With a GPU you can just assign one core to one particle. Here is a simple approach to do it with WebGPU: https://surma.dev/things/webgpu/ It uses the very simple approach, of testing every particle with EVERY other particle. Still very performant (the simulation, the choosen rendering with canvas is very slow) I curr…

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 Dilig…

Thanks a lot, that is very interesting! I will check it out in detail.

But currently I will likely proceed with my approach where I do transfer data back and forth between CPU and GPU, so I can make use of the CPU to do all kinds of things. But my initial idea was also to keep it all on the GPU, I will see what works best.

And yes, I also would not recommend WebGPU currently for anything that needs to deploy soon to a wide audience. My project is intended as a long term experiment, so I can live with the limitations for now.

Re: Liquid Layers

#53

Post by kotsoft »

ta435747 wrote: post #36
owork138 wrote: post #32

[dead]

That link just goes to the libgenis home page (although cool site! will have a look around). All I could find from the OP so far is: https://www.reddit.com/r/VoxelGameDev/comments/ecxiyw/voxels... that has a few links to a YT demo and some papers referenced.

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.

Re: Liquid Layers

#54

Post by kotsoft »

CaptainOfCoit wrote: post #31
d--b wrote: post #24

I really wish these were 3D simulations. The 2D ones are always a bit off to me...

"3D Liquid WIP Preview" https://kotsoft.github.io/pvfs3d/ From the description of "WebAssembly Liquid Simulator" https://www.youtube.com/watch?v=phXwC6HxWEQ Incredible stuff.

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.

Maybe WebXR will be good for the 3D version.

Re: Liquid Layers

#55

Post by kotsoft »

butterNaN wrote: post #41

I know this is asking a lot from what is already a bundle of fun, but I wish it also made noises, in fact my brain is already simulating some It's like a visual stim toy

Here's a video of the spatial sounds system from my 3D sims: https://www.youtube.com/watch?v=0HJ5lMpWTXQ

I will see if I can bring it to WebAudio.

Re: Liquid Layers

#58

Post by troglobite »

lukan wrote: post #39
troglobite wrote: post #17

Earlier quoted context omitted.

this kind of sims are better suited for CPU ;-), gpu are good to work on meshes, not really on pure particles. At GPU are super good for grid based hydro.

"gpu are good to work on meshes, not really on pure particles" Why? Having thousands of particles, all in need of doing the same operations on them in parallel screams GPU to me. It is just way harder to program a GPU, vs a CPU.

The issue is not really parallelism of computation. The issue is locality. Usually a hydro solver need to solve 2 very different problem short and long range interaction. therefore you "split" the problem into a particle-mesh (long range) and a particle to particle (short range).

In this case there is no long range interaction (aka gravity, electrodynamics), therefore you would go for a pure p2p implementation.

Then in a p2p, if you have very strong coupling between particles that will insure the fact that neighbors stay neighbors (that will be the case with solids, or with very high viscosity). But in most case you will need are rebalancing of the tree (and therefor the memory layout) every time steps. This rebalancing can in fact dominate the execution time as usually the computation on a given particle represent just a few (order 100) flop. Then this rebalancing is usually faster to be done on CPU than on GPU. Then evidently, you can do this rebalancing "well" on gpu, but the effort to have a proper implementation will be huge ;-).

Post reply on HN