High speed vehicle - grip, cornering

[PhoenixIllusion]

I'd been working on more of an arcade style GoKart setup with the Wheeled controller. For realistic world simulation, most of the default behavior (following) seems accurate.

I'd noticed even on the Jolt example on the official repo that the car wheels tend to overspin a lot on startup (although I know it is at 100% throttle, so this may be peeling out?)

#Acceleration
I've tried modifying my wheel traction, even setting the linear curves to 1-3 plus friction across the curves, which has at least prevented some of the initial over-spinning.

As a proper startup, for the acceleration of the vehicle would I need to code a dynamic throttle off the tires surface slip? I'd like a more "press A for gas", given the current is actually more like a real world gas pedal, 0-1 analog.

#cornering/drift
My next challenge was cornering. By the default traction settings, even with 3000+ mass, hitting the corners of a 1-friction surface at 70 mph seems to make the car slide like ice. I tried exaggeration the tire width to silly extents, but that doesn't seem to impact it. With forced lat/lon curves to 5-10 friction I can sometimes take the corners at 80 mph.

At too high of an sideways friction, the car will just stick like glue to the ground when attempting to slide that direction, until the car inertia breaks the friction and it jumps off the ground and stutters sideways in bunny hops, although not giving more driving control.

To hit the higher speeds, like boosting, I just keyed a button to scale up the max torque when pressed. I had my little cart run the perimeter of my track ( border of the entire map to give enough turn-radius time) at 140 mph with excess friction settings, so it at least is at a starting point for racing, just poor control.

For a GoKart, to get a "high-speed-energy feeling" without sliding around, thus some kind of grip and cornering, my current brainstorm thoughts are:

• Instead of altering friction over 1, apply per-frame downward force on the vehicle to press it to the ground relative to velocity
• Apply a per-frame relative corrective force to the ortho vectors of the car at higher speeds to cut down sideward slip and keep them "on track" when brake is not active (to allow drift). This may even allow a hazard angular-force correction logic step that can catch and reduce some wild spin outs/ "dancing like a spinning top" on hitting a bump
• Run the simulation with lower gravity and higher time-skip to compress time, so 70 mph looks like 140-200 mph
• Shrink the apparent scale of everything, so that lower speeds cover more apparent ground

I've looked into vehicle settings, but may have missed an obvious solution.
Is there a simpler way, or has someone else solved something similar regarding traction and turning/grip?

[LeXXik]

I ended up using a character virtual for our go karts. The dynamic behavior was just too hard to control and edge cases were breaking stuff. I'm pretty sure Mario go-karts are also kinematic controllers. Its not very realistic, but for arcade go karts? Its perfect.

[jrouwe]

I'd noticed even on the Jolt example on the official repo that the car wheels tend to overspin a lot on startup (although I know it is at 100% throttle, so this may be peeling out?)

This is indeed a hard problem to get right. The engine simulation is complex and makes some simplifications during its solve loop that probably make it different from a real engine. When working on this, my conclusion was that the main reason for the spinning wheels was that in a real car you don't release the clutch in 0.3 seconds (you would use much longer times at lower gears) and you also don't push the gas pedal to 100% instantly.

You can hack your vehicle by giving it the ability to apply more impulse to the road like the sample does:

https://github.com/jrouwe/JoltPhysics/blob/deeb4bca047308ddd48345c2d906ed1c9ae487ca/Samples/Tests/Vehicle/VehicleConstraintTest.cpp#L159-L167

(note currently not exposed to JS).

Maybe this is something you can use to fix your other problems as well? Tweaking cars is incredibly hard due to the number of tweakable variables.

[PhoenixIllusion]

This seems to solve the grip part of the issues. The main issue I've fought with after this is the cornering, which seems no matter where I set the center of gravity on a high speed car, it will still try to flip the car on a corner.

I've tried to target the CoM as close as I can in line with the 4 wheels, and set car's override gravity to 10x-100x along with a decrease in vehicle weight and engine torque to suppress the flipping some. That might be my temp solution for now. I can take some of my corners on a 3x-sized "track" from the example at 120-140mph and wipe out at 180mph, but I think 140 mph is plenty fast for a kart racer.

const vehicleMass = 125.0;
const maxEngineTorque = 300.0;
const carGravity = new Jolt.Vec3(0, -900, 0);

const TireMaxImpulseCallback = (inWheelIndex, outLongitudinalImpulse, outLateralImpulse, inSuspensionImpulse, inLongitudinalFriction, inLateralFriction, inLongitudinalSlip, inLateralSlip, inDeltaTime) => {
    Jolt.HEAPF32[outLongitudinalImpulse/4] = inLongitudinalFriction * inSuspensionImpulse;
    Jolt.HEAPF32[outLateralImpulse/4] = inLateralFriction * inSuspensionImpulse * 3; //grip on turns
};

EDIT: It looks like proper balancing so the CoM is at ground-level can prevent the flip without needing a gravity override to dampen it.

2024-05-30-jolt-car-steering.mp4

[PhoenixIllusion]

It seems this is close to just mapping the lateral/longitudinal friction curves of the tires so that they are equal to the squared value of your target? Given the default friction resolution value for Latitude/Longitude is sqrt( curve_value * body2_friction) ?

[jrouwe]

Yes, the main thing this callback allows you to do is to define an alternative tire model. E.g. maybe your tire has spikes and has grip even when there's very little force pushing the wheel down on the floor, you could make the function non-linear: outLongitudinalImpulse = inLongitudinalFriction * max(some_value, inSuspensionImpulse).

B.t.w. 300 mph seems like a pretty insane speed for a cart. I'm not really surprised that it tends to flip over. Moving the COM down is also what the sample does to make flipping over less likely.

[PhoenixIllusion]

With a just-about zero CoM elevation over the ground, it wasn't flipping at my second videos 300mph, so that was a good bounds-condition.

I can now finish the demo with any variety of controlled speeds and conditions less than that target. Marked as solution, since I can both take turns at that speed and not slip or flip, and this thread now mostly has the findings/discussion needed to approach modifying the solutions for higher speeds or more nuanced traction on the tires and road.

[PhoenixIllusion]

I think the cornering is just making sure the Center-of-Mass is closest to ground-level ... tweaking that, and the traction and grip equations seems to fix a lot of my issues. I will need to code something to feed the values based on current acceleration/rate to make it more natural, but this seems to solve the high-speed.

2024-05-30-jolt-car-steering-high-speed.mp4

[PhoenixIllusion]

Towards those upper ends, it does start running into risk of tunneling issues and might need to take into account either multi-step collision or continuous. Somewhat amusing to hit the wall at 300+ and have the car go halfway into it then rubber-band snap back out in the other direction.

This one was :

const vehicleMass = 125.0;
const maxEngineTorque = 1450.0;
// center of mass on ground as close as possible to zero
callbacks.TireMaxImpulseCallback = ///
Jolt.HEAPF32[outLongitudinalImpulse/4] = inLongitudinalFriction * inSuspensionImpulse * 10;
Jolt.HEAPF32[outLateralImpulse/4] = inLateralFriction * inSuspensionImpulse * 14;
// track sizing
const hull = new Jolt.ConvexHullShapeSettings;
block.forEach(v => {
  tempVec.Set(-v[1]*4, v[2]*3, v[0]*4);
  hull.mPoints.push_back(tempVec);
});

[jrouwe]

B.t.w. I added official support for the max tire impulse callback here: efecad1