Hacker News Reader

Comment by maccard | Hacker News Reader

80k 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 has 500k.

View on HN

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

But the original post isn't interacting either, it's just an integration with gravity, that happens to be rendered by WebGL.

Yeah that's what I'm saying, if this demo has been 80,000 interacting particles it would be extremely impressive.

Not 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/

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?)

Just 2 days ago I ran across my all my written notes from GDC 2002 (the only GDC I've gone to; I went by myself for fun) with that specific session, and I had your name written down. (I just thought that was a funny coincidence.) It was very memorable, especially the one with the Doom guy doing the Robotron thing with the camera zooming out. Late last year, Casey Muratori also mentioned it on his handmade hero webcast.

In particle simulations interactions can happen at a distance, so at every time step all particles need to be checked with all other nearby particles to get their distances and compute the force of their interaction. It looks like your simulation is a hard-sphere type interaction where you're only checking to see if two particles bump into each other and is considerably faster to compute.

No, it's not really different from a hard-sphere type interaction. It's the same thing. But that doesn't matter in this context, because in the system we built, our problem was harder/more-general because we were simulating 'guys', meaning you can program an arbitrary interaction into your guys (is guy type X near guy type Y, if so what happens?), and those 'guys' also interacted with a 2D height field terrain.

Keep in mind this was all on computers from the year 2002, which were pretty damn slow compared to computers today. Today you could do a lot of guys.

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

I'm assuming they all still moved, and the checking was just for change-of-independent-behaviour-pattern?

Yes, everyone moved every frame. If I remember correctly, they would get linearly extrapolated until next time the update for that guy ran. I think there was also an option to do the terrain interaction every frame, to avoid any perception of guys sinking into the terrain slightly.

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

I think this is a few years old. I remember seeing it before.

Reply on news.ycombinator.com