If you haven't tried Animal Well, give it a shot. The whole game and its custom engine are like 35MB and it's filled with really cool visuals and physics powered by fluid equations.
So once upon a time I stumbled upon simulating fluids in gamedev and I really wanted to learn how it works. Fast forward 2 months and I decided to write down everything I learned to hopefully make it easier for others in the future!
Great job. I have spent a lot of time working on fluid simulations (I still am). Glad to see more people still mesmerized. If you’re interested, this rabbit hole goes very deep.
Before 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 unfiltered value.
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.
I wonder how it'll read in 20 years. Like all the covid references in blog posts from 2020, or vague references to "the current political situation" from any point in the last 10 years or so.
This 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
This is really cool. I love how much detail you went into explaining the setup and walking through each piece of the simulation. Definitely bookmarking this to play around with later!
AI model latent space needs to be instrumented to a DAW and 3D helical visual effects on triangle slices to show the mathsemantic field gears grinding at the prompt: What's on your mind?
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).
Sure, but conservation in ray tracing is also a goal that not everyone has and isn’t required for teaching or games or making pretty & even plausible images. There are plenty of situations in both ray tracing and fluid simulation where conservation is not desirable.
Nice 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 you crank N up the missing confinement becomes visible.
Web exports from Godot (and other game engines) played on mobile is a hard place between compatibility, performance, and many other factors. It's getting better, but very slowly. Try on PC
https://store.steampowered.com/app/813230/ANIMAL_WELL/
Couple of notes, I think you forgot to apply timestep when adding rocket exhaust velocity, pretty sure it should be
You need to compensate by scaling up flame_velocity_amount, I used 85, seemed about the same.Thank you
In my implementations I use 4th order for both and vortices stick around a lot longer.
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 unfiltered value.
[1]: https://developer.nvidia.com/gpugems/gpugems2/part-iii-high-...
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.
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
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 you crank N up the missing confinement becomes visible.