Navier-Stokes fluid simulation explained with Godot game engine
31–36 of 36 posts
Re: Navier-Stokes fluid simulation explained with Godot game engine
#32The unlinked Jos Stam paper is available from his website https://www.dgp.toronto.edu/public_user/stam/reality/Researc...
Thanks, I didn't know it was available there - I'll update my blog and add the link as soon as I'm off work
Re: Navier-Stokes fluid simulation explained with Godot game engine
#33This is great! When I have some leftover time I want to try copying this implementation for 3D. I reckon I could get away with minimal modifications to support the third axis...I think... That'll perform even worse though, hopefully my CPU can handle it or I'm gonna need a lot of leftover time to make a shader
Yes, this should be relatively easy to extend to 3D. Performance might pose some issues so I advise to stick to a small grid, or look for optimizations like decreasing the amount of Gauss-Seidel loops etc. Moving this into a C++ library would also probably help a lot
Re: Navier-Stokes fluid simulation explained with Godot game engine
#34Nice writeup. One thing worth adding to the limitations: without vorticity confinement, the Gauss-Seidel projection step quietly dissipates the small-scale curl that makes smoke look like smoke. The 2001 Fedkiw/Stam/Jensen "Visual Simulation of Smoke" paper added it back as a correction force for exactly this reason. At N=16 it doesn't matter much because the grid itself can't represent fine vortices, but the moment…
Thank you, that's good to know when I try to move this to a Compute Shader and try to make it part of a game in the future
Re: Navier-Stokes fluid simulation explained with Godot game engine
#35Earlier quoted context omitted.
I mean if you're writing a ray tracer and the reflected light has more intensity than the light sources, then that's not desired. You can have the same sort of thing going on with a fluid simulation.
One of the nice aspects of Stable Fluids is that you don't need to iterate the pressure correction terms to convergence. Just run a fixed number of Jacobi or Gauss-Seidel sweeps and keep performance consistent. The only drawback of this is some mass loss in areas, which for the present purposes is acceptable.
I should add that this is a major "tell" for detecting when an app uses the Stable Fluids method: obvious mass loss (and very viscous, energy-dissipating flow).
Re: Navier-Stokes fluid simulation explained with Godot game engine
#36Before you go adding vorticity confinement, consider performing a higher-order backward advection scheme (Runge-Kutta 2nd or similar), and using a higher-order interpolation method (triangle-shaped cloud instead of bilinear). In my implementations I use 4th order for both and vortices stick around a lot longer.
If you implement this on the GPU, it's my understanding you can get the 4th-order interpolation quite cheaply exploiting the bilinear texture sampling hardware[1]. So instead of reading 16 grid values and combining them to get the interpolated sample value, you can fetch 4 bilinearly filtered samples and combine those. And thanks to the hardware filtering, those bilinear samples cost basically the same as reading an…
Yes, I do 4th order interpolation (M4') on the GPU. This paper is for 3rd order, though, but the methods may extend.
I suppose because the fetches are generally to similar memory regions, there may not be a substantial performance improvement due to L1 and L2 hits on recent GPUs.