Box2D Forums

Just another feature request. Feel free to disregard if you think it's unnecessary/too time consuming/too disruptive to the engine.

I would find it pretty useful to have a lightweight point particle object that was a little faster to simulate than a full fledged rigid body - I tend to use things like this for effects, and while it's easy enough to just run a separate particle engine alongside the physics engine, it's nice to have collisions working, but using small rigid bodies can be a bit much for this, esp. if you want hundreds of them flying around at once. I'm also considering trying to get SPH working alongside Box2D, and it would be nice to have particles built in to the engine for this.

I don't know, is this something other people would find useful, or is it just me?

I would also find this useful! But the particles should be as fast as possible even if it means other bodies don't react to them, etc.

I'm planning to add particles with two-way interaction (rope).

Do you want the particles to support constraints? Do you want two-way interaction?

It would be nice if it was customizeable, but in the least, there should be one type of particle that is absolutely optimized (for smoke effects, etc.) and one type that is just one step down from a body (for ropes, etc.). Because unless your making a steam turbine, you don't need smoke to affect other objects

Hmm, that's a good question. For my purposes, I like to have lots and lots of free particles moving around undergoing collisions with objects. For something like SPH, I would probably add forces in a separate step, which should be good enough if the integration method is right (symplectic Euler, leapfrog, or Verlet would all work fine). I would need them to interact with other bodies on collision, even if only under an extreme mass ratio approximation (i.e. just reflect the particle's relative velocity and apply that derived impulse to the larger body) if that makes things easier.

As far as smoke effects, and non-interacting stuff like that, my feeling is that if you don't need the particles to interact or collide, you could just as easily run a trimmed down particle engine alongside Box2D, anyhow, built in just a couple dozen lines of code - I'm not sure that it needs to be an actual part of the engine if there's no connection to the rest of it, though I'm sure people would definitely find it useful, so maybe it's worthwhile. My main need for particles is that I'd like them to be integrated correctly into the broadphase.

Re: constraints, I guess the real question is whether having the ability to use constraints would seriously impact the speed of simulation if no constraints are active. I wouldn't think it would be such a big deal, but I guess it all depends how it's implemented. If it doesn't make much of a difference, then I would vote to include the possibility, or at least the future possibility (given that it might be a bit of work to write special case constraint code if this is necessary). If it does cause a speed hit, say a 2:1 impact on performance, I'd leave it out for now.

But if the particles are seperate, it means redefining all the colliion areas specifically for them, because smoke still should react to other bodies (it shouldn't go through walls). Maybe we could have a particle class which has flags, so when all the flags are set, it is almost like a body, but with none set it would be just a mass-less dot that can't rotate, and can't go through stuff.

Sorry to resurrect this thread, it doesn't look like there was any conclusions...

I think a particle class in Box2d would be extremely slick. Even if they only generated a one-way collision response (they collide with rigid bodies, but don't apply a collision response to the rigid body).

A method of applying forces to the particles and a fast neighboring particles query (using Box2d collision data structures) would be really nice for doing SPH.

Any chance this could be done? I'd take a stab at it myself but would probably take me 10x as long to figure everything out.

Erin Catto: Can I bribe you with beer? Money? ;D

Much of this is possible with the ray-cast and AABB query functions. I'm not sure if that will be fast enough.

Are you suggesting using the ray-casting function to do the collision detection for the particles? If so, could you provide a few hints how exactly that might be done?

My idea for particle collision detection: Use the AABB query to find neighboring rigidbodies for each particle. Then shoot a ray from each particle towards center of mass of each neighbor. If it doesn't collide, the particle is inside the body, so shoot second ray from particle in direction of negative velocity vector. Find point of intersection, move particle to that position and reflect the velocity vector about the surface normal.

Is that generally how this is done?

oh hai.
http://mmankt.newgrounds.com/news/post/573035 Collisions still need some more work but for now the performance is great(1000 colliding particles in flash with 30 fps) and for my usage it's good enough.

Anyways it's really easy. Write a particle system. Once you get prev_xy and xy, raycast between those two points if raycast output.fracture < 1 you got a collision, correct xy, get the fixture, get the normal from raycast (output.normal.x,output.normal.y), get fall angle and , calculate new speed from: bounce_off_angle = 2*surface_angle - fall_angle - 180, speed vector length*bounce and tadada!