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.

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.

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.

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.