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
"Dynamic Compound Convex" Questions
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: "Dynamic Compound Convex" Questions
For now, you could hack it in the btConvexConcaveCollisionAlgorithm. There is a place, where a temporary btTriangleShape is constructed.Eternl Knight wrote: 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.
Code: Select all
void btConvexTriangleCallback::processTriangle(btVector3* triangle,int partId, int triangleIndex)
I will make modifications in the future that makes this easier.
Hope this helps,
Erwin
-
- Posts: 316
- Joined: Fri Jul 01, 2005 5:29 am
- Location: Irvine
Re: "Dynamic Compound Convex" Questions
If you make those columns tall, you might get objects wedged between them with only horizontal contact normals. The object will then ping-pong back-and-forth falling into the abyss.
Perhaps if you detect deep penetration, you could just generate sloppy contact points to push the object up and out.
Perhaps if you detect deep penetration, you could just generate sloppy contact points to push the object up and out.
-
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
Re: "Dynamic Compound Convex" Questions
Well, you could use overlapping truncated pyramids instead of colums, by enlarging the bottom. Then the resulting normal would always point upwards (as long as you make the pyramid large enough.Erin Catto wrote:If you make those columns tall, you might get objects wedged between them with only horizontal contact normals. The object will then ping-pong back-and-forth falling into the abyss.
Yes, some heuristic would be doable. It would be good to get Eternl Knight up and running.Perhaps if you detect deep penetration, you could just generate sloppy contact points to push the object up and out.
Thanks,
Erwin
-
- Posts: 44
- Joined: Sun Jan 22, 2006 4:31 am
Re: "Dynamic Compound Convex" Questions
I have thought of this and is something I have discussed with Erwin (briefly) in the beginning. For any face but the top triangle you need a specialized contact normal pointing in the direction of the height-field's "up" direction. How to do this is something I am not sure of.Erin Catto wrote:If you make those columns tall, you might get objects wedged between them with only horizontal contact normals. The object will then ping-pong back-and-forth falling into the abyss.
The problem with this solution is that in areas of steep changes in height, the truncated pyramids may have faces "above" the actual terrain - causing spurious contacts where there should be none. Hence the single column design. I have a feeling that changing the direction of the contact normal is easier than creating/checking the pyramids for intersection with the terrain surface.Erwin Coumans wrote:Well, you could use overlapping truncated pyramids instead of colums, by enlarging the bottom. Then the resulting normal would always point upwards (as long as you make the pyramid large enough.
--EK