51–60 of 85 posts
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
http://www.html5rocks.com/en/tutorials/webgl/million_letters...
Also, a paper about pure-GPU implementation:
Is there a way to start experimenting with webgl using python?
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…
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.
Earlier quoted context omitted.
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…
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…
Can someone give us a screenshot or video for those of us without webgl enabled?
(the WebGL animation is part of an interactive installation)
The code for this is quite readable and well-commented, and seems to be actually really short as well.
Earlier quoted context omitted.
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…
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.
Earlier quoted context omitted.
Yeah it is: http://news.ycombinator.com/item?id=4008846
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