1) implementation there's quite some boilerplate in JS to set up all the textures and the main animation loop, but if you look closely the CPU is mostly idle and the "heavy lifting" is all done on the GPU by several shader programs. There are no libraries used and you can take a copy of the html file and simply start by breaking things apart. For the massive speed I'm updating the particle data with a clever fragment shader trick that i've learned from https://twitter.com/BlurSpline/status/161806273602519040 And in a DIY fashion, I've mashed this up with my own texture feedback loop. The main idea is that the particle positions (and the velocity vectors too, each 2D only) are stored in a texture's rgba values (float32). So updating the particles data is in fact a render process of a quad in one draw call. Then I had also rendered the particles to another texture to sum up the "density" of the primitive 1 pixel point projections.
2) complexity when it comes to the mere particle count, the complexity really is O(n), but there's a wee bit more to it. The projection of the particles to the framebufferobject or the screen is the most costly in this setup and it's fillrate-limited by the graphics card. There's a noticeable difference when the particles are evenly distributed or when they overlap, but it must stay in the O(n) realm i suppose. Then there's another texture feedback loop system that is also directly dependent on the pixel count. The particles are stored in a 1024x512 pixels wide texture and the hidden texture feedback layer is also of that size, but it could differ too. There is absolutely no direct interaction between any two particles here. I project the particles to a density texture that is then diffused with an optimized two-pass Gaussian blur calculation and several resolution reduction steps. All the textures from the different steps are available as in put sampler to the shader programs, in particular "fs-advance" for the Turing patterns and the density projection (hey there, the blue channel is unused ^^) and "fs-move-particles" where i simply grab the gradient from the diffused density to update the particle's velocity vector and do the verlet integration.
The concepts used here also have names - just ask google or wikipedia for "dissipative systems/structures" and "stigmergy".
3) the fluid simulation code is not by me! Evgeny Demidov is the original author of the WebGL shaders for that: http://www.ibiblio.org/e-notes/webgl/gpu/fluid.htm I'm only adding to the current advection matrix
4) code size this could possibly fit into a 4k demo but i have no interest in that kind of challenge. i rather like to share something that is easily readable by others.
cheers!