[ODE] box tri tests

[Mike Armstrong]

In rewriting our box/tri collision test for use within our physics engine
I have made some observations that I hope will be of use to the ODE 
community. I have to add this is certainly not ground breaking but here 
goes:

So far ODE has had two methods of computing the collision contacts:

1) clip the tri to the box, resultant clipped points are the contacts, 
    with the contact normal being that of the tri normal.
2) clip the box edges by the plane of the tri and the planes created 
    via the tris edges.  The contacts are the clipped box edges with 
    normal of tri.

Now if 1) was to use an appropriate box face normal instead of the tri 
normal these two tests would be complimentary and solve two parts of the 
same problem.
1) where the tri sharply intersects into the box and 2) where the box 
sharply intersects into the tri i.e.

sorry for the bad ascii art.

1)

     @ |-----|
      @|     |
       @     |
       |@    |
       |-----|

2)


     @ |-----|
      @|     |
       @     |
       |@    |
       |- at ---|
          @
           @

where the tri is @ and box - and |


The only problem remains is how to choose the appropriate test and also 
how to choose the appropriate normal.
This is already done in the box/box test.  Here the separating axis are 
checked and the appropriate test chosen on the basis of the minimum amount 
of overlap.

for box tri tests required are:

    [1] tri normal
    [2] box normal 0
    [3] box normal 1
    [4] box normal 2

and ideally ( although my test is working reliably with out at present )

    [5] tri edge 0 X box normal 0
    [6] tri edge 0 X box normal 1
    [7] tri edge 0 X box normal 2
    
    [8] tri edge 1 X box normal 0
    [9] tri edge 1 X box normal 1
    [10] tri edge 1 X box normal 2
    
    [11] tri edge 2 X box normal 0
    [12] tri edge 2 X box normal 1
    [13] tri edge 2 X box normal 2
    

now the appropriate algorithm for generating the contacts is:

[1]      -> 1)
[2]-[4]  -> 2) with the normal dictated by the box normal used to generate 
               the result
[5]-[13] -> 3) please see the box/box edge edge test, 
	       although unimplemented in my routine it would be similar to 
               that case.

By combining the two tests boxes now roll off edges and corners giving a 
far more stable test.

Much as I would like to implement this test within ODE time constraints 
prevent me from doing so,  I hope this algorithm helps.  Feedback would be much 
appreciated.

mike