[ODE] More news on the crash problem

[Erwin de Vries]

> > 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.

This should be documented. I believe Opcode cant handle degereate triangles
as well, and i think it even checks&gives an error on this. I would have to
verify this.

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

I think its easy to add an assert in the build function.

> - 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).

This is a more fundamental problem with ODE's collision detection. The only
geometry in ODE that is truely stable in this situation is a plane. I know
of a solution, but it would mean a radical change in the collision detection
functions. For very fast objects like bullets you should use a ray.

Erwin