The lion kingdom hated the idea, but the track design had to be simplified just to get it done.  Instead of arbitrary gravity directions, it has to be a constant gravity vector.  Tux racer did that & it was still plenty entertaining.  The best maps in Asphalt had constant gravity vectors.  There are a few space racers with loops.

The sideways & inverted Asphalt tracks were just too hard to play.  All the godot examples have constant gravity vectors.  Most antigravity racers have constant gravity while using clever art to create the illusion of flying inverted.  The track textures tend to rotate around the ship to create the illusion of barrel rolls & the tracks tend to camber.

A bug in BFR created an interesting visual.

Move_and_slide has a problem where the player can't stick to the collision surface.  It has to bounce.  You can call move_and_slide_with_snap to try to get it to not bounce, but this requires specifying a raycast/snap vector to probe for the surface.  If the surface isn't inside the raycast vector, it bounces anyway.  If the raycast is too long, the player doesn't slide anymore.

The process of converting sketches to tracks needed work.  It has to smooth the track & it needs to work without a 3rd direction line.  Helas, more advanced modeling techniques require installing python modules not part of blender.  The mane modules not accessible in blender are scipy & numpy.  The internet has no good solutions.

---

Installing python modules for blender

The best the lion kingdom came up with was:

# run blender's version of python

cd blender-2.92.0-linux64/2.92/python/bin

# install pip

./python3.7m -m ensurepip --upgrade

# install the modules

./python3.7m  -m pip install scipy

Reboot blender

Then repeat every time blender is upgraded.

The source for a track design is now 2 lines.

The result of a long period of procrastination, doubt, & loathing was a long desired script which could create a 3D track from just 2 paths.  The key requirement was smoothing the paths.  That used the scipy.interpolate module.

Godot had a strange bug where the rocket would get stuck to the track instead of slide.  The only solution was limiting the falling velocity.  Then there was a bug where godot reported body.is_on_wall() instead of body.is_on_floor() when the rocket was on the floor.  It interpreted the floor mesh as a wall because the track is vertical.

Constant gravity got the rocket moving & sliding the farthest, but it still got stuck when it had to turn more sharply.  Move_and_slide doesn't turn the rocket.  It gives collision points, but not how far the rocket needs to turn to avoid the wall.  Lions aren't sure how this is formally done.  An algorithm which turns a fixed amount in every frame isn't very realistic.  Repeatedly turning to many orientations & testing for collisions in every frame is very inefficient.  Turning too much makes it appear to bounce off the wall.

A few more ideas came from a couple videos

That provided a way to align the rocket with the floor & make it turn more sharply depending on how much it hit a wall head on.  The cross product grows as the collision is more head on.

In all the Godot examples, the floor is the ZX plane.  Y is vertical.  

The mane problem is the BFR track is on the YX plane while the ground is the ZX plane.  The example equations can't be translated to the YX plane by swapping variables.  All the other games are on the ZX plane.  

Another problem is the up direction is diagonal.

The godot interface doesn't show the signs of the axes.  Trial & error showed up to be X=-1, Y=0, Z=1

The examples zero out the Y axis to zero out the up direction.  When up is diagonal, you have to get a cross product involving the up vector & subtract the cross product to zero out the up direction.  

Hacking out all these details yielded the 1st complete track run purely by sliding & bouncing off the walls.  A big part of the Asphalt games was how most of the tracks could be finished with no user input.  A few maps required user input to finish like the Chinese track.  The lion kingdom figured doing this would prove the physics were manely working.

Part of the magic was designing the track so it could be traversed passively.  In a few points, the rocket only avoided flying off the track by luck.  There is a flaw in how the rocket flies sideways if not acted on by a force.  These car attributes have to be programmed manually.

The next steps would be manually adding some car physics, finally adding user input, jumps.