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

[Russell Bartley]

The code changes I made are for a swept sphere. Where I use an ODE capsule 
geom with an extra flag bit set to indicate it is representing a swept 
sphere.

But it doesnt call dCollideSpheres() at all.

It calculates the collision point on the leading edge of the sweep inside of 
dCollideCapsuleBox() after the call to dClosestLineBoxPoints().

I haven't clarified if I can put the code up from my employers yet, but will 
check with them if anyone is interested?



----- Original Message ----- 
From: "Remi" <papaDoc at videotron.ca>
To: "Russell Bartley" <russellbartley at kromestudios.com>; "ODE Mailing List 
(E-mail)" <ode at ode.org>
Sent: Wednesday, August 22, 2007 10:13 PM
Subject: Re: [ODE] bad normals in capsule->box collision ?


> 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 




This message and its attachments may contain legally privileged or confidential information. This message is intended for the use of the individual or entity to which it is addressed. If you are not the addressee indicated in this message, or the employee or agent responsible for delivering the message to the intended recipient, you may not copy or deliver this message or its attachments to anyone. Rather, you should permanently delete this message and its attachments and kindly notify the sender by reply e-mail. Any content of this message and its attachments, which does not relate to the official business of the sending company must be taken not to have been sent or endorsed by the sending company or any of its related entities. No warranty is made that the e-mail or attachment(s) are free from computer virus or other defect.