Ah I see.

So being that a damped spring does work fine, hover wise, your reason for suggesting a PID thruster was just for better hover behaviour? Smoother and faster transitions to the desired hover height?

Also, could you explain your 2nd point a little more? In particular, I don't understand this line "Take a unit vector normal to your track that passes through P(t+dt)". Everything else makes sense.

Regarding disabling gravity, I recently played Wipeout 2048 - and noticed that in the zone tracks, you stick to the track like glue (or like a rollercoaster) even when going over a steep vertical drop. As if there is no gravity as such, more that your ship is constantly being adjusted to be a set height, as if the PID algorithm for example was adjusting the "error" below or indeed above your desired hover height. Or a bit like spline following behaviour.

In contrast, normal races in 2048 have standard gravity behaviour, more like what I have now in my game, where by going over a large drop would have you soaring through the air and landing a couple of seconds later.

Also, could you explain your 2nd point a little more? In particular, I don't understand this line "Take a unit vector normal to your track that passes through P(t+dt)". Everything else makes sense.

The point P(t+dt) is your prediction of where you will be at the next time step.

If you draw a line from P(t+dt) to the track, making the line end up perpendicular (normal) to the track surface, that is essentially your "predicted" elevation.

For example, you find this line and it's length is 5 units. You want to maintain an elevation of 10 units. You can now extend that line to make it 10 units long. The new endpoint of that line becomes P(goal). Now you just need to rotate your velocity vector to intersect with P(goal).

This is very similar to what Lorenzo Gatti said with:

"If the current velocity would cause penetration (downwards into the road), you can project the computed velocity along the tangent plane of the road."

Except that projecting the velocity vector will shorten it (slowing you down).

Rotating the velocity vector will maintain it's length. Both are valid options depending on what you want.

If you allow rotating your velocity vector both TOWARDS and AWAY from the track, you will get the "spline following" behavior.

If you allow rotating your velocity vector only AWAY from the track, you will not crash into the track, but you will float over jumps normally.

If it were my game, I would go the extra step and compute forces needed to actually create this change in velocity and feed them to the physics engine just like any other force. This isn't absolutely necessary, but I think it can help to avoid weird edge cases in behavior.

Cheers Wombat, that's very clear. It was mainly the "passes through" that I found confusing.

It's actually my own physics engine I use, built to be as fast as possible as I use software rendering. I apply the forces before the objects get updated by my physics engine. So yes, they do get added and updated like any other force, it's not a seperate integration.

I'll try out the 2 way velocity adjustment to see if that gets the behavour I want, like the Wipeout zone tracks.

For stability I'm also applying one force per ship. I use 4 additional raycasts just for track orientation.

CombatWombat - thanks again for recommending PID. Such a simple, clever little algorithm. It was very easy to implement in place of the spring too.

Amazing how closely and smoothly it manages to stick to the target hover height too, despite massive fluctuations in altitude and velocity.

The only slight problem I'm having is a bit of bumpiness on low poly collision geometry, specifically angled bends. It's similar to a very stiff spring in that it doesn't absorb shocks well enough. You get micro judder round inclined bends, where the spring would absorb those quick, sharp changes in terrain perfectly.

The best settings I've found so far for my uses are 0.05, 0.000001, and 0.19 for PID.

You may want to do something about the coarseness of your track. Even if the underlying track is polygonal, you could use some smooth interpolation between "nodes" or however your track is described.

I agree, it's always been a problem, having low poly geometry.

I can have seperate collision geom to render geometry, but part of the problem is I develop web games, so (relatively) high poly collision geom is going to add to the file size.

What do you mean by nodes? Spline points or something else? I have a spline for CPU steering and position calculation, and a big triangle mesh for the track.

Yes, I mean something like spline points. Your collision geometry could be continuously differentiable, described by something like a spline, and then you don't need it to take much space.

Sure, that would be ideal. I've never experimented with generating geometry from a spline before, do you happen to know of a good reference? Right now my splines are just a series of points used for various things like CPU steering and object placement. They have no bezier curves etc, they are just points.