Chaos Vehicles has been the "wait until next version" plugin since PhysX Vehicles shipped its last reliable release in UE4.27. Every major UE5 release promised parity and delivered something close-but-not-quite — skittish high-speed behavior, replication quirks, tire models that needed tuning regimes no small team could afford.
UE5.7 is the version where that changes. We shipped a four-player online arcade-racer prototype on Chaos Vehicles in Q1 2026. Ship-quality feel, stable netcode, ~80 hours of focused tuning time. This is the masterclass we would have wanted going in.
This is a long post. There is no short version of vehicle physics that is actually useful.
Why Chaos Vehicles, and why now
PhysX Vehicles was removed with UE5.0. Chaos Vehicles was the replacement, and for three years it was "the replacement" in the sense that you could ship with it if you had a physics engineer and six months of calendar time. UE5.7 closes the gap. The specific improvements that moved us from "experimental" to "we ship on this":
- Tire friction model v3. The previous model had a subtle issue where lateral grip curves discontinuously peaked at slip angles that depended on surface friction in a non-obvious way. v3 is a cleaner Pacejka-style formulation with parameters that behave monotonically. This is the single biggest feel-improvement.
- Suspension integrator stability at high Δt spikes. Hitches above 20ms no longer cause suspension oscillation. Massive win for less-than-solid hardware.
- Replication improvements. The vehicle movement component now uses the Network Prediction Plugin backend properly. Desync on moderate-latency links (150ms, 2% loss) is well-behaved without custom correction code.
- Better damping defaults. Out-of-the-box vehicles no longer feel like boats. You still need to tune, but the starting point is closer to "car" than "pontoon."
If you evaluated Chaos Vehicles in 5.4 or 5.5 and ruled it out — re-evaluate on 5.7. It is a different plugin.
Architecture refresher
The moving parts you need to know:
UChaosVehicleMovementComponent— base class for vehicle movement. You will useUChaosWheeledVehicleMovementComponentin 99% of cases.UChaosVehicleWheel— one asset per wheel type. Defines radius, mass, friction multiplier, suspension, steering/roll/handbrake flags.FVehicleSetupAsset(ChaosVehicleData asset) — collects wheel configs, drivetrain (engine, transmission, differential), steering, brakes.AChaosVehiclePawn— ships as a reference; you typically subclass for your actual vehicle class.- Skeletal mesh with physics asset — Chaos does not use a collision primitive separate from the skeletal mesh; suspension rays originate from wheel bone transforms.
The single most important thing to internalize: the visual skeletal mesh and the physics simulation are not the same thing. The physics sim is a rigid body with suspension forces computed from ray casts. The skeletal mesh wheel bones are driven from the sim output. Getting your mesh orientations and wheel bone axes right is 30% of setup pain.
Suspension: the foundation
Suspension tuning is where most projects go wrong early. The vehicle "feels floaty," "feels bouncy," "rolls too much," "snaps back too hard" — all suspension.
Key parameters on each wheel:
SuspensionMaxRaise— how far the wheel can travel upward (into the body) from rest. Typical: 5-12cm for a sports car, 15-25cm for an off-road vehicle.SuspensionMaxDrop— how far the wheel can travel downward (away from the body) from rest. Typical: 5-10cm.SpringRate— stiffness. Units are confusing — it is approximately "force per meter of compression relative to a 1kg reference." For a 1500kg sedan with 4 wheels you want enough spring rate that the wheel supports ~3750N at rest compression of ~4cm. Back-solve: start with 250-400 and tune.SpringPreload— how compressed the spring is at rest. Keep this at zero unless you know you need it.SuspensionDampingRatio— critical-damping ratio. This is the most important tuning parameter. 0.0 = no damping (bouncy mess), 1.0 = critically damped (smooth but lifeless), typical sports car = 0.45-0.65, typical off-road = 0.35-0.50.WheelLoadRatio— how much load transfer between wheels is simulated when one is in the air. 0.0-0.5 for normal cars, higher for drift/arcade feel.
Tuning methodology that works:
- Set all dampers to 0.5. Set spring rates so at rest the car sits with ~30-40% of raise travel used (wheels partially compressed).
- Drive over a 20cm bump at 30mph. Watch the body. If it oscillates more than twice, increase damping by 0.1. Repeat.
- Drive around a 45-degree corner at 60mph. Watch roll. If the car tips excessively, either increase spring rate or add an anti-roll bar (see below).
- Land from a 3m jump. Watch bottom-out and recovery. If it bottoms hard, increase
SuspensionMaxRaise. If it launches skyward, increase damping. - Re-test step 2. Iterate.
A mid-performance sedan in our project shipped with: SpringRate 320, DampingRatio 0.55, MaxRaise 8cm, MaxDrop 6cm. An off-road buggy: SpringRate 180, DampingRatio 0.40, MaxRaise 22cm, MaxDrop 12cm.
Anti-roll bars are configured on the movement component (not per-wheel). AntiRollBarTorque for front/rear axles. Rear-heavier anti-roll produces oversteer; front-heavier produces understeer. A balanced RWD sports feel wants ~15,000-30,000 front, ~8,000-15,000 rear. Drift-friendly setups flip this.
The tire friction model
Tire friction is a curve of lateral grip versus slip angle (and longitudinal grip versus slip ratio). Chaos's model uses a simplified Pacejka formulation exposed as:
FrictionMultiplier— base grip. 1.0 = surface-default. Set to 1.0 for stock tires, lower for ice tires and performance runs on wet surfaces, higher for sticky slicks.CorneringStiffness— how aggressively grip ramps up with slip angle. Higher = more responsive, easier to spin out at the limit.LateralSlipGraph/LongitudinalSlipGraph— optional curve assets for fine control. Default curves are now shippable; override only for specific feels.
Surface friction is on Physical Materials. Make a Physical Material per surface type (asphalt, dirt, grass, ice, snow) with appropriate Friction values (asphalt 1.0, dirt 0.7, grass 0.5, ice 0.1). Apply to landscape layers and meshes. The vehicle multiplies tire FrictionMultiplier by surface friction.
Tuning the grip curve in practice: we use a test track with a 50m-radius constant-radius skidpad. Target: the car should take the skidpad flat at a specific speed. Tune FrictionMultiplier until the skidpad speed is right. Then test a sharp hairpin at 40mph — the car should break loose progressively, not snap-oversteer. If it snaps, reduce CorneringStiffness.
Two subtle things:
- Front-to-rear grip balance matters more than absolute grip. A car with 0.95 front / 1.05 rear understeers. Reverse it and it oversteers. Most tuning passes are adjusting this ratio by 0.05 increments at a time.
- Longitudinal grip at low speeds is where wheelspin and launch feel live. Too much grip and the car launches on rails; too little and the wheels just spin.
LongitudinalSlipGraphlets you author this independently.
Drivetrain: engine, transmission, differential
The defaults here are worse than the suspension/tire defaults. Budget time.
Engine:
MaxRPM— redline. 6000-7500 for most passenger cars, 8500-12000 for sports/race.MaxTorque— peak torque in Nm. A 300hp sports car is in the 400-500Nm range.TorqueCurve— curve asset of torque vs. RPM. Default is flat, which feels wrong. Author a curve that peaks near 65-75% of MaxRPM and falls off above.EngineBrakeEffect— engine braking when off-throttle. 0.05-0.2 feels realistic; 0.0 feels like coasting forever.
Transmission:
bUseAutomaticGears— true for arcade, either for sim.GearRatios— array of ratios. Typical 5-speed: 3.5, 2.1, 1.4, 1.0, 0.8, reverse -3.0. Final drive (FinalRatio) multiplies everything; typical 3.5-4.5.ChangeUpRPM/ChangeDownRPM— automatic shift points. Shift-up around 85% MaxRPM, shift-down around 40% MaxRPM as a starting point.
Differential:
DifferentialType— AllWheelDrive, FrontWheelDrive, RearWheelDrive, LimitedSlipFrontDrive, etc.FrontRearSplit— for AWD, torque split. 0.5 = 50/50, 0.3 = 30 front / 70 rear (rear-biased AWD feels sportier).FrontLeftRightSplit,RearLeftRightSplit— for limited-slip, how much torque can transfer between left and right wheels under slip. 0.0 = open diff (one wheel can spin freely), 1.0 = locked (both wheels turn together).
A good first pass for a sports car: RWD, peak torque 420Nm @ 5000RPM, redline 7200, 6-speed with ratios 3.6/2.3/1.6/1.2/0.95/0.78, FinalRatio 3.9, open rear diff (0.0 LSD) for oversteer-friendly feel.
Controller feel: the last 20% that takes 60% of the time
Physics correctness does not equal fun. The controller layer — how player input maps to simulation input — is where feel lives.
Input curves. Raw controller stick input is linear. Players expect a curve. On PC/console gamepads, apply an inner deadzone (0.10-0.15) and a response curve (exponent 1.5-2.0). Raw keyboard input is binary and needs software ramping — 100-250ms to full, 150-300ms decay.
Steering speed limit. At high speeds, full steering lock causes instant wipeouts. Chaos supports SteeringCurve (curve asset of max-steering-angle vs. speed). A reasonable curve for a sports car: full lock (35°) below 30mph, linear ramp down to 8° at 150mph. This is the single largest feel improvement for "why does my car spin out constantly."
Throttle shaping. On controllers, applying full throttle from a stop should not instantly slam max torque into the wheels. Either shape the input curve (first 20% of trigger travel = 40% of throttle, etc.) or use Traction Control settings (bTractionControlEnabled, TractionControlAmount).
Brake behavior. Two modes most games conflate: brake (deceleration) and handbrake (rear-wheel lockup for drifting). Expose separately. Handbrake should set HandbrakeTorque on rear wheels to 2000-4000Nm.
Camera. Vehicle cameras are their own essay. Key points: follow with lag (so the camera is always slightly "behind" the car's rotation), add FOV-by-speed (FOV +10-15° at top speed feels fast), use the Gameplay Cameras plugin rig system if you are on 5.7 — it makes alt-cameras (chase, hood, bumper) trivial.
A detail we learned late: audio is ~40% of perceived feel. A great-driving car with a bad engine note feels worse than a mediocre-driving car with a great engine note. Budget audio time accordingly.
Networking: what actually breaks
Multiplayer vehicles are the hardest networking problem in most games. Vehicles are rigid bodies with many DOF, tight coupling to input, and hard physics constraints — everything about them fights prediction.
Chaos Vehicles on 5.7 uses the Network Prediction Plugin (NPP) backend. Out of the box it works for LAN/low-latency. Here is what we hit on real conditions.
Problem 1: Client prediction desync on collisions. Client predicts the collision; server authoritative simulation diverges slightly; client snaps. Fix: set the movement component's NetworkSmoothingMode to Replay and tune CorrectionPositionThreshold to 10-25cm and CorrectionRotationThreshold to 2-5°. Below those thresholds, smooth the difference over 150-250ms instead of snapping.
Problem 2: Wheel visual lag on remote clients. The body replicates with prediction; the wheel rotations are client-side cosmetic. If you drive the wheel spin from the replicated velocity, it looks fine. If you drive it from the physics sim directly on replicated pawns, it lags. Use velocity-based visual wheels for remote pawns.
Problem 3: Input rate matters a lot. Vehicles need high input sample rates or they feel rubbery. Bump client input send rate to at least 60Hz, ideally 90Hz. The default 30Hz is audibly wrong.
Problem 4: Suspension rays are expensive on dedicated servers. 16 networked vehicles × 4 wheels × suspension rays = real CPU cost. Profile. Lower suspension ray complexity on server if needed (the server does not care about fine wheel slip for replication; it cares about body position).
Problem 5: Rollbacks on high packet loss. Above 5% loss, prediction rollbacks cascade and produce visible jitter. Most games should limit matchmaking to under 3% loss and ship a graceful degradation (longer smoothing window on high-loss clients).
We measured our 4-player prototype on simulated 150ms / 1.5% loss links: desync events requiring >10cm correction = 0.8 per minute per player. That is well within "invisible to players" territory and required ~6 hours of tuning the thresholds above to get there.
Damage and destruction
Chaos Vehicles integrates with the Chaos Destruction system for visual damage. Two levels:
Cosmetic damage — deformable mesh pieces, particle effects, decals. Trigger on impact force threshold. No physics impact on vehicle performance.
Systemic damage — modify handling based on impact history. Damage to a front wheel reduces that wheel's FrictionMultiplier; damage to engine reduces MaxTorque; damage to suspension zeroes that wheel's spring rate. This gets grim quickly (the car becomes undriveable) so either cap systemic damage at gameplay-reasonable levels or reserve it for destruction-focused games.
We shipped cosmetic-only. The systemic pathway is real but the tuning effort is 3-5x what cosmetic costs, and for an arcade racer the feel payoff is small.
Testing methodology
Vehicle testing is where most projects underinvest. You need a standard test battery you run against every build. Ours:
- Constant-radius skidpad (50m, 100m, 200m radii). Measures max lateral G, understeer/oversteer balance.
- Straight-line acceleration (0-60, 0-100, 0-top). Measures drivetrain.
- Braking distance (60-0, 100-0). Measures brake force and grip.
- Bump test (20cm, 50cm, 100cm bumps at varying speeds). Measures suspension.
- Jump test (2m, 5m, 10m jumps). Measures suspension bottom-out and landing stability.
- Slalom (cones at 15m spacing). Measures responsiveness and body roll.
- Hairpin (sharp 180° corner, entry 60mph). Measures at-limit behavior.
- Bumpy straight (perlin-noise surface, 200m long). Measures high-speed stability.
Automate these. Each test should report numbers you can track over time. When a tuning change regresses one of them you find out immediately. We use an MCP-driven test harness for some of this — the Unreal MCP Server can run scripted driving inputs and scrape resulting telemetry, which is great for bulk tuning passes where a designer wants to see the curve of behavior across a parameter sweep.
Content pipeline
A production-quality vehicle is ~3-6 weeks of content work, independent of the physics tuning:
- High-poly + low-poly exterior mesh, baked normals, interior geometry
- Wheel skeletal mesh with proper pivot alignment
- Rig with suspension, steering, and wheel bones
- LODs (typically 4-5 for racing games where cars are visible at distance)
- Collision primitive (simplified low-poly hull)
- Physics asset with accurate mass distribution
- Damage model (deformable parts, broken glass, detached bumpers)
- Audio (engine RPM-driven samples, tire, impact)
- Paint/livery system
Our Blueprint Template Library ships a vehicle starter that wires the Chaos movement component with sensible defaults, an input mapping, and a camera rig. It does not replace the content work, but it replaces the "wire-up" work — roughly 2-3 days of engineering setup per vehicle reduced to an hour.
What we shipped with
For the prototype that motivated this post — 4-player online arcade racer, 3 vehicle classes, 4 tracks, 60fps target — our final tuning numbers:
- Sports car class: 420Nm / 7200RPM, RWD, spring 320 / damp 0.55, full lock 35° tapering to 8° @ 150mph, handbrake torque 3200Nm
- Muscle car class: 580Nm / 6500RPM, RWD, spring 380 / damp 0.50, full lock 32° tapering to 6° @ 140mph, handbrake torque 3800Nm
- Off-road class: 350Nm / 6000RPM, AWD 40/60 split, spring 180 / damp 0.40, full lock 38° tapering to 12° @ 100mph, handbrake torque 2800Nm
Network: NPP backend, 60Hz input, 25cm position / 4° rotation correction thresholds, 200ms smoothing window. Ran clean on 150ms links.
Total tuning time from "basic drivable" to "ship quality": 82 engineering-hours across 6 weeks of calendar time, with design driving 60% of decisions from gameplay feel rather than physics realism.
Common pitfalls we watched others hit
These are not speculative — each of these is a bug we hit or saw on a client project, and each wasted at least a day before root-cause.
Wheel bones with non-aligned axes. If the wheel bone's local axis does not match what the movement component expects, wheels spin the wrong way, steer the wrong way, or do not respond to suspension visually. Export from Blender/Maya with wheel bone local X pointing forward, Z up. Verify in the skeleton editor before wiring up anything else. We have lost half-days to this.
Missing physics asset mass. A vehicle with a default-generated physics asset often has wildly wrong mass distribution. A 1500kg sedan with 80% of mass in the front feels like a shopping cart. Open the physics asset, set the chassis body to your target mass, zero or nominal mass on wheel bodies (suspension applies forces at wheel transforms; wheel bodies do not need to be mass-carrying). Mass on the chassis. Always.
Collision primitives wider than mesh. If your collision hull is 5% wider than your mesh, cars spawn 5% clipped into walls and behave bizarrely. Tighten the hull.
Wrong scale. Chaos Vehicles uses Unreal-standard units (cm). A vehicle modeled in meters and imported without rescale is 100x too large, which does nothing sane. Check scale before anything else when debugging a new model.
CameraManager fighting the camera component. If you are using the Gameplay Cameras plugin for camera control, make sure your APlayerCameraManager subclass is not also setting camera transforms. Two systems fighting over the camera produces juddery output that looks like a physics bug but is not.
Network smoothing interpolating through walls. On correction, the interpolated pose can intersect geometry. If your camera is child of the mesh, the camera winds up inside walls for the smoothing window. Either (a) do not parent the camera to the mesh for networked pawns, or (b) disable smoothing and accept snaps, or (c) implement camera-specific collision that differs from vehicle collision.
Dedicated server simulating physics at wrong rate. Chaos Vehicles assumes a physics tick rate that matches the server tick rate. If your dedicated server runs at 30Hz but physics is at 60Hz, input latency doubles. Set both consistently.
AI vehicles using player movement component. AI-driven vehicles typically do not need the full networked player movement path. Split the class hierarchy: APlayerVehicle with full Chaos + NPP networking, AAIVehicle with simpler locally-owned simulation that replicates as a standard replicated pawn. This saves considerable server CPU on AI-heavy tracks.
Tuning philosophy
The hardest part of vehicle work is not knowing what knobs exist — you can read the docs for that. It is knowing how to iterate. Our approach:
- Fix the test conditions first. A constant test track, a constant vehicle, a constant observer. You cannot tune against a moving target.
- Change one parameter at a time. If you change spring rate and tire friction simultaneously, you learn nothing.
- Tune at the extreme, validate in the middle. If the car feels wrong in normal driving, exaggerate what feels wrong (make it way too bouncy, way too stiff) and find the value that makes it unambiguously bad. The right value is usually 30-50% of the way back from the "bad" extreme.
- Listen to designers but measure the objection. "The car feels floaty" is a direction. Measure body Z oscillation after a bump. That is the metric. Now tune against the metric.
- Do not tune for perfect realism. Real cars are not fun. Shippable vehicles are 60-70% realistic and 30-40% tuned for fun. Understand which parameters you are lying about and why.
- Save presets as data assets, not code. You will revisit settings. Every vehicle class is a
FVehicleSetupAssetyou can diff, copy, and revert.
What we do not recommend
For completeness, a few approaches we have seen fail:
- Hand-authored physics curves per vehicle. Designers tune slip graphs per-car per-surface, ending up with dozens of curve assets. Unmaintainable. Use default curves with
FrictionMultiplieras the tuning lever. - Running Chaos Vehicles for non-wheeled vehicles (hovercraft, spaceships). The plugin is called Chaos Wheeled for a reason; other vehicle types want a custom movement component. Forcing wheels onto a hovercraft is possible but painful.
- Pushing replication rate to hide netcode problems. If your networking feels bad at 30Hz, going to 120Hz often papers over the symptom without fixing the cause. Debug the prediction thresholds first.
- Skipping the physics asset review for every vehicle. "It looks fine" is not a physics asset review. Every vehicle needs a pass.
Bottom line
Chaos Vehicles in UE5.7 is production-ready for small studios in a way it was not in 5.4, 5.5, or 5.6. Tire model is good. Suspension is stable. Networking is tractable. You still need a physics-literate engineer for 6-10 weeks to ship a good-feeling vehicle — but that is a fraction of what it cost eighteen months ago, and it is within reach for teams that previously would have walked away from Unreal entirely for a racing project.
Set the defaults per the tables above. Run the test battery. Tune to feel, not to realism. Ship audio alongside physics. Budget for the last-20% controller polish that takes 60% of the time.
Cars are hard. Chaos finally makes them fair.