Incorrect normal in collision with static triangle mesh

[hiker]

The details are in the forum:
http://www.bulletphysics.org/Bullet/phpBB3/viewtopic.php?f=9&t=11208

The effect can be seen in this movie:
https://www.youtube.com/watch?v=e2SkBWHZXJQ&feature=youtu.be&t=40

At around 45 seconds the 'puck' (cylinder) will suddenly jump up significantly.

Basically the collision between a cylinder (or ball, same issue) and a static mesh uses an incorrect normal - the connection between the hit points on both shapes. In the case above the plane is flat with a normal of (0,1,0) (Y up), but the connection between the hit points can give e.g. (0.2, 0.98, 0). If the object should have a high velocity in the 'incorrect component' (in this case simply X), then the dot product computed in btSequentialImpulseConstraintSolver::setupContactConstraint:

         btVector3 vel1 = rb0 ? rb0->getVelocityInLocalPoint(rel_pos1) : btVector3(0,0,0);
         btVector3 vel2 = rb1 ? rb1->getVelocityInLocalPoint(rel_pos2) : btVector3(0,0,0);
         vel  = vel1 - vel2;
         rel_vel = cp.m_normalWorldOnB.dot(vel);

results in a too high velocity. This rel_vel value is used later to compute the strength of the impulse to resolve the collision. So when this is multiplied with the normal ( (0.2, 0.98, 0) in the example above), it results in a very high impulse up.

My patch was to use the normal from the triangle only, not the connection between the contact points, see:
supertuxkart/stk-code@0a883f3...431ed63

Though that is for bullet 2.79. I did not try a later release, but from what I have seen in the code while some refactoring has taken place, the maths done appears identical, so it should have the same issue. Note that our patch only fixes collisions between sphere/cylinder and triangle mesh (some other shapes might use the same collision function as cylinder).

[hiker]

Oops - slightly wrong link for my patch, better look at:
supertuxkart/stk-code@14a6f20...431ed63

[erwincoumans]

Thanks for the report! By the way, your game is looking great! It would be fun to play this in VR on the Oculus Rift/HTC Vive. Have you checked out the OpenVR SDK from Valve? I started playing with this in Bullet recently.

The InternalEdgeUtility was created to help fixing this, have you tried it? I noticed the old Demo to use it is not converted to the new Bullet Example Browser yet, here it is:
https://github.com/bulletphysics/bullet3/tree/old_demos/Demos/InternalEdgeDemo

This behavior may not always be what the user wants, to it would be good to have some option/flag to enable/disable it.

[benelot]

Erwin, can you send me the spreadsheet you told me about where you keep
notes on the porting of the old demos? I am happy to port them during some
time of boredom. And I am confused which are the ones that still need
porting, I think the names are not the same anymore.

On Sat, Jul 2, 2016, 19:25 erwincoumans notifications@github.com wrote:

Thanks for the report! By the way, your game is looking great! It would be
fun to play this in VR on the Oculus Rift/HTC Vive. Have you checked out
the OpenVR SDK from Valve? I started playing with this in Bullet recently.

The InternalEdgeUtility was created to help fixing this, have you tried
it? I noticed the old Demo to use it is not converted to the new Bullet
Example Browser yet, here it is:

https://github.com/bulletphysics/bullet3/tree/old_demos/Demos/InternalEdgeDemo

This behavior may not always be what the user wants, to it would be good
to have some option/flag to enable/disable it.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#676 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AC97qyVSxj9Rx71mMXxAjaP6iMNA3E2Uks5qRp8AgaJpZM4JAvHo
.