[ODE] Trimesh-CCylinder problem

[Colin Bonstead]

After spending a bunch of time reading through the trimesh-ccylinder 
code, I got something working for my problem.  Basically, I just reject 
any contact where the separating axes test returns an edge or vertex (so 
I only accept the axis for the polygons normal).  This means that if I 
actually ran into an edge that was only connected to one triangle it 
would not give the correct result, but the way our levels are set up 
that should never happen.

I was going to try and do what Pierre suggested in Game Programming Gems 
4, and make a cache of all the edges and verts that don't need to be 
tested, and use that to determine which axes are valid.  However, it 
seems like it's working fine just throwing them all out.  Any comments 
on this Alen?

-----Original Message-----
From: Alen Ladavac <alenl-ml at croteam.com>
Sent: Thu, 3 Jun 2004 09:07:48 -0000
To: Colin Bonstead <colin at cyan.com> <ode at q12.org>
Subject: Re: [ODE] Trimesh-CCylinder problem

Yes, you are correct, it is the exact problem you think it is. The 
triangle
collider has no info about triangle-connectivity, so when touching an 
edge
it gives you normal that you would get if it was a single triangle.
Effectively, the normal with point towards the main axis of the 
ccylinder
(for the edge case), or towards one of sphere centers of the ccylinder 
(for
case where you hit vertex of the triangle). If the colliders was given
connectivity info and if it then ignored flat/concave edges, you would 
not
get this behavior then. But this feature was not implemented yet.

Alen

----- Original Message -----
From: "Colin Bonstead" <colin at cyan.com>
To: <ode at q12.org>
Sent: Wednesday, June 02, 2004 20:45
Subject: [ODE] Trimesh-CCylinder problem


> I'm running into a problem with the new Croteam trimesh-ccylinder
> collider.  Basically, I've got an extra ccylinder around my avatars
> physical ccylinder, for detecting when he's near walls.  The extra
> ccylinder doesn't actually create contacts with anything, but I do 
call
> the collide function on it so I can get normals.
>
> When the ccylinder is touching the edge of a polygon I get a normal 
back
> that's significantly off from the normal of the polygon.  I found a 
note
> about this in the code (in collision_trimesh_ccylinder.cpp):
>
> ----------
> NOTES from Croteam's Alen
> As a side note... there are some extra contacts that can be generated 
on
> the edge between two triangles, and if the capsule penetrates deeply
> into the triangle (usually happens with large mass or low FPS), some
> such contacts can in some cases push the capsule away from the edge
> instead of away from the two triangles. This shows up as capsule 
slowing
> down a bit when hitting an edge while sliding along a flat tesselated
> grid of triangles. This is only if capsule is standing upwards.
>
> Same thing can appear whenever a smooth object (e.g sphere) hits such 
an
> edge, and it needs to be solved as a special case probably. This is a
> problem we are looking forward to address soon.
> ----------
>
> So, anyone have any ideas on how to fix this?  I really don't know
> enough about collision detection to fix it myself.  My one idea was to
> just filter my contacts and throw any that were significantly 
different
> from the normal of the polygon that generated them.  The problem with
> that is, I don't think there's any easy way to get the specific 
polygon
> that created a contact.
>
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>