[ODE] More news on the crash problem

[Flavien Brebion]

> This looks interesting. If i see it correctly there is absolutely no
> geometry near the generated contacts, right?

As i said, there is the road and the ground, but since the polys
are pretty big, you don't see them well in the screenshot. But
yeah, there is an actual contact, and its position is correct.
The normal is not.

> I'm not sure what the problem might be. If you're able to replicate it
> instantly it should be quite easy to find out what line in the collision
> function causes the wrong contacts.

Ok, i decided to dig up into the code and find why it generates an
invalid normal.

The reason is actually simple, but i'm a bit surprized this "exception"
case is not handled in the tri-mesh code.

It's caused by a degenerated triangle.

The polygons i give to ODE/Opcode are directly coming from a 3DS Max
mesh, and when exporting it seems some triangles are degenerated.

This generates a cascade of events; the most important thing is, in
dCollideBTL, the FetchTriangle call returns a degenerated triangle,
which results in invalid edges when calculating the plane equation,
which in turns invalidates the plane. And the plane's normal is
used as the contact's normal.

I have filtered out the degenerated triangles in my model loader,
and i no longer have any crash or invalid numbers.

But the tri-mesh code could probably be made more robust and handle
that exception without (indirectly) making ODE crash.

So now i still have two things to do:

- finding why some of my objects are still getting stuck into the
ground (although it's no big deal; just applying a little force
"unstucks" them).

- fixing the "tunneling" effect (still no good solution for that.
What if i want to simulate a bullet hitting a wall? Given the
size and the speed of the bullet, it will tunnel over any
tri-mesh).

And i should be done for the collision part of my hovercraft game.
Cheers.

F. Brebion