Height-Field Bug/Feature

Post Reply
Eternl Knight
Posts: 44
Joined: Sun Jan 22, 2006 4:31 am

Height-Field Bug/Feature

Post by Eternl Knight »

I noticed a "bug" in the height-field collision shape mentioned by someone else in the forums and have been able to reproduce this myself.

The problem is (as expected) that the height-field collision shape only checks for collision against the "surface triangles", yet it is actually meant to be a "convex shape" (i.e. it is not meant to be paper thin). That is, if something is completely on the "bottom side" of the triangle it is actually penetrating the height-field and should be flagged as such.

I looked at how the height-field is currently implemented and cannot see how this penetration behavior could be implemented. The way I would envision it working would be that the collision detection not only look at whether there is a collision with the generated triangles but at also whether the shape is "under" the triangles in question. I'm not sure how to do this with Bullet (or even if this is possible given the current Bullet API).

--EK
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Height-Field Bug/Feature

Post by Erwin Coumans »

The heightfield is infinitely thin indeed. We can give it some thickness, and collide with prismas instead of triangles, that should be no problem to implement. Future CCD would aleviate problems too.

Hope this helps,
Erwin
Eternl Knight
Posts: 44
Joined: Sun Jan 22, 2006 4:31 am

Re: Height-Field Bug/Feature

Post by Eternl Knight »

The solution I was thinking of (which you mentioned) was to collide with triangular prisms rather than just the surface triangles.

The issue I am trying to resolve with this is that the contact normal for all faces (except the surface triangle) would need to be "up" in order to push penetration back out of the terrain. And it is likely that the bounding box would need to take into account the prism "depth" as well.

Looking at the Bullet 2.62 implementation - there is no way this can be done with the current structure. What would be needed is something similar to the btConcaveShape class (which uses a btTriangleCallback), but instead of returning/processing triangles it returns/processes general collision shapes (in our case convex prisms). Somewhat like a dynamic btCompoundShape

--EK
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Height-Field Bug/Feature

Post by Erwin Coumans »

Exactly. We just have to modify the interface to allow a 'shapeCallback', instead of a 'triangleCallback'.

I'll put it on the todo list.
Thanks
Erwin
Eternl Knight
Posts: 44
Joined: Sun Jan 22, 2006 4:31 am

Re: Height-Field Bug/Feature

Post by Eternl Knight »

There is still some "special case" stuff that would only apply to height-field processing (namely the collision normal needing to point UP for all contacts but those on the single surface triangle). As long as the callback allows for sucvh an override - I think this will be a nice clean solution to the problem.

Thanks for adding it to the list. Given the (relative) simplicity of the solution, I would do it myself but I have no idea how to override collision normals (I'm willing to actually do the work on this if you can fill me in on this detail).

--EK
User avatar
Erwin Coumans
Site Admin
Posts: 4221
Joined: Sun Jun 26, 2005 6:43 pm
Location: California, USA
Contact:

Re: Height-Field Bug/Feature

Post by Erwin Coumans »

Thanks for adding it to the list. Given the (relative) simplicity of the solution, I would do it myself but I have no idea how to override collision normals (I'm willing to actually do the work on this if you can fill me in on this detail).
--EK
Thanks for offering help. It would be great if you can help, especially because the todo list for Bullet is only growing.

For a start, you could modify the existing btConvexConcaveCollisionAlgorithm.cpp to create a hardcoded prisma/btConvexHullShape, instead of a btTriangleShape in:

Code: Select all

void btConvexTriangleCallback::processTriangle(btVector3* triangle,int partId, int triangleIndex)
If you get this working, or run into issues, please let us know. Once this is working, we can either add a special case in the implementation, or add a btConvexHeightfieldCollisionAlgorithm and register that to the btCollisionDispatcher.
Eternl Knight wrote:There is still some "special case" stuff that would only apply to height-field processing (namely the collision normal needing to point UP for all contacts but those on the single surface triangle). As long as the callback allows for sucvh an override - I think this will be a nice clean solution to the problem.
I don't think we need a lot of work to make sure collision normal point towards the heightfield surface: If the prisma or tetrahedron defined by the triangle and some point(s) below the surface is big enough, the penetration depth normal will automatically point upwards, especially when we enlarge the prismas under the heightfield surface so that they overlap. However, I would suggest first to replace the triangle by a prisma, and see how this works out. I can assist with improvements to the collision normal, if necessary.

Do you think you can try this out?
Erwin
noisy
Posts: 10
Joined: Thu May 24, 2007 7:57 pm

Re: Height-Field Bug/Feature

Post by noisy »

Is there any progress on this?

Thanks,
noisy
Eternl Knight
Posts: 44
Joined: Sun Jan 22, 2006 4:31 am

Re: Height-Field Bug/Feature

Post by Eternl Knight »

Yes, I have implemented the "column-based" approach (where there is a triangular column for every surface triangle). It has a couple of problems which need to be resolved.

Firstly there is still an issue that when an object is completely "submerged" under the terrain, the contact normal should point "upward". Instead it points in the horizontal direction (as I use a convex hull for the column). If the contact normal were to point upward, the constraint would act to "push" the penetrating object back to the terrain surface. I believe a minor "hack" to this would allow for bouyancy (i.e. allow a smaller force to be used for contact correction based on how far under the "terrain" surface the contact happens to be).

Secondly, it would appear that raycasts are not yet working. Given I used the existing vehicle demo to test the changes, this means that the vehicle "chassis" (a btBoxShape) collides against the new terrain, but the wheels (using raycastss) do not. Erwin & I will be looking into this momentarily.

I have attached a zip of the changes to Bullet 2.63 to this message. To get it working, simply copy the extracted files over a clean Bullet 2.63 directory tree.

--EK
Attachments
bullet_diff.zip
(40.26 KiB) Downloaded 396 times
Post Reply