[ODE] Hovercraft (was ..tunneling effect)

[James Golding]

Hi Flavien,

Ok, I'll admit I've had more experiance with the Karma physics engine than ODE, but from what I 
understand the ideas are the same.

I've been doing some hovercraft stuff recently, and found an approach that works fairly well. I do a 
few cheap line-checks down from the hovercraft onto the terrain, and then add very soft, 
frictionless contact constraints if the line hits the ground (using hit-distance to give penetration 
and setting the normal to point back up the line). Because you are letting the solver generate the 
forces, you can make them very stiff if you want, and you don't have to worry about tweking for 
timestep, mass etc as much.

I also added a soft constraint on the 'pitch' and 'roll' angular degrees-of-freedom as well to try 
and keep the thing upright.

Squidgy constraints rock :)

James

Flavien Brebion wrote:
> 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
> 
> .
>