Explosions, implosions and attractors

sparkprime
Posts: 508
Joined: Fri May 30, 2008 2:51 am
Location: Ossining, New York
Contact:

Re: Explosions, implosions and attractors

Post by sparkprime »

It might be an interesting research project to model an explosion over several physics frames with a soft body that expands as the explosion progresses but also deforms as it hits things, much like a blastwave would. This could create some nice effects like explosions down corridors and such.

It may also be extremely cpu intensive, though.
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Explosions, implosions and attractors

Post by Erwin Coumans »

sparkprime wrote: testing whether a wall gets in the way of the explosion,
The general case is a hard problem, and small objects usually don't block the explosion. One option would be to mark large static geometry as occlusion objects and only testing those for occlusion, using ray casts. The expanding soft body approach sounds like an interesting idea, but how would you implement this efficiently enough for real-time?
mreuvers wrote: Yep, I used the generated contacts. So in effect I'm a 'frame behind', but for our tests that isn't that much of a problem.
The latest Bullet trunk contains a btGhostShape that should help volume triggers and explosions. The btGhostShape incrementally keeps track of its overlapping AABB's. Could you try to use those btGhostObject and perform the explosion directly using the center of mass, without contact points?

Thanks,
Erwin
sparkprime
Posts: 508
Joined: Fri May 30, 2008 2:51 am
Location: Ossining, New York
Contact:

Re: Explosions, implosions and attractors

Post by sparkprime »

Erwin Coumans wrote:The general case is a hard problem, and small objects usually don't block the explosion. One option would be to mark large static geometry as occlusion objects and only testing those for occlusion, using ray casts.
So, test each contact point (or object centre) and ignore ray results from objects not considered to protect from an explosion?
The expanding soft body approach sounds like an interesting idea, but how would you implement this efficiently enough for real-time?
To be honest it's probably not a good idea. To be realistic i think it would have to be a very dense blob of vertexes, in which case you're doing a lot of FP processing. In order to create a realistic explosion you'd need to run a *lot* of simulation steps during the initial microseconds of the explosion, in order for the soft body to expand nicely. Even if sufficient processing power was available, it would be probably better used for other things e.g. doing a more special-purpose simulation of explosions using lots of rays or something.

Maybe a more appropriate use for soft bodies would be simulating the slow-moving smoke that follows the explosion :)

It'd be nice to have a puff of volumetrically rendered smoke mushroom out when it hits the ceiling of the room, then slowly spread around before fading.

The latest Bullet trunk contains a btGhostShape that should help volume triggers and explosions. The btGhostShape incrementally keeps track of its overlapping AABB's. Could you try to use those btGhostObject and perform the explosion directly using the center of mass, without contact points?
That sounds useful. It seems that it would allow to process intersections and add impulses before the rest of the simulation and thus not be a frame behind? Does that mean it will only give AABB intersections, thus returning more collisions than really occur?

There is a real advantage with using contact points for an explosion though. Ignoring the "height" dimension for a moment, imagine the case of a 10m beam lying on the floor from (1,-1) to (1,9) and then an explosion occuring at (0,0). You really want the beam to swing around as the explosion affects only one end of it. I imagine if you just test for intersections and apply impulses to the center of mass, it would react quite unrealistically in this situation.

It should be faster without contact points though, right? So when the explosion is bigger than the victims, contact points are probably overkill.


An entirely different approach:

Regular explosions like a grenade or whatever usually have two effects - the expanding shock wave, and the shrapnel. Really, what we've discussed so far is just the expanding shock wave - modelled with a sphere. However, shrapnel should be fairly easy, just do a load of ray casts and apply impulses to whatever they hit, reducing these impulses with distance.

I wonder if it would be sufficient to just handle shrapnel with no consideration for the shock wave? This would work well for my beam example, assuming the beam was actually hit by several pieces of shrapnel. Judging by the raytracing demo, raycasts are fairly cheap and they could be staggered over a few internal steps to make them even cheaper.

However, rays are infinitely thin so the larger the explosion compared to the victims, the more rays we'd need, to guarantee enough hits. In fact, the inverse square law says that a linear increase in explosion radius would need a squared increase in the number of rays. Let's do some maths:

Area of a sphere is 4*pi*r^2, so the area of a 10m sphere is 1256m^2. Assuming rays are spaced well-enough to cover this area with optimum efficiency, we would need 1256 rays to reliably hit objects that have 1m cross sectional area and are 10m from the source of the explosion. Is this too many rays? If we run Bullet at 60hz, I think we could spread this out over at least 3 internal simulation steps, possibly as many as 10, without affecting realism too much.


Of course it would be possible to combine a shockwave simulated with a single sphere intersection test (or a btGhostShape) with a more localised shrapnel simulation implement with rays. That way, objects near to the explosion would get knocked about by the shrapnel and everything that was missed by shrapnel would still be affected by the shockwave. The shockwave wouldn't need to generate contact points, it could just apply impulses to the centre-of-mass of any affected bodies, and thus wouldn't need to be delayed by a frame. Any large objects near to the explosion, like the beam in my example, would be hit by shrapnel and would thus behave realistically. Objects further away would not be hit by shrapnel, but the effects of the explosion at this range should be small enough for the centre-of-mass approximation to be a reasonable one.
chunky
Posts: 145
Joined: Tue Oct 30, 2007 9:23 pm

Re: Explosions, implosions and attractors

Post by chunky »

This Ghost object is very interesting to me, we plan on having "zones" in our game where, for example, it would be impossible to fire a weapon, or where your weapons would be recharged while you're sitting within it.

I'm envisaging an implementation where the first time that a spaceship enters one of these zones [which would presumably be a ghost object, with no collision response], I would call spaceship::disableWeapons() or similar, and then call spaceship::enableWeapons(). Bullet's ghosts seem like a direct equivalent of Havok's phantoms, where you'd use phantomEnterEvent and phantomLeaveEvent. Do Bullet ghosts have an equivalent to these two methods?

Gary (-;
Post Reply