[ODE] Trimesh-CCylinder problem

Alen Ladavac alenl-ml at croteam.com
Thu Jun 3 09:07:48 MST 2004


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
>



More information about the ODE mailing list