[ODE] TriMesh update

[Erwin de Vries]

Hi,

I've just posted an update to CVS with a new triangle-box-collision
function. This is unlikely to be the last version for now. I will continue
to work on it later in the coming weeks. Some aspects of the collisions are
simply not handled right now, which is shown in the moving _trimesh example.
Let me know if you find any bugs or situations that arent handled well. Also
some parts of code have currently not been optimized. It should be a good
deal faster than the previous version though. Temporal coherence has been
disabled for now. Will be re-enabled later.

There are also some other small fixes in there in the trimesh and the
quadtree and opcode. Double precision support for the trimesh is one of
them, although its not recommended unless you have no other choice.

Russ: I've made 3 seperate commits. One which covers some general ode files,
and the other 2 are for the trimesh.

Erwin

----- Original Message -----
From: "Erwin de Vries" <erwin@vo.com>
To: <ode@q12.org>
Sent: Friday, August 29, 2003 10:47
Subject: Re: [ODE] More news on the crash problem


> > > 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
>
> _______________________________________________
> ODE mailing list
> ODE@q12.org
> http://q12.org/mailman/listinfo/ode
>
>