[ODE] Collisions time steps & tunneling effect

[gl]

My partial dHeightfield contribution addresses this problem.  It treats
heightfield triangles similar to planes, in that it extends the field's bbox
floor by a certain amount beyond what it would be otherwise (currently
hardcoded at 100units).  The collision detection will then kick out objects
even after deep penetrations - but just as with planes, the downside is that
the deeper the intersection, the more violent the outward push is.  Really
deep penetrations will make things go flying!

The reason I didn't make the depth inifite btw is that I personally didn't
want this for various reasons - but you can easily modify the code to suit.

Before you jump into that, it currently only supports spheres.  I was hoping
to spend some more time on it, but I won't be able to any time soon, so
you're on your own there.  Fabian Herb was also working on box support (how
far did you get Fab?).
--
gl

----- Original Message ----- 
From: "Flavien Brebion" <f.brebion@vrcontext.com>
To: "DjArcas" <djarcas@hotmail.com>; <ode@q12.org>
Sent: Tuesday, July 22, 2003 1:45 PM
Subject: RE: [ODE] Collisions time steps & tunneling effect


> I don't have a flat ground but a full terrain made of 150k
> polys. This was just for the example, it happens even on
> a flat ground made of 2 tris. Btw, using a plane won't fix
> the problem. Imagine a plane at y = 0, a box of dimensions
> (1, 0.5, 1) starting a pos (0, 10, 0) and going down with
> a velocity of (0, -3, 0).
> At t = 0, the box is at pos (0, 10, 0)
> At t = 1, the box is at pos (0, 7, 0)
> At t = 2, the box is at pos (0, 4, 0)
> At t = 3, the box is at pos (0, 1, 0), and due to its
> thickness of 0.5, still doesn't touch the ground plane.
> At t = 4, the box is at pos (0, -2, 0) below the ground,
> and again due to its thickness, doesn't touch the ground.
> As you see, the box has tunneled through the ground without
> any collision intersection, and that's perfectly normal.
> The problem is to fix it.
>
> As for the hovercraft, it's simulated with a single OBB,
> no joints. I transform the 8 corners of the OBB in world
> space, cast for each a ray down to the ground to find the
> distance d from the OBB corner to the ground, and apply a
> force inversely proportionnal to this distance d to each
> corner of the OBB. In summary there is 8 dBodyAddForceAtPos
> calls, plus some angular/linear velocity damping, and a few
> tricks. It's not easy to find a good force, and even less
> easy to find one that works both for high and low
> framerates.. but it's beginning to work decently.
>
> F. Brebion
>
>
>
> -----Original Message-----
> From: DjArcas [mailto:djarcas@hotmail.com]
> Sent: Tuesday, July 22, 2003 2:30 PM
> To: Flavien Brebion; ode@q12.org
> Subject: Re: [ODE] Collisions time steps & tunneling effect
>
>
> If you're having a flat ground, the easiest way it to use a plane, which
can
> be thought of as an infinity big box, going down into the ground an
> infinitely long way - so you can't get to 'the other side' of it.
>
> Out of curiosity, how are you making your hovercraft float?
>
> ----- Original Message -----
> From: "Flavien Brebion" <f.brebion@vrcontext.com>
> To: <ode@q12.org>
> Sent: Tuesday, July 22, 2003 10:26 AM
> Subject: [ODE] Collisions time steps & tunneling effect
>
>
> > Greetings,
> >
> > I'm using ODE 0.039 with OBB / tri-mesh collisions for
> > an hovercraft racing game. I currently have some issues
> > with collision detection.
> >
> > To simply describe the problem, small objets with high
> > velocities suffer from the tunneling effect. Just using
> > a flat ground made of 2 triangles, a pretty thick box
> > just influenced by gravity, if falling from more than
> > a few meters, passes through the ground more often than
> > it does not. It seems pretty obvious why (ODE uses
> > time steps, if the box is completely above the ground
> > at the previous time step, and if it is completely below
> > the ground at the next time step, no collision will be
> > reported). It's less obvious how to fix it..
> >
> > The doc FAQ mentions the problem so i believe it's
> > pretty common. It proposes:
> >
> > - to reduce the time steps: might work, but doing more
> > time steps also reduces the performance since for the
> > same elapsed time, you need to do N time steps instead
> > of doing only 1. Also, in essence it doesn't fix the
> > problem, just lessens it. A trick IMO.
> >
> > - increase ERP: don't think it helps if no intersections
> > between the objects are reported, am i wrong ?
> >
> > - use a variable time step: how is that different than
> > the first proposal ?
> >
> > So basically i'd like to know what everybody's thought
> > are on this topic, and how you solved it (if you solved
> > it!).
> >
> > Thank you,
> >
> > 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
>
>