[ODE] Tri-collider page on wiki

[Erwin de Vries]

Hi,

After several weeks (months?) of crunch time i finally have time to continue
my planned changes to the Tricollider. The CVS version is indeed very old,
and has problems we all know about. The version i posted to this list fixes
some problems, but has several bugs, which is why i'm glad it didnt make it
into CVS. The sphere collision function isnt accurate enough for large
triangles. I'm going to rewrite the triangle-sphere collision function to be
more robust in these cases. The box collision function computes a wrong
penetration depth (not deep enough) in some cases, which i found out after
the release.

I've planned to fix these issues somewhere next week, but dont bet your
lives on it. :-)

Since ODE now implements a ccylinder-box collision function i'm considering
implementing the triangle-ccylinder function along with some other
modifications.

Erwin

----- Original Message -----
From: <nlin@nlin.net>
To: "Cyrus Preuss" <cyrusp@wingssimulations.de>
Cc: <erwin@vo.com>
Sent: Tuesday, October 01, 2002 17:32
Subject: Re: [ODE] Tri-collider page on wiki


> Hi Cyrus,
>
> > ... I (Norman) have managed to patch Erwin's changes for spheres into
the
> > current CVS version of tri-collider. Contact me for details on an
interim
> > patched tri-collider if you need accurate sphere->triangle-edge
collision
> > now; hopefully a new release of tri-collider will resolve all of the
> > edge-related problems. ...
>
> This was several months ago, and I believe the current CVS version of
> tri-collider fixes these problems.
>
> Hm, I just browsed online CVS and it seems that the changes are not yet
> in CVS, but I may be mistaken. I am forwarding the e-mail to Erwin as
> well. Erwin, did the Opcode 1.2 changes, barycentric coords for sphere-tri
> collision, ever make it into CVS?
>
> Cyrus, the problem was that the old sphere-trimesh collision used a bbox
> for the sphere to do the collision for a first rough-estimate of the
> collision points, then from this potentially colliding checked each point
> to see if it was a real collision between the triangle and the sphere.
> This second-pass was inaccurate on the edges. To avoid "bumping" behavior
> when spheres rolled over "seams" between adjacent (and e.g. coplanar)
> polygons, the inaccurate edge collision was completely eliminated, under
> the assumption that when the ball rolls off of the plane of one triangle,
> it will roll onto the plane of the next triangle. This works for "concave"
> type meshes without upwardly-jutting creases (e.g. ball is rolling on
> the inside of a bowl), but fails for "convex" type meshes with upwardly-
> jutting creases (e.g. ball rolling upwards then downwards along and over
> the sharp edge of a wedge - in this case, edge contact is essential to
> account for the convexity of the geometry). This two-pass routine was
> then replaced by a one-pass routine using new routines in Opcode 1.2 which
> accurately calculated sphere-triangle collision, including edge cases
> (apparently using a barycentric coordinate approach).
>
> After discussing this with Erwin via private e-mail, he was kind enough
> to send me some patched files to fix that one case. However, at that time,
> the internal structures of the tri-collider were being rewritten, so there
> was quite a bit of tedious hacking I had to do to get Erwin's new changes
> working with the old tri-collider (though it does work).
>
> Erwin is continuing to make new progress on the tri-collider, so it
> is probably not recommended to use my solution unless you need a working
> sphere-trimesh collision *now*, and are willing to modify your code later
> when the new version of tri-collider comes out. If you need it now, I'll
> zip up my entire modified ODE source directory and send it to you, but
> it is probabaly wiser to see if Erwin has updated the official source
> yet rather than fiddling with my branched changes.
>
> BTW in case you're not already doing so, it may be a good idea to wrap
your
> interface to ODE within an abstract class of your own design, and only to
> call ODE indirectly through your own abstract class, which means that
changes
> like updating the tri-collider are localized, and your application code
> ideally wouldn't need to be touched if ODE gets updated.
>
> Cheers,
> -Norman
>
>