[ODE] Box/trimesh collision problem

[Yordan Gyurchev]

I had for some time issues with box/trimeshes.

Most of the time (as Geoff suggested back then) it was a problem with
collision detection and contact generation. Now I have fiddled a lot with
OPCODE and half of the problems were due to my changes. Here is
what I found my problems were:

- try to visualise contacts by some rendering mechanism. Not only the ones
that get back to you in the near callback but the ones actually found by the
collision system (sometimes they are merged into one). Can be a tedious
job but ultimately you get to understand how it all works and that is always
good.

- in my near callback (i think it is similar in the example callback) I 
allocate
a finite number of contacts and then pass it down the actual collision 
box/trimesh
function to collide and fill the contact information. I had for some reason 
put the
number 6 as maximum number of contacts. The tri/box routines sometimes 
generates
larger amount of contacts... if it doesn't have enough "slots" it will just 
ignore
the rest contacts resulting into the box dipping into the mesh...

Moral of the story: make sure you provide enough contacts to be filled by 
the collision
routine.

- i had made some mistakes in the past with calculating/updating the AABB of 
the geoms
that results in sudden drop through the mesh (as described). Basically 
objects that were
intersecting this frame for no reason don't have aabb contact next frame.
Real case: i save my aabb trees in binary files and load them runtime (this 
way i can
preprocess). There was error in the loading and some uninitialised vertices 
were creeping
in resulting in some corrupted values in the root aabb. The result was 
surprising: my boxes and
spheres would get to a point in the world where suddenly they drop through 
the mesh as if
it doesn't exist anymore.

Render your AABBs so you can see what is happening. Check for corrupted 
(uninitialised)
values they may not be obvious but will affect your simulation.

- at some point i had become so desperate to find what was going on I 
started rendering all
triangles that were touched in the box/trimesh collision.


Bottom line:
9 out of 10 its turns out to be a collision (contact generation) problem.

Hope that helps.

-Yordan





----- Original Message ----- 
From: "Adam D. Moss" <adam at gimp.org>
To: <ode at q12.org>
Sent: Friday, June 17, 2005 9:44 PM
Subject: Re: [ODE] Box/trimesh collision problem


> Brad wrote:
>> I've got a terrain set up as a grid of trimeshes. When I toss a sphere 
>> onto the terrain it works fine, and the spheres roll around like they're 
>> supposed to. If I try to toss a box onto the terrain, it may bounce once 
>> or twice, but very very soon it'll suddenly shoot up into the air. I've 
>> also got a plane sitting under the terrain, and I can throw some boxes 
>> onto that and they bounce and settle fine, then if I toss a box into the 
>> terrain and the box shoots up in the air, many times the boxes sitting on 
>> the plane will ALSO shoot off somewhere!
>>
>> Is this a known issue with ODE? Is there a problem with my code?
>
> If it's any help, I see box/trimesh issues too.  In fact these
> are readily apparent, for me, with test_trimesh.exe where
> some boxes (particularly those that settle near an edge) will
> behave fine, but others will, after a couple of bounces, fall
> right through the trimesh.
>
> Anyone else seeing that?  I'm using GCC 3.1.1, BTW.  How about
> you?
>
> --adam
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>