Car physics

Several different physics models are in use by the game, one for each car type. This document describes those models (which themselves are implemented in carphysics.c) In essence these functions control the forces acting on the car, rather than the actual movement of the car (which is handled by car_move() function in cars.c)

Input parameters

Each physics modelling function takes four inputs:

'Car' physics

The following state variables form the basis of the physics model for cars:

The model also relies on the following data from the car definition file:

Forces

The following forces are calculated for the model:

Engine and gearbox model

The output force of the engine is dependent upon the engine torque (calculated by feeding the RPM into the torque curve function), engine health, throttle value, and the gear ratio for the current gear. But since the game does not track the RPM of the engine, it first calculates it from the drive wheel speed.

Since all cars have automatic transmissions, the engine modelling also contains the logic to select the appropriate gear. For this, it merely calculates the torque that the engine would produce for each gear, and selects the gear that produces maximal torque. It does not take into account the health of the engine when performing this calculation, in order to have the gearbox respond in an appropriate manner when the engine becomes damaged (although it may be possible for 'manual' gearbox cars to be introduced in which the engine health is a contributing factor to gear selection).

Train physics

Since trains will usually only be driven on tracks, they can get by with much simpler physics, especially in the realm of the towed carriages.

A train will operate as a whole; only one driver is allowed throughout, and control inputs are propagated throughout all carriages. This allows engine carriages to be placed in a variety of locations, and their net forces to be applied to the net mass/velocity of the train - for as long as the train remains on the tracks.

Train movement is computationally driven by the front carriage; it finds the first driver (if any) for the controls to come from, and gets the total mass of the train. Engine forces are totaled and then applied as if they were acting on a single object, and the velocity of all carriages is set to the same value. Depending on the direction of travel, the carriages will then be moved along the track, starting from the forwards end and working backwards. Carriages will be placed on the track as if bogeys were mounted at the axle markers. Spacing method is as yet undecided - should the tow points be used (sensible) or should they be spread out so that they do not touch? (will eliminate collision detection problems). Former may be best, with extra collision detection flags to allow ignorance of cab/trailer cars.

If a train comes off the rails then it will act like an out-of-control car, obeying standard physics; this also applies to dead trains.

Articulated vehicle physics

Initial support will be via a stiff spring model. The physics model will be amended so that over the course of a frame the external forces (x,y,z,r) being applied to an object will be totaled up and then applied during the physics update. These forces will constitute collision forces as well as the spring forces holding cabs and trailers together.

AI support

AI support in the car physics code provides the AI with two important values: The current stopping distance (or, perhaps more usefully, the distance needed to change from one speed to another), and the current turning circle radius (or, perhaps more usefully, the speed needed to drive round a corner of a certain radius).

Stopping distance is calculated using the crit_dist() function as proposed in the RARS tutorial. TODO:
MUST-DOCS: LONG: Physics models for other car types. bikes can use car code with additions so that door frames are used for cornering images (and addendum to collision funcs etc.), etc.
MUST-CODE: MED: Improve car physics - tweak low-speed cornering and acceleration, different road friction values based around surface type, skidmark support, configurable max slip value, etc.
CODE: MED: Articulated vehicle/improved collision support, as above. Need generic function for applying a force at a point to a car; this will convert it to x,y,z,r force values and add it to the per-frame total. May also require a way of flushing the value (or immediately applying a single value) in order to fit in with current car-car/car-wall collision code? Does current code use time slices or distance slices or just gives up upon first impact?
MUST-CODE: MED: Trains, as above.
MUST-CODE: MED: AI support funcs. Does AI only need two funcs? Stopping distance (or deceleration amount) for a given speed, and turning circle for a given speed (or vice-versa). Code then only needs to worry about maintaining a speed that has a safe/valid stopping distance, and slowing to the correct speed before cornering (and aiming for a point rather than bearing, to make sure minor errors are recovered from).
CODE: MED: Tweak engine sound volume. Louder if throttle held down, louder/quieter if player is in the car?
CODE: MED: Fix wobbling. If friction forces are 0, make the car stop completely?
CODE: MED: Better tank support - tank-vs-tank collisions, better movement forces and impact damage applied to cars, etc. Maybe CFILTER_NOLOWCAR for ignoring cars which are low enough for the tank to crush.
MUST-CODE: MED: Improved torsion-from-rotation function. Current problem with handbrake turns is that Vroadr.y becomes zero/negative, causing wheel*Vwheelr.y to become zero/negative and the car to stop at 90 degree rotation to its direction of travel; wheel*Vroadr.y coefficient is far too dominant!
MUST-CODE: MED: Fix driving up/down slopes!
MUST-CODE: MED: Train collision checks
CODE: MED: Investigate train friction value. Too low?
MUST-CODE: MED: Fix engine torque values for existing cars. Tank engine only starts losing power once it's past its RPM limit!
???
Profit!