[ODE] Trimesh-CCylinder problem

Alen Ladavac alenl-ml at croteam.com
Fri Jun 4 09:13:19 MST 2004


This might be fine for your external "feeler" ccylinder, but it is not a
good solution for general collision. If you hit an edge at a sharp corner
(<90 degrees) between two triangles, and you hit it under such angle that
central axis of ccylinder is in the "blind angle" between the triangle
normals, you will be left with no contact points, and will pass through.
Have you checked some such cases?

Alen

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


> 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
> >
>
>
>
>
> _______________________________________________
> ODE mailing list
> ODE at q12.org
> http://q12.org/mailman/listinfo/ode
>



More information about the ODE mailing list