

WebGL: 80,000 particles - siavash
http://minimal.be/lab/fluGL/

======
hemancuso
The most impressive bit of this is that it it keeps under 20% CPU on my
Mid-2010 MBP [Chrome 19].

It's hard not to imagine another cyclical shift towards browser centric
development, away from rich client apps, when you have Chrome pulling off
tricks like this. Things that would've seemed impossible in 2008, the last
time everything was moving to the browser.

Give Apple/ARM/Intel/Samsung a few more cycles in mobile [more RAM, if nothing
else!] and you might need to reconsider the disadvantages of native apps in
favor of all the advantages that centrally hosted applications offer [no Apple
fee, no pirating, continuous deployment, cross-platform, etc, etc.].

I long for a vibrant open-source project that builds quality widgets and
elements for people to use inside this framework. Let's not pretend jQuery
mobile et. al. are anywhere close.

~~~
ajross
CPU utilization is the wrong metric. Your CPU is mostly idle because it's
feeding a tiny set of commands to the GPU each frame, and then idling waiting
for user input and/or vsync. The GPU is running full-tilt, but unfortunately
there's no good OS-level tool to show that.

One of the reason CPU utilization is so low is that this is a demo. Most of
the "logic" is just a straightforward computation of the mouse position, and
the particle coordinates are all figured out from that in the shader engines.
Real apps and games have real data that needs to be crunched.

( _Edit: I just checked the source, the particle positions are actually
computed in Javascript, the shaders are just straight rendering. And I don't
see anything particularly clever about the implementation, it's just a bunch
of array accesses. V8 is doing an amazing job on this._ )

But broadly, you're right: the need for highly optimized native code to drive
a modern GPU has mostly disappeared. A javascript interpreter (well, V8) is
more than good enough.

~~~
boblemarin
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.

~~~
ajross
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.

~~~
corysama
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!"

~~~
ajross
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:

[http://stackoverflow.com/questions/4349389/webgl-texture-
acc...](http://stackoverflow.com/questions/4349389/webgl-texture-access-in-a-
vertex-shader)

~~~
corysama
> Render to a buffer object and use that as your vertex array.

I don't think that's an option in ES2 or WebGL. I'd love to be proven wrong!

~~~
ajross
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.

~~~
corysama
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:

------
ashleyw
It's actually 30,000 particles, not 80,000. See the source: "numLines =
30000".

If you set a breakpoint at that line (28), then you can edit the variable in
the console to whatever you want. You can make it smaller without setting the
breakpoint, but any higher results in a "attempt to access out of range
vertices" error.

I can get it to ~40,000 on my iMac's 6970m 2GB without noticeable slowdown
(this is w/ Chrome 20 dev.)

~~~
schwa
Vertex indexes are 16 bit. It's probably set to 30000 for a very good reasons.

~~~
boblemarin
Please, check my post below for the truth about the numbers
<http://news.ycombinator.com/item?id=4009469>

------
windsurfer
I used particles pretty heavily in my (inneficient) WebGL game Up and Above:
<http://littlesquareblock.com/upandabove>

It's not nearly as efficient as this demo, but it's at least a game. There are
at least a dozen areas I could fix up to prevent the GC from going nuts if I
was so inclined, but it works fine for most people.

~~~
timtadh
Pretty neat game. WebGL is still a little clunky on Linux but I was still
getting a playable framerate (but just barely).

~~~
bananaoomarang
Seem to work well here (under Arch Linux, Chrome dev channel, nVidia
proprietary drivers)

~~~
windsurfer
Nice, I am an Arch user too :)

------
tintin
Is 80000 particles the limit?

With Flash you could render +300000 particles years ago:
<http://www.unitzeroone.com/labs/alchemyPushingPixels/>

~~~
mistercow
That demo gets about 19 fps on my machine, whereas the WebGL demo appears to
be getting close to 60, so that seems to be scaling pretty similarly. Also
keep in mind that the demo you linked to uses Alchemy, which is C/C++ compiled
to AVM2, so for WebGL to be getting roughly equivalent performance is pretty
damned impressive.

~~~
Father
Actually the 'math' was done using alchemy, the shader was pixelbender
<http://www.adobe.com/devnet/pixelbender.html> However the example was flash
then (3 years ago) vs webgl now. This is flash now; a version with 1.4 million
particles using the new molehill
<http://www.simppa.fi/blog/1_point_4_million_particles/>

~~~
lloeki
From the 1.4M page:

 _"On my OsX toy the difference between flash on browser and standalone is
insane. 200 000-300 000 particles is pretty much the maximum until it won’t
run smooth anymore. I wonder if this is memory related thing? or what? Who
knows? Someone from Adobe might… Well anyways. Here’s the same thing exploding
1.4 million particles in 1920×1200 resolution with smooth 60fps."_

Interesting behavior.

On that other JS demo mentioned in a sibling comment my puny 9400m runs at a
steady 30fps at 100k with 7~10% CPU on Safari. The same goes for some non-
browser pyopencl [0], which uses about 10% CPU. I seem to be hitting a sort of
bottleneck here as ramping either up to 200k or using the Flash realtime demo
brings FPS down to about the same level. The Flash one though, uses between 20
and 60% CPU and mostly hovers around 30%. Whatever that means.

[0] [http://enja.org/2011/03/22/adventures-in-pyopencl-
part-2-par...](http://enja.org/2011/03/22/adventures-in-pyopencl-
part-2-particles-with-pyopengl/index.html)

------
cpfohl
Wow, that's awesome.

if you don't let the particles catch up w/ your mouse (and trace circles
around them) the gather up in one place and turn white, resulting in some
spectacular 'explosions'

~~~
TazeTSchnitzel
If you let them catch up, you can make a sort of pink torus around the mouse.

~~~
jQueryIsAwesome
If you move it steady in a vertical line it creates two lines that looks like
they were smashing against each other.

I actually think this could become a game; maybe you show the player a pattern
and then he tries to recreate it... or something among those lines.

~~~
donut
There is already such a game, kind of:

<http://www.ea.com/auditorium-iphone>

Some of the levels are pretty hard!

------
nullspace
I get a dialog box : "There's no WebGL context available.". :\

Using Google Chrome 19.something on Ubuntu, with open source radeon driver.

~~~
sigkill
Chrome 18, nVidia GTX260M, on Windows with official binaries.

Same error.

------
Davertron
For anyone who's curious like I was, just go to <http://minimal.be/lab/> for a
full listing of other cool stuff he's worked on.

~~~
fuzzythinker
Love the portrait, audioSnake, and jQuery.eraser

------
mbell
Very cool, love it, wasted much time.

Very small bug I thought I'd mention: If you resize the browser window the
center of the particles no longer tracks the mouse pointer location but rather
appears to be offset by an amount depending on the resize that happened.
W7/C19

------
nextparadigms
It looks very impressive. I'd love to see some kind of game using particles
like that, something like Osmos:

<http://www.youtube.com/watch?v=pso6UBicLWU>

~~~
Flow
Spheres of Chaos... Mmmm. <http://www.spheresofchaos.com/>

~~~
starwed
That would be a great game to port to the web.

------
Jyaif
You can get 100 times as many particles by doing a pure shader based solution.
Still, very impressed by the speed of JS.

------
joncooper
If you're interested, here's a nice piece of related work:

[http://www.html5rocks.com/en/tutorials/webgl/million_letters...](http://www.html5rocks.com/en/tutorials/webgl/million_letters/)

Also, a paper about pure-GPU implementation:

<http://www.2ld.de/gdc2004/MegaParticlesPaper.pdf>

------
kiloaper
Amazing! (and works great in Firefox on Win7 as well)

~~~
mike-cardwell
Works great using Firefox on my Ubuntu laptop with only integrated graphics
too. Although I had to click the NoScript placeholder to allow the WebGL to
execute.

------
tannerc
This is wonderful. Turn on some good music and play around with this, makes me
think it would be a fine music video for some remixed songs.

------
keeran
Reminds me of Gravilux

<http://www.snibbe.com/store/gravilux/>

------
mxfh
Don't know how many of these 3.7 million static data points are rendered live,
just found this way more impressive:
[http://www.chromeexperiments.com/detail/swiss-addresses-
in-3...](http://www.chromeexperiments.com/detail/swiss-addresses-in-3d)

------
DigitalSea
Works absolutely flawlessly in Chrome, impressive stuff. Can't wait to see a
company like Blizzard release a HTML5 MMO in a few years time (it'll
definitely happen). Imagine a game like Diablo 3 in HTML5? Wow.

------
thu
From this tweet, it seems it is actually 30000 particles:
<https://twitter.com/boblemarin/status/204943143798448129>

~~~
ashleyw
Yeah it is: <http://news.ycombinator.com/item?id=4008846>

~~~
boblemarin
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).

If you want to benchmark the same page with 80000 particles, try this link :
<http://minimal.be/lab/fluGL/index80000.html>

------
alan_cx
Just in case people have missed the link at the bottom of the page:

<http://minimal.be/lab/fluGL/index80000.html>

------
tbundy
This is awesome. Also like his Lego survey stats app
<http://minimal.be/lab/legoStats/>

------
38leinad
any idea why i get the JS error "requestAnimationFrame is not defined" when I
run the HTML page on my local system. Same browser (firefox 12)) renders the
online-like just fine. As i understand this method is part of the browser's JS
api. So, why is it not defined if I run it "locally"?

~~~
banthar
Have you downloaded all the files? requestAnimationFrame is defined in
<http://minimal.be/lab/fluGL/RequestAnimationFrame.js>

~~~
38leinad
thanks; i missed the import. I only remember that the method also exists in
the JS api itself. did not think that there might be a wrapper around with the
same name :-)

~~~
daeken
AFAIK, no browser uses the name 'requestAnimationFrame'; everyone prefixes it
still.

------
CodeCube
Thanks for taking literally 10 minutes of my time ... pretty badass, am always
mesmerized by particles :)

------
notJim
The code for this is quite readable and well-commented, and seems to be
actually really short as well.

~~~
boblemarin
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.

------
goostavos
This is.. this is really quite neat.

Is there a way to start experimenting with webgl using python?

------
Tomis02
Doesn't work in Opera 12. Meh.

------
daenz
Can someone give us a screenshot or video for those of us without webgl
enabled?

~~~
boblemarin
you can see screenshots and videos on that page : <http://checkthis.com/7ezv>

(the WebGL animation is part of an interactive installation)

------
skiplecariboo
1993

------
bananaoomarang
This is pretty awesome, I hacked it so it's color-morphs now! Awesome stuff.

------
louhong
Would love to see this hacked to work with Kinect or the leap.

------
nixisfun
On my core i7 it does not go above 7% core usage. Very nice.

------
tudorw
circling the particles to try and trap them is fun, makes me feel a bit like
one of those machines they try and trap plasma in :)

------
quaz3l
Yup spent a solid 45 minutes not doing work.

------
Fizzadar
Awesome & beautiful, love it!

------
chucknelson
Wow, that is pretty impressive.

------
mouseroot
pretty cool i would like to see this put into use for a webgl sands game

------
BowlOfChilli
Me loves it, awesome.

