0.

0 Table of contents
1.0 : Preface
1.1 : Introduction

2.0 : Folder structure

2.1 : car.ini
2.2 : suspensions.ini
2.3 : suspensions.ini continued

3.0 : tyres.ini
3.1 : tyres.ini continued

4.0 : drivetrain.ini
4.1 : engine.ini

5.0 : Disclaimer
5.1 : Process outline
5.2 : Suspension geometry
5.3 : Suspension geometry continued

6.0 : Advice for engines

7.0 : Introduction to simulation tires

7.1 : Considerations for tire parameters
7.2 : Advice for developing simulation tires
1.0 Preface

Due to the wealth of questions regarding beginning or becoming proficient in creating

physics for cars specifically in Assetto Corsa, and the lack of proper documentation in
an easy-to-access source, I’ve decided to write this document. The purpose of this
document is to serve as a source for basic documentation of key physics files and to
offer some more meta-focused advice for creators. I am the creator of several car
physics modifications for Assetto Corsa, so I believe I have enough insight to deliver a
basic understanding of the systems of Assetto Corsa and the physics creation process,
but you should take anything written by random people on the internet with a grain of
salt. I have no qualifications and you shouldn’t be deluded into thinking I have. I will
mainly be focusing on creating physics for roadcars, but the same method should be
applicable to anything.

Due to the amount of lines in Assetto Corsa’s physics files (and the fact I’m making this
for free), the first releases will focus on only key features that are widely misunderstood.
Further documentation is not promised and there are some basic things still missing.

I would like to make acknowledgements about all of the people who helped me on the
way in learning simulation and real car physics, you know who you are. I’d also like to
thank the authors of many great books for providing resources to learn a sound
understanding of vehicle dynamics from, many of which will be mentioned later as
useful reading material.

Special thanks to Ilja Jusupov of Custom Shaders Patch and Content Manager fame for
revitalizing Assetto Corsa and to mclarenf1papa for developing the extended physics
features offered via Custom Shaders Patch. It is unlikely existing modders would have
enough motivation to go on without their contributions.

Arch
1.1 Introduction

As a physics creator of simulation vehicles, your goal is to obtain real-world information

about the vehicle, from now on referred to as “data”, interpret it correctly and input it into
the simulation as correct parameters in order to produce an intended input-in, output-out
behavior.

A simplified model of creating car physics could be as follows: Look for data -> calculate
parameters from the data -> input into the ini files -> test and verify -> back to
beginning.

The simulation is sufficient enough that accurate parameters are required and are able
to produce reasonably accurate behavior. In the case that accurate parameters cannot
be determined with complete certainty, as is the case when creating most car physics in
the context of an amateur hobbyist, educated guesses must be made. Currently there
does not exist enough information to realistically determine every parameter with
certainty, particularly for tires, so there will inevitably be some differences in parameters
between different car physics creators. However the large majority of the car should be
created on the basis of acquiring more accurate information and striving to implement it
correctly into the simulation.

Assetto Corsa is an empirically based tire load and slip simulator. The tire is a
pseudo-brush model with currently a single load and slip contact point determined by a
radius from the center of the tire dimensions. The tire has a spring and damping rate
and there are various parameters to control the behavior of the tire which we will go
over later. The tire can also wear and is subject to temperature behavior which can be
expanded with the use of Custom Shaders Patch.

Coupled to the tire is an unsprung mass element, which attaches to a sprung mass
element via a spring-and-damper system. Location of the tire in relation to the sprung
mass element, from now on referred to as “chassis”, is accomplished via several
suspension type options. Suspensions in Assetto Corsa are kinematically solved, which
means that you must input in coordinates for joint locations and the program will
generate behavior from them.
As the physics creator you must also specify stiffness rates for the corner springs, the
stabilizer bars (Commonly referred to as anti-roll bar or ‘ARB’), the corner spring
dampers, the packers, bump and rebound rubbers, from now on referred to as “packers”
and “bumpstops”, and possibly heave springs and any possible future additions.

Assetto Corsa is currently a hard-body simulation, which means that the chassis does
not deflect or introduce its own springrate onto any elements. The suspension links
have a specified, very stiff, currently fixed springrate and are able to deflect somewhat,
but you should not consider suspension elastokinematics (For example the deflection of
soft rubber elements like slide bushings on the joints of control arms in the suspension
geometry) to be a significant theme of Assetto Corsa’s simulation. Simple controllers for
a rear wheel steering system and active stabilizer bars are also available.

A simplified parameter based brake-torque system is available alongside (quite lacking)

temperature behavior. The use of Custom Shaders Patch will make possible an object
based brake-torque system and an expanded temperature behavior. There are also
simple controllers for some of the brake behavior.

Power generation is accomplished via look-up table files for torque input in Nm (newton
meter) and specific gear ratios can be chosen. Simplified turbocharger behavior is also
available. Assetto Corsa currently offers a simplified pseudo-mechanical differential
model for torque splitting capabilities, and rear-wheel, front-wheel and all-wheel
drivetrains. Simple controllers for some of the behavior of drivetrain and differential
elements are also present. A few look-up tables are also available to control the
behavior of the throttle pedal input in relation to torque generation.

A simple but effective force location based aerodynamics model is also present, and
with the use of Custom Shaders Patch, more specific aerodynamic look-up tables called
‘aeromaps’ can be implemented.

Various physics parameters may also be changed from a list of predetermined

parameters in-game via a specific menu, from now on referred to as the “setup”.
 2.0 Folder structure

The physics files necessary to produce vehicle behavior are located inside of a folder in
the car directory called “data”. It can also appear encrypted into the .acd format used by
Assetto Corsa.

Cars are stored in assettocorsa -> content -> cars. Car folder names MUST be input in
all undercase letters and must not contain spaces, input such as “example_car” in order
to avoid unintended bugs in the interface or other features of Assetto Corsa.

A typical car directory will contain the folders “animations, data, sfx, skins, texture, ui”
and the files “body_shadow, collider, driver_pase_pos.knh, logo, .kn5 file(s) for the car
3D and tyre_X_shadow files”. With Custom Shaders Patch, a folder called “extension”
can also be created for more configuration functionality.

We will be focusing on the “data” folder in this document, as it contains all of the
physics-related files.

Additionally, other tools provided by the developers of Assetto Corsa can be found in
assettocorsa -> sdk -> dev such as “ksSusEditor”, a basic suspension geometry viewer
which is compatible with DWB and STRUT layouts.
2.1 car.ini

car.ini is the central file for the car which determines basic parameters for visuals,
physics and interface. I will provide a basic explanation of the important physics related
lines.

[HEADER]
“VERSION” controls the version of the car that the engine will load. It does NOT
represent the development version of the car. Acceptable inputs are 1 or 2, with 2 being
preferred as it introduces various features. With Custom Shaders Patch, extended-1 or
extended-2 may also be used and are necessary to enable extended physics features,
from now on referred to as “Cphys”. Recommended input is extended-2.

[_EXTENSION]
“REQUIRED_VERSION” provides the minimum allowable CSP version that the car may
load in with. Input is the CM CSP ID. For example, CSP version 0.1.73 is “1430”. Not
necessary, but recommended if using features not introduced in older versions.

[INFO]
“SCREEN_NAME” controls the name of the car in some interfaces. Uppercase and
lowercase characters may be used alongside numbers, but some special characters
may be limited.

“SHORT_NAME” is an alternative name that is used for in-session naming of the car.

[BASIC]
“GRAPHICS_OFFSET” moves the VISUAL sprung mass of the car, the “body”, in
relation to the wheels. The body is referenced to the center of gravity, or “CG” of the car.
The GRAPHICS_OFFSET must be adjusted every time a change to the CG is made.
Input is in meters. Width, height, depth will be the standard format used by Assetto
Corsa dimensions.

“GRAPHICS_PITCH_ROTATION” rotates the body. Input is in degrees.

“TOTALMASS” determines the mass of the sprung and unsprung masses + driver, but
NOT fuel. Other fluids should be included. Input is in kilograms, kg.
“INERTIA” determines the SPRUNG inertia of the car in the form of a dimension box
that has mass specified by TOTALMASS. Unsprung mass generates its own inertia
separately. You must NOT input in the total car box dimensions. A solver to solve for
sprung inertia from total car inertia has been developed and may be shared in the
future. Input is in meters. Typical values are smaller than the physical constraints of the
vehicle.
Example: BMW E30 1.450,1.260,4.200 total, 1.179,1.339,4.149 sprung.

[CONTROLS]
“FFMULT” controls the car-specific gain for the Force Feed Back, from now on referred
to as “FFB”. Steering forces are generated via simulation of forces at the rack-end
positions and depend on the situation of the car and relevant suspension geometry.

“STEER_ASSIST” is a gamma function for load-based effects of FFB. It does NOT

determine powersteering or anything similar. Values other than 1.0 should generally be
avoided. The default setting is 1.0, or linear.

“STEER_LOCK” controls the in-cockpit steering wheel rotation of the car physics. It
must be input in as the real-world value and does not need to be matched to the user’s
simulation peripheral wheel. The input is from center to one side, so divide the total
range by 2 to solve for STEER_LOCK. Input is in degrees.

“STEER_RATIO” controls the effective steering ratio and is used in solving the
roadwheel’s steering angle. The real-world rack’s value should be entered if in doubt.

“LINEAR_STEER_ROD_RATIO” must be input manually and is used in solving the

roadwheel’s steering angle. You should reverse the value if the car steers in the wrong
direction, as it is dependent on the location of the steering rack, in front or behind the
wheel center.
The definition is meters of rack travel per degree of steering wheel steering *
STEER_RATIO.

[FUEL]
“CONSUMPTION” controls engine fuel consumption. The hint inside of Kunos car.ini
reads “fuel consumption. In one second the consumption is
(rpm*gas*CONSUMPTION)/1000 litres”.

“FUEL” controls the starting fuel amount that the car loads in with. Input is in liters.

“MAX_FUEL” controls the maximum fuel capacity. Input is in liters.

[FUELTANK]
“POSITION” controls the position of the fuel mass relative to CG. Input is in meters.

[RIDE]
“PICKUP_FRONT_HEIGHT” controls the display ride-height inside of setup and is used
by ride height rules. It is referenced from CG and the unit is meters. It does NOT control
anything related to the physics. “PICKUP_REAR_HEIGHT” is the above, for the rear
height.

[RULES]
“MIN_HEIGHT” controls the minimum allowable setup ride height as determined by the
above. Input is in meters. Including the MIN_HEIGHT line is not recommended due to
some issues with the ground plane calculation.

[PIT_STOP]
“TYRE_CHANGE_TIME_SEC”, the hint inside of KS car inis reads “time spent to
change each tyre”. I will repeat the hints for each line in this section.
“FUEL_LITER_TIME_SEC” “time spent to put 1 lt of fuel inside the car”
“BODY_REPAIR_TIME_SEC” “time spent to repair 10% of body damage”
“ENGINE_REPAIR_TIME_SEC” “time spent to repair 10% of engine damage”
“SUSP_REPAIR_TIME_SEC” “time spent to repair 10% of suspension damage”
2.2 suspensions.ini

suspensions.ini is the file which determines most parameters for the sprung and
unsprung mass, placement of the wheels and suspension linkages, stiffness of the
springs and dampers etc.

[HEADER]
“VERSION” controls the version of the suspensions that the engine will load. It does
NOT represent the development version of the car. Acceptable inputs are 1 through 4,
with 4 being preferred as it includes latest features. Recommended input is 4.

[_EXTENSION]
“TORQUE_MODE_EX” controls the version of internal force calculation used by Cphys.
Acceptable inputs are 0 through 2.

0 produces vanilla behavior, while 2 is corrected behavior for DWB, ML and STRUT
suspensions. 1 should not be used as it is a faulty implementation. Input 2 is
recommended when using accurate suspension geometry. Note that AXLE suspension
does not require internal force correction. Note also that only drive internal forces are
affected; axles not driven will not suffer from issues.

“FIX_PROGRESSIVE_RATE” is a fix for progressive spring rates via Cphys.

“USE_DWB2” toggles various more comprehensive Cphys DWB suspension features

on or off. Inputs are 0 for off, 1 for on.

“DAMPER_LUTS” toggles look-up table functionality for dampers with DWB2. Inputs are
0 for off, 1 for on.

[BASIC]
“WHEELBASE” controls the longitudinal dimension between the front and rear axle.
Input is in meters.

“CG_LOCATION” controls the distribution of the SPRUNG MASS over the wheels. It is
NOT the total car CG. Input is percent, for example 50% = 0.50.
[ARB]
“FRONT” controls the WHEELRATE of the front ARB. Input is in N/m.

“REAR” controls the WHEELRATE of the rear ARB. Input is in N/m.

“EXTEND” controls Cphys functionality for the ARB. Inputs are 0 to 1. FRONT and
REAR are SPRINGRATES when used with Cphys.

“FRONT_MOTION_RATIO” controls the motion ratio of the front ARB when used with
Cphys. Input is in %, with 1.0 being 1:1. An MR of 1.0 may be used if wheelrates are to
be retained as the input.

“REAR_MOTION_RATIO” controls the motion ratio of the rear ARB when used with
Cphys. Input is in %, with 1.0 being 1:1. An MR of 1.0 may be used if wheelrates are to
be retained as the input.

[FRONT]
“TYPE” controls the suspension type used. Acceptable inputs are “DWB, STRUT” and
for the rear “AXLE, ML” may be used as well.

“BASEY” controls the sprung CG height. It can be thought of as the position the
“suspension” connects to the “chassis”. A negative BASEY produces a positive CGH.
The formula is RADIUS - BASEY. Bear in mind that the loaded tire radius should be
used for accuracy. Input is in meters.

“TRACK” controls the lateral dimension between the left and right tire contact patch,
when the camber angle is 0 degrees and the suspension is at design height. Input is in
meters.

“ROD_LENGTH” controls the suspension height. A ROD_LENGHT value which

matches up with the suspension travel value will result in the suspension loading in at
the design height, or the height that the coordinate points for the arms are inputted in
and all of the lines are referenced from. Suspension travel is the amount of static spring
deflection for that wheel, from now on referred to as “SUSTRVL”. Input is in meters, with
more negative being compression, from now on referred to as “bump”, and more
positive being extension, from now on referred to as “rebound”.
“HUB_MASS” controls the mass of the unsprung portion for one wheel. With AXLE, it
controls the portion for both wheels. Take care to include the actual unsprung
distribution, as parts of the assembly are shared with the sprung mass, such as struts
and driveshafts.

NOTE: STRUT suspension types convert per-corner 20% of HUB_MASS as a sprung

mass, placed probably between STRUT_TYRE and STRUT_CAR. Additionally, 20% of
original HUB_MASS per corner is added as sprung mass at the sprung CG. You must
enter a higher HUB_MASS value for STRUT to attain intended values.
Example: 40kg per corner = 40 / 0.80 = 50 HUB_MASS.
Refer to Car Analyzer.

“RIM_OFFSET” controls the wheel offset. Effectively, it adds the amount to the X
coordinates of the suspension linkages. Take care to adjust TRACK after adjusting
RIM_OFFSET if the intention is to “change wheels”. Not required, but it simplifies
suspension creation, as you can use one set of coordinates with multiple wheels.

“TOE_OUT” controls the setup toe angle. It is lateral displacement of the tie rod. Input is
in meters. Currently not functional for AXLE.

“STATIC_CAMBER” controls the setup camber angle. Bear in mind that camber
adjustment will not move TYRE suspension points, it simply pivots the wheel. Input is in
degrees. Currently not functional for AXLE.

“SPRING_RATE” controls the WHEELRATE of a single corner spring on that axle, with
the value being shared for left and right. Input is in N/m.

NOTE: STRUT suspension types apply a pseudo-motion ratio to the SPRING_RATE,

approximately equivalent to Actual Motion Ratio * SPRING_RATE. The “motion ratio” is
kinematically solved. Actual SPRING_RATE can be checked via referring to SUSTRVL
in apps.
Example: 0.90 * 20000 = 18000.

“PROGRESSIVE_SPRING_RATE” controls the progressive WHEELRATE. Input is in

N/m/m. Can and commonly should be paired with SPRING_RATE.

“BUMP_STOP_RATE” controls the WHEELRATE of the PACKER_RANGE and

BUMPSTOP_UP/DN. Bear in mind that STRUT and AXLE suspensions currently have a
hardcoded 500000 N/m~ rate for the BUMPSTOP entries.
“BUMP_STOP_PROGRESSIVE” controls the progressive WHEELRATE of the
PACKER_RANGE. Input is in N/m/m.

“BUMPSTOP_UP” controls the deflection on the wheel, referenced from design height,
until impacting the bump rubber. It should commonly be placed farther than
PACKER_RANGE. Input is in meters.

“BUMPSTOP_DN” controls the deflection on the wheel, referenced from design height,
until impacting the rebound rubber. Input is in meters.
“PACKER_RANGE” controls the position of the packer (such as a plastic packer for
racecars, or rubber bumpstop for roadcars) along the SUSTRVL wheel deflection.
The formula is SUSTRVL + intended gap to packer from the intended height. For
example 0.100 + 0.030 = 0.130, resulting in a 30mm packer gap if your static spring
deflection is 100mm. Input is in meters.

“DAMP_BUMP” controls the wheel damping rate for bump travel when the wheel is
traveling slower than the DAMP_FAST_BUMPTHRESHOLD value. Input is in N/m/s.

“DAMP_FAST_BUMP” controls the wheel damping rate for bump travel when the wheel
is traveling faster than the DAMP_FAST_BUMPTHRESHOLD value. Input is in N/m/s.

“DAMP_FAST_BUMPTHRESHOLD” controls the transition point, or “knee” for the bump

damping to change from SLOW to FAST. Input is in m/s.

“DAMP_REBOUND” controls the wheel damping rate for rebound travel when the wheel
is traveling slower than the DAMP_FAST_REBOUNDTHRESHOLD value. Input is in
N/m/s.

“DAMP_FAST_REBOUND” controls the wheel damping rate for rebound travel when
the wheel is traveling faster than the DAMP_FAST_REBOUNDTHRESHOLD value.
Input is in N/m/s.

“DAMP_FAST_REBOUNDPTHRESHOLD” controls the transition point, or “knee” for the

rebound damping to change from SLOW to FAST. Input is in m/s.

[REAR]
Same as above.
2.3 suspensions.ini continued

Location of suspension links are accomplished via an X, Y, Z coordinate system,

referenced from the wheel center of one corner. For example 0.100, 0.050, -0.250.

The suspension coordinates are relative to the wheel center, meaning that a position of
0, 0, 0 would be positioned in the middle of the wheel. The suspension points should be
built where they are when the car is sitting at its design height, which refers to the
location when ROD_LENGTH equals SUSTRVL.

Positive values on X refer to positioning towards the car center, while negative values
refer to positioning away from the car center.

Positive values on Y refer to positioning above the wheel center, while negative values
refer to positioning below the wheel center.

Positive values on Z refer to positioning in front of the wheel center, while negative
values refer to positioning behind the wheel center.

NOTE: AXLE suspension type references the points from the center of the axle instead
of the wheel.

To start off, use the in-game “suspensions” app to analyze the positions of links and
become comfortable with viewing assemblies. knSusEditor is also suitable for viewing
DWB and STRUT suspensions. I will provide a list of the lines used for each suspension
type. The order of the lines is not particularly important, but I suggest sticking to one
standard format.
TYPE=STRUT
STRUT_CAR=
STRUT_TYRE=

WBCAR_BOTTOM_FRONT=
WBCAR_BOTTOM_REAR=
WBTYRE_BOTTOM=

WBCAR_STEER=
WBTYRE_STEER=

TYPE=DWB
WBCAR_TOP_FRONT=
WBCAR_TOP_REAR=

WBCAR_BOTTOM_FRONT=
WBCAR_BOTTOM_REAR=

WBTYRE_TOP=
WBTYRE_BOTTOM=

WBCAR_STEER=
WBTYRE_STEER=

TYPE=ML
JOINT0_CAR=
JOINT0_TYRE=

JOINT1_CAR=
JOINT1_TYRE=

JOINT2_CAR=
JOINT2_TYRE=

JOINT3_CAR=
JOINT3_TYRE=

JOINT4_CAR=
JOINT4_TYRE=
[AXLE]
“LINK_COUNT” controls the amount of TOTAL suspension links used for AXLE
suspensions. Due to high stiffness of suspension links, an input of 5 is not
recommended and 4 should be used instead. 5 results in frequent, unintended binding
of the suspension assembly.

“TORQUE_REACTION” controls the torque reaction of AXLE suspensions. NEEDS

MORE DETAILED DOCUMENTATION.

“ATTACH_REL_POS” controls the “motion ratio” for the corner springs and dampers for
AXLE suspensions. It causes a change in wheelrate when the suspension rolls. The
formula is Length between links / TRACK. For example 1.500 / 2.400 = 0.625

“LEAF_SPRING_LAT_K” controls the lateral resistance springrate of the axle. Unsure if

functional, unsure about input.

The suspension linkage inputs are as follows:

J0_CAR=
J0_AXLE=

J1_CAR=
J1_AXLE=

J2_CAR=
J2_AXLE=

J3_CAR=
J3_AXLE=

J4_CAR=
J4_AXLE=

Inputs may be excluded depending on LINK_COUNT input. For example excluding J4 if

using LINK_COUNT=4.
[GRAPHICS_OFFSETS]
I shall copy the hints present in KS suspensions.ini files.

“WHEEL_LF” ;Left front graphical offset of the wheel positioning in the x axis (width). +
is left - is right movement

“SUSP_LF” ;Left front graphical offset of the suspension positioning in the x axis (width).
+ is left - is right movement

As above for RF, LR and RR.

3.0 tyres.ini
Tyres.ini is the file which controls parameters for the load and slip characteristics,
stiffness, damping, resistances, heating etc. of the tire. Assetto Corsa uses a
semi-empiric tire model, meaning that you as the physics creator must input parameters
and pre-determined look-up tables and the model will generate behavior from them. You
do not however directly input physical characteristics like dimensions of the sidewall, or
softness of the rubber or whatever such as in some other tire models. However there is
a large degree of interactivity within the tire behavior and complex situations can be
generated from relatively few inputs resulting in relatively high telemetry correlation of
car behavior.

[HEADER]
“VERSION” controls the tire model version that the engine will load. Multiple inputs are
available, but the current relevant one is 10. The suggested input is 10.

[VIRTUALKM]
“USE_LOAD” toggles load effects for “virtual kilometers”, which is a function of tire slip
distance. It is used for wear effects namely. Acceptable inputs are 0 and 1. The
suggested input is 1.

[EXPLOSION]
“TEMPERATURE” controls the tire popping temperature of the tire. While tire internal
structures do deteriorate at around 200~ celsius, temperatures of 450c and beyond
have been observed for the surface and close to surface layers. It is better to bias high
than low, due to the relative simplicity of heat interactions compared to reality, the
average temperature of the tire may rise quite high compared to what it perhaps would
be in the inner surfaces of the tire when for example drifting or doing other extreme
temperature generating activity with complex rubber behavior. Input is in celsius.

[COMPOUND_DEFAULT]
“INDEX” controls the default tire that is loaded in the setup. The first tire set is entry 0,
while the second is 1 etc. Bear in mind that currently, default pressure for the tire is
loaded only from index 0 regardless of what is selected.
[FRONT]
Add ” _X” for every further compound. Example: FRONT_1 for the 2nd tire set in the
index.

“NAME” controls the display name of the tire in setup. Uppercase and lowercase letters
may be used alongside numbers, but some special symbols may not display
correctly.“SHORT_NAME” controls the display name of the tire in the leaderboard, and
is also used for some automatically generated behavior with Cphys. Standard inputs are
“SV, ST, SM, S” and such. However anything can be input. It is currently recommended
to stay to standard inputs if possible so that auto-guessed Cphys rain behavior will work
correctly.

“WIDTH” controls the width of the skid decal of the tire. It does not control any physical
characteristics. When in doubt, input the section width. Input is in meters.

“RADIUS” controls the UNLOADED tire radius at nominal inflation. Bear in mind that
real tires may differ from the theoretical spec. It does not control any physical
characteristics such as stiffness or flex. Input is in meters.

“RIM_RADIUS” controls the collision radius for the simulated wheel for use with ground
collision. It does not control any physical characteristics such as stiffness or flex. KS
suggestion is to add one inch to the wheel radius spec, as the wheel diameter is
measured from barrel to barrel, but there is some additional lip distance. Input is in
meters.

“ANGULAR_INERTIA” controls the rotational inertia for the tire + wheel + brake disc
assembly, and any other rotating unsprung mass. Input is in kg*m^2.

“DAMP” controls the damping rate of the tire at nominal load and inflation. Input is in
N/m/s.

“RATE” controls the vertical springrate of the tire at nominal load and at the inflation
pressure specified in PRESSURE_STATIC. If you change your PRESSURE_STATIC
but wish to maintain the same springrate, adjust RATE while respecting
PRESSURE_SPRING_GAIN. Input is in N/m.

“DY0, DY1, DX0 and DX1” are outdated load sensitivity values used in old tire models.
They are necessary to be included for the tire to load properly, but are unused in the
current suggested version.
“WEAR_CURVE” specifies the look-up table to be used for wear characteristics. The
format is vkm | grip percent, in whole numbers. The LUT must be included in the data
folder. Example : tire_example_wear.lut Example LUT format:

0 |100
30 |90

“SPEED_SENSITIVITY” controls the mechanical and chemical speed sensitivity of the

tire. Good value is generally around 0.002.
force/(speed_sensitivity * ((sin(slip_angle_rad) * m/s)^2+(cos(slip_angle_rad) * m/s *
slip_ratio)^2)^(0.5) + 1.0)
OR
1/( total tire slip in m/s * speed_sensitivity + 1)

“RELAXATION_LENGTH” controls the relaxation length input used by the complex

interaction of the tire model. It is not comparable to real-world relaxation length values.
Typical values range around 0.0700 to 0.1200. The input is in meters.

“ROLLING_RESISTANCE_0” is the constant parameter used in RR calculations.

“ROLLING_RESISTANCE_1” is the squared velocity parameter used in RR

calculations.
pgain=1+(PRESSURE_IDEAL / current_pressure - 1) * PRESSURE_RR_GAIN
RR=(ROLLING_RESISTANCE_0 + ROLLING_RESISTANCE_1 * V^2) * pgain
Divide by 1000
Load Curve Helper has a solver.

“ROLLING_RESISTANCE_SLIP” controls rolling resistance gain from tire slip. Typical

values in KS tires are observed to be 20~ times too high. Decent value for Cphys is
around 800~, perhaps lower for vanilla such as 300~.

“FLEX” is an outdated tire profile flex input. Must be included for the suggested tire
version to load, but is otherwise unused.

“CAMBER_GAIN” controls the amount of camber thrust. It is a slip angle shift from
camber angle. Typical value of 0.100 is acceptable.
CAMBER_GAIN * sin(camber)
“DCAMBER_0” is the first parameter used by formula based camber sensitivity.

“DCAMBER_1” is the second parameter used by formula based camber sensitivity.

The formula for formula based camber sensitivity is :

1 / (1 + camberRAD*DCAMBER_0 - camberRAD^2 * DCAMBER_1)

Where camberRAD refers to the absolute value of the camber angle in radians.

“DCAMBER_LUT” specifies the LUT used for LUT based camber sensitivity. Example :
tire_example_camber.lut. Lut input is angle in degrees and output is grip in percent.
Example LUT format :

-1|1.04
0|1
1|0.975

“DCAMBER_LUT_SMOOTH” toggles smoothing for DCAMBER_LUT on or off, with 0

being off and 1 being on.

“FRICTION_LIMIT_ANGLE” controls the peak lateral slip angle at nominal values to

attain maximum grip. It interacts with many parameters such as load and should be built
for the FZ0 you have chosen. Thus choosing a wise FZ0 is also necessary. Input is in
degrees.

“XMU” is an outdated friction parameter. Must be included for the suggested tire version
to load, but is otherwise unused.

“PRESSURE_STATIC” controls the nominal cold pressure of the tire. Actual cold
pressure will vary based on temperature conditions. RATE is referenced from this
pressure. Input is in psi.

“PRESSURE_SPRING_GAIN” controls the springrate gain of the tire from the

PRESSURE_STATIC value for every one psi. Value is in N/m.

“PRESSURE_FLEX_GAIN” controls the flex gain of the tire from the

PRESSURE_IDEAL value for every one psi. Typical KS values are backwards, and
input should be negative. Tires typically gain compliance with higher pressure. NEEDS
MORE DOCUMENTATION.
“PRESSURE_RR_GAIN” controls the RR gain of the tire from the PRESSURE_IDEAL
value for every one psi. NEEDS MORE DOCUMENTATION.

“PRESSURE_D_GAIN” controls the grip loss for every one psi under and above
PRESSURE_IDEAL. For example a value of 0.004 means a loss of 0.4% DY and DX
for every one psi deviating from optimal pressure.

“PRESSURE_IDEAL” controls the optimal pressure for grip and is referenced by many
lines. The input is in psi.

“FZ0” is the reference load for much of the tire behavior, and the load where values are
referenced from. Avoid very low or high values. Tire behavior is relatively nonlinear, so
data attained at a load of 1000N might not apply at all at a load of 10000N. Aim for a
good average in respect to the car conditions. Safe values when using custom tire load
curves are around 3000 to 6000. The input is in Newtons.

“LS_EXPY” is a lateral load sensitivity exponential parameter used by formula based

load sensitivity.

“LS_EXPX” is a longitudinal load sensitivity exponential parameter used by formula

based load sensitivity.

“DX_REF” is the reference mu for the longitudinal load sensitivity formula, referenced
from the FZ0 value.

“DY_REF” is the reference mu for the lateral load sensitivity formula, referenced from
the FZ0 value.

Formula based load sensitivity should be avoided as it is incapable of producing

acceptable grip characteristics.

“DY_CURVE” specifies the LUT used by LUT based lateral load sensitivity. Load values
should be spaced evenly to avoid dangerous smoothing conditions. The LUT input is
load in N and the output is mu.
Example: example_tire_195_55_15_lateral.lut
Example LUT format:

0|1.275
3000|1.10
6000|0.95

“DX_CURVE” is the same as above, except for longitudinal load sensitivity.

“FLEX_GAIN” is a parameter in the contact patch flex equations. It cannot be compared

to real-world values as the interactivity is high within the tire model. It is additive to the
slip angle. The author is unaware of the specific formula(s) used by the engine. An
approximation would be that FLEX_GAIN gets added to FRICTION_LIMIT_ANGLE
when load is 2*FZ0, however this is not completely truthful. The log outputs relevant
information for determining the practical effects. The effect appears to be somewhat
linear. Typical values for radial tires appear to be around 0.0500 to 0.1200. Most radial
tires perhaps end up around 0.0700 to 0.1000. KS values are somewhat non-compliant
compared to current understanding.

“FALLOFF_LEVEL” controls the grip the tire will produce when slipping at infinite SR. In
vanilla, the falloff curve is shared between lateral and longitudinal. It is input in percent,
such as 0.80 = 80%.

“FALLOFF_SPEED” controls the speed of grip dropoff after peak slip angle.

“CX_MULT” controls the optimal slipratio longitudinally. 1.0 = same as lateral. Above 1.0
= lower than lateral. Values below 1.0 are not typically recommended because tires are
typically stiffer longitudinally than laterally.
Formula: tan(slip_angle_opt) / CX_MULT.

“RADIUS_ANGULAR_K” is an input in the formula for tire radius growth in millimeters

from angular speed. Formula: RADIUS_ANGULAR_K * angularVelocity in rad/s.

“BRAKE_DX_MOD” controls how much more longitudinal grip the tire has in braking
compared to acceleration. Formula is (1+BRAKE_DX_MOD)*D. For example, a value of
0.02 will provide +2% D when braking, and a value of -0.02 will provide -2% D when
braking. Typical values for real tires seem to be around -0.02, but it is an argued topic. It
is possibly down to individual tire characteristics.

“COMBINED_FACTOR” controls the combined lateral + longitudinal slip grip gain.

Modern tires have been observed to not lose lateral grip when some longitudinal stress
is applied. A value of 2.0 is standard ie: traction “circle”, while values above 2.0 will
square it out, providing more grip in combined situations. Real tires appear to have
somewhat high values, perhaps around 2.1 to 2.3, but this information is subject to
change. It is possibly down to individual tire characteristics.

CPHYS FEATURE DOCUMENTATION WILL COME LATER IN LIMITED FORM.

[REAR]

Same as above.

3.1 tyres.ini continued

[THERMAL_FRONT]
Add ” _X” for every further compound. Example: THERMAL_FRONT_1 for the 2nd tire
set in the index.

HEATING FEATURE DOCUMENTATION WILL COME LATER.

[THERMAL_REAR]

Same as above.
4.0 drivetrain.ini
Drivetrain.ini is the file which controls parameters for the transmission and differential.

[HEADER]
“VERSION” controls the version of the drivetrain that the engine will load. It does NOT
represent the development version of the car. Acceptable inputs are 1 through 3, with 3
being preferred as it includes latest features. Recommended input is 3.

[TRACTION]
“TYPE” controls the driveline type. Acceptable inputs are “RWD, FWD, AWD, AWD2”.

[GEARS]
“COUNT” controls the amount of gears used. Maximum amount unknown.

“GEAR_R” controls the gear ratio for the reverse gear with any possible overdrive, but
without final gear. Input example: -3.382

“GEAR_1” through “GEAR_X” control the gear ratios for forward driving gears with any
possible overdrive, but without final gear. Input example: 3.321

“FINAL” controls the final gear ratio. Input example: 4.363

[DIFFERENTIAL]
“POWER” controls the maximum lock % for the limited-slip differential in the
acceleration direction. Inputs are in %, so that 50% = 0.50.

“COAST” controls the maximum lock % for the limited-slip differential in the deceleration
direction. Inputs are in %, so that 50% = 0.50.

Note: 1.0 in both POWER and COAST is an exception for a welded or spool-type
differential where the wheels are coupled directly together with no differential action.
Use an input such as 0.999 for a “100%” clutchplate differential. Bear in mind also that
real-world open differentials typically have some effective lock %, perhaps from 3 to
10% depending on friction ie: more when turning.

“PRELOAD” controls the amount of differential preload. Input is in Nm

[AWD]
“FRONT_SHARE” controls the AWD front mechanical split in full % values. For example
50% = 50. Acceptable inputs are 0 to 100.

“FRONT_DIFF_POWER” same as “POWER” but for AWD type.

“FRONT_DIFF_COAST” same as “COAST” but for AWD type.
“FRONT_DIFF_PRELOAD” same as “PRELOAD” but for AWD type.

“CENTRE_DIFF_POWER” same as “POWER” but for AWD type.

“CENTRE_DIFF_COAST” same as “COAST” but for AWD type.
“CENTRE_DIFF_PRELOAD” same as “PRELOAD” but for AWD type.

“REAR_DIFF_POWER” same as “POWER” but for AWD type.

“REAR_DIFF_COAST” same as “COAST” but for AWD type.
“REAR_DIFF_PRELOAD” same as “PRELOAD” but for AWD type.

[AWD2]
“FRONT_DIFF_POWER” same as “POWER” but for AWD2 type.
“FRONT_DIFF_COAST” same as “COAST” but for AWD2 type.
“FRONT_DIFF_PRELOAD” same as “PRELOAD” but for AWD2 type.

“CENTRE_RAMP_TORQUE” controls ramp-up torque for Viscous center differential.

Unit is Nm per rad/s of differential speed between front and rear axle.

“CENTRE_MAX_TORQUE” controls maximum torque for Viscous center differential.

Input is in Nm, at the wheels after gearing.

“REAR_DIFF_POWER” same as “POWER” but for AWD2 type.

“REAR_DIFF_COAST” same as “COAST” but for AWD2 type.
“REAR_DIFF_PRELOAD” same as “PRELOAD” but for AWD2 type.

Bear in mind that AWD2 is only capable of 0/100 to 50/50 split, but not FWD biased.
CPHYS FEATURES

[DIFFERENTIAL]
“VISCOUS_FACTOR_1” is a parameter used in viscous differential calculation via
Cphys since CSP version 0.1.73.

“VISCOUS_FACTOR_2” is a parameter used in viscous differential calculation via

Cphys since CSP version 0.1.73.

“VISCOUS_FACTOR_EXP_K” is a parameter used in viscous differential calculation via

Cphys since CSP version 0.1.73.

“VISCOUS_FACTOR_EXP” is a parameter used in viscous differential calculation via

Cphys since CSP version 0.1.73.

Formula:
viscousTorque =
(VISCOUS_FACTOR_1*SPEED_DIFFERENCE_RAD+VISCOUS_FACTOR_2*SPEED
_DIFFERENCE_RAD^2+(VISCOUS_FACTOR_EXP_K-VISCOUS_FACTOR_EXP_K/E
XP(VISCOUS_FACTOR_EXP*SPEED_DIFFERENCE_RAD)))

Output is in rad/s | Nm.

Note: Viscous coupling effect can and should be overlaid with a weak mechanical
coupling effect in typical assemblies from the open differential inside.

Refer to Car Analyzer for a visual grapher tool to solve Viscous Coupling torques with.

MORE DOCUMENTATION ADDED LATER

4.1 engine.ini
[HEADER]
“VERSION” controls the version of the engine that the engine will load. It does NOT
represent the development version of the car. Acceptable input is 1.

“POWER_CURVE” controls the TORQUE look-up table file loaded.

Units are revolutions per minute and torque in Nm, at the wheels after drivetrain loss.
Example: engine_example.lut.
Example LUT:
0|100
1000|125
2000|150

“COAST_CURVE” controls the coast torque method. Recommended input is

“FROM_COAST_REF”.

[ENGINE_DATA]
“ALTITUDE_SENSITIVITY” controls altitude sensitivity of the engine. Non-functional in
vanilla. Default value is 0.1.

“INERTIA” controls moment of inertia of the engine. Typical value is 0.100 - 0.150.
Input is in kg*m^2.

“LIMITER” controls the engine limiter RPM. Setting an RPM of 0 will remove the limiter.

“LIMITER_HZ” controls the frequency of power cut when hitting LIMITER. Input is in Hz.

“MINIMUM” controls idle RPM.

“DEFAULT_TURBO_ADJUSTMENT” controls default pressure amount when using

adjustable turbos. Example: 0.5 = 50% boost.

[COAST_REF]
“RPM” controls reference RPM for coasting torque.

“TORQUE” controls coasting torque at reference RPM. Input is in Nm.

[TURBO_0]
Can have multiple. First in index is 0, second is 1 etc.

“LAG_DN” controls the filtering amount for turbo lag when spooling down. 1.0 being fully
filtered, 0.0 being unfiltered. Typical values are over 0.980 - 0.990, lag increases
dramatically for every 0.01 when nearing 1.0.

“LAG_UP” same as above for spooling up.

“MAX_BOOST” controls the maximum theoretical boost pressure.

“WASTEGATE” controls the maximum allowed boost pressure. It is not the real-world
wastegate spring pressure or anything similar, but a practical max pressure.
Refer to “car physics” app to troubleshoot in-game boost pressure.

Formula: T*(1.0 + boost). When pressure is 1.0, torque is 2.0.

Example: 100*(1.0 + 1.0) = 200.

“DISPLAY_MAX_BOOST” is the boost pressure considered to be maximum by display

apps.

“REFERENCE_RPM” controls the theoretical earliest RPM where MAX_BOOST can be

attained, at full throttle with no lag.

“GAMMA” controls the gamma function used for the turbo pressure buildup under
REFERENCE_RPM.

“COCKPIT_ADJUSTABLE” toggles in-cockpit pressure adjustability, with 0 for off and 1

for on.

Useful resource for building engines: https://acstuff.ru/u/torque-helper/ by Ilja Jusupov.

[COAST_DATA]
“COAST0”, “COAST1” and “COAST” are unused legacy lines which must be included to
load the engine.ini.

[COAST_CURVE]
“FILENAME” controls the LUT used for coasting torque curve. Input may be invalid
without an existing file. Commonly “coast.lut”. Unsure if functional. Needed to load
engine.ini.

[THROTTLE_RESPONSE]
“RPM_REFERENCE” controls RPM where “LUT” curve is in effect.

“LUT” controls LUT curve used by 2D throttle map. Linear interpolation between
throttle.lut and LUT is done until RPM_REFERENCE. Refer to log for table.
Example: throttle2.lut.
LUT example:
0|0
50|50
100|100

NOTE: throttle.lut controls first throttle curve and is required. Throttle.lut may also be
used alone without [THROTTLE_RESPONSE] section. Input is %|% in full values.
LUT example:
0|0
50|75
100|100

[DAMAGE]
“TURBO_BOOST_THRESHOLD” controls amount of boost before engine takes
damage. Example: 1.10

“TURBO_DAMAGE_K” controls damage per second when over

TURBO_BOOST_THRESHOLD. Depends on (boost - threshold).
Example: 5

“RPM_THRESHOLD” controls RPM before engine takes damage. Example: 9000

“RPM_DAMAGE_K” controls engine damage per second. Example: 1

5.0 : Disclaimer

The author urges that the recipient of this message upon reading this document does
not take any of the information presented in the document too literally or mistake it for
professional advice. The author is not an expert, but they have created car physics
packages for simulation applications long enough to have perhaps something of value
to give to the new creators who are eager to improve but cannot find the resources.

The reader is free to disagree with anything in the document, but the reader is urged to
consider their stance and the basis for it. The stances on meta-textual concepts
discussed in the document are subject to change in opinion as more information is
acquired and could very well all be wrong. However they have an apparent basis in
producing acceptable simulation accuracy for hobbyist use in real-time car simulations
such as Assetto Corsa.

The reader should bear in mind that this is largely one person’s approach and view, and
it will change from one creator to the other. However there are many useful suggestions
for physics creation if simulation accuracy is an importance which will be covered in this
document.
5.1 : Process outline

The very first thing one must do when beginning the physics creation process is to
consider their subject. Not every car is created equal when it comes to amount and
fidelity of data present. Ideally one should make a car that they own themselves and
have access to and have acquired detailed data for from road testing and K&C
(Kinematics and Compliance) testing, dynamometer testing and wind tunnel testing.

This is not always a reasonable expectation. Most of my cars to now have been
roadcars with a reasonably large following and aftermarket resources such as testing
and measurements publicly available and relatively comprehensive documentation of
the mechanisms in the workshop manual of the car provided by the manufacturer. If one
is willing to accept somewhat lacking simulation accuracy, one can make a car that has
less resources available to aid in the process. Choosing to do will place a somewhat
higher stress on having sound fundamental understanding and a good “sense” for
reasonable values used by real manufacturers. I would suggest the reader picks a
relatively popular car that they can find data for, but in the beginning, you should
primarily make something that interests you enough to commit to it. Physics creation is
an ever-iterative process so you can always come back to the car later.

Useful resources for gathering data are primarily the manufacturer’s own publications,
such as workshop manuals and user manuals. Aftermarket information is also useful, as
sometimes the company has measured or acquired data themselves from the standard
car and reference it in relation to their products. Forums also occasionally have
resourceful users post their own measurements or findings so don’t ignore them. Do
exercise extreme caution when interpreting data, even if it is manufacturer data. Not all
of it is necessarily in the context you assume it to be in, such as suspension height, tire
size, occupants in the vehicle etc. Take care to determine what is the reference point for
the information. Look online for EPC (Electronic Parts Catalog) websites, or try to find
paper parts catalogs, as they can sometimes give hints for parameters such as “Oh, this
car shares this stabilizer with this one” and occasionally have dimensions, stiffnesses
and such reported. Don’t ignore video publications such as Best Motoring either, the
Japanese ones specifically have a lot of good data in them and footage by competent
drivers.
Don’t make the mistake of believing in too many generalizations. There are common
design principles and good solutions especially for roadcars, but there can be a large
variation between how cars are designed and how they behave even within the same
manufacturer’s vehicle lineup and especially between manufacturers.

Much of the same applies to tires. While they all generally follow similar trends and
logic, strange data anomalies can be present. Don’t be too afraid to deviate from
“acceptable” values, but be ready to make an argument for your case. “To me it feels
like” is not a terribly convincing argument, but sometimes it is embarrassingly close to
the reasoning used for some tire parameters. One should refrain from making “opinion
based” changes to suspensions of cars especially when good data is present and tread
with utmost care when seemingly going against data. The data should always be
thought of to only be to a certain degree of accuracy, and interpretation by the creator is
just as important. Do not for example mix up the torsion springrate of a stabilizer bar
when it is simulated in a Finite Element Analysis, when it is tested on an actual chassis
and when it is tested mounted to the wheel. Inputs in Assetto Corsa are primarily wheel
rates, which means that factors such as motion ratio and installation stiffness must be
taken into account and any additional rates such as resulting from rubber slide bushing
twisting should be taken into account.

Do not be afraid to use ; to quote out information inside of the .ini files. Good things to
quote out are the springrates under the wheelrate, dimensions of the stabilizers, motion
ratios for springs and dampers, stroke distances of the damper and height of the bump
rubber and such. I would recommend against including too much information into the .ini
files at first as it is very volatile in the beginning, but it is a good idea later. I also advise
against making multiple car versions early on in the process as you will need to update
all of them at the same time when basic things are changed.
Make sure to create a central data index folder for the car on a local drive. It’s a good
idea to make folders for manufacturers or racing series and not just one big folder with a
hundred cars in it like I do. Make a folder for the specific car or chassis family and place
it into the manufacturer folder. Create a Quick Access entry or hotlink or whatever for
your car folder, and for the “cars” folder in the AC directory. You will be clicking on both
of them often. It is a good idea to keep the car folder open on a separate screen, as
well. Make folders for “front suspension”, “rear suspension”, “wheels and brakes”,
“manual”, “documents” and the like in your car folder. With experience you will learn
what is most useful to go in what folder. Don’t haphazardly throw important references
into one big folder. Name your files in an understandable manner. Make a .txt file or two
where you can copy data, forum posts and the like into as a lightweight text format for
quick reference. If you do any manual calculations, split them all up into their own files
or preferably use a spreadsheet for automated calculations.
A good starting point for the car parameters would be to get total mass and unsprung
mass, wheelbase, track, CGH, inertia and tire radius to reasonable values first. Do not
focus on finding very specific information at first, just the general dimensions and
masses from an internet search or a dozen is fine. They will change later on anyway
when more specific data is found. Make sure to document any and all data you find in
text files or something similar with links to the source. Saving webpages to your local
drive is also a good idea. Make sure to save documents and do not rely on them being
hosted online. Save videos locally if they contain much relevant data or good footage.
Save any and all relevant images of the suspension components and the tires. Take
snips of relevant pages out of manuals, books and videos and save them in the relevant
folder for quick access.

Depending on your resources you will need to conduct testing in different ways. At
worst, just look at video of the car driving and gauge it against yours, or ask drivers of
the real car what they think. This process however varies in accuracy very much and
rarely results in anything very useful being uncovered. Telemetry analysis is a
somewhat better method, but not terribly practical for most cars, as most cars do not
have telemetry available. My preferred method is to just find more data and keep
gauging the reliability of data. You should fill gaps in understanding of the car with other
data. You can make an educated guess about some parameters based on what you see
and hear, but it is always preferable to get some hard numbers. Although the simulation
is very sound and capable of good correlation, beware that some minor aspects are not
modeled or might not work as intended or how you believe they work which will all add
up in the end.

Ideally you will not so much know what is right in your car, but more so you will know
what is wrong and how. The tires will often ultimately be a bigger source of error than
anything in your suspension kinematics, drivetrain or aerodynamics. A very good
practice is to try to get intended behavior out of the same thing in two different contexts,
such as a shared suspension geometry and shared tires mounted on another car with
similar, but different parameters. Manufacturers often re-use suspension layouts and
some parts, which will give a good opportunity for cross-correlating parameters. Real
examples are the rear suspension geometries of the S-chassis of cars compared to the
same generation’s Skyline cars, or the rear suspension geometries of the JZA80
compared to the JZZ30.
5.2 : Suspension geometry
When enough relevant information to somewhat form a car has been gathered,
personally I move on to making the suspension geometry. Laser scans of the
coordinates is one of the best resources, so are CAD models from the manufacturer.
High-definition schematics of the suspension in orthogonal views are also useful. A
basic method is to determine a pixel size from a known dimension, like the brake disc
diameter, then measure the amount of pixels from the center of the wheel or another
reference point and convert it into a metric value. For example if you know that 2px
equals 1mm, you will calculate 1 / 2 = 0.5mm per px. That is your constant which you
use to multiply your pixel measurements with.
I will not go over suspension kinematics in much detail in this document. However I
greatly recommend everyone to read “Suspension Geometry and Computation” by John
C. Dixon to gain an understanding of suspension kinematics. “Race Car Vehicle
Dynamics” by Milliken also includes much of the calculations and definitions used in
vehicle physics. While there are good technical articles out there, I would somewhat
recommend against reading random resources on the internet, as much of it gets some
important things wrong, and many of it is outright false. Hence I will not comment very
much on suspension kinematics myself, as I would just be spreading more false
information with all likelihood.

A practical and easy way to gain an elementary understanding is to move the points
around in knSusViewer, remember what kind of orientation change was made then
check the response in the ingame telemetry apps. There are also several suspension
kinematics tools online which you should play around in and note the changes.

At worst, a photo-reference method may be used to create suspension geometries. With

more sophisticated photo-matching methods which I will not outline in this document,
somewhat good results can be attained. It is advisable however to at the very least find
some known angles or dimensions to anchor the new data to. Do not expect too much
accuracy out of this method unless you happen to find extremely right-angles of the
assembly. Pay great attention to what position the assembly is in; fully drooped, without
a car mass, with a full load on it etc. Strive to design the geometry at the design height
of your choosing, usually the position the geometry is in without any occupants or fuel
loading it, but with the load of the car on it.

Ultimately, precision to the hundredth of a degree is not necessary, especially on

road-going vehicles equipped with rubber bushings that deflect from forces (Precisely
measuring such a geometry may prove challenging to begin with if the components are
worn) but you should take care to keep outputs within acceptable limits. I try to stay
within at least 0.1deg accuracy for angles in any given suspension position, but laser
scans have produced larger deviation than that in practice for some aspects. Given
insufficient data and a choice needing to be made, try to find a solution that produces
the least compromise to the car behavior as possible. It is highly recommended to use
TORQUE_MODE_EX=2 when building DWB, ML and STRUT geometries so that they
can be replicated closely. Great compromises that demand high levels of suspension
kinematics understanding must be made when building for EX=0 and the result will be
flawed in a way or another.
When building the front geometry, match the STEER_LOCK and STEER_RATIO values
in car.ini to the real-world values and ensure that your geometry is accurate. Adjust
LINEAR_STEER_ROD_RATIO until you are within the specifications for steering
angles. Even laser-scanned roadcar geometries may barely fall within the
specifications, and modified cars at a different suspension height or with geometry
modifications will likely differ from the idealized wheel angles. Don’t put too much
importance on matching the spec exactly, specifically for the inside wheel (The spec is
often +- several degrees for a reason) but an accurate geometry should nonetheless
provide closely matched angles. More complicated geometries such as Multilink strut
setups or the Super Strut layout may somewhat require a compromise in steering
angles to maintain more important characteristics. With Cphys it is possible to decouple
the strut axis from the steering axis (as is correct for real kinematics) in STRUT
suspensions which can allow better matching of steering and kinematic curves. The
user must have “MacPherson struct FFB adjustment” ticked inside of Content Manager
under FFB TWEAKS for FFB behavior to be corrected and more accurate geometries to
be used.

When building ML suspensions, there are some things which must be remembered.
Firstly, there are some bugs with alignment not always setting correctly when first
loading into the game. Also, PACKER_RANGE is not functional unless inputted into
setup.ini. BUMPSTOP_DN also does not function correctly, nor does BUMPSTOP_UP.
However ML produces more or less correct suspension curves and responds to
TORQUE_MODE_EX, so it is an useful tool for determining some basic suspension
behavior and curves via the in-game apps or setup menu. I would currently advise
against using ML suspensions and recommend a DWB which mimics ML behavior to be
built instead. I will not outline in detail how to go about doing that in this document.

For AXLE suspensions, real-world geometries may be inputted. However bear in mind
that the links are very stiff. A link count of 5 links is likely to bind. It is advisable to match
the kinematics with a 4-link setup if possible. If the upper arms are not laterally
separated very much between AXLE and CAR points, you may combine them into one
arm and not suffer any kinematic downside. Bear in mind that PACKER_RANGE is not
functional for AXLE.

DWB layout is very flexible and many suspensions can be built in it. Acceptable
replications of trailing and semi-trailing arm, swing-axle, multilink and other uncommon
or antiquated geometries may be accomplished to a good degree of accuracy when
using EX=2. It can also replicate MacPherson Strut layouts to reasonable accuracy if
there is need to use some DWB2 features with it.
Note that many modern roadcar suspension geometries incorporate elastokinematics
into their design which is currently not a feature of Assetto Corsa. ctrl_4ws.ini may be
used to hack in some rear-wheel steering effects for a loose replication of some
compliance steer, but most of the time such effects can be ignored without significant
issues. Note also that subframe location is fixed and will not deflect due to bushing
stiffness either. Hence effects like wheel hop are not particularly present.

Combination suspension types such as Z-axle as present in the E36/E46 and

Out-of-wheel DWB with swan-neck and separated steering axis such as in the Skyline
GT-R are also possible to be replicated to reasonable accuracy if using DWB. Pay great
attention to the nature of the joints and how they behave. In some cases, some creative
placement of links may be needed to more accurately match behavior. Try to acquire
real-world curves for the suspension to inform the design process. Remember that
laterally locating an entire A-arm without changing its dimensions or inclination will not
significantly change the curves in most cases, but may allow closer matching of the
Steering Axis Inclination and Scrub radius.
5.3 : Suspension geometry continued

When beginning geometry building, the first thing you should determine is the most
suitable TYPE to be used. Commonly DWB is most capable, but MacPherson,
Chapman and other struts should be usually done via STRUT. Completely solidly
coupled rear geometries may be created with AXLE, but beware that beam-axles are
NOT completely solidly coupled and may be best served by a DWB implementation
using the rear ARB to produce coupling similar to the torsional stiffness of the
beam-axle. Trailing arms are best suited to be made via DWB. Multilink geometries with
a short-arm long-arm arrangement are also best suited to be made via DWB. A good
understanding of DWB suspension will allow a reasonable implementation of many
suspension types. When building geometries, remember to place the suspension points
inside of the actual balljoint and slide joint center. The geometric angle of the arm
section is not relevant. Search for images of cutouts of balljoints and bushings to get a
better idea.

When building ML geometries, the process will be highly specific to the exact type and
arrangement of arms and generally some kind of compromise must be made. A simple
explanation would be that the aim is to match the dynamic rotation centers and swing
arm lengths as best as possible. It is recommended to first build the geometry with ML
layout to verify its characteristics, then build a DWB version for better compatibility and
less bugs.

Many ML geometries separate a set of arms, or all arms, to attain curves which are
physically difficult or impossible to attain with DWB due to physical or kinematic
constraints. In some cases you may want to place a TYRE joint at the intersection point
of the separated arms’ axis and move the relevant arms towards the new center while
maintaining real swing-arm lengths, although that is not always possible as there is not
necessarily any point in space where intersection happens. In that case it may be
beneficial to focus on the swing-arm lengths and angles. If the vertical separation of the
separated TYRE points is very high, a delicate compromise by changing Y and X of
TYRE and perhaps CAR points may need to be found. Take care that arm angles in roll
do not become strange, despite seemingly matching centers when at design height.
Example of what is meant by finding the intersection point of arm axis. Beware that it is
a 3D location and cannot be accurately discerned from a limited amount of images.
Pictured geometry is S14 rear.

Example of actual implementation with relatively few issues. Some accuracy in a limited
deflection range was sacrificed to maintain much better accuracy when lowered
significantly or fitted with “subframe spacers”.
Pictured geometry is 180SX rear.
When building typical Trailing or Semi-trailing arm geometries, DWB layout should be
used. You should locate the CAR side points and weld the upper and lower wishbone
CAR points to the true joint locations. Do not weld the TYRE points, I suggest adequate
separation on height for upper and lower balljoints. The amount of separation should not
be relevant to the kinematics, but an ample amount of separation may perhaps assist in
avoiding some unintended forces. The center point of the TYRE points should be the
wheel center on Y; the apparent angle of the trailing arm assembly is not relevant, only
the geometric angle. The toe arm should be placed along the instant axis ie:
WBCAR_STEER on the inboard CAR joint and WBTYRE_STEER on the outboard CAR
joint. Beware that in older CSP versions telemetry and UI shows erroneous camber and
toe values for suspensions with caster gain, typically toe-out when actual curve is toe-in.
Use external software to confirm. A new calculation for setup screen values (not apps)
is included in CSP 0.1.76+. The kinematics are correct however.

Example of an actual STA implementation with relatively few issues. EX=2 was used
and is recommended, otherwise the distribution of anti-squat to anti-lift is very skewed.
Pictured geometry is M3 E30 rear.
As a side-note, do not be alarmed if you notice the trailing-arm geometry producing
what appears to be extreme behavior in acceleration and braking. Trailing arm
geometries have typically low anti-squat and high anti-lift. This is further magnified by
the assembly losing anti-squat when the rear squats, and gaining anti-lift when the rear
lifts. Specifically, trailing arm geometries equipped on a driven rear axle will experience
high amounts of squat, and commonly squat on brake application as well. While this
behavior appears erroneous, it is consistent with the kinematics and real-world
experimental testing.

Experimental curves from Nissan, comparing acceleration to suspension deflection.

Vehicle A is a rear-wheel drive passenger car equipped with Multilink rear suspension,
while Vehicle B is a rear-wheel drive passenger car equipped with Semi-trailing arm rear
suspension.

Note: The squat and lift resistance caused by anti-effects applies to internal forces such
as the hub trying to rotate from torque. It is not congruent with external forces and
should not directly influence the distribution of wheel loads in a pure accelerating or
braking situation. In simple English, how much the car squats or lifts is not an indicator
of load transfer.
Note also that due to relatively low compliance of Assetto Corsa’s suspension arms and
lack of subframe bushing simulation, wheel-hop and other such effects are not present.
6.0 Advice for engines
It would be advisable to begin by finding manufacturer quoted power and torque values
and dynamometer charts for your specific engine. Make sure to do the conversions for
units properly. Assetto Corsa uses Nm wheel-torque inputs. There are some things
which must be considered when creating engines from dynamometer charts, specifically
for turbocharged engines. I will produce an imagined scenario using
https://acstuff.ru/u/torque-helper/ which is also a suitable tool to build curves with.

The above image shows a curve which could be typically produced experimentally from
a dynamometer measurement of a turbocharged engine. However such a curve is likely
not truthful when inputted into Assetto Corsa. Turbochargers, especially larger ones,
have a noticeable lag when increasing pressure. Dynamometer curves will inherently
feature this lag in the curve. The practical end result is that turbocharged engines built
by following dynamometer data very literally are lacking in torque below the spool RPM.
It is necessary to build the curve so that it produces the intended result inside of Assetto
Corsa.
The above curve shows an example of a more suitable curve for use inside Assetto
Corsa which will produce a torque curve closer to the intended one.

Take care not to fall into the trap of trying to match a dynamometer curve very literally.
Even the most precise dyno will have variance on a per-run basis, with the curve
changing shape subtly and power/torque peaks and valleys changing in magnitude and
position. There can also be significant magnitude differences between any given dyno,
especially if the measurement was done in different conditions. Manufacturer’s claimed
curves can sometimes be more truthful than dynamometer results, although be wary of
abstractions or idealizations. Bear in mind also that drivetrain losses are not constant
and will typically increase somewhat linearly with increasing RPM, so a wheel-torque
graph might have percentually higher low-end torque compared to a crank-torque
graph. Bear in mind also that throttle application may not be immediate in real dyno
runs, while in Assetto Corsa, the curve should be built with the assumption of 100%
throttle application at all times.
7.0 Introduction to simulation tires

As I am not a simulation application developer and have not created tire models, I will
not talk about the technical specifics of tire modeling too much. I am wholly unqualified
to make statements about that. At most I have an “academic understanding” of tire
modeling, which means I don’t have any understanding. I’m sure I mischaracterized
AC’s model earlier as well, that is fine. Correct me later. However I will offer a
perspective on how to think about tire simulation in a practical manner within the context
of a real-time driving simulator for hobbyist use. Perhaps some of my views will aid
creators in extracting more promising behavior with better tire parameters and avoid
some headaches and misconceptions. I will not discuss telemetry correlation as I only
have limited experience in doing it.

Due to the limited amount of available tire data and even less actually representational
and usable tire data, unfortunately in most cases many parameters in tires must be
decided based on trends or guesses and not actual empiric data for the specific
application. Luckily reasonable tires can be created by following trends, and
applications can even be created to automatically create various reasonable tire
parameters from relatively few inputs.

By narrowing down the likely range for acceptable parameters and establishing some
generalized trends, a method can be developed for creating simulation tires which
provides acceptable results with minimal guesswork. There is enough data to ascertain
some common value ranges and theoretical models have been produced which mirror
real tire outputs rather closely, so hardpoints to base guesses from do exist. However
one should exercise great caution when analyzing tire data or trends. As I said earlier,
tire characteristics are relatively nonlinear and interactive, with relationships existing
that are not present in Assetto Corsa, such as optimal pressure not being a strict
constant in real tires. Surely more such interactions exist. Pay great attention to the
testing method as well, not every method produces as realistic results as others. Tire
data is not absolute and true in all cases.

Assetto Corsa’s tire model has one main benefit over many other real-time simulation
models, namely that the amount of inputs is relatively low but the behavior generated is
quite dynamic and appropriate in most situations. A classical type of tire model such as
Pacejka would require look-up tables and inputs for several more parameters, many of
which no good data exists for.
7.1 Considerations for tire parameters

Earlier I said Assetto Corsa is a tire load and slip simulator. While not entirely true, as
the behavior of the unsprung mass and chassis are considered and there are various
other effects such as driving torque or aerodynamics, they all ultimately influence the
tire slip or load, which are the deciding factors for “grip”. Even alignment changes
effectively only change the load sensitivity or slip characteristics of the tire.

The tires are the only contact point with the road (hopefully!) and thus decide the
attitude and acceleration of the masses. While the suspension and chassis play an
extremely significant role in car behavior by affecting the distribution of loads between
the tires and axles and should not be ignored or skimped on, the tire is what will actually
decide the car attitude for most situations. Apart from the event where the car is in flight,
the tires are always a significant influence on the car attitude; and even in the air they
may produce gyroscopic effects which will influence the car attitude. Although steering
forces are solved via rack-end forces in Assetto Corsa, the tires produce the majority of
relevant forces for FFB and thus will greatly shape the impression of driving any given
vehicle.

The aim in tire development then could be said to be to optimize the tire load and slip
behavior to closely match reality. Indeed in a controlled scenario like a constant radius
steady-state turn, matching car behavior might be possible via multiple methods. The
great difficulty comes in matching transient characteristics (which refer to the period
when outputs of the tire are changing rapidly such as on corner turn-in) and only sound
tire parameters can replicate most tire characteristics accurately. Unfortunately transient
characteristics of tires are not practical to measure so it is difficult to say what is correct
and what is not.

Luckily, steady-state characteristics are not that difficult to reasonably match to reality,
so much of the difficulty in finding tire parameters comes from matching the transient
effects. It is difficult to change only the transient behavior of the tire without also
influencing the steady-state behavior. There may be multiple parameter combinations
which all provide sufficient correlation within a limited scope of analysis. Flawed
assumptions for parameter ranges might make efforts futile, so finding a “likely best
option” for tire parameters is one main goal of tire development for a car package
7.2 Advice for developing simulation tires
I will not cover telemetry correlation with much detail in this document as I mostly have
secondhand and consultation experience in the area. Instead I will offer some practical
advice for creating a reasonable tire parameter set within Assetto Corsa, although the
meta-textual advice mostly transfers over to any other sound empiric real-time tire
model. I’m going to focus on road and sport tires, racing tires can have quite varying
characteristics and need to be approached on a case by case basis with more scrutiny
than road tires.

A reasonable first step would be to establish some hardpoints to compare to, such as
any tire data you do have, lateral G figures from skidpad testing and statements from
the manufacturer or any bodies that have performed testing on the tire. Data should be
thought of to be representational at best, although in my experience sound tire data and
skidpad G figures do more or less line up with trends. A reasonable starting point to
apply parameters to would be a well implemented tire similar to the type and
dimensions of yours, although there are not that many well implemented tires available
publicly for Assetto Corsa as of writing, so the process of generating a baseline set of
parameters might be difficult. The suspension geometry and parameters for the
unsprung mass and chassis should be filled in accurately before in-depth creation
begins. With experience this guideline can be circumvented somewhat.

In a case where everything must be made from scratch, I recommend setting

FRICTION_LIMIT_ANGLE to something reasonable like 8 - 10deg, CAMBER_GAIN to
an acceptable generic value of 0.100, ROLLING_RESISTANCE_SLIP to 0 and using
standard KS values or commonly accepted values when unsure. Check that the RATE
when the tire is at PRESSURE_IDEAL is not far out of bounds of expectations.
A reasonable starting value would be 250,000 - 300,000 N/m until data is found or
better estimations can be made. A DAMP value of 500 N/m/s is acceptable.
ANGULAR_INERTIA of 1.0 kg*m^2 may be used for now. It is perhaps also reasonable
to set CX_MULT to 1.0, BRAKE_DX_MOD to 0.0 and I suggest adopting a generic
heating model to start off with. It would also be helpful to input a relatively accurate
RADIUS value to your tire, for the purposes of having a reasonable effective gearing
ratio and car height.
Once the parameters are in somewhat reasonable bounds, begin by changing the DX
and DY values until cornering G when at hot temperature and pressure is +- 5% from
the measured value. The purpose of this is to ensure the tire is close to the intended
performance and driving impressions are not very skewed by over or
under-performance. I suggest matching your load curve to one from a tire with similar
dimensions and changing the global grip amount 1% at a time. Note that modern radial
tires likely have quite significantly less slope on the longitudinal load curve than the
lateral one.* Refer to the included tire load curve tool for more advice.

*Subject to change, can vary greatly from one tire to another.

Once tire performance is reasonable, if the suspension can be thought of to be

representational, reconsider the FRICTION_LIMIT_ANGLE value. As a gross
generalization, tires with less lateral strength might perhaps operate at higher peak slip
angles. Angles even around 10deg have been observed for older performance tires
however, so do not take pure grip as an indicator for how “tight” a tire is. Note that flex
effects must be taken into account.

Approximate values for FRICTION_LIMIT_ANGLE can be obtained via comparing the

steering angle trace of the real car to the sim car, assuming linear steering racks and
correct implementation of the rest of the physics. Due to the relatively low lateral grip
loss of real tires, this may not be very accurate, so I personally suggest to stay above
0.25deg increments for changes if precise data is not present. If more compliance is
needed in the tire behavior, I would suggest raising FLEX_GAIN first before raising
FRICTION_LIMIT_ANGLE very much. Pay attention to CX_MULT as well; some tires
might require noticeable deviations from 1.0. Perhaps as a guideline, tighter
performance tire types might need >1.0, while older more compliant types might need
<1.0.

COMBINED_FACTOR of even 2.20 might be reasonable for modern tires, but it will
depend on what DY and DX curve you are using. Possibly, older tire types such as road
bias tires might not have very much COMBINED_FACTOR, but it is an apparent
commonality for modern radial tires. Beware of setting COMBINED_FACTOR too high
to account for insufficient DX.
For a generic road tire, perhaps a LEVEL of 0.75 and SPEED of 3.0 is a suitable
starting point.
Do not ignore the effects of heat when comparing behavior to real life. Surface
temperature changes rapidly mid-corner, and while some car layouts might not see very
much dynamic balance change from braking to apex and apex to exit, it is significant for
layouts with very biased load or tire-use bias, particularly front-drive, front engine and
rear drive, rear-engine vehicles.

Unfortunately heating behavior in vanilla is unsuitable, so compromises might need to

be made for vanilla heating models. Due to relative complexity and nothing being set in
stone for Cphys heat, documentation is not currently included. Please refer to cars that
the author has created, particularly the resources uploaded to the Girellu github.

For most use cases for roadcar type vehicles, vanilla style heat may be used without
dramatically influencing the subjective experience of using the car, but it is worth
studying Cphys heat once basic tire parameters are well understood by the reader.