• ### Popular Now

• 13
• 18
• 19
• 27
• 10

#### Archived

This topic is now archived and is closed to further replies.

# Hovercraft theory: hovering forces, damping, springs..

This topic is 5286 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

I''m working on an hovercraft racing game. However i''ve got some problems with my hovercraft. It''s very unstable: as soon as it starts to tilt, it continues to tilt for a long, long time. I want the movement to damp after 1 or 2 seconds. The hovercraft is simulated by a simple oriented bounding box. For the hovering physics, i get the 8 corners of the bounding box in world space, cast a ray under the hovercraft to find, for each corner, the distance to the ground. As a result, i get 8 contact points with the ground, and for each i know at which distance the corresponding corner of the OBB is. I apply a formula (that''s the one causing my problems) mostly based on this distance to generate a force applied at the corner of the hovercraft. Each force results in a bit of linear and angular velocities. I''m not a complete newbie on physics, but not an expert either (i''m using ODE btw). For my formula i tried to implement a damping/spring force based on this:
f = (-damping * dp - spring * d) / m;

Where damping is the damping coefficient, spring the spring coefficient (how original). dp is the dot product of the velocity and the normal at the ground, generally it''s just the Y component of the velocity. d is the distance to the "target hovering height"; for example if it''s a height of 4.0 above the ground and the current position is 2.5, d = 2.5 - 4.0 = -1.5 The problem i have is that, although it works well in 1D, this formula doesn''t seem to work at all when using 8 springs. It''s as if the effect of one spring was cancelling the effect of its opposite. As a result, my hovercraft hovers at the correct height, but is tilting like mad, and it doesn''t seem to damp at all. I tried many parameters for the damping and spring constants but none seem to work. I can probably provide a video if needed. Any help is welcome. Y.

##### Share on other sites
I assume you are using this formula once each frame to find the force applied at the point of contact between the ground and the hovercraft? Are you mistakenly applying the formula to all 8 contact points every frame? (Remember, your craft is hovering, as such only one or possibly two points should actually be contacting the ground when it tilts.)

##### Share on other sites
Not sure what you''re talking about. Even when tilting, it''s an hovercraft. There''s never a real contact point with the ground.

The goal of applying the 8 forces is to stabilize the hovercraft over time, but yeah, all 8 forces are applied each frame (btw i tried with the 4 "bottom" forces only, and it didn''t change anything).

Y.

##### Share on other sites
I''d asume the problem is in the distance of your force points.

Imagine it in 2D.
You have a line A-B hovering over the ground. when A is at the correct high, but B is to low, you will increase the force that''s pushing up B.

As the center of mass lies in the middle of the line A-B, with pressing B upwards, you rotate the object around it''s center and press A downward while doing it.
In the next step A is to low, and B probably to high, and your problem starts with switched sides.

I''d suggest to:
- increase the FPS of your physic engine. (do more but smaller timesteps)
- don''t apply the forces at the edges, but perhaps half way from center to the edge, or:
- increase the number of force-points at the bottom side (i would ignore the top side) real hovercrafts don''t have 4 points in all their edges, but infinetly number. try to use a 4*4 grid at the bottom side.

Hope this helps.

##### Share on other sites
quote:

I''d suggest to:
- increase the FPS of your physic engine. (do more but smaller timesteps)

My physics engine speed is tied to the graphics framerate. In my tests it''s running at > 150 fps, so i don''t believe it''s the problem.

quote:

- don''t apply the forces at the edges, but perhaps half way from center to the edge, or:

Tried that, makes it a bit better, but doesn''t basically solve it.

quote:

- increase the number of force-points at the bottom side (i would ignore the top side) real hovercrafts don''t have 4 points in all their edges, but infinetly number. try to use a 4*4 grid at the bottom side.

That''s an idea, i will try that. However i''m concerned about performance: that''s casting 16 rays through the whole scene, per hovercraft. 10 to 20 hovercrafts racing in the game, would make that solution too slow..

Y.

##### Share on other sites
Yasena, as you know I will also soon be interested in testing small simplified models for hovercrafts. My experience in game physics, is that such unstabilities are caught between two antagonous constraints :

- precision lost in the integration of differential eaquations due to large time steps.
- the strength of the damping parameter (*).

The more you want to reduce inertia and unrealistic oscillations, the more damping you need, but then the more FPS you need.

You should use a special and independant FPS for the physics. In your case I suggest around 1000FPS because coldet (simple ray casting) and physics cost nearly nothing.
Example :
while( tPhys{
UpdatePhysics( tPhys );
tPhys+=0.001f;
}
// Then Eventually extrapolate graphic objects positions to reach the exact
// tPredicted frame. But 0.001 second should be precise enough.

Example : Dt = 1second, damping = 1.5, differential equation is
dV.z/dt=A.z = -V.z.
Any such differential equation should converge to V.z= 0.
But the discretized step method adds numerical unstability :
V.z -= 2*V.z;
1, -2, 4, -8, etc ...
console : program aborted, infinity exception in ...

Another comment is that I feel the logic between dp and d is not geometrically coherent. Imagine a stone on the terrain, then dp could be nearly perpendicular to the local up of your hover. I'd prefer simply a dp is the velocity component in the local Up (hover) direction = (Vel*Up)*Up. Next add a ratio of your previous perp effect due to the terrain normal at the point you reach in the Up direction if you want.

Pls tell me if it works better.

[edited by - Charles B on September 24, 2003 9:14:05 AM]

##### Share on other sites

The good news is, i''ve found the cause of my instabilities. A bug in my code; you know that part about damping, using the velocity? I was using the linear velocity at the center of mass, instead of the velocity at the 8 corners.

Using the correct velocity fixed most of the problems. Damping can now be well controlled by its constant; at 0.6 it damps almost immediately, while a value of 0.05 results in a damping over 1 or 2 seconds average (much better). I can also control the hovering height with the spring constant (the lower it is, the closer to the ground the craft will hover).

I tried 16 rays, but i didn''t make a difference with only 4 rays (i got ride of the "top" ones).

Charles, i can''t agree with your statement that collision detection costs nothing. If you were to cast hundreds of rays per frame, in a scene consisting of >150 000 triangles, and on an average CPU (1 Ghz), collision would likely to be your bottleneck.

Now i''m happy, i''ll be able to move onto other issues.

Y.

##### Share on other sites
Yep but small rays, with a quadtree or regular grid partition, that''s basically not much more than one or two triangle/segment tests. Well 50 cycles or so What I do in my terrain engine is use a bresenham like algo over the quad-tree or the regular grids of the patches. Also local AAboxes set like russian dolls are cached. That''s speedy, specially if you cache the previous node pointer and use space time coherency. I am sure one can send 100000 rays per frame on a terrain but 100 or 1000 are usually enough in common games. Of course you also have to deal with other kinds of meshes probably. I remember your screen shot, ramps, etc ... Octrees or regular grids for each static mesh ?

Still I think fixing a constant and low time step for the physics is a good deal. Because you''ll remove many bugs, and you can precompute many variables dependent of time step. For instance precompute exact results of differential equations in some cases.

Glad your demo works fine. I hope you''ll allow us to see a demo soon

##### Share on other sites
Yeah, that''s my problem. You''re right about the quadtree, obviously, but i must point out that 99.9% of the time, players will be on the track, not in the landscape

My track segments are created procedurally along a curve, which means they''re pretty much all different. They''re treated as tri-meshes for collisions, so it costs more than a few tris/ray to test. And excepting the curve, there might also be accurate collisions with other hovercrafts, buildings/obstacles, ramps, etc..

Each static (or semi-static: as long as they''re not deforming and just use a standard transformation matrix, it works) object is internally split into an AABB tree, in which leaves store collision triangles. I''m using Opcode for that.

Yeah, the demo is on its way. But i don''t want to show something incomplete or not well polished, so it will still take a few months, i guess

Next step now: an "intelligent" camera. The one is use is always in the back of the hovercraft, so it''s perfectly tied to the transformation matrix of the hovercraft. Doesn''t look natural/smooth.

Y.

##### Share on other sites
I have coded a minor form of "intelligent" camera in a commercial game. It was based on a physics model but with some computations highly simplified.

The simpliest form was a kind of telescopic arm attached to the back of the car with a "spherical joint". The camera is attached to the other side and has some "intelligent" lookat rotations. So when the 3D car (it was a flying one) went up the camera looked slightly from above becaue of angles and lengthes of the arm due to inertia. When you brake, it gets closer, when you accelerate, further. Well I could try to remember the code if required. This was small but efficiently good looking.

With some coldet for the arm and cam you can probably avoid camera traversing walls. Just use simple velocity clamping perp to the polygons. Else ray cast solutions and a model equivalent to your hover would probably work too and be smoother.