[ODE] bad normals in capsule->box collision ?

[Remi Ricard]

Hi Russell,

 >      I've come across a rare case, where I believe the 
dCollideCapsuleBox() function returns a bad normal in the contact structure.
 >
 >      Stop me if it has already been flagged, or I'm barking up the 
wrong tree.
 >
 >      Inside this function it works out where on the box a collision 
occurs, and where along the capsules axis a collision would occur.
 >          It then calls dCollideSpheres() passing in the location on 
the capsule axis and the capsule radius as the first sphere, and the 
location on the box as 1 sphere with a zero radius as the second sphere.
 >
 >       Inside of dCollideSpheres(), if the 2 centres of the spheres 
are identical, it cant work out a normal (rightly so), and invents a 
normal along the x axis. This is a fact of life in a sphere->sphere 
collision, but in the context of a capsule->Box collisionis not the answer.
 >
 >     I have a solution inside of dCollideCapsuleBox() that detects 
this problem before entering the dCollideSPheres function, and 
calculates the correct normal, but it is a little ugly.
 >
 >     Is my logic sound, and if so, has anyone come across this problem 
before? If so is there aa standard solution out there?
 >
 >     Also if this is true, I suspect dCollideCapsuleCapsule, and maybe 
even dCollideCapsuleSphere could suffer from the same problem?

I found a similar problem with the normal inverted and submitted a bug 
on the ODE SourceForge site (Bug #1757060).


The problem was created when the capsule and the box were barely 
touching each other by the sphere part. The "penetration" distance was 0 
and the vector from point on shell of the sphere to the point on the box 
was almost zero (1e-16 in the wrong direction) then this created a 
normal vector in the wrong direction.

I also created a small test program that show the problem but I did not 
know how to solve it.

Can I see our ugly code ? ;-)

Remi