[ODE] bad normals in capsule->box collision ?
Remi Ricard
remi.ricard at simlog.com
Wed Aug 22 07:38:34 MST 2007
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
More information about the ODE
mailing list