4 ms·

Is 80000 particles the limit? With Flash you could render +300000 particles years ago: http://www.unitzeroone.com/labs/alchemyPushingPixels/ http://www.unitzer

• mistercow 14y ago
  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 14y ago
    Actually the 'math' was done using alchemy, the shader was pixelbender http://www.adobe.com/devnet/pixelbender.html 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/ http://www.simppa.fi/blog/1_point_4_million_particles/
    • mistercow 14y ago
      Well, that's looking like about 3 fps; it's a lot more particles, but it's also a lot slower, so I don't know how that balances out.
    • lloeki 14y ago
      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-particles-with-pyopengl/index.html http://enja.org/2011/03/22/adventures-in-pyopencl-part-2-par...
• arthur_debert 14y ago
  Also look that the stage (canvas) size for the demo (this used to make a big difference in older versions of the player at least).
• spot 14y ago
  you can do the same in JS if you have such simple particles as well (ie rendering by just writing a few bytes). http://mrdoob.com/lab/javascript/strangeattractor/ http://mrdoob.com/lab/javascript/strangeattractor/ does 300k as well (though it's borked right now since he has to update his stats code). here's another fast one in webgl: http://iacopoapps.appspot.com/hopalongwebgl/ http://iacopoapps.appspot.com/hopalongwebgl/ reading the source, it has 280000 particles.
• jcromartie 14y ago
  No it's not the limit. I cloned the page and changed it to 300K, and it seems to work.
• mrhyperpenguin 14y ago
  Probably not. The author of this WebGL app is updating the particles on the CPU which probably explains the low particle count. Now-a-days it's pretty much standard to use two floating-point off screen textures to store, update, and draw the particles completely on the GPU. This way, you can get 1M+ particles easy.
• zoop 14y ago
  While looking pretty, the demo actually is fairly unoptimized. Each draw loop the vertex buffer is rewritten after iterating over and updating each particle's velocity. Preserving state directly on the GPU makes it so you can get up into the millions of particles (depending on the videocard of course): http://mikecann.co.uk/projects/HaxeWebGLParticles/ http://mikecann.co.uk/projects/HaxeWebGLParticles/