[ODE] How to compile Triangle Collider?

[Erwin de Vries]

> > The current combination works just fine. Its what i use as well.
Opcode1.1
> > might improve the accuracy for sphere collisions slightly, as i'm using
an
> > AABB Opcode test for the spheres right now.
>
> Uuh, that statement raises some serious concerns about accuracy for me. If
> a sphere-mesh test is approximated with an AABB-test and this is only
"slightly"
> inaccurate, I wonder about the overall accuracy of the tri-collider for my
> purposes.

The tree query uses AABB's. Triangles that never touch the sphere wont
contribute to the generated contact.

> In my case, I need to do collisions with a spherical object and a mesh,
where
> the sphere and the mesh are assumed to be perfect representations of the
> geometry. I am simulating a ball game where the ball will need to bounce
> against and roll through tight geometry accurately (tubes, gutters,
pathways,
> corners, hills, holes). I need accuracy similar to what you would need for
> a pool game.

For a pool game the sphere collider is accurate enough. For a game you
describe i would consider rewriting the sphere collision functions the way
they did it in the flat four engine. It _might_ produce better results. But
test it first of course.

> Is the accuracy good enough for this, or am I better off using hundreds of
ODE
> primitives (boxes) to simulate my geometry? Should I upgrade to Opcode
1.1?
> In your estimation is upgrading the tri-collider to Opcode 1.1 easy? I am
already
> behind schedule on my game (aren't we all) and want to spend as little
time
> as possible with porting code... I had planned on modeling my collision
> geometry with hundreds of little boxes but it would be much easier for me
> if I could directly use a low-poly mesh as my collision geometry - if it
is
> accurate enough.

Upgrading to Opcode 1.1 would be fairly easy i think, but i've never looked
into it, so i cant say for sure. Using boxes grouped together might work
better for some geometry. It really depends on your geometry, and i havent
done any real testing with any other data than our own car-racing games. I
would say that for most types of geometry the spherecollider works. The
boxcollider is a little more shady.

> > The worst part about the algorithm is the clipping of the contacts. I
> > couldnt think of a way of determining the penetration depth when a point
is
> > outside of the triangle. "Depth = 0.0f;" is what i do right now. You
should
> > try and see how good it works for you.
>
> What is wrong with this? If the point lies outside of the triangle then
the
> geometry does not collide with the triangle, merely with the infinte plane
> containing the triangle. I think I am misunderstanding something here. Do
> you mean that the generation of a contact point on the plane but outside
of
> the triangle might incorrectly inhibit the correct generation of another
> valid contact point which IS in the triangle? In other words, is it
correct
> to say that the presence of contact points outside of the triangle is or
> may be indicative of missing contact points within the triangle whose
> influence is then ignored? Or am I totally off base here?

Ehmm... Yes you are right. Moving a box towards a sharp edge will likely
produce inaccurate physical behavior. Perhaps others can comment on how well
it works for you?

Erwin