Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebGL: 80,000 particles

minimal.be

Post reply on HN
Print view View original

61–70 of 85 posts

Re: WebGL: 80,000 particles

#61

Post by ashleyw »

ashleyw wrote: post #35

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…

UPDATE: It turns out the slowdown at 40,000 was due to the Web Inspector being open (I have no idea why!) It's actually still pretty damn smooth at a MILLION particles! Crazy!

Re: WebGL: 80,000 particles

#62

Post by ajross »

corysama wrote: post #59
ajross wrote: post #55

Earlier quoted context omitted.

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. Eve…

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

Re: WebGL: 80,000 particles

#63

Post by lloeki »

Father wrote: post #38
mistercow wrote: post #11

Earlier quoted context omitted.

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.

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/

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

Re: WebGL: 80,000 particles

#64

Post by tretiy3 »

windsurfer wrote: post #18
timtadh wrote: post #17

Earlier quoted context omitted.

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

That's good to know. We get really bad performance on linux because of the AA I think.

core i3, 3Mb ram ubuntu 12.04 works nice. great job! thanks

Re: WebGL: 80,000 particles

#66

Post by 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

Re: WebGL: 80,000 particles

#67

Post by brooksbp »

hemancuso wrote: post #23

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 […

This is fun to play with on a cr48. Performance is decent for the given hardware.

Re: WebGL: 80,000 particles

#70

Post by Andys »

ajross wrote: post #44
hemancuso wrote: post #23

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 […

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…

http://manpages.ubuntu.com/manpages/lucid/man1/intel_gpu_top...

While running this page on Firefox on Ubuntu it showed:

    render busy 7%
    bitstream busy 0%
    blitter busy 10%
    Vertex Shader Invocations: 1520152/sec
    Pixel Shader Invocations 59160531/sec
Post reply on HN