Problem with Terrain collisions (was googlecode Issue 772)

[erwincoumans]

What steps will reproduce the problem?

1. Run the TerrainDemo and throw some boxes around

What is the expected output? What do you see instead? Boxes go through the terrain

What version of the product are you using? On what operating system? using the latest (r2716) on Windows 8.1

Please provide any additional information below. Ok, After spending hours trying to figure out why the terrain doesn't work in my engine i decided to try and reproduce it in the TerrainDemo. It turns out all i had to do was run the Terrain Demo and throw some boxes around and i got the exact same behavior.

Not only the boxes are unstable (and jump around on the terrain until the go to sleep) the BIG problem is that at some part of the terrain they just go right through it.

https://code.google.com/p/bullet/issues/detail?id=772&colspec=Modified%20ID%20Type%20Stars%20Status%20Owner%20Summary See discussion there too.

After further investigation i found out that the problem happens on some triangles in the terrain and from the debug draw i could see that as the box was hitting the triangle the contact point where generated , but instead of pointing away from the terrain they pointed inside the terrain and just pushed the box through it.

IMPORTANT : I also found out that SPHERES do not have the same problem. Sphere behave beautifully and they are much much more stable than the boxes, which means the problem is probably in the box-concave collision algorithm.

here is a little video i took of the Terrain Demo to show all this : http://youtu.be/zCJwxk089iM

Thanks :)

[ghost]

Hi!, i am having same problems with the btheightfieldterrainshape. i notice that when i am using: nmf.m_flags = btTriangleRaycastCallback::kF_FilterBackfaces;
if (test.collides(rayFromWorld, rayToWorld, nmf))

the collision on the triangles are sometimes on the front and sometimes on the backside. I am using setUseDiamondSubdivision(true); if that means what. Hope its only a little problem.

[ghost]

ok it seems that

• if i dont use DiamondSubdivision all Triangle faces are in front direction
• if i use DiamondSubdivision the Triangle frontfaces and backfaces are mixed like a chess
• if i use ZigzagSubdivision the Triangle are alternately 1 line frontfaced and 1 line backfaced

but i need DiamondSubdivision where all triangle faces are in front direction. Is this a bug or intended?

[erwincoumans]

It is likely a bug. Right now I don't have time to look into this. Do you have time to work on a suggested patch?

[ghost]

i could try . whats the suggestion? :)

[ghost]

ok just spent a bit time testing and seems, if i switch vertices[1] and vertices[2] all faces are in front:

if (m_flipQuadEdges || (m_useDiamondSubdivision && !((j + x) & 1)) || (m_useZigzagSubdivision && !(j & 1))) { //first triangle getVertex(x, j, vertices[0]); getVertex(x, j + 1, vertices[1]); getVertex(x + 1, j + 1, vertices[2]); callback->processTriangle(vertices, x, j); //second triangle // getVertex(x,j,vertices[0]);//already got this vertex before, thanks to Danny Chapman getVertex(x + 1, j + 1, vertices[1]); getVertex(x + 1, j, vertices[2]); callback->processTriangle(vertices, x, j);

[erwincoumans]

Does that solve the problem for you? If so, could you provide a patch or generate a pull request in git? If you don't know how to create those, I'll have a look at applying it manually later. Thanks for looking into this!

[ghost]

my problem is actualy solved with that. but i am not sure if its the same problem as in the issue description. i've checked my terrain for collision holes but didn't find one, "till" now. pull request is on the way.

[ghost]

the original issue isn't solved with the face correction. found "one" triangle in the terrain that doesnt collide ... :(

[erwincoumans]

It would be good to have a reproduction case of a failing collision, that doesn't need user input (mouse/keyboard etc). If you still have time, perhaps you can modify the ObsoleteDemos\TerrainDemo? Thanks!

[ghost]

that could take a while (i am just trying it in my free time). but if i want to use the bullet heightfield, i have no other choice. in current state its unusable. but its strange, that no one else spent time on it. O.o a suggestion in the forum was, to add a new feature for setting heightfield thickness.

more feedback with other user experiences could be helpfull :)

[ghost]

closed the pull request: https://github.com/bulletphysics/bullet3/pull/162 actually it works for me. maybe u find some time to make a comment here. :) actually the problem with static terrain is solved for me. Hope it doesnt have any bad influence on other things...

[erwincoumans]

Yes, the workaround in the GJK implementation to deal with degenerate cases using small/zero collision margin was causing the issues. Thanks for tracking it down. Commit here: https://github.com/bulletphysics/bullet3/commit/7f3cbc066ff8e72c48e8b292b0b0d6fc415d401c