"Dynamic Compound Convex" Questions
Posted: Thu Oct 11, 2007 2:09 am
I am working on implementing a volumetric approach to the height-field collision shape so that fast moving objects are detected as colliding with the terrain even if they pass through thin shell of triangles making up it's surface.
I am making a new shape class for this as the existing height-field will work just fine when using continuous collision detection algorithms. This is a problem primarily with the Discrete Collision Detection code path.
Anyhow, the idea is relatively simple (and will hopefully tie easily into a "water/bouyancy" class later). Instead of generating just the surface triangles, I take the points for the triangle and a copy of these points translated "down" by a configurable margin and make a btConvexHullShape for the results. So in effect there would be a triangular "column" in the new height-field object per surface triangle in the current height-field object.
The problem is that this is not easy to "hack" into the current Bullet architecture. There are really only two ways of handling multiple "collision shapes" at runtime based on the bounds of the colliding object. There is the current method used by the height-field (i.e. generates the triangles for collision based on the bounds, callback derived from btConcaveShape) or the btCompoundShape which requires that all shapes be added to it before processing the collision.
Hence a naïve method would be to simply create a btConvexHullShape at the start (making the terrain non-modifiable and negating the primary benefit of it being stored as a 2D height-field in the first place) or to create a new "compound shape" that enables the creation of child shapes on the fly as required.
The question coming from all this is to ask people more knowledgable than me as to whether this should be done by creating a new compund shape or by altering the existing one to allow dynamic creation/return of convex shapes as required by bounding box?
--EK
I am making a new shape class for this as the existing height-field will work just fine when using continuous collision detection algorithms. This is a problem primarily with the Discrete Collision Detection code path.
Anyhow, the idea is relatively simple (and will hopefully tie easily into a "water/bouyancy" class later). Instead of generating just the surface triangles, I take the points for the triangle and a copy of these points translated "down" by a configurable margin and make a btConvexHullShape for the results. So in effect there would be a triangular "column" in the new height-field object per surface triangle in the current height-field object.
The problem is that this is not easy to "hack" into the current Bullet architecture. There are really only two ways of handling multiple "collision shapes" at runtime based on the bounds of the colliding object. There is the current method used by the height-field (i.e. generates the triangles for collision based on the bounds, callback derived from btConcaveShape) or the btCompoundShape which requires that all shapes be added to it before processing the collision.
Hence a naïve method would be to simply create a btConvexHullShape at the start (making the terrain non-modifiable and negating the primary benefit of it being stored as a 2D height-field in the first place) or to create a new "compound shape" that enables the creation of child shapes on the fly as required.
The question coming from all this is to ask people more knowledgable than me as to whether this should be done by creating a new compund shape or by altering the existing one to allow dynamic creation/return of convex shapes as required by bounding box?
--EK