[ODE] 2D Rectangle Geom??

[John DeWeese]

>>How about the ode/contrib/tri-collider? A box with a zeroed dimension
>>sounds pretty sketchy.
> 
> From my experience, the tri-collider isn't as precise as native box-box or
> box-sphere colliders - this can be caused by OPCODE that uses single
> precision; or from the fact that tri-something collision is much more
> complicated than, say, sphere-box collision.

Well, I haven't use the tri-collider/opcode method, but triangle 
collision is not at all more complex than box collision... you test a 
few planes in a boolean fashion. Single precision should be much of a 
problem for calculating positions, though it can be a problem for 
differential systems. Perhaps it has something to do with generating 
good sets of multiple contacts. OK, lack of opcode showing through, I 
step down.

>>>I'm currently using BoxGeoms for roads for my vehicles.  I'm wondering
>>>if there is a more performant solution.
>>>All I really need is a 2D rectangle to collided against, or put another
>>>way, a bounded plane!
> 
> You can have several problems with boxes: first, when you have several
> adjacent boxes, you obtain several contacts when the wheel hits the
> boundary - you'll have to implement merging of these contacts yourself (or
> the car will jump slightly on the boundaries).

With a triangle mesh, you have convenient access to exact edges that 
share vertices, which you can use as part of the collision detection 
process. This aids in finding exact solutions for valleys and ridges 
without the need for a separate pass, as in the case of using separate 
geometries.

> Second - you usually need to collide with only the "top" face of the box
> (that is, a bounded plane). If you use plain box and the wheel approaches
> the edge of the box, the contact normal may go not in the "up" direction,
> but in the "side" direction (when there's smaller distance to the box side
> than to the up face").
 >
> For my car simulation I was considering adding additional code to the ODE's
> native box geometry: eg. a flag "collide with upper face only", and modify
> box-sphere collider (and possibly the others as well, but they don't matter
> much for a car sim). That's pretty easy to do, as it just projects the
> sphere onto the box axes and chooses minimal depth (well, I thing there's a
> bug - in some cases it chooses the maximal depth). You just have to modify
> it so it always projects onto the top face.

So basically, you are reducing the box collider to a rectangle collider, 
which is a plane test clipped along 4 axis-aligned planes. How would you 
define a curved track in your sim? I imagine that you would need to make 
two boxes sorta rotated and offset from each other that intersect and 
produce a nice diagonal line. If this is the case, I think it would be 
pretty difficult to build a racetrack when worrying about exact 
placement of boxes. This is another area where a tri mesh has an 
advantage, since you can edit your tracks with some 3D editor and write 
do export/import without relatively little pain.

That reminds me... wouldn't it be nice to have constructive solid 
geometry for collision? What? Did I just volunteer for something?

   - John DeWeese