[ODE] Objects getting stuck with tri-mesh

Dave Lloyd dave at chaos.org.uk
Mon Sep 8 06:20:01 2003


My guess is that you'll need to keep some state such as the direction of 
initial penetration and use that as the preferred side from which to 
validate contact points. It seems to me that the symmetry of the 
situation lacks any other way to determine which way to go.

Dave

Flavien Brebion wrote:

>Already tried it. In theory this should work, but
>in practise, the object still gets stuck:
>
>Let's imagine that your object is falling
>"down". The object intersects a ground box (like in
>my previous picture), and detects two kind of collision
>points: those on the top of the box (with normal "up")
>and those on the bottom of the box (with normal "down").
>
>Given the "down" speed, you invalidate the bottom
>contact points.
>
>This makes your object go up.
>
>Now your "speed" vector is "up".
>
>This invalidates the top collision points and
>revalidates the bottom collision points.
>
>Your object will go down again.
>
>Repeat and rince forever.
>
>F. Brebion
>
>
>-----Original Message-----
>From: ode-admin@q12.org [mailto:ode-admin@q12.org]On Behalf Of Frederic
>Marmond
>Sent: Wednesday, September 03, 2003 2:25 PM
>To: Flavien Brebion
>Cc: Open Dynamics Engine
>Subject: Re: [ODE] Objects getting stuck with tri-mesh
>
>
>I come late into this thread, but an idea:
>perhapse could you do this:
>- get the speed vector of your body(pos at this frame - pos at last frame)
>- for each colliding point, check it with the normal vector. If the
>angle between the 2 vectors is less than, let's say 110°, take the
>collision into account, otherwise discard it.
>
>it is not very clean, and will 'just make it less likely to happen'. It
>could also introduce some side-effect...
>
>Fred
>
>Flavien Brebion wrote:
>
>  
>
>>A smaller timestep won't fix it, it will just make it
>>less likely to happen. It will also increase the CPU
>>work.
>>
>>Extending the box depth: not possible in my case,
>>the objects would look unrealistic.
>>
>>The dHeightField would fix it, but only for the
>>terrain. The problem would still be there for other
>>objects on which you can collide (mainly a road, in
>>my case).
>>
>>F. Brebion
>>
>>
>>-----Original Message-----
>>From: ode-admin@q12.org [mailto:ode-admin@q12.org]On Behalf Of gl
>>Sent: Wednesday, September 03, 2003 5:03 AM
>>To: Open Dynamics Engine
>>Subject: Re: [ODE] Objects getting stuck with tri-mesh
>>
>>
>>
>>Well, for one you can use a smaller timestep until you get something
>>workable (smaller timestep = less penetration).  Can you not extend the box
>>depth also?
>>
>>For the ground, another option is to use my dHeightfield contribution.  It
>>only supports spheres currently, but it's written so each triangle acts
>>    
>>
>like
>  
>
>>the planes do - ie. you can penetrate very deep, and it will still kick you
>>out.
>>
>>I've been trying to talk someone into adding more colliders, but so far no
>>luck : ).  I'll need them eventually myself, but I'm busy with other things
>>right now...
>>--
>>gl
>>
>>----- Original Message -----
>>From: "Flavien Brebion" <f.brebion@vrcontext.com>
>>To: "Open Dynamics Engine" <ode@q12.org>
>>Sent: Tuesday, September 02, 2003 2:38 PM
>>Subject: [ODE] Objects getting stuck with tri-mesh
>>
>>
>>
>>
>>    
>>
>>>I've finally found WHY i get some objects
>>>stuck into my scene.
>>>
>>>It's actually very easy to understand. Check this
>>>figure:
>>>
>>>http://www.fl-tw.com/LightSpeed/stuck.jpg
>>>
>>>If the object falls "quickly" on a pretty thin
>>>box (or any actual thin solid, represented as a
>>>tri-mesh), there will be reports of contact
>>>points both on the upper and under sides of the
>>>box -> contact forces cancel each other (or
>>>almost) and the object gets stuck inside the
>>>box.
>>>
>>>Now the question: what's a robust way to fix it?
>>>
>>>F. Brebion
>>>
>>>_______________________________________________
>>>ODE mailing list
>>>ODE@q12.org
>>>http://q12.org/mailman/listinfo/ode
>>>
>>>
>>>
>>>
>>>      
>>>
>>_______________________________________________
>>ODE mailing list
>>ODE@q12.org
>>http://q12.org/mailman/listinfo/ode
>>
>>_______________________________________________
>>ODE mailing list
>>ODE@q12.org
>>http://q12.org/mailman/listinfo/ode
>>
>>
>>
>>    
>>
>
>
>_______________________________________________
>ODE mailing list
>ODE@q12.org
>http://q12.org/mailman/listinfo/ode
>
>_______________________________________________
>ODE mailing list
>ODE@q12.org
>http://q12.org/mailman/listinfo/ode
>  
>