Subtractive CompoundShapes

User avatar
JohnHardy
Posts: 18
Joined: Mon Mar 05, 2012 11:39 pm
Location: Lancaster, UK

Subtractive CompoundShapes

Post by JohnHardy »

Hello all,

I'm looking for a better way of applying physics "damage" to space ship meshes (i.e. chop out convex shapes). However, doing this requires:
  1. Compute the HACD of the ship mesh + create compound shape.
  2. Subtract the boolean "damage" mesh from all the shapes in the ship mesh.
  3. Recompute the HACD of all the damaged shapes.
  4. Push back into physics engine and visuals, recreating compound shape with many more shapes.
This is OK, but super slow and sucks when it comes to implementing visual repairs etc. Not to mention screwing up the visual meshes, which really would be better applying damage on a per-pixel basis for rendering needs. The main problem is getting the modified shape into the physics engine for collisions (i.e. boaring holes etc).

I was thinking a better approach might be to use "subtractive" CompoundShape elements as well as the standard "additive" ones. This would mean that if a ray (or whatever) intersects a "subtractive" region, it is not counted as a collision at that point, and the algorithm continues as if one were not detected.

The process is then:
  1. Compute the HACD of the ship mesh + create compound shape.
  2. Add a SubtractiveShape (in the shape of the damage) to the compoundshape.
  3. Enjoy.
I'm happy to take a crack at implementing this, but before I begin I want to make sure that it (a) doesn't already exist, and (b) is not horribly flawed! :wink:

What are your thoughts?
Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: Subtractive CompoundShapes

Post by Basroil »

JohnHardy wrote: The process is then:
  1. Compute the HACD of the ship mesh + create compound shape.
  2. Add a SubtractiveShape (in the shape of the damage) to the compoundshape.
  3. Enjoy.
I'm happy to take a crack at implementing this, but before I begin I want to make sure that it (a) doesn't already exist, and (b) is not horribly flawed! :wink:
So... You are proposing to arbitrarily subtract a shape from a set of convex shapes? Lets assume your HACD of a cylinder provides 8 semicircular convex shapes. Now you subtract a cylinder perpendicular to the surface going through at least one shape but not splitting any shape into two sets. How many of those convex shapes are now concave?

Any reason why you can't just skip the first step (HACD+compound) and just subtract from your original mesh and then decompose?

In fact, any reason why you can't have a destruction hierarchy and build up rather than down?
User avatar
JohnHardy
Posts: 18
Joined: Mon Mar 05, 2012 11:39 pm
Location: Lancaster, UK

Re: Subtractive CompoundShapes

Post by JohnHardy »

So... You are proposing to arbitrarily subtract a shape from a set of convex shapes? Lets assume your HACD of a cylinder provides 8 semicircular convex shapes. Now you subtract a cylinder perpendicular to the surface going through at least one shape but not splitting any shape into two sets. How many of those convex shapes are now concave?
Ah, nice through experiment. I'm proposing to add a "SubtractiveShape" to the CompoundShape. So taking the cylinder example -- I'd have my 8 semi-circles. Then to poke a hole through the center, I would add a 9th cylindrical shape to the CompoundShape. Then when the collision algorithm tested the subshapes, it would disregard any collisions that were detected in the "SubtractiveShape" cylinders and move the collision to the edge of the SubtractiveShape along the original trajectory.
Any reason why you can't just skip the first step (HACD+compound) and just subtract from your original mesh and then decompose?
I expect it would be faster to perform the collision tests on selected convex shapes rather boolean intersections on the whole (~50K+) mesh. The damage shapes are also typically significantly smaller than the ship as a whole.
In fact, any reason why you can't have a destruction hierarchy and build up rather than down?
Technically no, but the damage is not as organic as the type we are going for as it restricts it to pre-set patterns.

Thanks for your reply :)
User avatar
JohnHardy
Posts: 18
Joined: Mon Mar 05, 2012 11:39 pm
Location: Lancaster, UK

Re: Subtractive CompoundShapes

Post by JohnHardy »

I've just been looking through the source -- where is the code which searchers the tree of internal collision shapes and checks them?
Basroil
Posts: 463
Joined: Fri Nov 30, 2012 4:50 am

Re: Subtractive CompoundShapes

Post by Basroil »

JohnHardy wrote:I've just been looking through the source -- where is the code which searchers the tree of internal collision shapes and checks them?
You'll probably have to consider a few places, but you might want to start by looking at http://bulletphysics.org/Bullet/BulletF ... tml#l00296 and http://bulletphysics.org/Bullet/BulletF ... ource.html .

Still seems like you're computing some things too many times, like the first HACD being done at runtime rather than stored as a "precompiled" data chunk. I've personally never seen a game that goes for 100% destruction, usually it's built on a finite limit of elements with some procedural textures to help with realism. If you can make it work, all the more power to you.
User avatar
JohnHardy
Posts: 18
Joined: Mon Mar 05, 2012 11:39 pm
Location: Lancaster, UK

Re: Subtractive CompoundShapes

Post by JohnHardy »

Ah thanks, the btCompoundCollisionAlgorithm is the missing piece. Why is it separate from the btCompoundShape like that? How are the two linked?
Still seems like you're computing some things too many times, like the first HACD being done at runtime rather than stored as a "precompiled" data chunk.
Sorry, I should have been clearer -- Step 1. is done when the ship loads up. It also doesn't need to be HACD -- could be anything as long as its in a compound shape.
I've personally never seen a game that goes for 100% destruction, usually it's built on a finite limit of elements with some procedural textures to help with realism. If you can make it work, all the more power to you.
Yea, they are rare. A few have done it that I'm aware of -- Red Faction's Geomod and Stan Melax' demo game. There is also the DMM / finite element analysis approach (http://www.youtube.com/watch?v=Z734GXypSwk) but that's hella tricky. Bullet's very own Erwin has some posts/slides on it too: http://www.altdevblogaday.com/2011/09/02/destruction/

I'm pretty sure this approach will work for basic "everywhere" damage, but its so simple -- there has to be a catch. I can't see it yet though!
User avatar
JohnHardy
Posts: 18
Joined: Mon Mar 05, 2012 11:39 pm
Location: Lancaster, UK

Re: Subtractive CompoundShapes

Post by JohnHardy »

p.s. would it be possible for a mod to move this to the R&D forum? It would probably be more appropriate there. :)
User avatar
JohnHardy
Posts: 18
Joined: Mon Mar 05, 2012 11:39 pm
Location: Lancaster, UK

Re: Subtractive CompoundShapes

Post by JohnHardy »

I've made a start, but could use some pointers.

1. What's the difference between: btCompoundCollisionAlgorithm.cpp and btCompoundCompoundCollisionAlgorithm.cpp
2. Which method iterates through the compound shapes (using the tree) and generates the colliding pair.
User avatar
JohnHardy
Posts: 18
Joined: Mon Mar 05, 2012 11:39 pm
Location: Lancaster, UK

Re: Subtractive CompoundShapes

Post by JohnHardy »

Bump?