9 ms·
WebGL: 80.000 particles
- amelius 12y agoCool. I wonder what the governing equation for the particles is... Also, If I open developer console in Chrome (docked at the bottom), it seems the mouse position is off like 100 pixels or so.
- boblemarin 12y agoThe 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.
- amelius 12y agoOkay, thanks for sharing. But still, I'm wondering why the orbits of the particles always end up being roughly the same size.
- corysama 12y agoHave you seen this VR demo: http://youtu.be/fAhzW4blqvM 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.
- hmottestad 12y agoWorks perfectly on my macbook pro 15" retina from 2012.
- thomasfoster96 12y agoSmoothest WebGL I've ever used on my iPhone. Well done whoever created this!
- sebgeelen 12y agoIt's this guy (https://twitter.com/boblemarin https://twitter.com/boblemarin). I know him, and he is pretty damn good.
- boblemarin 12y ago:)
- LaSombra 12y agoWorks fine on my Lenovo T530 with Fedora 21
- crossroads091 12y agoWhy the hate?
- vixen99 12y agoDefinitely minimal on my Firefox
- imron 12y agoI had the same problem - then I realised you need to click/drag the mouse.
- Udo 12y agoI was expecting the particles to be done as a pure shader implementation, but when I looked at the source that's not the case. While a vertex shader is used to display the particles, the "physics" is done in a JavaScript loop.
- boblemarin 12y agoExactly, there's not much optimisation in there. In fact, it was my first try with WebGL.
- pierrec 12y agoThis also surprised me. You can do the exact same thing, but with millions of particles, if you store and process them on the GPU. The first example of that technique being used in WebGL is probably by Mr.doob [1]. Since then, there have been many iterations, some of which are basically a cooler version of the linked demo [2]. (And simpler, judging from the source!) [1]: https://www.chromeexperiments.com/experiment/magic-dust https://www.chromeexperiments.com/experiment/magic-dust [2]: https://www.chromeexperiments.com/experiment/one-million-particles https://www.chromeexperiments.com/experiment/one-million-par...
- thekemkid 12y agoThat is so cool. There's a great demo of orbitals and the like that can be picked up from this. I would have loved if a physics teacher showed me something like this when I was in school.
- fulafel 12y agoThe standard particles example in three.js has 500.000 particles. A description like "80k dynamic interactive physics based particles" would do this one more justice. (There's a dynamic particles demo in the threejs examples too, though it doesn't say how many there are...)
- davexunit 12y agoSince these particles aren't dynamic, they are much easier to render at high volume. You create the vertex buffers once and you're done. Dynamic particles are a lot more complicated, since the buffer needs to be updated constantly. If anyone has some good articles about how to render a large number of dynamic particles, where the simulation happens on the CPU (i.e. it's not all shader trickery), using modernish OpenGL (no fixed function stuff), please share. I'm eager to learn more about it, but haven't found good resources. It's a blocking issue towards my goal of creating a bullet hell shoot-em-up game.
- flohofwoe 12y agoUnfortunately dynamic buffer updates is one of the tricky parts to do right in OpenGL since you need to assume what the driver does under the hood, and the best technique depends on what GL version you're targeting, and what GL extensions are available. I found this blog post very useful: http://hacksoflife.blogspot.de/2012/04/beyond-glmapbuffer.html http://hacksoflife.blogspot.de/2012/04/beyond-glmapbuffer.ht... If you can afford to target bleeding edge OpenGL, the AZDO slides contain the current state of the art (there's a whole section about dynamic buffer updates somewhere in there): http://www.slideshare.net/CassEveritt/approaching-zero-driver-overhead?related=1 http://www.slideshare.net/CassEveritt/approaching-zero-drive... On WebGL, the established tricks like buffer orphaning don't work, and direct mapping isn't available. It seems best to simply do a bufferSubData and not care about double buffering etc (https://groups.google.com/forum/#!searchin/webgl-dev-list/floooh/webgl-dev-list/vMNXSNRAg8M/lu1NkJ22J_YJ https://groups.google.com/forum/#!searchin/webgl-dev-list/fl...)
- maccard 12y ago80k particles isn't an awful lot, unfortunately. I can hit well into the millions on desktop GPU's, so I would assume 2-300k would be well achieveable EDIT: Seems that http://threejs.org/examples/#webgl_buffergeometry_particles http://threejs.org/examples/#webgl_buffergeometry_particles has 500k.
- benihana 12y agoI think this is a few years old. I remember seeing it before.
- flohofwoe 12y agoThis three.js demo doesn't seem have dynamically updating particles though, it's essentially rendering static geometry (as far as I can glance from the source).
- acadien 12y agoParticles can be misleading too because if they're simply propagated by some PDE on a regular mesh (or even no mesh) it is an embarrassingly parallel problem. But if they're interacting particles then you need neighbor lists and predictor corrector methods to propagate them which is considerably more difficult to implement and parallelize.
- maccard 12y agoBut the original post isn't interacting either, it's just an integration with gravity, that happens to be rendered by WebGL.
- acadien 12y agoYeah that's what I'm saying, if this demo has been 80,000 interacting particles it would be extremely impressive.
- jblow 12y agoNot really. Back in 2002 we did the first game jam where the engine concept was "100,000 guys". That was 13 years ago: http://www.indiegamejam.com/igj0/ http://www.indiegamejam.com/igj0/ Those guys all interacted with each other and the environment (though the engine was designed to do the interactions in slices, where 1/N of the guys would be checked each frame, but N was not high, like 4 or 5 maybe?)
- LoSboccacc 12y agowe need a remake of this now https://www.youtube.com/watch?v=E_87pSWYhKo https://www.youtube.com/watch?v=E_87pSWYhKo 'attack of the killer swarm' one of the first round of games out of experimental gameplay project
- sebgeelen 12y agoThis same page appear on HN almost 3 year ago : https://news.ycombinator.com/item?id=4008040 https://news.ycombinator.com/item?id=4008040. Interesting how this all WebGL stuff is still so "hacky" and not yet commonly used all around .
- pjmlp 12y agoMaybe because it isn't available everywhere, specially in mobile platforms?
- bhouston 12y agoIt is available on all new Android and iOS devices. And it mostly works (although less so iOS devices.)
- pjmlp 12y agoAs if everyone just would dump their devices and buy new ones for WebGL. Not everyone is using iOS 8 and Chrome blacklists lots of Android handsets, and lets not forget about other mobile OSes. I also assume you also checked Android Auto and TVs regarding WebGL support.
- bhouston 12y ago> As if everyone just would dump their devices and buy new ones for WebGL. That just happens every three years, and we don't have to do anything about that.
- bastomi29 12y agohttp://airterjun99.mywapblog.com/5-air-terjun-terdekat-dari-jakarta.xhtml http://airterjun99.mywapblog.com/5-air-terjun-terdekat-dari-...
- sakri 12y agoI made a test a while back to see how Canvas performs with particles : http://codepen.io/sakri/full/ntLAv http://codepen.io/sakri/full/ntLAv . If I select the "per pixel" method, on my old laptop I get 60fps with 80,000 particles. I wasn't very impressed :D (although I'm sure the code could be improved)
- flohofwoe 12y agoI did some emscripten/WebGL performance tests a while ago which went into the hundred-thousands particles for 3D-shape-particles at 60fps, but this depends very much on the target hardware, less on the browser or operating system. Both tests use simple 3D shape particles (5-vertex diamonds) and hardware-instanced rendering (instanced_arrays extension), the first updates particle positions on the CPU, the second on the GPU (fragment shader writes particle position to offscreen render target, which is then sampled in vertex shader to displace particle positions). The first (CPU updates) goes up to around 450k particles on my Windows7 desktop machine before consistently dropping below 16ms per frame, the second (GPU updates) goes to about 800k particles before dropping below 60fps: http://floooh.github.io/oryol/Instancing.html http://floooh.github.io/oryol/Instancing.html http://floooh.github.io/oryol/GPUParticles.html http://floooh.github.io/oryol/GPUParticles.html These numbers are not much different then using desktop GL (2.1 with extensions). The real advantages for this type of scenario would come from updating persistently mapped buffers which are not available in WebGL. What's impressive is the raw math performance of asm.js, the particle update loop is simple glm code (https://github.com/g-truc/glm https://github.com/g-truc/glm) without any fancy optimizations.
- marcosscriven 12y ago>What's impressive is the raw math performance of asm.js I continue to be staggered at how well asm.js performs, and really glad Chrome has taken on optimising for it as well as Firefox.
- corysama 12y agoRunning the instancing demo on an iPhone6+ I can get to 150k particles before dropping below 60fps. There's an obvious speed up about three seconds in where I guess the JITter decides to get serious. So, even though there's no official support for asm.js on mobile safari. It still works surprisingly well!
- hackcasual 12y agoTry it without instancing. I was working on a rendering approach and initially went with instanced rendering. I was reading about how badly some GPU's handle that, so switched it off and saw a pretty decent perf gain. Basically trading some startup time to mass create the attribute buffers in exchange for better ongoing perf.
- im2w1l 12y agoBy drawing circles rapidly around the particles, you can herd them into a tiny blob. Move your mouse into the blob for a colourful explosion.
- hamburglar 12y agoThis is always the first thing I do with one of these. It's so satisfying. On this one, if you make big, fast circles so the blob is moving as little as possible, then you let go, you can get the whole blob to just drift off to the side and stop (it disappears), so when you mousedown again somewhere else, you get a big stream of them all coming from the same general area. I could play with this for hours. :)
- ykl 12y agoHere's a much cooler version by Nop Jiarathanakul. Nop's version has shape targeting, which is especially cool. Check out the running horse. http://www.iamnop.com/particles/ http://www.iamnop.com/particles/
- jbogp 12y agoBig difference between this one (which is great) and OP's is that OP's done all the WebGL himself whereas Nop's uses Three.js
- nopjia 12y agohere's one with 1 million particles done in vanilla WebGL http://www.iamnop.com/particles-mrt/ http://www.iamnop.com/particles-mrt/ (it's a little unstable since it uses WEBGL_draw_buffers)
- conkrete 12y agoOn my currently laptop I only pull about 5fps when viewing this. Indeed cool, but the OPs (albeit more simple) runs at a solid 60fps
- msl09 12y agoyeah iamnop crashes my firefox
- cookiecaper 12y agoRuns at near-60 FPS in Firefox for me. Using Linux and Firefox 37.
- msl09 12y agoFirefox 31 from the debian wheezy package
- ChristianGeek 12y ago
- adam12 12y agoThe developer could improve this page by adding a demo mode that shows the particles moving randomly around the screen. The demo mode could be shown after a couple seconds of user inactivity.
- niche 12y agowould be cool if you could somehow output this to audio
- grimmdude 12y agoI find playing with this very relaxing. +1!
- merpnderp 12y agoI've looked over the code and I can't figure out what makes the particles brighter. Some of it is when the particles overlap, they appear brighter, but if you don't touch the screen, all the particles fade out to black. Anyone know how that is done?
- teraflop 12y agoThe particles are drawn as line segments, with lengths proportional to their velocity. As the velocity approaches zero, each line segment covers a smaller and smaller fraction of a pixel. Because the lines are drawn with antialiasing (at least in Chrome) this causes them to fade into transparency as the pixel coverage approaches zero.
- deleted 12y ago[deleted]
- flohofwoe 12y agoThe particles are rendered with additive blending: gl.enable(gl.BLEND); ... gl.blendFunc(gl.SRC_ALPHA, gl.ONE); It basically means that the particle color is added on top of the already rendered particles (with the alpha value used to modulate the particle color, which is a bit strange, it would be more usual to use gl.ONE for both parameters). The more particles overlap, the brighter that pixels becomes. Details are explained here: https://www.opengl.org/wiki/Blending#Blend_Equations https://www.opengl.org/wiki/Blending#Blend_Equations
- flohofwoe 12y agoPlus what teraflop writes about particle velocity being proportional to their line length. The 'overbrightening effect' should be caused by the blending however.
- tripzilch 12y agoLoving the fact that this runs so smoothly on my old netbook.
- ManyParticles 12y agoIve made something similar to this a while ago. https://www.chromeexperiments.com/experiment/one-million-particles https://www.chromeexperiments.com/experiment/one-million-par... It does its calculations on the GPU so it can handle a million particles easily. You can also pause it to explore it in 3D.