The particles are attracted by the position of the mouse, each having a slightly different (randomized) attraction factor.
If a particle ever reaches the exact mouse coordinates, its position is randomly generated anywhere on the screen.
When rendering the particles, it simply draws a line between the previous and the new position. So when a particle is transported to a random place, it create the rays that appear around the cursor.
There's no real complexity in the maths involved, but I remember spending quite some time tweaking the random ranges to get something nice.
Have you seen this VR demo: http://youtu.be/fAhzW4blqvM ? It looks similar enough that I bet it's inspired by yours.
Yours is a very fun demo. I tried modifying it to move more work to the GPU. I had the CPU only update a subset of the particles each frame and the GPU would interpolate a curve to fill in the missing frame updates. It sorta worked. It was N-times faster and could do more particles. But, the interpolated curves were progressively less responsive and fun.
Much of the code comes from a WebGL tutorial (context and shaders creation, and the shaders code). I added the interactive parts, the particles and tweaked the shaders.
The particle positions are indeed computed in Javascript, and even if the version you tried only had 30000 of them, the "real 80000" version [ http://minimal.be/lab/fluGL/index80000.html ] does not raise my CPU usage that much.
A more clever way to code that animation would be to pass the mouse position to the GL shaders that would compute themselves the particle positions, and I think modern GPUs are very optimized for that kind of stuff.
Please don't be too rude, cause it was my first WebGL experiment.
Apologies if I seemed rude, it's really very nice. But yes: a shader absolutely could compute a particle position based on a previous value (and other state, and inputs like mouse position, etc...) as a mapping between, say, a 1D texture and a 1D output framebuffer that gets used as the next frame's source texture. Honestly, given the apparent performance this is what I had assumed was happening.
Having the GPU compute position updates into a texture would indeed be orders of magnitude faster, but it would require the vertex shader to read from a texture to get the results. Unfortunately, vertex texturing is an extension that is not required in the WebGL standard and not supported on a significant percentage of machines. It's almost a shame that vertex texturing makes really fun demos really easy to make. Every time I see a VT demo, there are dozen of comments crying "Doesn't work for me. WebGL is broken!"
No need to read the texture in the vertex shader. Render to a buffer object and use that as your vertex array. But broadly yes: that's the problem with OpenGL support, and WebGL in particular is still very bleeding edge.
I'd be pretty surprised if vertex texture fetch wasn't supported though. It works on basically all hardware from the PVR SGX on up. Unified shaders are pervasive on both phones and desktops. I did find this, though, which implies that for a while that the browsers weren't properly exposing support:
FBOs are absolutely part of ES2, and thus presumably an official part of WebGL. I've used them in embedded contexts, but never in a browser. And as always, this is on the bleeding edge of what the drivers are prepared for, so dragons may lurk. But at least in principle it should work.
I've seen talk of CPU-less render-to-vertexbuffer dating back to 2004, but I've never dug into how to actually do it until now. From what I can dig out, it requires PBOs which are not available in ES2. I guess copying back and forth over the bus via gl.bufferData(ARRAY_BUFFER, gl.readPixels(...), gl.STREAM_DRAW)) is still better than doing the math in JS. I might have to try combining the glReadPixels with the mapped buffer extension that is available on the iPhone P:
When I wrote that experiment (nearly one year ago), I started with 80000 but finally went for 30000 because it was smoother on my laptop. I just forgot to change the title when posting (it was a long ago, and I wasn't expecting it to get much attention).
Please consider this library as an invitation for web devs to dive into html-based multimedia. Its main goal is to highlight the ability to do such things.
It is quite clear that Sprite3D will never reach the level of libraries like Three.js or PaperJS.
