Generative artist here: the beautiful thing about this exploration is that these techniques can be applied to ANY vector field, whether they originate in random noise or global simulations.
The reason these add so much visual interest to a simple noise function is that each pixels color now relies on many more of the random values. Generative art blossoms with this extra computational effort.
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 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).
On the other side, I am a lifelong Linux user, and even with advanced LLMs, trying to get Microsoft Windows to behave sanely takes hours every month for years on end (thanks, day job). Things Linux figured out in 2003 are still magic or completely undoable on Windows.
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.
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.
Sure, I usually measure performance of methods like these in terms of FLOP/s; getting 50-65% of theoretical peak FLOP/s for any given CPU or GPU hardware is close to ideal.
Quadtrees and octrees are themselves quite deep research areas. If the acceleration data structures interest you, I highly recommend Hanan Samet's book "Foundations of Multidimensional and Metric Data Structures". It's from 2006, but is basically the bible for the field.
Note that even without an acceleration structure ("direct summation" in N-body research terminology), a CUDA program or GLSL shader program can exceed 60 fps with 10,000 to 20,000 particles. And a parallel, C/C++/fortran vectorized CPU code can do the same with over 5 thousand.
The general algorithm used here (of computing attraction and repulsion forces between pairs of particles) is very similar to that used in simulations of many interesting phenomena in physics. Start with Smoothed Particle Hydrodynamics (https://en.wikipedia.org/wiki/Smoothed-particle_hydrodynamic...) and then check out Lagrangian Vortex Particle Methods and other N-Body problems (https://en.wikipedia.org/wiki/N-body_problem).
And the algorithms to solve these quickly is another deep area of research.
Thank you - I was just about to point out some of that.
The reason that the flocks are tight is because the separation "force" is normally computed as a repulsion between a target boid and all other nearby boids individually, not vs. the center of mass of all nearby boids.
Let's be a little more clear: these are not "laws" as much as they are scaling relationships, this is not "new math" (see Ziph and others), and central planning has always had an impact on city development. Nevertheless, I appreciate this line of inquiry.