They did two much more impressive demos[1][2] with this technology, including drawing complex geometry using only point sprites, on DX9(no compute shaders).
It's remarkable that those five year old demos could easily do flows, shading and blending on milions of particles in real time, while this JS version starts dropping frames at 262K.
Subtle presentation a great effect, but this bit from the demo's nfo is kind of insane:
3d smoothed particle hydrodynamics with a fully-featured solver,
supporting surface tension, viscosity and collisions with arbitrary meshes.
rendering as metaballs converted to triangle meshes with marching cubes.
simulating around 250,000 - 1 million particles per frame and generating & rendering
several million vertices per frame during triangulation.
except we wanted to do it in realtime. on a consumer gpu. on vanilla directx 9.
no cuda/compute, no geometry shaders. (they'd probably be too slow anyway.)
with everything else youd expect from a modern demo going on around it and on top.
the best possible lighting, depth of field, post-process antialiasing.
twice. (for stereoscopic 3d.)
with style.
The page also shows that sometimes what you think is hard is easy and what you overlook is the really difficult bit:
> The problem with SPH in realtime is it’s really really hard. The simple explanation of the algorithm is: “take all the particles near my particle and perform some force exchange between them”.
At this point I was expecting a long discussion on all the clever tricks they have found to calculate the force exchange between thousands of particles in a snap. And instead...
> The force exchange is easy; the “all the particles near my particle” is a bitch. On GPU it’s even more of a bitch; and in 3D it becomes an order of magnitude more of a bitch.
> [...]
> The problem is simply the neighbourhood search. You end up with a variable amount of fast-moving particles affecting each particle, where it’s hard to pick an upper bound – so the spatial database is hard to construct. If you solve the neighbourhood search, you can solve SPH.
Using Safari, which isn't supported, but I wanted to say kudos to the author for adding a video for unsupported browsers. That was definitely a neat feature that many WebGL demos overlook!
I've no idea what all you folks are using, but in my hands (linux amd64 i5 8Gb debian/jessie) this is a very impressive website in that it straight-out crashes firefox/iceweasel (31.1), stymies firefox nightly (35.0a1), and leaves google-chrome (37.0.2062) declaring that it couldn't be loaded. (just a theory: i'm running nouveau on my nvidia, as the last blob wouldn't compile)
i3 with Mint 17. Looks good[1] up to 131K on Chrome (37.0.2062.120). I don't know if your configuration is wonky or your machine is just old, but it actually is a very impressive website.
This has really nothing to do with js. I could mechanically translate the demo to Haskell or Python and it would perform equally well, as all the heavy computations are done on the graphics card and those are given in a C like but implicitely parallel shader language. All this really demonstrates that the webgl bindings to opengl have minimal overhead. One thing that is impressive, how you can trivially and more or less declaratively define a user interface using the browser rendering engine, whereas a similar user interface in a simple opengl demo would have to be very primitive or use a third party library. This makes such webgl demos much nicer to interact with compared to a similar demo written in c, but the actual code is nearly the same, since it is mainly library calls to opengl.
http://david.li/disintegration/