An A.M.

POOR MAN’S PRODUCTION presents

the ASSETTO CORSA MODDING

MANUAL 3.0
1
WRITTEN BY:

A.M.

WITH CONTENTS FROM:

A.M., Kunos developers, official Assetto
Corsa forums and others

The ACMM 3.0 -

Assetto Corsa Modding Manual 3.0 - is an

A.M. POOR MAN’S PRODUCTION

Edition 0.34 pre-alpha Revision C

2022 | 2023

© 2023 A.M. All rights reserved.

2
 To all Modders and Kunos developers

I hope AC2 will be compatible with the AC engine, the official content, the mods and the amazing projects users and communities brought to this simulator.
Imagine driving the Bizzarrini GT 5300, the true heir of the Ferrari 250 GTO, on the 1970 Le Mans, in a physics engine with an improved tyre model, dynamic weather, more realistic damage with glass shards and
metal chips, oil on the track, exploding tyres and vehicles with more than four wheels.
I’m not interested in a career path with driving licences and shiny trophies. I want to feel the thin, rubbery line of death. Modders raised the bar pretty high with AC, which now already looks like a gorgeous next-
gen title, even though it was born to be a simulator, not a game, always remember that.
Obviously AC will always be the best “game” I’ve ever played. A.M.
3
Preface

This manual is meant to be read in its entirety, more like a book than a “guide”, even if it aspires to become the latter. I think that whenever
you’re doing something in your life you should be aware of the full picture, otherwise your objective is missing. We tend to forget that every
part is connected to the others, and that’s where this work of mine comes in handy. It’s a collection (mind me the word) of information, well
organized, or at least organized the best way I could think of. But it follows a path, hopefully as linear as possible. The beginning will be (or
seem) simple, and going further and further our magnifying lens will be more and more focused on the details that the common user ignores
and doesn’t need.

I also wouldn’t recommend printing this text, as to make the huge amount of info fit into a smaller number of pages I often used very small
fonts, which would become unreadable on a piece of paper. My suggestion is to read it like an ebook, on your PC or your tablet, where you
can zoom the pages to your liking.

The main purpose of this document is to revise and expand the old “car Pipeline 2.0 ” made by Kunos, the creators of the Assetto Corsa racing
simulator, for a better clarification and explanation of all the procedures needed to make car and track mods for AC (latest release 1.16.4,
Ultimate Edition) from scratch, or with a conversion.

A brand-new track creation guide, with some help, will be produced for the first time. Also, a brief game user manual is being written and
expanded. I really hope this will be, if not the best, at least the most complete and organic guide to AC and its modding ever made.

I know that the popular AC Custom Shaders Patch mod exists. But I don’t know if I will include it. Being that project currently under
development it would be a bit difficult to keep track of everything. I might change my mind about this.

If you have any suggestion, find errors or have extra content that can be added, contact me with this email:
assettocorsathemanual@gmail.com (for serious purposes only), or join this discussion:
https://www.racedepartment.com/threads/ac-modding-manual-3-0.252064/

This project is currently in a WIP (Work-In-Progress) state, therefore it’s subject to changes. Any image, sentence, or paragraph is being
added, written down, revised, expanded or shortened, corrected and sometimes deleted, just like pencil on sheets of paper.
Highlighted text consists of reminders for me, or parts that are going to be modified soon; please don’t judge the micro-chaos of the document.
Do not rely too much on the cross-references to pages, sections, chapters, or paragraphs, in many cases they may be wrong or in the process
of being written!

I’d like to quote the following message here:

“Because my books are self-published, I am the researcher, the author, the proofreader, the editor, the typesetter, the illustrator, and the
publisher. To add to my struggles, English is not my mother tongue. As such, grammatical, typographical, and other forms of errors may seep
in, at places. For that, I apologise ahead of time. It is difficult to insert new text into a book this size, without also injecting minor editorial
errors, here and there. In order to reduce the entropy, I re-edit the entire text, regularly. But if you do find errors, drop me a line. […]
I do not write books like this one to make a living; I make my living by other means, so that I could have the spare time to write such books.
And I write not because I believe I have some special knowledge to impart, but because I enjoy sharing with others what little I know. […]
Teaching gives me the opportunity to probe deeper into the subjects and to fill holes in my own understanding thereof. And sharing ideas and
knowledge invigorates me. So, there you have it.” – Amen Zwa, Going Nowhere Fast in Assetto Corsa
Yours,

A.M.

4
 HOW TO READ THIS MANUAL

“You don’t have to teach us how to read.”

I know, but when I was a high school student and even prior to that, whenever I read a textbook I used to take notes, underline the most important parts to
remember them the day after, when I’d have had the test, which was always too late. But that’s enough about me, times change.

If you don’t take notes, someone else has to do the work for you, to make things easier (and to guarantee that you pass your exams). That’s why I adopted a
system to organize and highlight ideas, keywords and concepts. I find it quite efficient and effective, especially if you give yourself enough time to read the
entire work.

First of all, this book is split in five parts: PART 1 is a general manual about Assetto Corsa, PART 2 is about the creation of cars, PART 3 is about tracks,
PART 4 is CLASSIFIED, PART 5 is dedicated to coding apps and software mods. It’s truly simple. I might add more of them, but that is at my discretion.

Second, each PART is divided into Chapters. They’re numbered, and they constitute for the reader the logical handrail to follow. There is no doubt about it;
if you skip a Chapter, you will not be able to move forward and you will be stuck there, unless it consists of things you already know. This is because they
don’t represent only steps in a process, but more so in that they are interdependent.

Third, every Chapter has got several main Paragraphs. Sometimes you can follow them, sometimes you don’t need to. Their purpose is to introduce,
contextualize and define more specific information handled within them. They’ve got numbers too so you don’t get lost.

Finally, you have the little ones, the Paragraphs. Keep an eye on them, they can get quite beefy. Important stuff, stuff you shouldn’t ignore, stuff you forgot,
stuff you hid from yourself: there’s plenty here.

And what about paragraphs without numbers? Can I say those exist because I can’t really justify the use of four digits to enumerate them? To be fair, once
you start reading a Paragraph, everything should have the same importance. So their purpose is only to make things more clean, fresh, “cool”, like everyone
would their manuals to be like. I’m joking, however they’re not pointless.

Following this structure, you will often find colours, underlined or bold text. Let’s discover their meaning:

• A bold, dark blue colour text is adopted for file paths and folders (in the field of computer science), for example: %root%\assettocorsa\_CommonRedist
The only two exceptions to this rule are the DEVELOPMENT (DEV) and FINAL (FIN) project folders, that you will learn to recognize with a green bold text.
• Filenames will usually be red italic text. Example: suspensions.ini
• If there is something really important, you will see red bold text. If there is a key word, it will be black, to make it more visible:

“ The AC engine does not support 2 OBJECTS with the same NAME in the same model. ”

The colours will be inverted if the whole sentence is less important, but we want the key word to be highlighted anyway:

“ In order to have a working car mod, this folder and its contents are REQUIRED. ”

• Bold text of any colour is also used to distinguish the various items in particularly long lists of things. You can already see many examples in the GLOSSARY if you go to
the next pages.
• When you encounter magenta italic text it means that’s my personal, biased comment. After all, this book should be fun to some extent, right?
• Whenever black italic text is found, the focus is on the words themselves, which demand attention, both semantically, logically, syntactically and allusively. One wants to
give more importance to the declension and “tone” of the word, which influences its meaning, left to be guessed by the reader based on the context.
• Every picture (figure) in this manual shall be numbered (aside from covers and photo albums), following this example: Fig. 1.2. This will be its cross-reference too.
• Scattered throughout the document there are little Pro tips: their function is to give an explanation to things that usually people do the wrong way. They tend to become
reference points once you start having a global understanding of AC and its modding.
• Often you will find sections with the title FAQ. This stands for Frequently Asked Questions. Here you will get answers to questions you may have. They’re VERY useful. It’s
also where you will see the best of the worst errors made by newbie modders.

Here we have other rules I personally followed while writing this book. Maybe they’re useful if you want to produce a manual by yourself too.

• Avoid Comic Sans and Times New Roman-lookalike fonts no matter what. A light, modern font shall be used. Cambria Math is reserved to formulas when needed.
• Use Courier New for scripts and code fragments, being more programmer-friendly and old-school.
• The text of bulleted and/or numbered lists shall have a smaller font size to prevent the reader from getting lost on the page.
• Use as much as possible the blank page while adding useful information and keeping the formatting balanced. Footnotes and line spacings are there for a reason.
• There must always be captions under the images, no matter how short and concise.
• Intrigue the reader with details he or she does not expect to find. As a consequence, being inclusive and comprehensive is required. It is actually difficult, you know?
• Conclude the speech at the end of the page, whenever possible. It’s annoying and unsatisfying having to turn the page mid-sentence.
• Try to be positive even if you had a bad day at work. If you can’t, don’t write anything until a good mood is restored.
• If you have taken the time to read this, it makes you a better person, doesn’t it?

As your very first tip: when navigating this manual, the search bar of your ebook/pdf reader is your friend. Use it to find key words you’re interested into.

5
 INDEX

Welcome to Windows XP.

ABBREVIATIONS – GLOSSARY p.
PART 1: Assetto Corsa User Manual p.
PART 2: Car modding p.
Introduction p.
Table of Contents p.
PART 3: Track modding p.
Introduction p.
Table of Contents p.
PART 4: Software mods / apps p.

APPENDIX 1: Official cars list p.

APPENDIX 2: Official tracks list p.

6
 ABBREVIATIONS - GLOSSARY
These definitions are simplified and will give you only a general understanding of what we’re talking about.

2+2: Shorthand for cabin accommodation consisting of two full-size front seats and two small rear seats. The rear seats are unually only suitable for young children or adults
on short journeys only.
4x4: Shorthand for four-by-four, or four-wheel-drive (4WD). A four-wheel-drive vehicle has power transmitted to every road wheel.
24 Hours of LeMans: A 24-hour endurance motor race, staged annually at Le Mans, France, since 1923. It uses a circuit consisting of public roads that have been cordoned
off for the event.
ABS (Anti-lock Braking System): A braking system that stops the wheels from locking during braking, so the car can be steered away from danger in an emergency.
Absolute density: The absolute density refers to the theoretical air density at a given altitude according to the International Standard Atmosphere (ISA) conditions. The sea
level air density is assumed to be 1.225 kg/m3 or 0.0765 lb/cu.ft.
See Density.
Absolute pressure: The absolute pressure is equal to gage pressure plus the ambient atmospheric pressure. It is zero referenced against an absolute (perfect) vacuum.
Absolute pressure = gage pressure + ambient pressure.
The absolute pressure is used in Boyle’s Law for all calculations.
Absolute zero temperature: The absolute theoretical minimum temperature by international agreement at which all the molecular motion ceases is -273.15°C or -459.67°F
or zero on the Kelvin and Rankine scales. The absolute zero temperature is found where a thermodynamic system has lost its energy, the entropy is at its minimum value and
no more heat is available – it is at its absolute minimum.
Jacques Charles (1746–1823) a French physicist is credited with discovering circa 1787, the absolute zero temperature. Charles’ Law states the volume of gas is directly
proportional to its temperature. By plotting the volume of all gases versus temperature, Charles discovered the lines all converged at the same point on the graph indicating
-459.67 degrees Fahrenheit.
See Temperature.
Acceleration: An acceleration is the rate of change in velocity of an object moving in its reference system. Therefore, an increase in speed is considered acceleration.
Acceleration is directly proportional to the unbalanced force and inversely proportional to its mass. Reducing speed (decelerating) is a negative acceleration. Note that
changes of direction cause accelerations, but they are referred to as “internal”, or “apparent” (this will be clearer with forces).
Acceleration = change in velocity/time of velocity change. (a = Δv/Δt). (delta)
AC: Stands for Assetto Corsa, your racing simulator.
Active Suspension: Electronic-controlled method of automatically pitching the suspension for specific track bends or terrains (the latter for road vehicles).
Aerodynamics: The study of forces that come into play when the car has picked up speed, due to air.
Air dam: A metal or plastic “lip” at the lowest point of the front of a car that improves aerodynamics by keeping moving air from getting underneath, reducing drag and lift.
Air filter: A felt or paper component that cleans air of particles before it enters the engine.
Air-cooled engine: An engine that circulates air externally to cool hot components, usually asisted by a fan. Internal water-cooling is favored in modern engines.
Air suspension: A suspension system that uses inert gas or pumped air to keep the car stable on rough roads or fast corners.
Alternator: A small generator that converts the engine’s mechanical energy into an electrical current. The electricity it produces charges the battery and powers circuits for
lights, electric windows, and radios.
Angle of Slip: The angle between the direction of the wheels (front and rear) and the direction of travel of the vehicle.
Anim/anims: Short for animation/animations.
Anti-surge baffle: A plate that stops liquids from shifting position inside a reservoir, particularly an oil sump, as a result of the car’s movements.
Apex or Clipping Point: The nearest point a car gets to the inside of a curve in an ideal racing line.
API: An Application Programming Interface is a way for two or more computer programs to communicate with each other. It is a type of software interface, offering a service
to other pieces of software. A document or standard that describes how to build or use such a connection or interface is called an API specification. A computer system that
meets this standard is said to implement or expose an API. The term may refer either to the specification or to the implementation.
In contrast to a user interface, which connects a computer to a person, an application programming interface connects computers or pieces of software to each other. It is not
intended to be used directly by a person (the end user) other than a computer programmer who is incorporating it into the software. An API is often made up of different parts
which act as tools or services that are available to the programmer. A program or a programmer that uses one of these parts is said to call that portion of the API. The calls that
make up the API are also known as subroutines, methods, requests, or endpoints. An API specification defines these calls, meaning that it explains how to use or implement
them.
One purpose of APIs is to hide the internal details of how a system works, exposing only those parts a programmer will find useful and keeping them consistent even if the
internal details later change. An API may be custom-built for a particular pair of systems, or it may be a shared standard allowing interoperability among many systems.
The term API is often used to refer to web APIs, which allow communication between computers that are joined by the internet. There are also APIs for programming
languages, software libraries, computer operating systems, and computer hardware.

7
ARB (Anti-Roll Bar): Forms part of the suspension assembly and helps to support the car when cornering, by resisting the tendency for the body to roll.
Automatic (shifter): A clutchless transmission that will automatically select the appropriate gear for the driver.
Backbone chassis: A longitudinal, central structure supporting a car’s body, drivetrain, and suspension.
Balance: The degree to which a car has understeer or oversteer in a corner.
Beam front axle: A single suspension beam with a wheel on either end, attached to the car’s frame by coil or leaf springs.
Bearing: Component providing a support between the fixed and moving parts of a machine, allowing the free rotation.
Bertone: An Italian coachbuilder and design consultancy, operating between 1921 and 2014.
bhp (brake horsepower): Horsepower originally gave a measure of the energy output of steam engines in terms of the equivalent amount of pulling power provided by a
draft horse. In cars, “gross” bhp is a measurement of the power output of a standalone engine. “Net” bhp is an engine’s output after power has been sapped by ancillary
equipment, such as the alternator. Bhp is measured by applying a special brake to the engine crankshaft.
Big end bearing: The larger, lower bearing of the connecting rod that links the pistons to an engine's crankshaft.
Block: See cylinder block
Blown (engine): A general term for an engine that has its power boosted by a turbocharger or a supercharger.
Bore: The usually cylindrical hole within which an engine’s piston moves. Also refers to this cavity's diameter.
Brake Balance: The bias of braking power between the front and rear tyres.
Braking Distance: The distance between the point where braking starts and ends.
Bubble-top: A car roof that is notably rounded, made from glass, Plexiglass, or metal.
Bug (software) / Buggy / Debugging: It is an error, flaw or fault in the design, development, or operation of computer software that causes it to produce an incorrect or
unexpected result, or to behave in unintended ways. It can be caused by a particular asset (in AC for example cars and tracks).
Bugs in software can arise from mistakes made in interpreting users' requirements, planning a program's design, writing its source code, and from interaction with humans,
hardware and programs, such as operating systems or libraries.
A program with many, or serious, bugs is often described as buggy.
The effects of bugs may be subtle, such as unintended text formatting, through to more obvious effects such as causing a program to crash, freezing the computer, or causing
damage to hardware. Other bugs qualify as security bugs and might, for example, enable a malicious user to bypass access controls in order to obtain unauthorized privileges.
Some software bugs have been linked to disasters.
The process of finding and correcting bugs is termed "debugging" and often uses formal techniques or tools to pinpoint bugs.
Bump Damper: An energy absorbing device, fitted between the wheel and car body, which resists upward movement by the wheel.
Butterfly valve: A disc that pivots along its diameter within a duct, forming a valve that can be opened and closed in order to regulate the flow of air into an engine
component, such as a carburetor.
Cabriolet: A two-door car, although usually not a sports car, with a fabric-covered removable or folding roof.
Camber: Slight upward curve to the centre of race track.
Camber Angle: Camber angle is designed to make a tyre work as effectively as possible when a car is going through a corner. Negative camber is applied so that when fully
stressed a tyre will be as close to perpendicular as possible.
Camshaft: A rotating shaft featuring cam lobes that open and close the engine’s inlet and exhaust valves. It can operate the valves indirectly by pushrod (usually in an
overhead-valve engine) or directly (in an overhead-cam engine). Two camshafts per cylinder are used in double-overhead-camshaft engines -one for the inlet valves, and
one for the exhaust valves.
Carburetor: A device on older engines in which fuel and air are combined, producing a combustible mixture, which is then ignited in the cylinder.
Catalytic converter: A device fitted to the exhaust of cars running on unleaded gasoline. It uses a chemical catalyst (including precious metallic elements such as platinum)
to stimulate reactions that convert harmful gases into (almost) harmless ones.
Castor Angle: Castor gives greater responsiveness and stability to the front wheels. The larger the castor angle, the heavier the steering and more stable the front end.
cc: Short for cubic centimetres, the universal measurement of the volume of an engine’s cylinders.
Centre of Gravity (CG or CoG): The position within the car around which all the mass is gathered. The lower the centre of gravity, the greater the downforce.
CG: Computer graphics deals with generating images with the aid of computers. Today, computer graphics is a core technology in digital photography, film, video games, cell
phone and computer displays, and many specialized applications. A great deal of specialized hardware and software has been developed, with the displays of most devices
being driven by computer graphics hardware. It is a vast and recently developed area of computer science. The phrase was coined in 1960 by computer graphics researchers
Verne Hudson and William Fetter of Boeing. It is often abbreviated as CG, or typically in the context of film as computer generated imagery (CGI). The non-artistic aspects of
computer graphics are the subject of computer science research.
Some topics in computer graphics include user interface design, sprite graphics, rendering, ray tracing, geometry processing, computer animation, vector graphics, 3D
modeling, shaders, GPU design, implicit surfaces, visualization, scientific computing, image processing, computational photography, scientific visualization, computational
geometry and computer vision, among others. The overall methodology depends heavily on the underlying sciences of geometry, optics, physics, and perception.

8
Computer graphics is responsible for displaying art and image data effectively and meaningfully to the consumer. It is also used for processing image data received from the
physical world, such as photo and video content. Computer graphics development has had a significant impact on many types of media and has revolutionized animation,
movies, advertising, video games, in general.
Chassis: A load-bearing frame on wheels, which, in all early cars, carried the mechanical parts and to which the body was attached. Most of today’s models have a unibody
design, and so have no specific chassis unit, but the word survives to denote the drivetrain package.
Chicane: A sharp bend that reduces speeds by forcing drivers to drive through in single file.
Choke: A carburetor valve that temporarily restricts air flow so that the fuel-air mixture is gasoline-rich and easier to ignite when the engine is cold.
Clap-hand windshield wipers: Windshield wipers that fold together in the center of the windshield, and sweep toward the outside edges of the windshield when they are
activated.
Classic: A car built after January 1, 1940, and more than 25 years old.
Close-coupled: A body style of a two-door compact car that places the rear two seats within the wheelbase.
Clutch: A device that disconnects the engine from the transmission so that a different gear can be selected.
CM: Content Manager - A 3rd party launcher for Assetto Corsa by Ilja Jusupov (aka x4fab) which you need for an easier modding. The free (Lite) version is all you need, but
if you want some more tools you can buy the Full version for a small price. We will avoid most of the times (if not always) the vanilla AC launcher (AssettoCorsa.exe),
because it takes a lot of time to load, it is not efficient at managing the game contents and it doesn’t let you edit any of them. Plus a ton of options are missing (especially for
mods).
In addition, if you start adding many mods to your game, the vanilla launcher won’t be able to handle all of them: it can only manage around 750 cars. After that number it
will get stuck at the “Populating favourites” loading phase.
Coachwork: A car’s outer, painted body panels - work traditionally executed by a coachbuilder.
Column gearchange: A gear-selector lever mounted on the steering column instead of on the floor.
Combustion chamber: The space at the top of an engine’s cylinder into which the fuel-air mixture is compressed by the piston when at its high point, and the place where
the spark plug is located to initiate combustion.
Compression ratio: The ratio between the volume of one cylinder and the combustion chamber when the piston is at the bottom of its stroke, and the volume of the
combustion chamber alone when the piston is at the top of its stroke.
Compression ring: See piston ring
Compressor: A device that increases the pressure of a gas by reducing its volume by compression. Used in turbochargers and superchargers to increase the performance
of the engine.
Connecting rod: A mechanism that connects an engine’s piston to the crankshaft - often shortened to con-rod.
Copper-brazed engine: An engine found in Crosley cars and constructed from metal sheets, instead of castings, held together by copper alloy soldering techniques.
Cosworth-tuned: An engine modified by Cosworth, a UK-based designer and builder of engines for road and race cars.
Coupe: From the French verb couper, “to cut”, this originally referred to a two-door closed car with a lower roof-line. Coupes today tend to have a roofline tapering at the rear.
Courtesy light: A small light activated on opening a car door, lighting the car interior, door sill, or ground beneath the car.
CPU: A Central Processing Unit, also called central processor, main processor or just processor, is the electronic circuitry that executes instructions comprising a computer
program. The CPU performs basic arithmetic, logic, controlling, and input/output (I/O) operations specified by the instructions in the program. The form, design, and
implementation of CPUs have changed over time, but their fundamental operation remains almost unchanged. Principal components of a CPU include the arithmetic–logic
unit (ALU) that performs arithmetic and logic operations, processor registers that supply operands to the ALU and store the results of ALU operations, and a control unit that
orchestrates the fetching (from memory), decoding and execution of instructions by directing the coordinated operations of the ALU, registers and other components. Most
modern CPUs are implemented on integrated circuit (IC) microprocessors, with one or more CPUs on a single IC chip. Microprocessor chips with multiple CPUs are multi-
core processors.
Crankcase: The lower part of the cylinder block that houses the crankshaft.
Crank handle: A hand tool inserted into the front of an engine and used to turn it (mostly manually), so that the internal combustion process is activated. Also known, in the
UK, as a starting handle. Crank handles are typical of automobiles made up to the 1930s and were very common, until they were replaced with electric starter motors.
Crank pulley: The main pulley at the end of an engine’s crankshaft. It is used to drive ancillary devices, such as the alternator and the water pump.
Crankshaft: The main engine shaft that converts the reciprocating (up and down) motion of the pistons into a rotary motion to turn the wheels.
Crumple zones: The front and rear sections of a car designed to deform or collapse on severe impact; the energy absorbed prevents damage to the passenger compartment
and fuel tank.
CSP: Custom Shaders Patch, also known as Shaders Patch or Custom Shaders, it’s a mod by x4fab (aka Ilja Jusupov) that brings a major overhaul of the AC graphics and
enables things such as and rain, more than 1 light source, dynamic weather, among other advanced graphics and physics options. The mod is meant to work on the latest AC
release, 1.16.4.
cu in (cubic inches): A former volumetric measurement of cylinder capacity - and therefore engine size - for engines in the US; replaced with the litre since the 1970s.
Cylinder: The cylindrical bore in which an engine’s pistons move up and down.
Cylinder block: The body, usually of cast metal, into which cylinders are bored to carry the pistons in an internal combustion engine, and to which the cylinder head or heads
attach.

9
Cylinder head: The upper part of an engine, attached to the top of the cylinder block. It contains the spark plugs that ignite the fuel in the cylinders and usually the valves.
Damper: Forms part of the suspension system and absorbs the energy that is produced when the spring is compressing or extending. Damper force increases with speed
(heave, roll and pitch velocity).
Dead axle: An axle that carries a wheel, allowing it to spin freely, but through which no power is transmitted. Dead axles are common on trucks.
Density: Density, denoted by the Greek letter ‘ρ’ (rho), is defined as the mass per unit volume (mass/volume). To be precise, it should be stated whether it is absolute, static,
or relative density that is being considered. Notice mass is used in density calculations, not weight.
Differential: A gear set in the drive system of a car that allows an outer wheel to rotate faster than an inner wheel, necessary when turning a corner.
DIN figures: A measure of engine power output defined by Germany’s Deutsches Institut für Normung.
Direct injection: See fuel injection
DirectX / Direct3D: Microsoft DirectX is a collection of APIs for handling tasks related to multimedia, especially game programming and video, on Microsoft platforms.
Originally, the names began with "Direct", such as Direct3D, DirectDraw, DirectMusic, DirectPlay, DirectSound, and so forth. The name DirectX was coined as a shorthand term
and soon became the name of the collection. When Microsoft later set out to develop a gaming console, the X was used as the basis of the name Xbox to indicate that the
console was based on DirectX technology. The pattern has been continued for Windows APIs such as Direct2D and DirectWrite.
Direct3D (the 3D graphics API within DirectX) is widely used in the development of video games for Microsoft Windows and the Xbox line of consoles. Direct3D is also used
by other software applications for visualization and graphics tasks such as CAD/CAM engineering. As Direct3D is the most widely publicized component of DirectX, it is
common to see the names "DirectX" and "Direct3D" used interchangeably.
Disc brakes: A braking system in which each wheel hub contains a disc that rotates with the wheel and is gripped by brake pads in order to slow the vehicle.
Distributor: A device that routes high voltage from the ignition coil to the spark plugs in the correct firing order.
Since the popularization of microtransactions in online distribution platforms such as Steam, the term DLC has become a synonymous for any form of paid content in video
games, regardless of whether or not they constitute the download of new content. Furthermore, this led to the creation of the oxymoronic term "on-disc DLC" for content
included on the game's original files, but locked behind a paywall.
In the case of AC, DLCs are addons made and sold by Kunos on Steam. If you own the Assetto Corsa Ultimate Edition (1.16.4), you will automatically own all of them.
DLC: Downloadable Content is additional content created for an already released video game, distributed through the Internet by the game's publisher. It can either be added
for no extra cost or it can be a form of video game monetization, enabling the publisher to gain additional revenue from a title after it has been purchased, often using some
type of microtransaction system.
DLC can range from cosmetic content, such as skins, to new in-game content such as characters, levels, modes, and larger expansions that may contain a mix of such
content as a continuation of the base game.
While the Dreamcast was the first home console to support DLC (albeit in a limited form due to hardware and internet connection limitations), Microsoft's Xbox console and
Xbox Live platform helped to popularize the concept. Since the seventh generation of video game consoles, DLC has been a prevalent feature of most major video game
platforms with internet connectivity.
DOHC (double-overhead camshaft): See camshaft
Downdraft carburetor: A carburetor in which fuel is fed into a downward current of air.
Downforce: The force which pushes the car downward allowing the vehicle to grip the road surface.
Drag: Resistance to forward motion of the car. Can be caused by aerodynamic resistance or mechanical resistance.
Drivebelt: A belt that drives various devices in, or attached to, a car’s engine, including the alternator.
Driveshaft: A revolving shaft that takes power from the engine to the wheels.
Drivetrain: The group of mechanical assemblies—engine, transmission, driveshafts, and differentials—that generate and harness power in a car. Today these are collectively
know as the “chassis", and can be transplanted into several different models to save on development costs. Sometimes “drivetrain” can refer to the engine and the transmission
only.
Drophead: A body style featuring a convertible top that folds flat.
Drum brake: A braking system, largely supplanted by disc brakes, in which braking shoes are pressed against the inner surface of a drum that is attached to the car’s wheel.
Dual-circuit brakes: A braking system that has two independent hydraulic circuits to retain braking capability should one circuit fail.
Dynamo: An engine-driven generator of electric power in early cars. It has now largely been replaced by the alternator.
ECU (Electronic Control Box): Contains, among other information, the Driver aids software and settings, (traction control, active suspension etc.). The Electronic Control
Boxes are frequently inspected by the FIA following a race to test for illegal driving aids being used by constructors. On road cars, the ECU has more functions, related to the
onboard electronics, security and safety systems.
Entry-level: A car model that is the lowest-priced or features the lowest specifications in a range.
Exhaust manifold: A piping system that carries waste exhaust gases from the cylinders to the exhaust pipe.
Exhaust port: A passageway in the cylinder head leading from the exhaust valve(s) to the exhaust manifold.
Exhaust valve: A valve in the cylinder head that opens at the beginning of the exhaust stroke, allowing the piston to push the exhaust gases out of the cylinder.
Extension (*.*): kjlj
Here we have some of the most common extensions you may find while modding or reading this manual:

10
3ds 3D model format used by Autodesk 3D Studio Max log plain text generated by various programs (here AC) to report system events
7z compressed archive created with 7-zip lut Assetto Corsa Look-Up-Table, plain text format
acd Assetto Corsa encrypted vehicle data file, container format m4a
ai Assetto Corsa AI (artificial intelligence) file for offline car opponents mid, midi
bank Files created by FMOD containing audio and events for games mp3
csv plain text, comma-separated values file (common with MS Excel) mp4
dds raster image saved in the DirectDraw Surface (DDS) container format mpeg, mpg digital video file format standardized by the Moving Picture Experts Group
dll dynamic-link library, set of procedures executed by a Windows program msi MS-Windows installer package file
doc, docx MS-Office Word document (.doc is for Word 1997-2003) pdf Adobe Portable Document Format, typically read-only documents
exe executable programs in MS-Windows, either applications or installers png digital raster image similar to JPG but with lossless compression and transparency
fbx 3D model saved in the Autodesk Filmbox format, often used in games psd native format used to save files in Adobe Photoshop
flac Free Lossless Audio Codec; compressed audio format with no quality loss rar compressed archive created with WinRar
gif rtf text files including extra info about font style, formatting, images, etc.
htm, html rto Assetto Corsa gear ratio file
ini configuration file used by Windows programs to initialize program settings tmp temporary backup, cache, or other data file created automatically by a software
iso optical disc (e.g. DVD) file format containing an exact copy of the data txt document that contains plain text
jar Java archive (JAR) format, which utilizes Zip-compression vob
jpg, jpeg digital raster image format that features lossy compression wav digital audio in the WAVE format, storing pure PCM uncompressed waveform data
json simple data structures in the JavaScript Object Notation format wma Windows Media audio format
kn5 Assetto Corsa 3D model container format xls, xlsx MS-Office Excel spreadsheet (.xls is for Excel 1997-2003)
knh file containing a single animation frame for car driver reference position zip
ksanim Assetto Corsa animation file (read-only)

Eyebrow headlights: A stylistic feature, first seen on the Lamborghini Miura, that gives the impressions of eyebrows or eyelashes framing the headlights.
FFB: Force Feedback. When referring to sim racing, force feedback is a feature within certain wheels that try to simulate the feel of a real car by making the wheel react with
force and resistance. When driving a real car, the driver can get a sense of the vehicle's grip, any bumps or curbs hit, the feeling of the road, etc. by using all their senses. For
example, you know you hit a pothole because your body can feel the car as it goes through it. But in the virtual world, there's no real way of feeling that. As a result, a force
feedback wheel can react to appeal to your sense of touch and give you more awareness of the virtual car. A force feedback wheel will, for example, give counter-resistance
when turning into a tight corner at high speeds, shake and rumble when your virtual car hits a curb, goes off-road, hits gravel or sand among many other things for example.
All of this is done to not only increase realism and immersion but most importantly give essential cues to the driver which would otherwise be impossible to feel.
FIA: Federation Internationale de l’Automobile. The motor racing sport’s governing body.
Factory team: A racing team funded by a car manufacturer.
Fairing: Any cover or cowling designed to make components that extend outward (of an engine, for example) more aerodynamic.
Fastback: A rear roofline profile that tapers to the end of the car’s tail, giving it a sportier appearance.
Firewall: The bodywork sections that form a barrier between the engine and the passenger compartments and that support the windshield.
Flat-twin, flat-four, flat-six, flat-twelve: Any engine that has its cylinders and pistons positioned horizontally in two opposed banks. These are sometimes called “boxer”
engines because the pistons in opposing pairs of cylinders move toward and away from each other alternately, as if trading punches.
Floorpan: A shallow, pressed-metal tray that forms the underside of the car and carries suspension and other drivetrain elements. Clever design has often allowed the same
floorpan to be shared by several different models.
Fluid flywheel: A now-redundant transmission device allowing the driver to change gear without using a clutch.
Flywheel: A heavy circular plate attached to the crankshaft that stores the rotational energy produced by the engine’s torque impulses. Releasing this energy between impulses
smoothes engine operation.
Formula 1: More formally known as the FIA (Federation Internationale de l’Automobile) Formula One World Championship, this is the premier world series of single-seat
motor races. It was inaugurated in 1950.
Four-stroke engine: This is the predominant type of car engine today. There are four stages in the power cycle, which occupies two crankshaft rotations: intake,
compression, combustion, and exhaust. Each of these is governed by the upward or downward motion or “strokes” of the piston.
Four-wheel drive (4WD): See 4x4
FPS (display): The frame rate (expressed in frames per second) is the frequency (rate) at which consecutive images (frames) are captured, rendered or displayed. Very simply
it is the number of frames you see every second.
The term applies equally to film and video cameras, computer graphics, and motion capture systems. Frame rate may also be called the frame frequency, and be expressed in
hertz. Frame rate in electronic camera specifications may refer to the maximal possible rate, where, in practice, other settings (such as exposure time) may reduce the frequency
to a lower number.
The human visual system can process 10 to 12 images per second and perceive them individually, while higher rates are perceived as motion.
A sufficiently high frame rate on a racing simulator is essential for a smooth, life-like driving experience. A low frame rate interferes with your ability to control the car smoothly,
and thus destroys your sense of immersion. Here is why. When driving a car in real life, your brain is the controller, your body is the sensor and actuator, the steering wheel
and the pedals are the control inputs, and the car is the system under control. Your limbs exert control forces on the steering wheel and the pedals. Your eyes, your inner ears
and your whole body sense the resultant movements of the car. Your brain uses this feedback information from the sensory organs, and determines the new forces your limbs
should exert on the controls.
Similarly, when driving on a simulator, your eyes see a frame that shows the car’s instantaneous location and orientation, your brain computes the new control forces based on
what your eyes saw, your limbs apply these forces to the controller, the simulator moves the car to a new location and orientation in accordance with the new control inputs,
the graphics card generates another frame that reflects the new location and orientation, and the entire feedback process repeats.

11
If the frame rate drops well below 30 fps and the transition between two adjacent frames becomes perceptible, your visual feedback system will be thrown out of kilter. The
frame update delay causes your eyes to continue to see the old location and orientation of the car, even after your limbs have exerted the new control forces. In the real world,
the brain is not used to work with delayed feedback, so it misconstrues the lagging visual update as having exerted insufficient amounts of control forces. Consequently, it
commands your limbs to apply more forces. The car has now turned more than necessary. When the delayed, new frame finally appears, it shows the over corrected new
location and orientation of the car. Through the eyes, your brain senses the over-correction error, and immediately applies a new counter correction. The frame delay, again,
fools the brain into making another over correction, but this time in the opposite direction. The car is now going out of control, weaving left and right.
So, without achieving an adequate frame rate, you cannot drive in a simulator. Usually for games, using the same hardware, a lower rendering quality yields a higher frame
rate, and a higher image quality a lower frame rate.
Front-wheel drive: Power is transmitted to the two front wheels of a vehicle only. This lightens the car (in case the engine is on the front), which needs no transmission shafts
or trunking to its rear wheels.
Fuel injection: A fuel supply system, universal to new cars, which dispenses with a carburetor. Fuel is pumped from the gasoline tank and sprayed by injectors straight into
the engine’s inlet ports, where it mixes with air before being burned in the cylinder. In diesel and direct injection gasoline engines, fuel is injected straight into the cylinder,
rather than into the inlet port.
Getting a Tow: Another term for slipstreaming (drafting), gaining speed by sitting behind a rival car prior to overtaking.
Gas turbine: A jet-type rotary engine drawing its energy from the continuous burning of a flow of fuel–air mixture, which drives a turbine. Used experimentally in cars, it is
too slow-reacting to directly replace the reciprocating engine.
Gated shifter: A style of gearbox in which the slots into which the gear selector lever must be pushed are visible. It is usually found in sports or racing cars; other types of
car tend to cover it up with a rubber or stitched-leather gaiter.
Gear: A toothed or cogged machine part that meshes and rotates with other such parts to transmit torque.
Gearbox: The metal case in which the gears and gear-changing mechanism are housed. It is usually joined to the end or the bottom of the engine.
Giugiaro: This can refer to the Italian car stylist Giorgio (often alternatively known as Giorgetto) Giugiaro, or to the design consultancy he started in 1968, which is more
formally called Italdesign-Giugiaro. The consultancy was acquired by Volkswagen in 2010.
GPU: A Graphic Processing Unit is a specialized electronic circuit designed to rapidly manipulate and alter memory to accelerate the creation of images in a frame buffer
intended for output to a display device. GPUs are used in embedded systems, mobile phones, personal computers, workstations, and game consoles. Modern GPUs are very
efficient at manipulating computer graphics and image processing. Their highly parallel structure makes them more efficient than general-purpose central processing units
(CPUs) for algorithms that process large blocks of data in parallel. In a personal computer, a GPU can be present on a video card or embedded on the motherboard. In certain
CPUs, they are embedded on the CPU die.
Grand routier: An informal name, more common in English than French, which translates as “grand road traveler”. It is often applied to elegant and fast European touring cars.
Ground Effect: The car has an underbody shaped like an inverted wing which almost sucked the car on to the track and gave tremendous grip. This wing is also called diffuser.
GT: From the Italian “gran turismo”, meaning “grand touring,” these initials refer to high-performance closed cars.
GUI: The Graphical User Interface (GUI) is a form of user interface that allows users to interact with electronic devices through graphical icons and audio indicator such as
primary notation, instead of text-based UIs, typed command labels or text navigation. GUIs were introduced in reaction to the perceived steep learning curve of command-line
interfaces (CLIs), which require commands to be typed on a computer keyboard. The actions in a GUI are usually performed through direct manipulation of the graphical
elements. A series of elements conforming a visual language have evolved to represent information stored in computers. This makes it easier for people to work with and use
computer software. The most common combination of such elements in GUIs is the windows, icons, text fields, canvases, menus, pointer, especially in personal computers.
Gullwing doors: Doors that open upward. They are a key feature of the Mercedes-Benz 300SL and the DeLorean DMC-12.
Hardtop: A sports, or sporty, car with a rigid roof that is either fixed or removable. A car with a fabric roof is called a soft-top.
Hatchback: The tailgate on any non-wagon with a sloped, instead of vertical, tail. It is also a style of car pioneered in four-door form by the Renault 16 of 1965, and in two-
door form by the Renault 5 of 1972.
Head: See cylinder head
Heat shield: Rigid or flexible layers of heatresistant material that protect a car’s components or bodywork from excessive engine- or exhaust generated heat.
Homologation: A rigorous testing program that new cars must undergo to ensure they meet construction and usage rules in a territory; only then can they be legally driven
on the road. The term is also applied to the rules governing individual motorsport categories.
A “homologation special” is, in general, a roadgoing version of a racing car; a minimum number of these must be constructed for it to qualify as a production model.
Hood: A hinged covering for a car engine. It can also refer to the folding, canvas-covered top of any convertible car.
Horizontally opposed layout: The full technical term for an engine whose cylinders are mounted flat on either side of the crankshaft.
Hot hatch: The nickname for a high performance version of a compact three-door (sometimes five-door) car, exemplified by the Renault 5 Alpine and Volkswagen Golf GTi
of 1976.
Hot rod: Short for “hot roadster,” a US term that originated in the 1930s to describe any standard car whose engine had been modified for higher performance. After World
War II, hot rods were modified production cars used in straight-line speed trials.
hp (horsepower): See bhp (brake horsepower)

12
HUD: What is a HUD (Heads-Up Display)? It is any transparent display that presents data without
requiring users to look away from their usual viewpoints. The origin of the name stems from a
pilot being able to view information with the head positioned "up" and looking forward, instead of
angled down looking at lower instruments (Fig.). A HUD also has the advantage that the pilot's
eyes do not need to refocus to view the outside after looking at the optically nearer instruments.
In video gaming, the HUD (heads-up display) or status bar is the method by which information is
visually relayed to the player as part of a game's user interface. While the information that is
displayed on the HUD depends greatly on the game, there are many features that players
recognize across many games. Most of them are static onscreen so that they stay visible during
gameplay.
Hydraulic brakes: A braking system that uses fluid to slow the car down via pressure on the
brake pedal.
Hydraulic damper: A damper is the proper name for a shock absorber, which dissipates the energy of a car’s suspension movement and converts it hydraulically, via
internal oil, into quickly dissipated heat.
Idle-speed positioner: A device that optimizes the rate at which the engine runs at idle, when the throttle is closed, to maximize fuel efficiency.
Ignition coil: An ignition system component that converts the car battery’s 12-volt power into the thousands of volts required to ignite the spark plugs.
Independent suspension: A suspension system that allows every wheel to move up and down independently of the others. Its advantages are better handling and a more
comfortable ride.
Indianapolis 500: An iconic US motor race for single-seat cars, staged annually since 1911 at the oval Indianapolis Motor Speedway.
Induction system: The apparatus through which air passes as it enters the engine.
Inlet plenum chamber: An air chamber between an engine’s throttle body and inlet manifold that beneficially affects the operation of the induction system.
Inlet port: The route within a cylinder head through which the fuel-air mixture passes to the inlet valve.
Inlet trumpet: A trumpet-shaped engine air intake designed to exploit the effects of wave motion to force more air into the cylinders.
Inlet valve: The valve through which fuel is drawn into the engine cylinder.
Inline engine: An engine that has its cylinders arranged in a straight line or row; it has been the predominant automotive layout in small cars for decades.
Intercooler: A radiator that cools the compressed air from a turbocharger or supercharger before it enters the engine. This increases power and enhances reliability.
IRS (Independent Rear Suspension): A suspension system in which the rear two wheels are free to move up and down independently of each other.
Knock-off wire wheels: These are wheels consisting of wire spokes between hub and rim that fit on to splined hubs, and are secured in place with, effectively, a large nut.
Traditional British sports cars have traditionally had wings on these nuts so that it can be undone (or "knocked off") using a mallet; this system was for years illegal in
Germany. Italian cars often had a plain nut that needed a special tool to undo it for wheel removal.
KP 2.0: The Kunos pipeline 2.0 is a brief official guide of 76 pages on how to make car mods for Assetto Corsa. It is an update of the Kunos pipeline 1.03, with corrections
due to the development stages of AC. The focus is on visuals. It is based on 2015 hardware standards, and some aspects are even older. Many procedures are not explained,
some are not even mentioned and most are overlooked. A copy of the KP 2.0 is present as a PDF file in every installation of the simulator, under the
%root%\assettocorsa\sdk\dev\car_pipeline_2.0rev folder. It’s an outdated document, but a lot of the instructions are still used to this day and have been corrected and
incorporated in this very manual.
KS: Kunos Simulazioni S.R.L., the Italian software house that developed Assetto Corsa and AC Competizione, and other popular simulation software.
ksEditor: Small program useful to convert .fbx models to AC .kn5 models. Also called SDK Editor, AC Editor, Kunos Editor. In the Steam library it is improperly called AC SDK;
the SDK is the Software Development Kit, which includes example files, templates and instructions for the AC modding, all under the %root%\assettocorsa\sdk folder, so the
editor is just a component of the SDK. You can find it in every installation of AC. It is the same editor that the developers used to work on the game assets, and the graphics
engine is the same. Thus it falls in the WYSIWYG editor category, which means “What You See Is What You Get”. With graphics mods, this characteristic falls apart, because
the editor keeps the vanilla visuals, as it cannot be modded (or at least such mods do not exist right now).
Laminated windshield: Fitted to all new cars as a legal requirement for many years, a laminated windshield consists of two layers of glass with a layer of plastic in between,
similar to the principle of bulletproof glass. The screen will not craze all over if hit by a stone, and won’t splinter if it breaks.
Landaulet-body style: A type of coachwork featuring a folding fabric top above the heads of the rear seat passengers while the front of the car remained closed in with a
metal roof. The style, which is now old-fashioned, has often been seen on cars used for formal processions where royalty or political leaders wish to be seen by their
subjects or citizens.
Launcher (game software): It is a program (almost always used in games) that manages the graphic interface when you are not in a real-time session of the game. You
can usually consider any loading screen part of a launcher. Sometimes launchers are part of the game itself, sometimes they aren’t. Talking about AC, we can say that the
vanilla launcher is AssettoCorsa.exe in the installation folder. It lets you prepare the race, in fact when you select your car, track, opponents etc. it writes on the race.ini file in
the assettocorsa\cfg folder. Then you could technically close the AC and open acs.exe. This is basically the game engine, and it can work without any launcher if you feed it
with the correct race.ini config file. This flexibility lets you make alternative launchers. Actually, during development and bugfixing, Stefano Casillo (author of AC and founder
of Kunos) almost never used the launcher. He always filled in the race.ini by hand.
Leaf spring: Also known as a “cart spring,” this is a basic means of suspension noted for its toughness, although not for its supple ride quality. The spring comprises
overlaid arcs (or leaves) of steel that are fixed to the underside of the car, forming a shock-absorbing cushion on which the car’s axle presses. The heavier the car, the more
leaves must be added to the spring.
Limited-slip differential: A differential that counteracts the tendency of wheelspin if one driven wheel hits ice or another slippery surface.

13
Limousine: A luxurious sedan, usually with a long or extended wheelbase, with an emphasis on rear-seat comfort. Limousines are sometimes fitted with glass divisions
between driver and rear passengers.
Live axle: A beam-type axle that contains the shafts that drive the wheels on each end.
Logged data chart: Graphical method of displaying information which has been recorded during a lap. Also known as Performance Analysis, it is a form of telemetry.
MacPherson strut: Named after its inventor, Ford engineer Earl MacPherson, this is a suspension upright comprising a hydraulic damper with a coaxial coil spring. Most
often used for front suspensions, it has the advantage of causing little intrusion into the engine bay.
Mille Miglia: A 1,000-mile (1,609-km) road race around Italy on public roads, held 24 times between 1927 and 1957. In 1977, the name was revived for an annual parade
of historic cars.
Mod, modding, modder: That’s what this manual is about. Modding is a slang expression derived from the English verb "to modify". The term “mod” refers to modification
of hardware, software, or anything else, to perform a function not originally intended by the designer, or to achieve bespoke specification or appearance. The term is used in
relation to computer games, particularly in regard to creating new or altered content and sharing that via the web. It may be applied to the overclocking of computers in order
to increase the frequency at which the CPU operates. Case modding is a popular activity amongst many computer enthusiasts which involves the customization of a computer
case or the installation of water-cooling technology. In connection with automobiles, modding can connote engine tuning, remapping of a vehicle's engine control unit or
customization of the coachwork.
Modding may sometimes infringe the legal rights of the copyright owner. Some nations have laws prohibiting modding and accuse modders of attempting to overcome copy
protection schemes. In the United States, the DMCA has set up stiff penalties for mods that violate the rights of intellectual property owners. However it is also worthy of note
that some other European countries have not interpreted the legal issues in the same way. In Italy a judge threw out a Sony case saying it was up to owners of a console what
they did with it. Similarly in Spain, mod chips have been ruled as legal despite the EU copyright legislation.
Types of modding:
There are two different ways of running unsigned code on a game console. One is through soft modding (modifying software, normally using a softmod) to allow the user to
change data contained on its hard drive in the case of the Xbox. Another type of modding, known as hard modding, is done by modifying the hardware, such as components
connected to the Hypervisor in order to run exploits to the BIOS of the console or to run unsigned code and games. This form of 'modding' (more correctly termed as hacking),
while not as popular as softmodding, is mostly done as it is able to 'run' many different types of software. Soft modding is more popular because of its ease of installation and
its relatively low price (it can even be done for free with the right tools).
Another type of console modding is about appearances, much like computer case modification. Which includes, adding lights, cutting the game system case, to fit hardware
and/or expose the internal systems. Cooling is a large part of console hard 'modding'.
Some companies actively encourage modding of their products. In cases such as TiVo and Google, there has been an informal agreement between the modders and the
company in which the modders agree not to do anything that destroys the company's business model and the company agrees to support the community by providing
technical specifications and information. Assetto Corsa was intended and designed as a moddable simulator from the beginning.
The softmods in games can be as simple as altering the mechanics of a weapon in a first-person shooter, or as complex as turning one game into an entirely different one
(this happened a lot especially with classic Doom and old DOS games). The latter is known as a total conversion.
The modder (although it is more grammatically accurate to use the word modifier; not to be confused with the slang that stands for moderator, typical of social platforms) is
the person that actually produces mods. These people are usually technically inclined and they deliberately modify games (or anything else) to their advantage (e.g. someone
who cheats by altering the game code because he is too much of a newbie) or for fun. Most of the time they do anything out of passion, and what pushes them is the satisfaction
of making things work the way they want. It’s very rare that their hobby becomes a job. If you win a contest, maybe. While modding isn’t a guarantee you’ll land a job in the
games industry, it’s a great way to discover your passion for game development, and refine your skills – all while bolstering your résumé and building a portfolio of work. Mods
build skills because they are using tools similar (or sometimes exactly the same) to the ones that the game developers use. This can be invaluable in both improving your skills
and learning what gamers like.
Monobloc: An engine design in which the cylinders are cast together as a single unit. This improves the mechanical rigidity of the engine and the reliability of the sealing.
Monocoque: See unibody construction
MPV: Shorthand for Multi-Purpose Vehicle or Multi-Passenger Vehicle. The term applies to tall, spacious cars that can carry at least five passengers, and often as many as
nine, or versatile combinations of people and cargo as a people hauler.
Muscle car: A US standard production car, usually with two doors, featuring a large-capacity, high-performance engine. Many experts consider the 1964 Pontiac GTO the
first true muscle car, although the Rambler Rebel was an ancestor in the same spirit.
NA (automotive): Usually means, referring to engines, Naturally Aspirated, so the car does not have turbines or compressors that increase the air/fuel mixture flow.
NACA duct: America’s National Advisory Committee for Aeronautics created this distinctively shaped air intake, which can be used to ventilate internal components such as
brakes while causing minimal disturbance to external aerodynamics.
NASCAR: The National Association for Stock Car Auto Racing—a US organization that oversees motor racing series and events.
OEM (automotive parts): An Original Equipment Manufacturer is generally perceived as a company that produces non-aftermarket parts and equipment that may be marketed
by another manufacturer. When referring to auto parts, the term refers to the manufacturer of the original equipment, that is, the parts assembled and installed during the
construction of a new vehicle. In contrast, aftermarket parts are those made by companies other than the OEM, which might be installed as replacements after the car comes
out of the factory. For example, if Ford used Autolite spark plugs, Exide batteries, Bosch fuel injectors, and Ford's own engine blocks and heads when building a car, then car
restorers and collectors consider those to be the OEM parts. Other-brand parts would be considered aftermarket, such as Champion spark plugs, DieHard batteries, Kinsler
fuel injectors, and BMP engine blocks and heads. Many auto parts manufacturers sell parts through multiple channels, for example to car makers for installation during new-
vehicle construction, to car makers for resale as automaker-branded replacement parts, and through general merchandising supply chains. Any given brand of part can be OEM
on some vehicle models and aftermarket on others.
ohc (overhead-camshaft): See camshaft
ohv (overhead valve): See overhead-valve engine

14
Overdrive: A gear ratio for fast cruising that causes the gearbox output shaft to turn faster than the input shaft. This lowers the engine revs for a given vehicle speed, which
cuts fuel consumption, but also torque, which restricts overtaking power.
Overhead-camshaft: See camshaft
Overhead-valve engine: An engine in which the inlet and exhaust valves are contained within the cylinder head, and not beside the cylinder, as they are in a sidevalve engine.
Overrider: A metal or rubber-faced metal upright fitted to a bumper to protect against the bumpers of other cars in a low-speed collision.
Outbrake: To brake very late into a corner when dicing with a rival car.
Oversteer: Oversteer is characterised by the rear end of the car losing grip, giving the car a tendency to spin.
Over-square engine: An engine in which the cylinder bore measurement is greater than the stroke.
Packers: Packers form part of the suspension assembly and adjust the position at which the bump rubbers become loaded.
Paddock: The parking area behind the pits where all the equipment, trucks and spare cars are kept by the teams.
Pinin Farina/Pininfarina: An Italian coachbuilder and design consultancy founded as Pinin Farina in 1930 by Battista “Pinin” Farina. The company adopted the Pininfarina
title in 1961.
Piston: The component that moves up and down inside the engine cylinder and which, on the combustion stroke, transfers force from the expanding gas to the crankshaft via
a connecting rod.
Piston ring: An open-ended ring that fits into a groove in the outer surface of an engine’s piston, sealing the combustion chamber. Piston rings also act to cool the piston by
transferring heat to the cylinder wall, and regulate oil consumption.
Platform: The concealed, but elemental and expensive, basic structure of a modern car. It is the task of car designers to achieve maximum aesthetic diversity from a single
platform.
Pony car: A genre of car informally named after the Ford Mustang, which was one of the first compact sporty coupes, aimed at the US “baby boomers” of the 1960s, and
featured the emblem of a galloping horse. It could be ordered with several high-performance engine options.
PP Filter (PPFX): The term post-processing is used in the video/film business for quality-improvement image processing (specifically digital image processing) methods
used in video playback devices, video playing software and transcoding software. It is also commonly used in real-time 3D rendering such as in video games to add
additional effects.
Instead of rendering 3D objects directly to the display, the scene is first rendered to a buffer in the memory of the video card. Pixel shaders and optionally vertex shaders are
then used to apply post-processing filters to the image buffer before displaying it to the screen. Some post-processing effects also require multiple-passes, gamma inputs,
vertex manipulation, and depth buffer access. Post-processing allows effects to be used that require awareness of the entire image (since normally each 3D object is
rendered in isolation). Such effects include:
Ambient occlusion (HBAO, Screen space ambient occlusion (SSAO, reflections), etc. Haze (depth, heat)
Anaglyph High-dynamic-range rendering
Anti-aliasing (FXAA, AGAA, SMAA, MLAA, custom methods -not sample-size AA like Image distortion
MSAA and SSAA) Infrared
Bloom Lens flare (cubic lens distortion flare, pseudo lens flare)
Blur (depth of field, motion blur, smart) Light scattering
Bloodlust effect (red vignetting with particles, etc.) Nightvision
Bokeh Outlines
Bump mapping Particle effects
Cel shading Pixel vibrance
Chromatic aberration Point light attenuation
Color correction Posterization and deposterization
Color grading Scanline
Contrast adjustment Screen borders
Dynamic contrast Screen rotation
Crepuscular rays Shading (ink, paint, sketch)
Digital camera light compensation Shadow mapping
Dithering (including subpixel) Sepia tone
Eye adaptation Sharpen/unsharpen (texture unsharp mask, LumaSharpen, sharpen, sharpen complex
Film grain 1/2, adaptive-sharpen)
Filmic scene tone mapping Sobel operator
Fog/mist Split screen
Gamma correction Upscaling (xBR, Super xBR, SuperRes)
Global illumination Texture filtering (point, linear, bilinear, trilinear, anisotropic, etc.)
Glow Vignette
Grayscale
Powertrain: See drivetrain
Propshaft: A contraction of “propeller-shaft”; a long shaft that conveys engine torque to the rear axle of a rearwheel-drive or four-wheel-drive car.
Pushrod engine: An engine in which the valves are not operated directly via the camshaft but via intermediate rods. This allows the valves and camshaft to be widely
separated, but reduces the maximum rotation speed of the engine, as the valves are spring-loaded, and there are delays due to inertia. That’s the reason why motorbike
manufacturers like Ducati adopt desmodromic valve gearing. With this system the valve is closed by the camshaft, and its accuracy allows high revs to be used without the
risk of valve bounce. It was a feature on Ducati racers since the later 1950s, and became available on their road bikes in 1971.

15
Rack-and-pinion steering: A rack and pinion consists of two gears that together convert rotational motion into linear motion. It is the favoured system for car steering because
it provides good feedback to the driver about the behavior of the wheels, and gives what is often described as “accurate” steering.
Radiator: A heat-exchanger used to cool liquids by presenting a large surface area to a flow of air.
Razor-edge styling: A car styling trend toward sharp-edged lines that emerged in the UK coachbuilding industry in the late 1930s. It was a reaction to the prevailing preference
for rounded, streamlined forms, and instead was used to convey dignity and formality.
Rear-wheel drive: Power transmitted to the two rear wheels of a vehicle only.
Reciprocating engine: Also known as a piston engine, which converts the up and down (or “reciprocating”) motion of pistons to the rotary motion needed by the wheels.
Redline: The maximum speed at which an engine is designed to operate without incurring damage. It is usually indicated by a red line on the rev counter dial.
Rev: Short for revolutions-per-minute, a measure of engine speed.
Roadster: A term that originally described an open car with a single seat to accommodate two or three abreast, but which now applies to any kind of two-seat open sports car.
Rocker arm: A pivoted lever, one end of which is raised and lowered by the camshaft, either directly or via a pushrod, while the other end acts on the stem of the engine
valve.
Rebound damper: An energy absorbing device fitted between wheel and car body which resists downward movement by the wheel.
Refuelling: Refuelling is an essential part of race strategy. The less fuel a car holds, the faster it can travel, but this will result in the need for more time-consuming pit stops
to refuel.
Responsive handling: The car responds quickly to steering, acceleration and braking inputs from the driver, allowing very accurate manoeuvres.
Rev limiter: A device which limits the RPM of the engine to a preset value. This is used in the pit lane to keep the car speed within the pit lane speed limit.
Ride height: The height of the car floor, above the ground, measured from the wheels.
Rocker panel: The section of a car’s bodywork between the front and rear wheel arches and below the side doors; usually called the “sill” in the UK.
Rolling chassis: The frame of an older, separate-chassis car, with all drivetrain components fitted.
Rollover bar: Also caller rollbar, it is a strong metal hoop incorporated into the structure of a car with a folding roof. It is designed to protect the heads and upper torsos of
driver and passengers should the vehicle overturn.
Rotary engine: Any type of power unit that dispenses with the reciprocal motion of pistons, producing rotary motion directly. The only type ever fitted to production cars was
one designed by Dr. Felix Wankel, and the most recent car to feature one was the Mazda RX-8, which appeared in 2001.
Running board: A fixed step below the doors on early cars that aided entry and exit in the days when seating positions were high, as in horse-drawn carriages. Running
boards began to disappear in the 1930s as cars were built lower.
Running gear: The wheels, suspension, steering, and drivetrain of a car.
Rumble Strip: The bobbly, coloured strip on the edge of the track which serves as a warning to the driver to transgress no further.
Run Off Track: A stretch of track close to a dangerous section of the circuit, that gives the driver an escape route if things go wrong, e.g. the driver loses control of the car.
Scavenge oil pump: In a dry sump engine, this additional pump evacuates oil that collects at the bottom of the engine, sending it to a separate oil tank.
Sedan: Any type of car with a fixed metal roof.
Semi-elliptic springs: Another term for leaf springs, due to their elliptical shape.
Semi-trailing suspension: An independent suspension assembly for the rear wheels of a car in which each wheel hub is linked to the chassis by a lower triangular arm that
pivots at an acute angle to the vehicle center-line.
Servo assisted braking: A braking system that uses a stored vacuum (or “vacuum servo”) to magnify the force the driver applies to the brake pedal.
Shaft drive: Power delivered from the engine to the wheels by means of rotating shafts.
Shunt: A good old knock from the car behind you.
Side-valve engine: A form of engine design in which the valves are placed at the side of the cylinder, rather than within the cylinder head. In an L-head engine, the inlet and
exhaust valves are placed together on one side of the cylinder; on a T-head engine they are located on opposite sides.
Silencer: A chamber placed along the route of the exhaust pipe and designed to reduce exhaust noise.
Sim: Simulation or simulator (depending on the context). It is a reconstruction of reality made with mathematical models and a high computational power.
Skirts: Metal body panels that partly conceal the wheels to give a sleek styling continuity to body lines. They are usually fitted over the back wheels, and can be detached for
wheel changes.
Sleeve-valve engine: An engine that has a metal sleeve placed between the piston and cylinder wall. The sleeve oscillates with the motion of the piston and has holes that
align with the cylinder’s inlet and exhaust ports, facilitating the entry and exit of gases.
Slide throttle: A type of throttle featuring a perforated plate that slides across the air inlet to allow more or less air to enter the engine.
Sliding gear transmission: An old-fashioned manual gearbox. When in neutral, nothing inside the transmission revolves apart from the main drive gear (attached to the
crankshaft) and cluster gear (attached to the wheels). To mesh the gears and apply engine power for motion, the driver presses the clutch and moves the shift handle to slide
a gear along the mainshaft mounted above the cluster. The clutch is then released and the engine power transmitted to the driven wheels. This system has been superseded
by constant-mesh, or “synchromesh,” gears.

16
Small-block: The smallest V8 engines from Chevrolet and Ford, first produced in the 1950s.
sohc (single overheadcamshaft): See camshaft
Solenoid switch: An electronically controlled switch, more properly known as a relay, which allows a low-current electric circuit to control a high-current one. A car’s starter
motor, for example, requires a high-current circuit.
Sound engine: It is the software used for the sound system.
Sound generator: The term refers to the part of the sound engine responsible for creating sound streams in real-time, which are sent to the sound management system in
the sound engine.
Sound management: The part of the sound engine responsible for playback and spatialization of sounds in the simulated environment.
Sound system: The term refers to the complete audio recording/editing/reproduction setup. This includes both hardware and software.
Spa 24 Hours: An annual endurance motor race held in Spa, Belgium, since 1924.
Spark plug: An electrical device, screwed into the engine cylinder head of a gasoline engine, that ignites the fuel in the cylinder.
Spider: A “spider-phaeton” was originally a light horse-drawn cart with two seats and large wheels. Alfa Romeo adopted the name for its two-seat sports cars in 1954, and it
is now the standard name for cars of that type, particularly ones that are compact and low with a snug cockpit.
Sports car: A two-seater with a convertible top, low or rakish lines, good roadholding, and above-average speed and acceleration.
Springs: The springs form part of the suspension assembly and are the main means of supporting the car on the wheels.
Spyder: The German equivalent of a “spider,” and most commonly associated with Porsche.
Straight engine: See inline engine
Suspension travel: The distance through which the moving parts of the suspension travel in relation to the fixed parts.
Subframe: A self-contained structure, additional to the chassis, that is designed to carry specific components such as the engine or suspension.
Suicide doors: A slang term for passenger doors that are hinged at the rear. Before the time when seatbelts were universally fitted, such doors could be hazardous if a
passenger fell from a moving car. They were also, in early motoring times, prone to flying open when on the move and being forced back by the air stream, dragging the
occupant out as they struggled to slam them shut.
Sump: An oil reservoir at the bottom of an engine. A “dry sump” is usually fitted to a racing car or sports car engine that is likely to be subjected to high cornering, braking,
and acceleration forces. In a conventional “wet sump”, these forces can cause oil to surge, uncovering the oil pick-up pipe, which can result in engine damage.
In a dry sump system, a scavenge pump removes oil as it falls into the sump, pumping it to a separate oil tank.
Supercar: A very expensive, high-performance sports car. The first supercar is widely recognized to have been the Mercedes-Benz 300SL of 1954, but the term later came to
describe a mid-engined two-seater as exemplified by the Lamborghini Miura of 1966.
Supercharger: An engine-driven compressor that forces air into the inlet system, thereby increasing the amount of fuel-air mixture entering the cylinders, and hence the
torque and power.
Supermini: A market term for a small hatchback car with a four-cylinder engine, as exemplified by the Renault 5 of 1972.
Suspension: A system that cushions the car’s structure (and occupants) from the motion of the wheels as they traverse uneven road surfaces.
SUV: Stands for Sport-Utility Vehicle, a high-riding car with four-wheel drive intended for consumer rather than industrial use.
Swash plate: A plate attached at an angle to a rotating shaft that is used to convert the shaft’s rotational motion into reciprocal motion at pushrods lying parallel to the shaft
axis.
Swing axle suspension: An early type of independent rear suspension consisting of two half-axles pivoted at the rear differential. The wheels remain perpendicular to the
axles at all times. The system improved ride comfort but could lead to alarming handling in high-speed manoeuvres, and has not been used for several decades.
Synchromesh gearbox: A gearbox in which gear wheels are in constant mesh. All-synchromesh gearboxes are universal in modern road cars.
Tappet: A valvetrain component that makes sliding contact with the camshaft lobe, converting the cam’s profile into the reciprocating motion of the valve.
Targa Florio: An open-road race through the mountains of Sicily, staged between 1906 and 1973, and since revived as a classic car event.
Telemetry System: Multi-function system that measures all aspects of car and driver performance.
Tex or tx (computer graphics): A texture map is an image applied (mapped) to the surface of a shape or polygon. This may be a bitmap image or a procedural texture.
They may be stored in common image file formats, referenced by 3d model formats or material definitions, and assembled into resource bundles.
Textures may have 1-3 dimensions, although 2 dimensions are most common for visible surfaces. Rendering APIs typically manage texture map resources (which may be
located in device memory) as buffers or surfaces, and may allow 'render to texture' for additional effects such as post processing or environment mapping.
They usually contain RGB color data (either stored as direct color, compressed formats, or indexed color), and sometimes an additional channel for alpha blending (RGBA)
especially for billboards and decal overlay textures. It is possible to use the alpha channel (which may be convenient to store in formats parsed by hardware) for other uses
such as specularity.
Multiple texture maps (or channels) may be combined for control over specularity, normals, displacement, or subsurface scattering e.g. for skin rendering.
Multiple texture images may be combined in texture atlases or array textures to reduce state changes for modern hardware. Modern hardware often supports cube map
textures with multiple faces for environment mapping.

17
Texture space:
Texture mapping maps the model surface (or screen space during rasterization) into texture space; in this space, the texture map is visible in its undistorted form. UV
unwrapping tools typically provide a view in texture space for manual editing of texture coordinates. Some rendering techniques such as subsurface scattering may be
performed approximately by texture-space operations.
Baking:
As an optimization, it is possible to render detail from a complex, high-resolution model or expensive process (such as global illumination) into a surface texture (possibly on
a low-resolution model). Baking is also known as render mapping. This technique is most commonly used for light maps, but may also be used to generate normal maps and
displacement maps.
Throttle: A device that controls the amount of air flowing into the engine.
Tifosi: Italian Fans.
Time Penalties: Should the stewards choose to impose a time penalty the offending driver must, in normal circumstances, proceed to the designated area and remain there
until a specified time period has passed, after which the driver may re-join the race.
Torque: The twisting force produced by the engine. It can be portrayed by two forces of equal intensity but opposite direction, acting at the opposite ends of the diameter of
the camshaft, where it attaches to the flywheel. (add Picture)
Torsion-bar: A suspension part that acts as a spring when twisted by the wheel’s movements.
Traction: The ability of the rear tyres to grip the track surface and cause the car to accelerate.
Traction control: Electronic equipment, relying on sensors, that allows the car to accelerate as fast as possible without losing traction and the wheels spinning. This system
was outlawed for F1 in the ‘94 season.
Trafficator: A direction indicator device, common in cars until the mid-1950s, consisting of a semaphore arm containing a small light that sticks out of the side of a car to
show which way the driver intends to turn. They were replaced by vastly more effective flashing indicator lights on permanent view on a car’s bodywork.
Transaxle: The term for an assembly that combines the gearbox and differential components in a single casing.
Transmission: All the components of a car’s drivetrain, although often it refers to the gearbox alone.
Transmission tunnel: The raised section running lengthwise along the centerline of the cabin of a car with a front engine and rear- or four-wheel drive. It houses the propshaft.
Transverse engine: An engine that is mounted with its crankshaft axis across the car, rather than parallel to its centerline.
Tuned: A term to describe an engine that has been modified for added performance.
Turbocharger: A device fitted between an engine’s inlet and exhaust systems that uses the exhaust gases to drive a turbine. This in turn drives a compressor that forces air
into the intake system, boosting engine power when the car is under hard acceleration.
Turn-in: The point on the track where the driver starts to steer the car into a corner.
Turning circle: The diameter of the circle described by a car’s outer front wheel when turning with its steering at full-lock.
Twin-cam: See camshaft
Two-stroke engine: An engine with pistons that move up once and down once (performing two “strokes”) in the combustion cycle.
Two-wheel drive: Transmission to the front two or rear two wheels only, in contrast to four-wheel drive.
Tyre Blankets: Special electric blankets placed over tyres just before a start to keep them up to racing temperature.
UI: In the industrial design field of human–computer interaction, a user interface (UI) is the space where interactions between humans and machines occur. The goal of this
interaction is to allow effective operation and control of the machine from the human end, while the machine simultaneously feeds back information that aids the operators'
decision-making process. Examples of this broad concept of user interfaces include the interactive aspects of computer operating systems, hand tools, heavy machinery
operator controls, and process controls. The design considerations applicable when creating user interfaces are related to, or involve such disciplines as, ergonomics and
psychology.
Generally, the goal of user interface design is to produce a user interface that makes it easy, efficient, and enjoyable (user-friendly) to operate a machine in the way which
produces the desired result (e.g. maximum usability). This generally means that the operator needs to provide minimal input to achieve the desired output, and also that the
machine minimizes undesired outputs to the user.
Unblown: An engine without a supercharger or turbocharger, properly termed “normally aspirated.”
Undertray: A cover with a flat or shaped surface that bolts to the underside of a car to create better aerodynamics or protect components from damage.
Understeer: Understeer is characterised by the front end of the car losing grip. This gives the rear of the car a tendency to carry straight on, through a corner.
Unibody construction: A car structure, now almost universal, in which the car body bears all the structural loads. It is, effectively, the chassis and the body combined in
one strong unit.
V4, V6, V8, V10, V12, V16: The designations for engines designed with their cylinders arranged in a V-formation for compactness. The numbers relate to the number of
cylinders in each engine.
Vacuum advance: A mechanism that enables the distributor to adjust spark timing according to engine load.
Valvetrain: The parts of the engine that control the operation of the valves.
Vanilla (AC): The official version of the game, including all the original files, without any mod (in particular CSP).

18
VPN: A Virtual Private Network extends a private network across a public network and enables users to send and receive data across shared or public networks as if their
computing devices were directly connected to the private network. The benefits of a VPN include increases in functionality, security, and management of the private network.
It provides access to resources that are inaccessible on the public network and is typically used for remote workers. Encryption is common, although not an inherent part of a
VPN connection.
A VPN is created by establishing a virtual point-to-point connection through the use of dedicated circuits or with tunneling protocols over existing networks. A VPN available
from the public Internet can provide some of the benefits of a wide area network (WAN). From a user perspective, the resources available within the private network can be
accessed remotely.
VPNs cannot make online connections completely anonymous, but they can increase privacy and security. To prevent disclosure of private information or data sniffing, VPNs
typically allow only authenticated remote access using tunneling protocols and secure encryption techniques.
The VPN security model provides:
• Confidentiality such that even if the network traffic is sniffed at the packet level (see network sniffer or deep packet inspection), an attacker would see only encrypted data, not the raw data.
• Sender authentication to prevent unauthorized users from accessing the VPN.
• Message integrity to detect and reject any instances of tampering with transmitted messages.

Common misconceptions:
• A VPN does not make your Internet "private". You can still be tracked through tracking cookies and device fingerprinting, even if your IP address is hidden. From that perspective, using
adblockers (advertisement blockers) like uBlock Origin, and applying more restrictive privacy settings in the browser is much more effective.
• A VPN does not make you immune to hackers.
• A VPN is not in itself a means for good Internet privacy. The burden of trust is simply transferred from the ISP to the VPN service provider.

VR: Virtual reality is a simulated experience that can be similar to or completely different from the real world. Applications of virtual reality include entertainment (particularly
video games), education (such as medical or military training) and business (such as virtual meetings).
Currently, standard virtual reality systems use either virtual reality headsets or multi-projected environments to generate realistic images, sounds and other sensations that
simulate a user's physical presence in a virtual environment. A person using virtual reality equipment is able to look around the artificial world, move around in it, and interact
with virtual features or items. The effect is commonly created by VR headsets consisting of a head-mounted display with a small screen in front of the eyes, but can also be
created through specially designed rooms with multiple large screens. Virtual reality typically incorporates auditory and video feedback.
Wagon: A square-backed car that is adapted to carry cargo, with a load bay accessed by a fifth door or tailgate, or else twin hinged doors. The term was originally coined for
a utility vehicle used for running errands on large country estates.
In the US, it is called a station wagon.
Water-cooling: A system that uses circulating water to cool engine components. It is the predominant cooling system in modern engines, although some use an air-cooling
system.
Waterfall grille: A curved radiator shroud as a styling feature on the exterior nose of an older car, whose bright metal slats and cascading shape give the impression of a
waterfall rushing over the car’s metal prow. They give the impression of being aerodynamic, although frequently they are not.
Wet-liner: A cylinder liner that is in direct contact with the engine’s liquid coolant.
Wheelbase: The exact distance between the axes of the front and rear wheels.
Whitewall tires: Tires featuring a decorative ring of white rubber on their sidewalls. It was a popular styling fad, particularly in the US, from the late 1930s to the early 1960s.
And they still rock as hell.
Wings: Devices fitted to the front and rear of the car which produce aerodynamic downforce. This allows faster cornering speeds. The rear wing also produces significant
aerodynamic drag. Wings mounted upside down give negative lift and hold the car down.
Wishbone suspension: An independent suspension system that uses two wishbone-shaped arms to link each wheel hub to the chassis.
Works driver: A racing driver employed by a car manufacturer to drive for its team, as opposed to an independent “privateer.”

19
 PART 1:
ASSETTO CORSA
USER MANUAL

20
Assetto Corsa - Unofficial user manual

1 - Is Assetto Corsa worth buying?

The short answer is yes. Today, there are many racing simulators on the market for PCs and consoles. Most are good, many are great, and few are horrid.

Assetto Corsa (Italian for 'race trim' or ‘race setup’) is not a game. It is a superb simulation software from the Italy based studio Kunos Simulazioni SRL,
located at Vallelunga, just inside the international racing circuit, allowing the development team to work with the cooperation of real-world racing drivers and
teams.

It comes with a proprietary tire model, a licensed sound engine, realistic physics and aerodynamics. The exteriors and interiors of the cars are fully modelled
and the tracks are laser-scanned. This software is really good to enjoy a particular car on a particular track. It’s polished in all the essentials: realism, visuals,
immersion, configurability, expandability, performance, stability, and usability.

A proper wheel is strongly recommended to feel the car and the road through a detailed Force Feedback. The vanilla release requires at least a good mid-
ranged PC for an enjoyable gaming experience.

Pro tip: AC can reproduce the experience of race driving with a high degree of realism. But it is not the real thing. It will never be the real thing. Always keep this in mind. This
is due mostly to the numbers you input in the simulation: the physics engine is just a mathematical solver, and what makes the vehicles “feel” right is their specific data. It
means that with the right input values, AC can be almost identical to real life in terms of physics, but often the specifications are strategically kept confidential by car manufacturers
or simply are not available (especially with historic and exotic vehicles). In addition to this there are other variables, for example human errors while interpreting vehicle data
and dynamics. Heck, there’s still a lot of research going on in this field. That’s why all kinds of engineers exist, so you don’t have to worry about it. Also, consider that even if
the software is a simulator, its public release was meant to be fun and satisfying 1, being designed for common people. If the cars were truly accurate, you’d have a harder time!
Kunos made compromises.

This simulator was born with moddability in mind, so you can create your own vehicles and tracks, along with the physics and much more, which later will
become the main topics of this manual. Mods have less boundaries in terms of how accurate they can get, within the limitations of the software.

Actually, some of the most detailed cars in AC were originally mods: for example, the Lamborghini Miura P400SV, the Porsche 917/30, the Shelby Cobra
427 S/C, the Nissan Skyline GTR R34, the Mazda Miata, MX5, 787B, the Audi Sport Quattro (even the rally S1E2). Sometimes the models were made by
third-party 3D artists instead; the Alfa Romeo GTA, the Mercedes C9 LM 1989, the Lamborghini Countach, the Ford Escort MK1 RS 1600 and the Praga R1
were all made by Mirza Rustemović, senior vehicle artist at Studio397, who created vehicles also for rFactor 2 and The Crew 2. Due to their high quality,
Kunos bought some mods and probably commissioned a few models. It doesn’t mean that devs didn’t do anything, what were you thinking?

Not only that. Users started making graphic modifications to the vanilla game engine, altering the original shaders. That’s where the most popular AC mod
excels, and it’s called Custom Shaders Patch (CSP), made by Ilja Jusupov (aka x4fab). The sim is almost unrecognizable after installing it, and new features
are added and expanded with every update of the mod, bringing over time also physics corrections and bug fixes, even if AC is not supported anymore by
Kunos, and it is considered EOL (End-Of-Life), meaning that there will no longer be updates. Mods prolonged the lifetime of this simulator to this very day.

If you still have doubts, there’s been a period in time when Ferrari used a modified version of AC (AC Pro) in the simulators for road cars. It’s worth noting
that in 2014 their F1 team switched to RFactor Pro (which software they used before is unknown, but it may have been something made in collaboration with
Kunos, as there’s been a close relationship between the software house and the Italian car manufacturer). Below is just a small proof (Fig. I).

Fig. I – Photo taken from an in-house Ferrari simulator. This image is publicly available, so no worries. Does it remind you anything? Upscaled and enhanced like in movies, obviously.

AC Pro is an AC release for projects that involve a commercial and public use (industrial, training, marketing and promotional applications), distributed upon
direct request to professionals. I can’t say the exact number, but the price is more than 1500 euros at least. It is for the most part like the normal AC, but with
a view mode that can turn off any visible object (Proview), and an empirical tire model that reads from a custom look-up-table with OEM data. Comes also
with some features added so that you can use your own graphics and/or physics engines, and the models of the cars you want can be created by Kunos (or
with their assistance) and included in the package; you will also be granted with their customer support service.

1
In an interview with Kunos back in 2012, Aristotelis Vasilakos stated: “there is no reason why the experience of the user shouldn’t be fun and easy. We started [AC development] with that mindset”.

21
1.1 - AC vs ACC. What’s the difference?
With the 2019 release of the successor title, Assetto Corsa Competizione (ACC), updates and official support to Assetto Corsa have ceased. Yet, the
community continues to thrive, mainly because ACC contains only the tracks and cars in the events of the GT World Challenge series – firmly titled the
Blancpain Endurance Series. The cars and tracks are modelled very accurately and updated each season with the respective official liveries, and new
vehicles such as the BMW M4 have also been added.

AC instead is a generalist sim: supports many tracks and cars, including road vehicles. It can be modified in almost every regard; the opportunities are
seemingly endless. This sim is not tied to any official series, and that gave the developers creative freedom to go make it as versatile as possible.

- The game modes in both titles are fairly predictable for modern racing titles. Both have quick races, time trials, practice sessions and customizable
championship modes. Competizione includes a few extras such as hot stint mode, hot lap superpole and official race weekends, while AC has a time attack
mode, drifting and drag racing. Both have career modes as well, although not mind blowing. However, the career should not be the focus of any simulator,
as it is not a game.

- From the point of view of graphics, ACC is slightly more realistic and polished, even if vanilla AC looks very good too (Fig. II).

Fig. II – At first glance there’s not much difference, but when playing it’s noticeable. However AC can be on par if not better, thanks to CSP and other graphic mods.

- Technically wise, ACC mainly runs on the Unreal Engine 4 (UE4) by Epic Games for the graphics (Fig. III), while AC's graphics and physics engines were
built in-house by Kunos.

Fig. III – Details about ACC’s physics from a Kunos developer (Gergő Panker).

Quoting some posts in the official forum by Stefano Casillo, founder of KS:

“ACC physics was lifted straight from AC1. Physics is implemented in a static lib and data is sent back and forth from UE4 that is only used for graphics. UE4's physics
engine was later used to implement audio query for things like dynamically changing reverbs.”

“In AC car data was coming in using text files... in ACC we were forced to use UE4 data system to input values, so car data input is done through the UE4 data editor
instead. [...] But ACC UE4 side simply loaded the data from the UE4's data system and forwarded them to our "AC1" engine that did the rest of the work. Same goes for
things like the track geometry: ACC UE4's side would read the triangles of the 3D model and sends them down to the physics that creates its own "version" of the world. This
might sound like a weird approach and it is, if you think about developing a game from 0 in UE4, but our situation was quite different as we came from a software like AC that
was designed from the start to have totally separated "worlds" for physics and graphics... thus making it quite easy to lift the entire physics system from AC and "plug" it in
UE4.”

22
The physics engine is the same, more refined because the developers could take their knowledge from AC and improve it, and because the focus is much
narrower. For example, Competizione v1.2 introduced chassis flex simulation (Fig. IV), intentionally avoided in AC due to the fact that, quoting Aristotelis
Vasilakos,

“[...] we didn’t have enough data to implement such a complex feature and we didn’t have the experience to know how to judge if said data and implementation would work
properly or not.”

Fig. IV – Simulation shared by Aristotelis Vasilakos (KS dev team) to demonstrate the progress on the chassis flex model. (left) Static frame. (right) Chassis under tensile stress.

For a lengthy explanation about this major feature, see Fig. V below.

Fig. V – General description of the chassis flex portrayed by ACC from a KS developer.

Another implementation brought by ACC is the five-point tire model: AC has only one contact point for each tire, to make it less performance demanding,
and this generates collision detection problems, especially when going across kerbs (most of the time a single contact point is fine).
Even if graphically the tire starts to be “on the curb”, the actual point still remains down on the asphalt (Fig. VI left). This also tricks the mind of the driver,
because in real life, if the edge of the tyre touches the curb surface, the driver will hear and feel the tyre touching the edge and take appropriate action or at
least he will know he is gradually going over the curb. In AC this won’t happen. As an example, many people see in real life the left inner curb of Eau Rouge
(Circuit of Spa-Francorchamps) being dirty from tire skid marks and think that real drivers abuse the curb. They try to do so in AC and get an instant spin.

23
Fig. VI – (left) At some point the single point will go over the curb. Instantly the physics will consider a surface inclination of let’s say 30°. This is an extremely big change on the contact
point and a huge spike in load and rolling resistance, resulting also in big spikes in the grip. (right) Often the tire can be over a stepped curb, with the outer side going over the shallower
part of the step, and the inner side going over the completely flat part of the curb, leaving the contact point hanging through the deepest region. The result is that the tire will read and
portray the worst possible condition of the curb, something that in real life would never occur.

Consider also the following situation: you are on the limit of grip in a turn. The outside wheels are right on the edge. You climb with your front inner tyre on
a high curb. This means that you raise the front inner end of the car and thus you load more the rear tire. The latter, already at the limit of its adhesion,
cannot afford any more load, so it starts to slide. In AC the front inner tyre will also take a huge spike in load and rolling resistance, so it actually brakes for
a moment and throws to the suspension more forces than it should. Those end up to the rear suspension and wheel, which loses even more grip. Usually
in very stiff race cars, the inner rear tire might even go airborne losing all grip and forcing the differential (if locked) to give even more torque to the outside
rear tyre (Fig. VII left).

Fig. VII – (left) Rear tire going airborne on a GT3 car. (right) If during the whole process you also remain with your foot on the accelerator, you will have a situation where the rear outside
tire pushes forward with less lateral grip while the front inner tire pushes backwards. Practically your car is transformed to a tank with treads that move at different speeds.

Finally, some kerbs have an almost vertical step at their outside edge (Fig.).

Fig. -

24
Often the driver will ride and go over the edge of said kerb and then slowly return to the main road going almost parallel with the curb. Adding full 3D flex
(yes, another feature) of the contact point (only vertical in AC), created in the initial development stages of ACC a critical condition in the above scenario. The
single contact point would go to the vertical parallel side step and being as high and vertical, instead of climbing over it, it would start to flex outwards,
practically getting trapped in a rail. The driver would see that the car wouldn’t follow his commands to re-enter and at some point he would move some more
the steering wheel, creating more lateral force than actually needed. The front tyre contact point would climb over the step and then obviously would have
excessive slip-angle that would steer the front end very fast. At the same time, the rear tyre would be in the same condition and still trapped, so it won’t be
able to follow the rotation of the car and will continue straight ahead in the rail, practically inducing the car into a very fast spin.

This is one of the most well-known and widely reported “curb of death” situations in AC. To solve the problem, since version 1.0.7, ACC features a 5-point
contact model. Kunos implemented 2 contact points at the edge of the front of the tyre footprint, 1 in the middle of the footprint and 2 more contact points at
the edge of the rear of the footprint. Each single point moves and flexes independently reacting on forces and surface contact, but also, predictably obligates
to move the other points together, averaging the resulting forces and collision vectors, giving a much better representation of what an actual tyre would do.

Examining the examples of Fig. x & y again, we can observe massive improvements of how the new tyre model reacts.

On the first smooth high curb situation, the advantages are multiple (Fig.).

Fig. -

First of all, when the edge of the tyre touches the curb it activates the sound and properly moves the FFB steering wheel, thus communicating at the driver
the correct width and position of the tyre. Furthermore, the contact points at the edge of the tyre, get the spike of the steep angle of the curb, but their forces
are averaged to the rest of the contact points that are still on a flat surface. The tyre actually “climbs” over the curb, instead of instantly finding itself on top of
it. There are no more load and angle spikes as before.

So obviously if you are too aggressive the rear tyre will lose grip and can still provoke a spin, but the result is no more exaggerated.

On the second example, the contact points now include the whole width of the tyre and if that’s the case successfully keeping the middle of the tyre in the air
while also being spread longitudinally in the footprint length. There is always a contact point touching the surface at the front or the rear of the footprint even
if the tyre is rolling on the steps. On top of that, the extra points are controlling for load spikes and avoid situations of excessive rolling resistance or vectors
that point backwards to the car motion.

This greatly improves acceleration over stepped curbs, as in example at the exit of turns, which in the past, drivers would avoid in order to not harm their
acceleration.

Finally, on the most important third example, as clearly explained before, the multiple points permit the tyre to “climb” over obstacles. So when the edge of
the tyre hits the vertical step of the edge of the curb, those contact points start to flex and go parallel “entering the rail”, but the rest of the contact points,
still push through the direction and push also the edge points to climb the edge. The driver doesn’t have to do anything with the steering wheel, and the tyre
simply goes over the edge of the curb without any dramatic situations.

As an extra bonus, the devs also added a new dynamic feature to the tyre flex behavior. As previously mentioned, the footprint of ACC’s tyre model flexes in
three dimensions. Going even further, the lateral flex provokes the tyre to lower its profile. This means that the more it flexes laterally, the more the ride height
lowers. Obviously the change in ride height is minimal, but in a car with proper simulated aerodynamics even few millimetres are important to the handling
and balance. You might notice a bit less understeer on power exit with cars having the engine on the rear and in the middle, since the lateral flex of the tyre
will bring the nose very slightly lower. Gives a bit more control to the front end of the car.

Lap times remain more or less equal and general balance of the car setups doesn’t change, except for better precision, stability and predictability of the tyres
both on and off the curbs.

Don’t forget about the dynamic weather and time of day that’s missing from AC! Other relevant features introduced in ACC that are worth mentioning are:

• ACC v.0.7 brought brake ducts simulation and a brand-new tyre damage model;
• ACC v.1.2 introduced the selection of different brake pads and wear for brake pads and brake discs;
• TC and ABS work exactly as in the cars. So higher numbers mean more intervention. Lower numbers mean more sliding etc.

25
• Unlike AC, in ACC car setups preserve the alignment: caster, toe and rod length (that defines ride height) remain to whatever values the player has chosen. You don’t need
to adjust everything when changing a setting. For example, if you have 60mm front height and you want to change the spring stiffness, you click on the spring stiffness and
the game will keep the 60mm height without having to adjust it manually as in AC. Inversely, if one wants to stiffen the springs, the game will automatically reduce the rods
to leave the car on same height and as such won't get the alignment altered. Another situation: in AC if you go from full fuel to empty fuel tank, the car (while in the setup),
will raise and you'll get higher ride height, different camber and toe settings from the suspension movement and so on. In ACC the ride height and alignment will remain
the same. For someone used to the older title, getting used to ACC may feel strange. In AC you’re the mechanic, in ACC you’re the pilot/race engineer, someone else does
the work for you. You give the orders to the mechanics, like in the real world. “They” will do everything necessary to keep the setup and just change whatever you wanted.
But this implies a little less freedom.
• there is more…

- ACC cannot be modded very easily, aside from car liveries, due to the Unreal Engine project encryption (but some people managed to bypass it and
convert the models anyway).

- Moreover, ACC is still officially supported and continuously improved.

- At the beginning some people believed that Kunos made a mistake with ACC, limiting their options to GT3 cars. The consensus is that they doubled-down.
Many fans were miffed by this and felt betrayed, complaining that such vehicles provide an unsatisfactory and underwhelming driving experience.

I say that they could not have made a better choice instead: let me explain why.

While GT3 can be no fun for an amateur driver who enjoys slower paces and different automobiles, it is the most popular non-F1 racing class in the world.
This not only means being able to gain exposure to the public and to the concrete world of motorsport (thanks to the official series), but also being joined by
the best teams and having easy access to more accurate data, understanding and interpreting car behaviors in a better way, developing software technology
in tandem with the progress of car mechanics. This would have been extremely difficult had they followed F1 where every car is almost a top-secret invaluable
item. Formula games will never be accurate; many discussions about it are futile 2.

Later in development, in mid-2020, Kunos started adding GT4 cars to ACC with the release of the GT4 Pack DLC. These cars, having a softer and bouncier
handling, revealed bugs and problems in damper calculation that were later fixed and retroactively applied to the GT3 cars.

This demonstrates that you always have to remember the following: Competizione is just a learning phase for Kunos. It is not a REVOLUTION, it is an
EVOLUTION. It's not that they do things for nothing. This was already the case in AC, where various cars were interpreted even in the absence of data. Very
often manufacturers do not have the necessary specifications, and much of the work must be reserved to the judgment of the simulation programmers.
Indeed, many cars in the original AC do have estimated/guessed values at best.

Thus, AC2 will benefit of ACC’s lessons and will definitely become the next AC, as the physics engine will be natural heir of its predecessors, and it may even
be backwards-compatible if the system with separate configuration files for the vehicle physics will be brought back. What will really interest me is the new
graphics engine.

- In the end, AC and ACC are two separate simulators (Fig. III).

Fig. III – Two titles that changed the history of sim-racing forever.

It’s crazy how some people bought AC Competizione and thought it would work with mods and Content Manager. No, don’t laugh, I’m serious, it happened.

Is it finished? …it’s getting smaller

2
And don’t even get me started on the fact that Codemasters’ F1 game series began using LIDAR laser-scanned tracks only in 2022. With the budgets they have.

26
1.2 – AC feature list
Below are the main characteristics of Assetto Corsa, so that you can compare it with other racing titles.

In general
• Accurate modelled cars (physics, aerodynamics, exterior & interior)
• In depth car setups, values in SI units
• Tires: accurate wear curve, degradation (blistering, graining, overheating), flat spotting (vibration)
• Damage model: visual (body), engine (accumulative), gearbox, suspension, steering, aerodynamics
• Laser-scans for many tracks (traditional modeling approach for the others)
• Multitude of driving aids
• Pit stop system: animated pit crew, tyre changes, refuelling
• Flag system: checker flag, yellow, blue and black flag
• Dynamic track surfaces
• Dynamic time of day in single-player (limited to hours)
• Weather conditions: light/heavy fog, clean/light/heavy cloud
• Complex audio engine (powered by FMOD)
• Post-Processing filters (PPFx): many on-the-fly presets, glare, depth of field, color saturation, motion blur, crepuscular rays, heat shimmering
• Dedicated server client with basic admin commands
• Modding tools (cars & tracks)
• Built-in photo mode
• Replays (file size limitations may apply)

Singleplayer
• Three offline driving modes: practice, race, and challenge.
Practice: you choose whichever car and track combination you desire. You are alone on the track. So, it is suited to learning a new track or getting acquainted with a new
car.
Race: gives you total control over the selection of the track, the car, and the opponents. There are three options for choosing opponents: the single option forces all the
opponents to drive the same car you chose; the random option mixes things up by selecting the number of opponents and their cars, based on the difficulty level you
chose; the custom option allows you to choose the track, the car you drive, the number of opponents, their strengths, and the cars they drive.
There are three types of races: in a quick race, you start on the grid at a position you chose; in a full race weekend, you practice, you qualify for a starting grid position,
then you run the race. The session parameters - time of day, ambient temperature, track surface condition, starting position, race length, and whether or not to enable the
penalty assessments - can all be set.
Drag races are included, and are very straightforward. You must out drag your AI opponent, who is driving in the adjacent lane. Dragging is a test of talent for timing and
touch. You are allowed seven runs, and you must win a majority of the runs. You will probably need to tune your car to win a drag race.
Challenge: has four types of events: time attack, hotlap, drift, and special events.
Within a time attack your task is to drive lap after lap, flat out, until you reach or exceed the maximum points. There are three sectors on each track, with a timing gate at
the end of each sector. Driving through a timing gate earns you points. The catch is that as the laps wind on, the allotted duration in which you must reach the next timing
gate is shortened. Eventually, you run out of time, and the challenge ends. If you did earn the maximum points before the time runs out, you win the event.
Hot lap is similar to a time attack in that you drive as fast as you can, as long as you can. But the goal of this challenge is to surpass your previous hot lap time.
Drift requires you to collect points by drifting throughout the entire track. To earn enough points to keep progressing up through the levels, you need to drive sideways,
even on the straights. Otherwise, you will not earn a sufficient amount of points, before the time runs out.
A special event can be a drag race, a drift event, a track race, a time attack, or a hot lap. However, you cannot alter its parameters. In a track race special event, for
example, the car is chosen for you, you cannot alter the number of AI opponents, you are always dead last on the grid, each race is five laps, and you must progress
through four difficulty levels - easy, medium, hard, and alien. You can win even at the most difficult level with 100% AI strength, but you are unlikely to achieve this,
without altering your car’s factory set-up to some extent. In drag races the opponent will be an identical car, while in hotlap instead of your previous best, three lap time
targets, each progressively quicker, are pre-defined. The same applies to time attack special events.
• Career mode: racing games like Gran Turismo make a big show of the career mode, which obliges the user to progress from circulating mind-numbingly short tracks in
insipid cars to driving around full-length tracks in unrealistically fast cars. After having paid a substantial sum of money for the game, the user must still step through a
plethora of low-level career stages, before he can experience the fun bits - driving proper race cars on long racetracks. Racing simulators, like AC, do not foist upon the
user a mandatory career mode. Instead, he can drive whatever car he fancies on whichever track he likes. But AC also supports novice (N), intermediate (I), trofeo (T), and
so on, all the way up to advanced (A) career levels.
There is not much to say about the career mode. You start with a slow car that is relatively agile (Abarth 500 EsseEsse). To unlock the next level of career, you must earn
points and medals by winning races in the present level.
• Automatically generated list of favourite combinations
Multiplayer
• Online mode, LAN
• Server client included
• Public servers with Booking or Pickup mode, can feature mod-content thanks to server-client checksums

Missing features in comparison to other simulators / driving games:

Dynamic time of day in Multiplayer (brought by CSP?)
Dynamic weather (brought by CSP)
Server controlled rolling start procedure
Day and night cycle (brought by CSP)
Spectator mode (online, broadcasting)

27
1.3 – History of AC
Assetto Corsa is not the first title made by the software house Kunos Simulazioni. Actually, the first title is from a period when the company didn’t even exist
yet: we’re talking about netKar. Made by a single person: Stefano Casillo (founder of KS in 2005 and lead developer until 2020), a genius and a perfectionist.
According to him, he developed the software at home in the evening, as a personal project. When he started in 2001, he had neither the knowledge nor the
experience in implementing real-time simulators. He acquired the necessary skills by reading mechanical engineering textbooks. Impressive, that.

netKar “Namie” was the nickname for the release 0.9.9 of netKar, created in 2003 (Fig.). That version is the last free sim ever released by Casillo. You could
drive only with a steering wheel or a joypad, as there are no mouse/keyboard inputs. But it did have mods!

The release 0.9.6 was called “Elisa” and the 0.9.5 “Kuraki”. If you don’t give names to your software, you aren’t truly having fun.

Fig. – The early days of Kunos were humble, but with a ton of effort. (Top left) The cockpit of the Ferrari 360 Modena parked in Imola’s pits. (Top right) The Ferrari 250 GTO’s model in
the garage. (Bottom left) Side view of the Toyota Supra JGTC. (Bottom right) The Pagani Zonda C12 S at Falkenberg. All of the pics from netKar Namie.

Actually, Casillo likes the culture that comes from Japan, and the name of the company itself, “Kunos”, is the fusion of two words: “Kuroi” and “Neko”, which
mean “Black Cat” in Japanese. That’s also the KS logo, and the name of one official, fictional track: Black Cat County. Why a cat? He loves them.

netKar subsequently became KS’s netKar Pro (Fig.) in 2006 3, which added a ton of features, including rain weather and keyboard/mouse support.

Namie 0.9.9 had two main flaws on the chassis physics: one was in the anti-roll bars code, and it is easy to exploit hitting a curb hard; this will throw the car into a roll on
itself. The second flaw was in the reaction torques at the differential generating a couple on the body moving too much weight back and forward as function of engine
torque. (Stefano Casillo, 2005)

The sound engine was most likely using QSound 3D dependencies, as the game had QMDX.dll in the files.
The entire software structure was then changed and what was a modular software solution in netKar “Namie” became a monolithic structure driven by scripts
and databases. In nK 0.9.9 there was a main simulation program (nks.exe) that connected to a client module for multiplayer (nkClient.dll) and cars' modules
(f3000.dll, mini.dll, etc.). In netKar Pro instead everything was easier and held into the nks.exe file. Also, the basic sound engine became DirectSound.

3
Also stylized as nKPro.

28
Fig. – (Top) A screenshot from netKar Pro, with the Formula KS2 at the Aosta track. The visuals are still holding up to this day; they’re very beautiful indeed, even after all these years.
(Bottom) The car and track selection menus (5th Anniversary version) with the Osella and Trento-Bondone.

That simulator was very popular on the market, enough to be the protagonist of various commercial agreements, even with Abarth during 2009 (Fig.).

Fig. – (left) Two Abarth-shaped PCs (at the time powered by Intel’s top-of-the line i7 core processors) at the "My Special Car" exhibition in Rimini (Italy), designed to run a Special
Limited Version of netKar Pro (called Trofeo Abarth 500). (right) The PC without the panels. Back then having two DVD drives was a pro gamer move!
29
The netKar engine hatched a string of well-respected titles (Fig.) often forgotten, because they consisted of promotional software, including Marangoni Hill
Climb Simulator (title from 2007 with the Osella PA-21 S), Trofeo Abarth 500 (2009, already mentioned above) and Ferrari Virtual Academy (2010), which
enjoyed a rare blessing of Maranello. These old-school simulators all had one thing in common: they were as spartan as they could get: there were no AI
opponents, as the purpose was to play online races in multiplayer. In single player you could take the cars for a practice/hotlap session.

Fig. – A shot from one of each netKar-era title from Kunos. The contents of Marangoni Hillclimb and Trofeo Abarth 500 were included in the final release of NetKar Pro, that’s why you
can find the Osella in Fig. too.

We know for a fact that NkPro was mod-friendly. In fact, Kunos did support what they called the nK|dK (netKar Development Kit), which allowed the community
to create additional cars for the simulator. One important element with the creation of nK|dK was the possibility to deeply analyse the car's behaviour in an
engineering-like environment and compare it with theorical and experimental data from books and other sources.

[…] nothing is "cheated" and you can check the formulas from your car dynamics book with the simulator and find the same results […]. (Stefano Casillo, 2005)

Moreover, we know for a fact that at least until 2006, netKar Pro used a PAC-96 tire model:

The main element of our simulation was the subject of a total rewrite. The model is now a Pacejka 96 full model with integrations for temperature and pressure changes
plus some integration for dynamic behaviour for the quick spinning on the Y axis of the tire (quick steer).
What I really love about this Pacejka's model is the incredible control it gives on the relationship between longitudinal and lateral forces plus the ability to reproduce a
tire with 3 different "zones": a linear zone, a sliding zone, and a frictional zone once the tire lost the grip. I find the linear zone often missing, generating a tire that is in
"sliding" mode all the time... giving a sort of "floating" feel to it. In netKar PRO, you get a clear linear zone that gives the tires an incredible amount of "bite": you really
need to push the car to get into the "sliding" mode of the tire and this makes driving fast with netKar PRO a very different experience, where you literally throw the car into
a corner at speeds that most of the time you won't believe and you'll handle it on the edge. [...]
I turned off the automatic surface smoothing featured in nK 0.9.9, and this makes the ride really scary on the stiff lower cars and you'll often find yourself bottoming
around shaking like crazy. The fact of driving directly on the triangles of the track also gives meaning to the idea of "fast bump and rebound" settings... mostly unused
before, you'll need these badly to set up the attitude of the car on bumps. I was able to turn off the smoothing because the new tire model is so good to handle the
contact/no contact situations, much better than the old one. (Stefano Casillo, 2005)

As a small curiosity, netKar’s combined graphics/audio engine was called “Dracula”, and its source code was publicly released.
Not only that, but a motorbike simulation was made: netBike. It doesn’t end here. Lord Kunos 4 tried to make a soccer game: netFive, which somehow I
managed to get footage of, but trust me, it was literally a ball on a field, that’s not worth showing. Sadly these were test projects which died very early on, and
were never finished.
It shall be said that Stefano started approaching the world of programming at an early age. We had the privilege to ask him few questions about his life 5.
Here’s a little excerpt:
Interviewer: What were you doing before you began self-studying programming?
Stefano: I started at 10-11 years old, so really nothing. But when I really got into it, I was playing and teaching electric guitar.
I: What made you want to study programming on your own?
S: I always enjoyed making games and nobody around me had any idea of how to start. So grabbing books and experimenting was the only way to make it happen.
I: How did you start (which resources and language)?

4
Aka Stefano Casillo. This nickname is well known in the official Assetto Corsa forum.
5
In reality, this monologue was taken partly from one of Stefano’s public posts on the social platform called Reddit and partly from his own personal blog (deleted long ago). I think it's more
authentic when things are said spontaneously. Interviews are boring.

30
S: Basic to QBasic to C/C++. At the time there was no internet, so book I could find around. I lived near an university with a bookstore, still remember the faces of the guys
seeing this 13 year old kid asking for C books!
I: How long did it take for you to feel confident enough in your skills and knowledge to know you could be employed as a programmer?
S: Once I got my first "finished" game done in C. Took me about 2 years.
I: What else did you do besides self-study that helped you in your journey to becoming a programmer?
S: Nothing, just enjoying what I was doing. My target wasn't really to get a job, I wanted to finish what I was working on. The realization that somebody could pay me to do it
came much later.

I: How did you get your job as developer?

S: My first couple of jobs were as Visual Basic/Java developer. When Fonderie Multimediali S.p.A. in Rome offered me a position as software developer for me it was the real
deal. But after 4 years working as software developer and hardly any contact with guitars and music I came back to Napoli and joined Infobyte as a Java 3D software developer.
The working enviroment was great. Time for a change again, Quantel offered me a position as Software Developer in Newbury, UK. There I had a lot of spare time, also for my
music. But I always had a passion for C++ and game development, so I used to leave office as soon as possible to get home to work on my hobby gamedev stuff in C++, often
even while in the office I was coding games when nobody was watching. I started to work on a tennis game, I wanted to try the approach “don't go for a huge difficult project,
go for a simple easy one”. But it was time to aim to something that would’ve changed people’s perspective, it was time for netKar! Eventually I had enough code and little things
to show to make up for missing formal education and, after a lot of attempts, landed my first job as C++ dev, interestingly enough it was not in the game industry but in the
video editing software industry.

Later on he would travel to Japan, following his passions. But that’s another story.

Assetto Corsa is recognized as the 2014 follow-on to netKar Pro. The strategy behind the product was presented to the public at the GGJ (Global Game Jam)
2013 of Rome. Stefano Casillo gave a talk there, giving background information (Fig.).

Fig. – Excerpt of the presentation showing which slice of the market Kunos wanted to appeal.

KS started developing AC from scratch with the Unity engine in 2009-10 (Fig.).

Fig. – An image from one experiment on the Unity game engine (2011). I believe the Tatuus was the first car in the game.

However, its prototype predecessor began as a project for the ACI’s driving school (Automobile Club d’Italia, the Italian Automobile Club). It was called ACI
Ready To Go (Fig.).

This was “the ugliest project to test in my life; driving at 30 km/h to see if there was a bug on the other side of the town; tremendous, horrible”, as Casillo
stated (2013). Made 90% in C# and with a little dose of C++ interfacing with the DirectX10 API.

31
Fig. – Probably the only existing shot of this experimental software. The car was a Toyota Yaris, in a Milan-lookalike town.

In 2011 however, they built a completely new in-house engine, due to constraints of external integrability i.e. not being modding friendly, the ugly motion
blur, the fact that the distance of each shadow cascade could not be adjusted (which was essential to have an extremely defined shadow in the car cockpit),
and long loading times: “30-40 seconds to load a track, absolutely unacceptable” (Casillo, 2013).

This “new” graphics engine would’ve been called the “Kunos DX11 Renderer”.

Kunos stated 6 that AC has basically nothing in common with netKar Pro in its code 7. It was done on purpose, to start fresh with the project. I can confirm
that this is actually true: not only netKar Pro’s executable (nks.exe, 1.8MB) is much smaller than AC’s one (acs.exe, 23MB), but also the internal structure is
different, and while common automotive terms are the same, many expressions of the first do not exist in the second (e.g., SUSWEIGHTFRONT,
ARMWEIGHTREAR, INERTIAX, OFSETTIREF, DRAWR, INTAKEK, PRESSUREK, IGNITION, etc.).

The sim is coded in multiple programming languages. C++ is used for the simulation and Google Go for the multiplayer server. The user interface and launcher
core is coded in C#, but the interface frontend in HTML to allow users to create interface modifications. That means allowing users to make a total conversion.
Python can be used for developing plugins for retrieving simulation data in real time. APIs used are DirectX 11 for graphics, FMOD for sound and ODE for
collision detection and rigid body physics. Originally the physics API was PhysX, but was changed to ODE by the end of 2012.

Below are listed the various versions of AC ever released, since the beginning of development:

PC demo
The Assetto Corsa Technology Preview was a playable benchmark that was released on 22 February 2013, in collaboration with Fanatec. The software was directly based on
build 0.9.9 of the simulator.
It offered one car, the Lotus Elise SC, and one track, Autodromo dell'Umbria in Magione, Italy, as well as two playing modes, free practice and time attack. The preview's
main purpose was to allow users to get their first taste of the game engine, test it, and report feedback. The preview required the player to own a netKar Pro license.
PC early access
Assetto Corsa was greenlit on Steam Greenlight on 13 June 2013. The game was released through Steam's Early Access program on 8 November 2013. This service allows
developers to release a functional but yet incomplete product, such as beta versions, to allow users to buy the title and help provide funding, testing and feedback towards the
final production. Through the Early Access program, the game received updates roughly every two weeks, adding new and improving existing content and features.
PC release
The Release Candidate, a feature complete version of the simulator, was released on 15 October 2014. The final version, following general bug-fixing and performance
optimizations, was released on 19 December 2014. The game continued to receive free updates, new features and paid DLC with additional content such as new cars and
tracks. The last update has been the release 1.16.3, delivered in 2018, with the EOL (End Of Life) of the product, ceasing its support 8. The only exception was the “Silent
Update” that came out unexpectedly in 2020 with release 1.16.4, now directly sold to new buyers of the sim.
Console release

6
In an interview for Drivingitalia.net back in 2012.
7
One thing they share though is the Trento-Bondone Hillclimb. That map was brought to AC from NetKar Pro (it was the same track in the Marangoni Hill Climb spin-off).
8
Kunos made explicitly clear since the beginning (in the GGJ 2013 presentation) that the support for the simulator would’ve lasted five years, until 2018. Everything was planned.

32
In May 2015, the PlayStation 4 and Xbox One version of the game was announced. It is published by 505 Games and was released after delays on 26 and 30 August 2016 in
Europe and North America respectively. Marco Massarutto, co-founder and executive manager of Kunos Simulazioni, states that the physics model of the console version is
identical to the PC version and the rendering and physics engines had to be rebuilt to better utilise multi-threading—the performance targets for the PlayStation 4 are 1080p,
60FPS, with the Xbox One "matching the PS4 as closely as possible". The console version of the game received an entirely new UI optimised for use with a gamepad.
On February 14, 2018, a new release called Ultimate Edition, containing all previously available DLC, was announced for consoles. This edition was then released on April
20, 2018 and is available also for PC.
Mobile release
In August 2021, a mobile port of the game was announced. It was officially released for iOS devices (iPhone and iPad) on August 31 and it was entrusted to Digital Tales.
The graphics are reduced to the bare minimum and not even comparable to the PC or console versions.

AC sets itself apart from the competition with its fanatical attention to detail. It is not without shortcomings, however.
For instance, it currently hasn’t (and will never have) official support for mist, rain, wet tracks, and loose surface rally tracks. Stefano Casillo confirmed in 2014
that Kunos, at that time, had no plans to support wet weather in AC, and that this feature was slated to appear in version 2 of AC (nowadays ACC). This
contradicted his vision from a year earlier, when he had mentioned rain and night racing as possible additional features (GGJ 2013 presentation). But none of
these shortcomings detract from the impressive achievements attained by the development team in a very short period: a topping simulator that is realistic,
immersive, fast, stable, and refined from the very beginning.
And I personally appreciate the fact that Kunos made it without a game designer.

We don’t have game designers at Kunos Simulazioni, because men with ideas, we don’t need them. If we need ideas we turn on [the TV], watch the Formula 1 race, and
the day after we have all the ideas we need. (Stefano Casillo, 2013)

33
1.4 – How many cars and tracks are there in vanilla AC?
Since its 2014 release, Kunos developers were able to expand precisely from 37 cars across 10 manufacturers to 178 cars and 24 manufacturers. A bit of an
improvement I would say. For a full list of the vehicles, see APPENDIX I of this book.

You can also visit this website for a more compact visualization: http://benobro.org/ac/cars.php. It’s very useful if you want to compare the vehicles on-the-
fly for your races, sorting them very easily (even if CM has filters for grids too, which you should learn to use). Be aware that the missing specifications are
due to unknown Kunos interpretations, industrial secrets and "historic epicness".

Regarding the quality of the vehicles, Kunos’ range for what was considered acceptable for the definition of the models (their polygon count) kept increasing
over the years (Fig.).

Fig. – (left) The BMW Z4, part of the base game (2013). (right) The BM4 M4, part of the Dream Pack 2 DLC.

If I recall correctly for the Ferrari SF70 they put way more detail compared to every other car in the game.

Meanwhile, talking about maps, the default game has 15 tracks, with extra layouts accounting for a further 20 course configurations. Four more tracks were
added as DLC, increasing the layout roster by ten. The fabled Nürburgring Nordschleife was added via the Dream Pack 1 DLC pack to the PC version of
Assetto Corsa in March 2015. In total, the sim has 19 official tracks with replete with 45 layouts.

It is worth mentioning that all the official tracks in Assetto Corsa were created by one person.

34
1.5 - How is AC for slow and amateur drivers?
- Slower cars often can provide the most rewarding experience for people with less skills. If the sensation of driving a car is what you're looking for in a sim,
then in my opinion nothing comes even close to Assetto Corsa.
- Raw speed doesn't guarantee wins. Consistency and respect for the rules is where you'll get good results. You can put in clean laps that don't involve
constant wheel twitches like in games and hybrid arcade simulators.
- If you keep running off the track and crashing into walls, slow down until you’ve learned with muscle memory how tire grip works in a simulator. It might
be very different from driving games you have played before. Learning with less powerful cars often helps.
- Use all the driveable surface of the track. It’s not there for nothing.
- Driving aids are available on each and every car: this gives you the chance to start with a lot of help, and altering the percentage of how much aids are on
allows users to slowly increase the difficulty level as their driving ability and familiarity with the car increases. With smaller cars, naturally this is easier, but
for more powerful cars it’s really helpful for someone new to the technique of not slamming the brakes and accelerator all the time.
- As a general guideline, I advise not to change anything on the car setups until you can drive 10 laps one after the other with a regular pace (lap time).
Only then start adjusting tyre pressure, gearbox sets, suspensions, etc.
- For any virtual opponent, you can adjust Aggression and Strength percentage per driver (internally AC creates an AI profile per car per session only) for
single races, trackdays or whole championships (Fig.). The influence of those differences depends a lot on car and track combination. A 60% AI will crash
more often around the Nordschleife than around Monza. These features are also available in the Content Manager launcher (Fig.).

Fig. – REPLACE IMAGE

- One important tip (thanks to Aristotelis Vasilakos, Kunos dev team):

"Don't be a simracer". We (yes, me too) have been used by decades of information overload and have become control freaks. That was also because older simulations had
less dynamic models... once you had your tire temperatures at a value it would stay there forever, so simracers tried to achieve perfect values to gain any performance possible.
Modern simulators are much, much more dynamic. […] So values and colours in the UI will change as you drive. Don't get obsessed about it. As long as you don't see
extremes, keep driving. Check the variations on the range of 1, 2 laps, not turn after turn. This doesn't mean that the cars are not sensitive to those variations, on the contrary,
they are a lot! But you can't do much about it. Concentrate on driving well and the rest will come.
- Car set-up tooltips are super useful if you do not understand what everything does when preparing your car for the race. A basic aid for a few quick tweaks
is fantastic and it is not common at all in racing games. Hover with the mouse on the setup entries to make them appear (Fig. IV).

Fig. IV – Example of the tooltips found in the setup screens of AC.

35
- The driving line: it’s a pretty basic assist for people that don’t understand how to find their own line and brake points on the track, and it gives you a trajectory
to follow with your vehicle.
It won’t be perfect and for racing it actually might hurt your development as you need to learn by memorising sections, turn in points, apexes and exits.
Following the line will normally take your focus away from the actual objects you need to look at as markers, like curbs, signs, poles and so on. Why is it
there then? Well, mainly to let you complete your first three laps.
The line will be green for throttle, yellow for coasting and red for braking (Fig. V); in most games it changes colour in a dynamic way, if you’re going too fast
or too slow. In AC it’s not dynamic (is static) because it depends on the pre-recorded AI opponents’ line.

Fig. V – The various colours of the driving line. As you can see the arrows follow the direction you should drive towards. This is a track mod with traffic, that’s why you see two lines.

This means it may be very bad on circuit/map mods, and even in official ones it won’t be the best path to follow with any car in particular. If you turn it off
you will improve much quicker.
Someone who understands lines and brake points can learn a brand-new track in 10-30 laps to a fairly good level. To be able to get the most out of a specific
vehicle setup you will likely need to drive more than that and every next lap you do you’ll likely learn something.
- How am I supposed to know where I need to brake when entering corners? Again, pick a braking marker or some static object like a pole or tree. Brake
when you reach it. Then keep braking later until you lock the wheels or make a mistake. Then adjust your technique to avoid it. You can watch onboard
footage of real drivers as well to find the optimal braking markers.
- In Assetto Corsa the performance delta on the first lap you drive is something you can never trust. For the Vallelunga track is not that far from accurate,
but in general you should do multiple laps (at least two) to have a decent accuracy value (Stefano Casillo, 2015).
- You can also enable your ghost so you always have a direct visualization of your best round; you can offset it around 1sec or more ahead, this way you can
follow your own racing line and start testing where and how to go faster than yourself. Soon you will see that you can brake later, accelerate sooner or coast
faster through a turn and catch up on that ghost. In a while you will have no idea how you were so slow earlier and you will learn to interpret body roll, wheel
sound, etc. to estimate when you are on the edge of grip and suitable speed through a turn.
- Watch the replays of your races or practice sessions! You can definitely learn from your errors. Otherwise why should this feature be there? It’s rare to see
a good race. You need to develop the capacity to understand how you’re driving in the first place.
- Want to see how fast your lap times are compared to other players? AC got great support for third party apps. Check the installation guide for RSR Live
Timing in-game app who will tell you just that.
Download it from here: https://www.racedepartment.com/downloads/rsr-live-timing.1362
Install by unpacking it in your : SteamLibrary\SteamApps\common\assettocorsa

- Playing with a controller: drifting is doable, so you may try it, but do not expect much results; you will probably get kicked from online play because it will
be hard not to be off pace and avoid contacts with one, and it may not be much fun.

36
2 - Basics
2.1 - PC vs Console versions
AC is available on PC, PS4 and Xbox One. It can be played also on consoles of the same kind (from Sony, Microsoft) compatible with older generations.

For example the simulator hasn’t been released for PS5, so you will be playing the PS4 version. However there are no improvements in resolution or image
quality between PS4 and PS5. The framerate is just higher and more stable.

The main difference between the PC and the console versions is that the sim can be modded on PC, while on consoles you will be able to play only vanilla.

You will need a Steam subscription (=account), in order to legally purchase, download, install, and run AC on your personal computer. Steam is a software
distribution service launched in September 2003 by Valve Corporation LLC, an American video game developer, publisher, and digital distribution company
headquartered in Bellevue, Washington.

Steam supports digital rights management (DRM), game review, and social media. You should download the Steam client from SteamPowered.com, install it
in the default folder C:\Games\Steam, run the client, and create an account. You receive a welcome email, which contains a code you must use to register
your gaming PC with the Steam service. Once your account and your machine are recognised by the Steam software, you may proceed to purchase our
simulator, using a credit card or a PayPal account.

You can run AC only under the control of the Steam client. Steam updates games automatically, and its DRM (Digital Rights Management) system ensures
that your copies are legitimate.

Yes, because you have, essentially, a leased copy of AC. The time of licence keys has apparently ended years ago in the world of games. Oh boy, it’s the era
of NFTs (Non-Fungible-Tokens) and pay-to-win servers. Nice.

Just as Steam is not required to reimburse you the value of your collection if you're banned from their service, if tomorrow Valve LLC closed shop, they
probably would not be required to turn off their DRM. Moreover, it would not surprise me in the slightest to learn that the DRM is mandated by the publishers
who allow Steam to sell their product, so while it's a nice thought, I find it unlikely that Valve would be able to legally turn it off as a final action.

Plus unless you’re a skilled programmer you don’t really know what kind of telemetry data does Steam collect from your PC, apart from the game achievements
and progress. Anything else should be none of their business. You like being watched, don’t you?

So what can you do if you don’t want to use Steam or it suddenly goes down? The only option is piracy, which is easy but illegal, although if Steam went
down then theoretically you could argue that cracking would be legal under the DMCA, as the product would be broken, and removing the DRM would be
required to fix it to a working state. It's a bit shaky though, because you have a "subscription", not a game arguably. But that hasn’t happened.

Enough with this digression. The latest AC release is the 1.16.4. People often think that 1.16.3 is the latest, due to the fact that this version appears more
often on the web (thanks to piracy), but the truth is that 1.16.4 is the so-called “Silent Update”. This is because it is indirectly linked to a DLC which you can’t
buy, being part of a Ferrari E-sport event featuring a couple cars, the Ferrari 488 Challenge Evo and the 488 GT3 Evo 2020 (Fig. VI).

Fig. VI – To obtain the vehicles you can try registering to the event here: https://esports-registration.ferrari.com/regulation or find a mod as replacement.

The update 1.16.4 includes changes in the main launcher files and car data. If you buy the Ultimate Edition, these are included, but you won’t get the extra
vehicles, those being related to the e-sport event you’d have to take part in. But if you really want them, register to the Ferrari website 9. If you are not in one
of the countries listed, you can just pick a random country and it should be fine. Once you finish the registration you should get a message to verify your
email address. After that you will get a “Welcome to Ferrari Hublot Esports Series!” email. In this particular mail you will obtain the Steam key for the Ferrari
488 Evo. With it you can go in Steam and select the Games tab, then activate a product where you will put the key. The content should start downloading.

The Ferraris are not the only Esport-related content: for example, you can get the Dallara Stradale by registering on https://esports.cusbologna.it and
participating to the tournaments. There are many official partnerships like this one.

9
It is not guaranteed that any of the contests mentioned herein are still active/working/functional today!

37
Now, updating AC to 1.16.4 or directly buying the Ultimate Ed., you may encounter an error in CM with old versions of CSP telling you that v1.16.3 is required.
This can happen also if you have an older AC version (Fig. VII).

Fig. VII – Here the version is 1.16. This is usually not a problem with Steam, as the games are automatically updated (often this error is encountered with pirated copies of the game).

CSP looks at the changelog.txt located in the AC root install folder. This file is updated to reflect changes that were made to version 1.16.4. Old CSP versions
do not understand what release 1.16.4 means, so they cause this error. You can adopt different solutions to fix this:
1. Update CSP. This most likely will fix the error, as AC 1.16.4 is correctly displayed since CSP release 0.1.74. Otherwise...
2. Edit changelog.txt and remove the entry for 1.16.4;
3. Edit changelog.txt and change the first line from 1.16.4 to 1.16.3;
4. Rename changelog.txt to changelog.txt.bak;
5. Move or delete changelog.txt.
6. Leaving this error and not doing anything is also an option, as it does not appear to cause any functional issues so far.

2.2 - Hardware requirements

Official hardware requirements:
Minimum Recommended
OS: Windows Vista Sp2 (with KB971512 platform update) OS: Windows 7 Sp1, 8, 8.1, 10, 11
Architecture: 32/64 bit Architecture: 64 bit
Processor: AMD Athlon X2 2.8 GHZ, Intel Core 2 Duo 2.4 GHZ Processor: AMD Six-Core CPU, Intel Quad-Core CPU
System memory: 4 GB RAM System memory: 6 GB RAM
Graphics: DirectX 10.1 (AMD Radeon HD 6450, Nvidia GeForce GT 460) Graphics: DirectX 11 (AMD Radeon 290x, Nvidia GeForce GTX 970)
Graphics memory: 512 MB Graphics Memory: 3 GB
DirectX: Version 11 DirectX: Version 11
Network: Broadband Internet connection Network: Broadband Internet connection
Storage (Hard Drive): 15 GB available space Storage (Hard Drive): 30 GB available space
Sound Card: Integrated Sound Card: Integrated

For reference, nowadays Kunos uses the following setup bench for testing purposes (presumably support for bugs and fixes):
CPU: Intel Coffee Lake i7 8700k 4.7Ghz
Motherboard: AsRock Z370 Extreme4
RAM: 32GB Corsair DDR4
Storage: 2 x SSD Samsung EVO 970 M.2 1Tb | 3 x SSD Samsung EVO 860 500Gb
GPU: Asus ROG Strix GeForce RTX 2080 SUPER OC Edition
Monitor/display: Samsung Q4970R 3840x2160 | Oculus Rift S
OS: Windows 10 Professional
Audio compartment: Native Instruments Komplete 6 / AKG 240mkII / M-Audio BX5 D2 + Creative Sound Blaster Z / Magnat Monitor Supreme 5.1 set
Seat and controllers: R-Seat S-1 | Thrustmaster TS-PC | Fanatec Clubsport Pedals V2 | Thrustmaster TH8RS Shifter | DSD Sequential Bent

As a small addition, it is known that a Ks dev was using the following setup:
CPU: Intel i5-3570@3.40 GHz (OC 4GHz+)
Motherboard: AsRock Z77 Extreme
RAM: 16 GB DDR3
GPU: Zotac GTX 970 4GB
Monitor/display: Asus VG248QE 1920x1080
OS: Windows 8.1
Controllers: G110 + G400s + G27 | TrackIR 4

About the graphics technology:

Assetto Corsa is DirectX11 only, compatible with DirectX10.1 cards. It works also on older DX10 video cards but might have fps hit; in any case these did not
receive any support from Kunos and will never do, due to technical factors.
To use DX10 (why would you?), you should set to 1 the following parameter in the graphics.ini config file, under assettocorsa/system/cfg:
[DX11]
ALLOW_UNSUPPORTED_DX10=0 ; UNSUPPORTED, USE AT YOUR OWN RISK

Kunos did not use the advanced DX11 features, like tessellation, as those would have required a huge pipeline change. Their point was to have a product
with the most modern API back then (2013).

38
About the CPU architecture:
By default AC is able to run on 32-bit processors, given the fact that acs_x86.exe exists in the install folder. But nowadays a 64-bit architecture is required,
especially to use Custom Shaders Patch. This is not directly related to the double precision physics. It’s just that the mod at its core doesn’t work on 32-bit
systems, and if you try to use it on an OS with such architecture, an error message will be displayed (Fig. VIII).

Fig. VIII – The error that will appear on a 32-bit system if you try to launch AC with CSP. dwrite.dll is the file that makes the shaders patch injection work.

Also, talking about CPUs, AC will benefit a lot from processor with a high performance per core, rather than multicore.
Going back to the hardware requirements, if you start modding your Assetto Corsa installation, you may need a better setup. Keep in mind that the official
hardware requirements are for the vanilla game, while with mods you never know which is the right compromise, until you experience various solutions for
yourself, playing with settings.
In case you want to turn a PC into a dedicated gaming box and maximize its performance, update your motherboard’s BIOS, the operating system patches,
the graphics card driver, and the input devices’ drivers 10. Remove all the software you don’t use from the machine, except the games (which you better keep
in a secondary drive, so that if Windows has any problem and needs repair/restore/reinstallation, you don’t have to worry about them 11). Even preinstalled
apps like MS OneDrive, unknown CD/DVD burning software, Chat/Messenger apps and others shall be deleted. Do not uninstall hardware drivers (e.g. Nvidia,
AMD, ATI, Intel, Synaptics, Realtek, …) and system packages like Visual C++, .NET Framework, DirectX, Python libraries, SQL server client, Java, etc. Disable
speech recognition, and Cortana as well. Apply the most restricted privacy settings. Strip bare the Windows Aero user interface theme by disabling all the eye
candies, gadgets and transparencies. Disable unused services working in the background, and if you want, block Windows Update too. Especially remove
anti-virus software, because those run continuously in the background and steal CPU cycles. Now, since the machine will be unprotected, minimise your web
and email activities on it, or avoid them altogether.
At this point you should obtain a better performing machine.
Pro tip: installing several registry/system cleaning tools like CCleaner or Glary Utilities to make your PC faster is not useful at all, it will eventually slow down anyway. Those
programs ignore a lot of things that should be “cleaned”. Just use the default Windows Disk Cleanup tool to clean the cache and temporary files 12. Note that a fresh Windows
installation is usually faster than an old one, in particular before you connect your machine to the Internet and it starts with the updates.

2.3 - Is a ray-tracing graphics card required?

Always keep in mind that Assetto Corsa does not support ray-tracing technology (at least for now, who knows what modders can do?). It is not required to
buy an RTX graphics card then.
Wait… I’ve seen that you can add RTX to any game on YouTube videos. What about those?
Well, those are shader injections with a software called Reshade. Using Reshade doesn’t bring proper ray-tracing to your games, it’s just a lie. It's been very
concerning how many thousands of videos online say "RAY TRACING NEXT-GEN GRAPHICS FOR GAME X". 3rd party plugins approximate effects based on
screen space depth and color sampling, but you cannot light correctly a scene this way. Ray tracing is specific to the triangles in the entire scene, not only to
the pixels on screen.
The basis is this: any form of light in a computational environment has to be considered as a group of vectors, with a given direction and magnitude. They’re
called “rays”.
- Screen-space Ray-Traced Global Illumination shaders (post-process Reshade ssRTGI) find the direction of the ray of light going out of each pixel on the
screen. This is a process, because we want to create a parallax effect 13, where rays scatter as they get farther from the camera and therefore intersect more
with things nearer, less with things farther. The process doesn't have access to the full depth map, so anything outside of the field of vision doesn't exist (no
light calculation). A depth buffer and color information are used. The program continuously casts rays so when you move around it has to reorient them
depending on what new information it sees, unlike ray tracing where it has all of the information at all times. Bounced light effects can appear and disappear
if the reflecting faces are visible on screen or hidden behind other geometries. These effects are nice, but easy to break if the player moves the camera POV
(point of view).
- Proper ray tracing gives light weight as well as direction, it calculates how the light should react when hitting a material and where it should go after that.
So after light hits, for example, water, it'll reflect around the room, maybe light the walls slightly and also refract against the water. The biggest difference is
how light interacts with itself. If you shine two beams of light through different transparent materials, such as coloured glass, the colours will mix and make
the colour it’s supposed to, just like how real light reacts. This is called color bleeding. You also have scattered surface light reflections. And nothing is baked
in the textures. The whole process can actively take a lot of data from the geometry of the 3d scene being rendered, and it happens at the GPU level. This
technology is heavily demanding, which is why a graphics card with dedicated acceleration cores is needed for the calculations of the lighting effects.

10
However, it is always valid the rule “if it ain’t broke, don’t fix it”. If a peripheral works perfectly fine there is no need to update its firmware/drivers. Often it does more harm than good, especially
if you don’t know what you are doing.
11
Be careful, because game data (progress, save files, etc.) may be stored in the user folders under the C:\ drive (especially AppData). Always backup all your important stuff!
12
If you really want a cleaning software, adopt BleachBit. For uninstallations you can use the Windows Control Panel in combination with Bulk Crap Uninstaller. Avoid registry cleaners.
13
The effect by which the position of an object seems to change when it is looked at from different positions (Cambridge Dictionary, 2023).

39
RTGI shaders aren’t ray tracing. This doesn’t mean they’re bad. They can look really good (Fig. IX), thanks to the implementations you can add, and to their
customizability. They’re just the less expensive (literally in every sense) and more exciting option.

Fig. IX – There’s only one Minecraft with true ray tracing support (the leftmost) but, as you can see, a huge amount of nice screen-space shaders (and these are not all of them!).

If the game you’re thinking of doesn’t support ray-tracing, it is not possible to add this feature without heavily modifying the core of the graphics engine.
Taking a game like GTA V as an example, you’d need the source code to “inject” such a thing. Sadly, for a lot of games it is not publicly available (yet).
Recently however, it seems to be possible to “remaster” games with ray tracing, using the Nvidia Remix tools: https://www.nvidia.com/en-us/geforce/rtx-remix. This is
very recent, so don’t expect a new release of your favourite game soon.
Pro tip: the literature is not cohesive in separating the different types of ray tracing existing nowadays, so always try to investigate from context. Also, the different acronyms
RX or RTX created by GPU manufacturers (AMD, nVidia, Intel, etc.) do not portray the ray tracing technique by itself. Those are commercial trademarks for cards that support
a proprietary implementation of the technology, which was theorized and created independently.

2.4 - Dual GPU system

It is possible to run AC with two graphics cards (and more, but they would remain mostly unused, as the simulator is mainly CPU-bound).
If you are running a dual GPU system and encounter a full black screen in the vanilla launcher then make sure that AssettoCorsa.exe is assigned to the GPU
your desktop is using and acs.exe is assigned to your "high performance" GPU. These files are in the main installation folder, usually under the
STEAM\steamapps\common\assettocorsa path. This can be done in the Nvidia control panel for Nvidia users and in the Catalyst Control Center for ATI/AMD
users.
If you use CM to load race sessions, you shouldn’t encounter this problem, as acs.exe is launched directly.

2.5 - Virtual reality (VR) supported hardware

Here are all the VR devices officially supported:
Oculus CV1, DK2, Rift / Nvidia 3D Vision / NaturalPoint Track IR / D-Box motion systems / Track IR-Pro

2.6 - Gaming devices (PC)

AC is compatible with any game device recognized by Microsoft Direct Input, including keyboard, mouse, joypads (mainly 360), joysticks, lots of steering
wheels and professional motion systems.
It is strongly recommended to use a wheel with 900° of rotation.
- Officially supported hardware:
THRUSTMASTER LOGITECH MICROSOFT
T100 Force Feedback G25 - G27 - G29 - G920 SideWinder Force Feedback
T300RS Logitech MOMO Force - Logitech MOMO Racing
GAMEPADS
T300 Ferrari GTE Logitech Driving Force - Logitech Driving Force
Microsoft XBOX 360 / XBOX One
T500RS Pro - Logitech Driving Force GT
Thrustmaster GPX
TX Racing Wheel Ferrari 458 Italia Edition
FANATEC
TH8RS Shifter GENERIC
ClubSport Wheel Base - ClubSport Wheel Base v2
RGT Force Feedback Clutch All Direct Input USB devices
ClubSport Shifter & Pedals – all versions
F430 Force Feedback
Porsche wheels – all versions
Ferrari F1 Wheel Integral T500
CSR - CSR Elite
599XX EVO 30 Wheel Add-On Alcantara Edition

40
- Keyboards
I'm not a hardware guy, but if I had to design a keyboard, I'd probably include some kind of electrical switch under each key, with a set of wires leading to
and from each switch so I could detect when they were pressed. Bzzzt, wrong!
Real hardware designers reduce manufacturing costs by sharing only a few electrical connections between many keys. Next time you are throwing out an
old keyboard, rip it open first and take a look inside. You'll see a crazy circuit board with a matrix taking voltage to and from the various switches, but if you
look carefully, you'll notice the same inputs and outputs are routed to many different keys. How can this possibly work? The trick is that in order to detect a
single keypress, you don't actually need a unique wiring for that key. As long as each key has a unique combination of input and output connections, you
can figure out things like "source #3 and destination #5 have voltage, so 'O' must be pressed".
You can also detect multiple keypresses, using logic like "sources #3 and #4 are connected to destination #5, which means both 'O' and 'K' must be
pressed". In fact, any combination of two keys can be reliably detected (the proof of which I shall leave as an exercise for the reader).
More than two simultaneous keys, however, are a problem. Some combinations may work ok, but others will try to connect source and destination wires
that are both already in use by other keys, in which case the new press will be completely ignored. Even worse, exactly which combinations can be detected
varies from one keyboard to another, depending on the details of how their wiring matrix is laid out.
This behaviour was fine for the word processing applications that keyboards were originally designed for, but is not so great for games. There is nothing we
can do to fix the hardware, but there are a couple of ways we can minimize its impact:
• Prefer the shift, alt, and ctrl keys, because these usually have dedicated wiring that will not cause conflicts.
• Avoid game designs that require pressing many keys at the same time.
• Avoid the keyboard entirely. Gamepads don't have this problem. They have other problems!
- There is a feature in Assetto Corsa that has a lot of impact on the experience of keyboard and mouse users: the built-in throttle limiting.
It should make life easier, but it makes everything worse instead, especially for drifting. It consists of a 66% throttle "traction control" cut that is always on
when using keyboard and mouse throttle input. It cannot be forced off whatsoever, even by the multiplayer servers. You can totally see it with the Pedals
app (Fig., and for more details about apps, see p.).

Fig. – If you try to make the wheels spin with the mouse or keyboard, on the left is what you will see in vanilla AC: the throttle input will be reduced to 66%. On the right is what it
should be (and what it is when a hardware pedal controller is fully pressed).

I actually like that this is visible: Kunos could have totally hidden it. The problem is solved by the Custom Shaders Patch mod, which brings the Forced
throttle fix. You can bind a key to act as an additional, correct gas control, configurable with some build-up lag in the options.
Modders who work without a steering wheel and pedals absolutely need this fix, especially for physics creation and debugging.

- Gamepads
Gamepads, like keyboards, are not perfect. They are designed to be cheap, sturdy, and nice to hold: accuracy comes second.
Specifically, the analog thumbsticks are not very precise at reporting their absolute position (although they are good at measuring relative movements, so
the returned values will change if you twitch the stick even a small amount). The main way you notice this lack of precision is that when you let go of the
stick it never goes back exactly to zero, just to some kind of smallish value roughly near to zero.
Thumbsticks that don't return exactly to zero are a bad thing. This makes game characters twitch around or sidle across the screen when they should be
sitting still, and it makes menu systems randomly change selection even when you didn't move the stick.
So why have you never noticed this problem? Because the deadzone takes care of it for you!
Usually the default modes apply the response curve in Fig. X to both the X and Y components of the stick position.

Fig. X -

In other words, if the position of either axis is close to zero, it clamps that axis to be exactly zero. There is no feedback from one axis to the other, so if you
are holding the stick straight up we will return a large positive Y value but still clamp your nearly-zero X input.

41
It is possible to implement a circular mode. This examines the position of both axes together, and only clamps to zero if the combined stick position is close
to the origin.
The plots of Fig. below show the effect of the two aforementioned deadzone modes. on the X component of the input position.

Fig. – (top row) Independent axes mode. (bottom row) Circular mode. (left, center, right) Components of the input position, respectively: X, Y, and both axes combined.

Notice how the independent axes deadzone (left) stays active all the way out to the ends of the vertical and horizontal axes, while the circular mode (right) is
more subtle and only affects the center location.
You will generally want to use independent axes mode for things where the X and Y stick positions control unrelated game values. For instance, steering a
car is independent of accelerating and braking, or moving up and down through a menu is independent of moving left and right. The circular mode works
better for things where the stick input is used to choose a location on a 2D plane, such as aiming a weapon or moving the character in a Mario64 style
platformer.
You can see how the right deadzone mode can make a big difference to how responsive your game feels. So yeah, controllers are not accurate at all. You
better use a broomstick handle.
- How to play with a PS4 controller on PC?
Connect it and use Ds4windows. Then bind all the buttons and you’re good.
- Mice
If you don’t use an obsolete ball mouse and have an optic one, you are probably fine. A fancy gamer 14 mouse is not required.

Extra: DashPanel, Simhub, etc.

2.7 - Format & reinstall

The game files are primarily handled through the Steam client. Missing files may be restored through a 'Check of integrity of game cache' via the Steam
dropdown menu. Backup your game configuration with your replays, screenshots and setups stored in the username\Documents\Assetto Corsa folder, if
you'd like to format your hard drive or do a clean reinstall.
If you have a modded pirated version of AC that doesn’t work anymore, try uninstalling the mods first. If it still doesn’t work you can try installing the same
version on another PC to retrieve the main files and copy them replacing the ones that don’t work. It can be time consuming, and often it’s faster to reinstall
everything from scratch instead of debugging. Otherwise search for a completely different pirated copy. Or buy the game when on sale if you can afford it.

14
Sad but true: people who play games for fun do exist; they’re called players. “Gamer” stands for “video game addict”, a kinder word to allow politically correct marketing campaigns.

42
2.8 - AC root folder
Basically the Assetto Corsa’s install folder. Linking it on your desktop will become super useful later when modding the game. How can you find it?
1. Open Steam and go to your library (Fig. VII).
2. Right-click on Assetto Corsa and select the Properties;
3. Select the Local Files tab and click on the Browse button;
4. The install folder opens in a File Explorer window; go in the parent directory (steamapps\common), right-click on the assettocorsa folder, select Send To > Desktop (link).

Fig. VII – Nothing much to say, just follow the steps in order from left to right.

If you changed the destination folder during the Steam setup, or you have a pirate copy of the game, you should know where you installed it better than me.
Throughout this manual, we will often refer to the AC install folder like the following: %root%\assettocorsa

2.9 – Can I play Assetto Corsa on Linux or Macintosh?

Yes, you can, but you may have to put some effort to make it work.
- On Macintosh:
• Performance would be very bad in VR through emulation like Parallel. Just running the game on a screen would be bad through Parallel.
• Bootcamp is the best (and probably the only) solution. Even if in theory you port AC to the Mac OS, you can have problems with the Force feedback (e.g., Logitech G25/27
doesn’t support FFB under several versions of Mac OS).
- On Linux there are some alternatives:
• Install Steam from your distribution's software application, log into Steam, enable Steam Play in the settings, restart Steam, install the game.
• Using Lutris, a free open-source gaming platform that installs and launches games from Steam automatically.
• Other options are: dual boot Linux-Win (but then what’s the point of using Linux?), use a virtual machine with Windows (really slow, huge loss of performance), use Wine
(can be difficult to set up), or use Protontricks (it can potentially run very well, but it’s not worth the effort unless you're ready to tinker with it and have a lot of patience).
And yes, you can host an AC dedicated server on Linux, so multiplayer is possible. The CSP mod is a completely different story. It is not proven that it can
work.

2.11 - Game performance characteristics

This game runs in two primary CPU threads: one for physics, the other one for everything else. It is CPU limited in single-player and GPU limited in
Multiplayer. In contrast to many other PC games, Anisotropic Filtering (AF) has a big impact on FPS. Higher Anti-Aliasing (AA) settings require an
increasing amount of GPU memory. Combining AA and FXAA yields the best AA outcome. Raising a single value, AF or AA, may not result in optimal
resource management and/or overall high graphical fidelity. Since AF and AA have almost the same impact on FPS, and AA a high impact on GPU memory,
a high AF and a low AA setting provide a compromise in FPS, graphical fidelity and resource usage.
Other settings with a relative high impact on performance are Motion Blur, Depth of Field, Reflection Quality and Reflection Rendering Frequency. Also, the
HUD apps can reduce the framerate.
Generally, the game is more CPU-limited than GPU bound.
43
3 - Game Configuration & graphics settings
3.1 - Default vanilla keyboard shortcuts
You can change almost all the keys in the options; some are fixed and not customizable, for example the function (F1-F12) numbers.

While in the vanilla AC launcher menu VR (OCULUS)

F11 : Toggle fullscreen/windowed Ctrl +Space : Re-center view
Look Left +Look Right : Re-center view
During any session
Up/down arrows : Throttle/brake Replays
Left/right arrows : Steer left/right Ctrl +R : Start replay
X : Shift Up Ctrl +Space : Pause replay
Z : Shift Down Ctrl +S : Slow motion (during replay)
L : Headlights Ctrl +D : Rewind
H : Horn Ctrl +F : Fast forward
Q : Glance left Ctrl +P : Skip to previous lap
W : Glance right Ctrl +N : Skip to next lap
Ctrl +A : ABS ON/OFF Ctrl+1 : Switch to previous opponent car
Ctrl +T : Cycle traction control modes ON/min<TUNING<max/OFF Ctrl+3 : Switch to next opponent car
Ctrl +H : Toggle UI (HUD) apps ON/OFF Ctrl+2 : Switch to player’s car
Ctrl +O : Restart the session
Ctrl +U: : Cycle virtual desktops During multiplayer sessions
Ctrl +L : Drivers/opponents names ON/OFF Ctrl +1 : Switch to previous opponent car
Ctrl +M : Mouse steering ON/OFF Ctrl +3 : Switch to next opponent car
Ctrl +G : Automatic shifter ON/OFF Ctrl +2 : Switch to player’s car
Ctrl +I : Ideal racing line ON/OFF In the vanilla showrooms
Ctrl +Q : Damage display ON/OFF ENTER : Enter/exit the car
Ctrl +J : Show damage display Spacebar : Open/close doors
Ctrl +C : Enable AI driving the car Numpad 7 : Headlights on
Ctrl +num 1-3 : MGU-H (Motor Generator Unit – Heat) mode Numpad 8 : Brake lights on
Numbers (1-0) : Live turbo adjustment (for cars that support it) Numpad 0-3 : Animate wing 0-3 (if present)
F1 : Cycle car cameras I : Car gearbox animation
F2 : Random cameras Right mouse button : Rotate the car
F3 : Track cameras Mouse wheel : Zoom in/out
F5 : Free external orbit camera , and . : Rotate wheels/steer
F6 : Extra car cameras F7 : FPS mode (freecam)
F7 : Free camera Tab : Track camera
F8 : Take screenshot W : Wipers
F9 : Cycle leaderboard on bottom screen/compact/OFF Arrows : Move the camera around the car
F11 : Virtual rear mirror ON/OFF (a must for multiplayer races) Page Up/Down : Change to previous/next skin
F12 : (Steam related) screenshot +/- : Adjust exposure
Keypad +/- : Change Force Feedback (disabled in replays) Ctrl +Keypad +/- : Adjust FoV
Ctrl +Keypad +/- : Adjust onboard FOV (Field Of View) F : Roll left
Ctrl+Shift+Keypad +/- : Change saturation G : Roll right
Page Up/Down : Adjust exposure (HDR) Q : Azimuth +
Home : Open/close AC console (see pag.) E : Azimuth -
Alt +F4 : Quit session immediately (if your boss enters the office!) A : Zenith +
D : Zenith -
3.2 - Resolution & Rendering mode
Assetto Corsa will run on Single, Triple screens or on VR devices. Many resolutions in combination with many refresh rates (Hz) are available.

3.3 - Anti Aliasing & Anisotropic Filtering

As both main graphical quality options, AA and AF should be looked at first when balancing fidelity and performance. Note that AF requires more resources
in AC in comparision with other games.

3.4 - Reflection Quality & Reflection Rendering Frequency

Both these settings are responsible for the reflection quality on the car's bodywork. Reflection Quality determines the resolution of the reflection and Rendering
Frequency dictates how often reflections on the bodywork will be updated.

3.5 - Shadow resolution, World detail and Smoke generation

Lowering Shadow resolution and World detail can help increase FPS on parts of tracks with a lot of detail or many trees that are casting shadows - especially
helpful on mod tracks. Lowering Smoke generation helps to reduce the FPS drop during race starts.

3.6 - Post processing effects (PPEs)

PPEs have an impact on FPS, Motion blur and Depth of field quality more so than the rest. The headlights of the car won't glow with PPEs or Glare quality
disabled and have a diminished glow with Glare quality reduced. You may reduce colour saturation below 100%, or set the PPE preset to 'Photographic' in
order to bring the game visuals closer to reality. Enabling Fast Approximate Anti-Aliasing (FAAA) simultaneously with normal AA will reduce FPS greatly.
FAAA is not as effective as AA.
44
3.7 - Vertical synchronization (V-sync)
V-sync is a graphics technology that can either improve your gaming experience or destroy it completely. It’s designed to sync the current refresh rate of
your display monitor with the frame rate that is being rendered by the GPU. The video card is prevented from doing anything visible to the display memory
(where the pixels are stored and then sent as frames to the monitor) until after the monitor finishes its current refresh cycle (completes the visualization of
one frame, which depends on how the pixels are turned on or off, based on the display technology, e.g. CRT, LCD, OLED, etc.).
This is in order to fix a rendering issue known as screen-tearing, which is when information from multiple frames is displayed in a single screen draw, with
artefacts (Fig. VIII). The frames aren’t in sync and show two completely different and out-of-order pieces of visual information. As a result, your gaming
experience is completely ruined and your screen only displays an annoying mess of images.

Fig. VIII – Example of screen tearing on a triple-screen setup.

This problem is due to the fact some 3D scenes are more complex than others, and thus get drawn at variable rates. Not only that, graphics cards (and
computers in general) are not perfect machines, and depending on the system and the software used (game, driver, OS, etc.) the performance is not
consistent. V-sync helps get rid of screen-tearing, trying to match the exact refresh rate of your monitor to the frame rate of the GPU. By doing so, the
image you’re seeing on your screen is smooth and always in sync.
It’s important to know that having V-sync always turned on is not a good idea. It can be helpful but it can also become a nuisance if not used under the right
circumstances.
With a 60Hz display, V-sync would force a cap of 60 fps, meaning the display will anticipate a frame precisely every 16ms. If the GPU misses this timing
requirement (takes too long drawing the frame), the display will repeat the previous frame. This eliminates the chance of “tearing” by restricting the display
only to drawing frames every refresh interval, but can cause stuttering (wait time) when the 16ms window is missed (the display will repeat the previous
frame). So the responsiveness of mouse and keyboard and any other peripheral hardware will be delayed.
All these events happen during milliseconds, so let’s adopt a timeline to visualize them, like in Fig..

Fig. – Visual comparison of the generation process behind the video signal, with or without V-sync active..

Therefore, if your framerate is overall lower than your monitor's refresh rate, activating V-sync won't improve picture quality, and it’s better to turn it off.

45
Without V-sync, tears happen the most when the number of frames per second you render on screen is a 1x, 1,2x, 1,25x, 1,33x, 1,5x multiplier of your
display’s refresh rate. If you run the game at these precise rates, you will see a tear (or more than one) on the screen, either stationary or slowly going up or
down. Then for 60Hz displays, very common nowadays, if you disable V-sync, you should not cap your framerate to exactly 60, 72, 80 or 90 fps, otherwise
you will obtain the worst kind of tearing possible, due to the rendering inconsistency of the GPU (for example in case you get 59.8 or 61.1 fps, 88.7 or 93.2,
and similar). How it happens is based on how waves work, so you can have some sort of harmonic effects. If you ever tried tuning your guitar, you know that
once two strings have almost the same note, when you pluck them together the sound is more intense. The principle is similar, tears appear more often.
If you don't want tearing to happen but desire to have a framerate cap regardless, you need to use a frame limit that is not a precise multiply of your screen's
refresh rate. Else, you will encounter a much more noticeable periodic phenomenon. Screen tears are only visible to human eye when they appear in the same
place constantly. This is why using non-precise multipliers is important. The tears will appear almost randomly on the screen, and because they only stay
there for less than 1/60th of a second (if the framerate is > 60 fps), it happens too fast for the human eye to spot it. This doesn't mean that going way above
60 fps on a 60hz screen is useless.
If you don't want screen tearing, use framerates that move the tear to a different place with each screen refresh. 83 fps is a good number for 60 Hz and 120
Hz screens.
3.8 - Maximum frame latency
To be changed in graphics.ini, a file located under %root%\assetto corsa\system\cfg. Open it with a text editor and search for the MAXIMUM_FRAME_LATENCY
line of code. This is the setting of how many frames the game should render the frames in advance to what you are seeing on screen. The default value is 0.
A value of 1 may improve picture quality and Force Feedback (FFB) response.
A high number of prerendered frames can reduce stutter, but since the computer renders frames in advance and doesn't know the input the player will make
at the wheel, it also makes the visuals not sync up with what is actually happening in the FFB.
MAXIMUM_FRAME_LATENCY=1 means at most one image will be prerendered;
MAXIMUM_FRAME_LATENCY=0 means that will be used the preset of your graphics card driver which is usually 3 or 4 prerendered images.
If you installed CM, you can change the frame latency from the settings easily (Fig. IX).

Fig. IX – How to change the frame latency from the AC video settings in CM.

3.9 - Stuttering
Sometimes stuttering could simply be related to too high graphics quality settings in game. Try lowering step by step your video settings until you achieve a
solid frame rate. If the issue is still present, here are some scenarios can cause stuttering:
• Addon in-game apps
• Messed up config files
• Video overlay software (MSI Afterburner, Fraps, Aida64, Gpu-z and similar)
• Screen recording software (OBS, Nvidia GeForce Experience, nVidia ShadowPlay, Xbox Game Bar)
• 3rd party graphics tools (Nvidia Inspector, ATI Tray Tools, SweetFX, ATI RadeonPro and similar)
• Background monitoring (Cpu-Z, Gpu-Z, Aida64, Intel Overclocking utility and similar)
• Controller emulation software and hardware (not original x360 gamepads, motionjoy software and similar)
• Antivirus / Firewall wrong configurations
• X-fire software
As you can see, there’s plenty of potential causes that can generate stuttering in Assetto Corsa (and in any other game!). So, before writing new threads or
posts on various forums, please check by yourself your PC overall status. You can always check the background processes with Task Manager.

46
3.10 - Mirror resolution & High quality mirror reflection
Quality of mirror reflections - has a minor impact on FPS and should be fully enabled.

3.11 - Field of View (FOV)

The Field of View ingame should mimic your FOV sitting in a car in reality. Correct FOV is important for proper (sim-) racing & gaming and to experience a
proper sense of speed while driving. Although there has been no official word if this game uses vertical or horizontal FOV, experimental results showed that
AC features vertical FOV.

3.12 - How to disable vertical head movement?

Tick the option in the view tab for 'Lock onboard camera to horizon'.

3.13 - Glancing left/right speed

Determines the speed at which you glance left or right during driving. This option is subjective, but an increase does help to reduce the time you are
looking away from the road while driving.

3.14 - How to setup up triple screen with mismatched monitors

I've seen a few tutorials about this, but I'm hoping this will a “definitive” solution, at least for Nvidia users. AMD/Intel users may adopt similar methods. The
theory is that you need to run different resolutions on each screen so that the pixel density is 1:1 size. The displays will have to be physically aligned if the
heights of the stands do not match (this is necessary most of the time).
Tools used:
SRWE (https://github.com/dtgDTGdtg/SRWE/releases)
Nvidia Control Panel
Windows Display Settings
Calculator for PPI (https://www.omnicalculator.com/other/pixels-per-inch can be used)
Preface:
In my case, I have one 27" 1080p monitor in the middle of two 24" 1080p monitors, and I was having trouble making them line up for AC. Using surround
did not work, and lacking the in-game tools (such as in project cars 2) to make them work accordingly.

Instructions:
Do not enable Nvidia surround. Disable the Fullscreen rendering in the graphics settings via the AC launcher or CM. Set the display mode to Triple screen 15.
Go to the PPI calculator and find an appropriate resolution for each of your side monitors, so that their PPI is the same as your larger one in the middle. In
my case it was 1710x960. Then go to the Nvidia Control panel, create these custom resolutions for your side panels and apply them.
Open the Windows Display settings. Ensure that your monitors are arranged correctly, and the middle monitor is the primary one. Line up the monitors using
this tool so that when you drag a window from one screen to the next, they remain the same size and retain the same relative shape. Leave this settings menu
open in the background.
Go to My Documents\Assetto Corsa\cfg and open "video.ini". Change the resolution to the one you would use if all monitors were the same (in my case
5760x1080). Save and exit this .ini. Alternatively, you can change the same setting in the CM options dedicated to AC graphics (Custom resolution).
Open SRWE and leave it in the background. Launch an AC race session. In SWRE press "Select Running Application" and select "acs.exe". You will notice
that some fields are now populated. There, select a number to input int he "X-position" field that will allow you to access the AC apps menu on the far right
of the screen. For me it was roughly -2500. At this point open the simulator’s Triple screen app. You will notice that there is a seam in the picture where
your monitors are supposed to meet. Use the tool to erase this seam. Return the angle to 0, return the bevel correction to 0, and input the exact width of
your center screen in mm (not the total, or average, just the center screen). Alt-tab back to SWRE.
In the width and height fields, ensure it is reporting that AC is in the desired resolution. In the X-position field, enter in the correct negative X-position. For
me it was -1920, as I am emulating 3 1080p screens. Check the "auto-attach to last known process" box. Return to AC.
You will notice that the angles and bezels are now set up incorrectly. Enter in the correct amounts into the triple screen setup app. If you have different sized
bezels as I have, enter in the average between the two measurements for now. Enter the correct screen angle and distance to center screen also.
You will notice that the images do not line up correctly. Alt-tab to the Windows Display settings, and line up the images correctly. You can use your arrow
keys to adjust this. Go back and forth until it is lined up correctly. Once it is lined up, close the Display Settings.
In AC, make fine adjustments to the bezel compensation until it is lined up perfectly. Use the distance to screen field to adjust FOV, as it may be too high due
to your screens being lower in size than reported to the game.
When you open AC, open SRWE along with it so you can adjust the X and Y axis of the screen to access the apps, and place the latter in their desired location
if you have not done so already.
And by now, you should be good to go! In addition to AC, this should work on any games that have a basic setup for triple screens such as AC but do not
have the advanced tools like PCARS 2.

15
In Assetto Corsa’s triple screen mode you effectively get 3 cameras to render the image without any stretching, 1 per monitor, and you adjust the FoV using the Triple screen app.

47
3.15 – Virtual Reality (VR) devices configuration
Stabilizing the view in VR

To stabilize head camera movement during driving you have few options:

1. Enable Lock Camera to Horizon in AC View settings.

2. Use RHM (Real Head Motion). This is a newer version that works with ACC for monitors and AC monitors and VR. Settings I use, feel free to experiment
with different values.

PP Filter

The Sol_Extra post-process filter works really well with VR.

Make also these changes in the SOL Config app (which you have to install if you don’t have it):
[general]
sol__use_cpu_split = true ; splits the weather calculations in parts over multiple frames
blacklevel__compensation = 3 ; adjust for your HMD

AC VR Settings for Samsung Odyssey+

Ultra

With a nVidia GPU, force Anisotropic Filtering in driver and disable in game. See “Nvidia Driver Settings”.

High

SteamVR Settings

Disable the Advanced Supersample Filtering (Fig. X), as it can cause additional blurring.

Fig. X – The SteamVR video settings you should use. How to open them.

The general video settings depend on the video card you have, so you can set them as high as you want while avoiding losing performance significantly.

Nvidia Driver settings

- The AF (Anisotropic Filtering) from the Nvidia drivers works much better than the original Assetto Corsa’s, so you can override the second with the first
one in the Nvidia Control Panel (Fig. XI); this will significantly lower texture shimmering. After setting the AF, check the “Texture Filtering – Negative LOD
Bias” parameter, because it will be automatically set to Clamp, overriding the in-game MIP_LOD_BIAS settings; it is recommended to set it back to Allow.
You also have to disable Anisotropic Filtering in the AC settings as it may add some performance overhead with both enabled.

- Enable MFAA (Multi-Frame Sampled Anti-Aliasing), that will improve antialiasing quality. For example, MSAAx4 in game settings is converted into
MFAAx8 with a smaller performance impact comparing to MSAAx8 (do not expect MSAAx8 quality though).

48
Enabling MFAA will add a ~5% overhead to the GPU load, also at lower framerates it doesn’t work that well, and should be off. Below 30fps the time
between frames grows so much that MFAA becomes increasingly inaccurate and the human eyes pick up on the AA sample pattern changes, which means
that this anti-aliasing technique is only usable with high frame rates.

Fig. XI – The settings you may want to change for VR optimization in the Nvidia Control Panel.

Enabling Windows Mixed Reality (WMR) Reprojection

First of all, what is reprojection?

To summarise without getting technical reprojection locks your VR frame rate to 45 whenever your system can't maintain 90 fps.

Well, to be honest it doesn't just lock it to 45. Your rendering rate is absolutely locked to 45fps under reprojection, but the frames are interpolated, guessing
(reprojecting) every second frame. So you still get 90 fps, just half of those are not “real" frames. Saying that reprojection only locks to 45 or to 90 fps is
very misleading.

Oculus devices activate reprojection individually per frame, on demand. Video can be up-sampled from effectively any achieved FPS to 90 FPS.

The technique is not very accurate, and the effect is entirely visible and to most people, quite unpleasant. Whilst it's pretty juddery, its consistency is better,
less nausea inducing than letting the frame rate fluctuate, and it also helps approximate head tracking movement when the system might not have the time
to display your movement otherwise.

It’s basically meant to have a decent experience when your system can't keep up. Playing at 45fps is bearable. Super-sampling (SS) has made it more of an
issue as it increases the workload on your system and increases the frequency reprojection is used.

You have to find the sweet spot where SS makes a difference to you visually without SteamVR having to use reprojection constantly. And not everyone
seems to get that. You may still want it active for general use; don’t worry, it will only kick in when needed. But turning it off and enabling the frame time
monitor in your HMD (Head Mounted Display) can help identify if you're actually running at 90fps or dropping frames that reprojection would otherwise be
masking.

Then, how to enable reprojection for WMR?

Go to Steam\SteamApps\common\MixedRealityVRDriver\resources\settings and open the default.vrsettings file with a text editor, you will find this script:
{
"driver_Holographic" : {
},
"driver_Holographic_Experimental": {
// Motion reprojection doubles framerate through motion vector extrapolation
// motionvector = force application to always run at half framerate with motion vector reprojection
// auto = automatically use motion reprojection when the application can not maintain native framerate
// disabled = turn off motion reprojection
//
// Comment out or remove this line to use the SteamVR settings for controlling motion reprojection
// "motionReprojectionMode" : "disabled",
// Motion reprojection indicator to display the mode currently selected
// green = off because application can render at full framerate
// cyan = on because application is cpu bound
// blue = on because application is gpu bound
// red = off because application running at less than half framerate or motion reprojection disabled
//
// green + cyan + blue = motion reprojection half-framerate mode or application requested motion reprojection
"motionReprojectionIndicatorEnabled" : false,

To activate Reprojection for all apps set “motionReprojectionMode” to either “motionvector” or “auto”, depending on whether you want to
always run at 45fps or only when the game cannot maintain 90 fps.

49
Close WMR and SteamVR before making changes.

If you prefer to control reprojection per-application, and without restarting WMR every time, comment or remove the “motionReprojectionMode” line,
then restart SteamVR/WMR. Now you will be able to manage the settings via SteamVR Motion Smoothing (Fig. XII). The default USE GLOBAL SETTINGS on
SteamVR is the same as the previously mentioned “auto”.

Fig. XII -

Note: reprojection adds some GPU overhead which can reduce the framerate if you don’t have enough computational headroom. That means when you can
maintain 90fps with reprojection disabled, reprojection on auto may trigger switch if GPU can’t keep up with frametime target anymore.

Pro tip: you can also control reprojection through the new WMR option in Steam Dashboard.

Rechargeable batteries for VR controllers

NiZn (Nickel-Zinc) batteries last longer and track better due to higher voltage (1,5 Volts). They need a special charger; you can get the full kit online.

There are positive reports on rechargeable Li-ion (Lithium) batteries as well, even if those have a lower voltage (1,2 V).

3.16 - Degrees of rotation

Determines the sensitivity of the steering wheel. If the the maximum rotation is matched with your wheel's rotation, both your and the ingame wheel will
rotate congruently. You may increase them to the maximum (1180°), in order to reduce sensitivity and therefore increase steering precision of Formula
cars.

3.17 - Throttle, brake and clutch boundaries

You may adjust pedal boundaries with the white sliders. The top brake boundary may be changed, in order to reduce the necessary force required to press
your Load Cell brake pedal and still retain 100% maximum brake in-game.

3.18 - Gear shift debouncing

Adjust slider to eliminate skipping gears while shifting.

3.19 - KERS & DRS activation

Both are implemented as activatable features in the game. These are expected with the addition of the McLaren P1. Albeit the Hi-KERS system of the
LaFerrari is fully modeled.

3.20 - Steering settings

Recommended to reduce all options to minimum other than FFB gain, in order to experience the purest FFB possible. You may choose a Filter value of 1 or
2% to reduce a sudden jiggle of the wheel while driving due to road surface imperfections.

3.21 - Brake gamma

A linear brake gamma (value of 1.00) is highly recommended to have a predictable and precise braking feel.

For Load Cell users: the human foot with its plethora of pressure receptors is able to detect and react to pressure a lot better than to foot travel. A linear
brake gamma and a linear pressure increase of the Load Cell will benefit greatly from that.

3.22 - Save configuration feature

50
You may save any configuration of your input devices via this feature. You may have to double click on an entry multiple times for it to load properly. You
also may save a general profile each for Street-, GT- and Formula cars.

3.23 – Audio configuration

Racing simulators have “simple” audio needs. The driver should be able to hear his engine, so that he may know when to shift gears, without having to look
at the tachometer. He needs to be able to hear his tyres screeching, so that he may know when he had been too exuberant in his application of throttle or
brake. He needs to be able to hear the opponents who are behind and next to him, so that he may know what defensive action to take. That is all; all the
other sound effects are icing on the cake.

AC emits the sound of the engine revving, gears crunching, tyres locking up, tyres rolling over surfaces like gravel and rumble strips, brake pads grinding
their rotors, the wind rushing by. It is quite a complex ambience.

You can adjust the relative levels of these sounds in the Audio settings panel (Fig.) which you may open by pressing the Options button. While you are
there, turn off vexing things like the UI music and the video cutscenes, for more immersion. And if you hear pops and cracks, move the latency slider to the
right. Otherwise, keep the default setting.

Fig. -

AC also generates other environmental sounds: the sound of loose stones hitting the under tray of the car, when you drive onto a gravel trap; the
suspension parts rattling, when you go over a kerb; the metal-on-metal gnashing, when you trade paints with another car; the impact when you hit a barrier.
The most important noise in this cacophony is the tire screech. AC emits this noise when you lock up the front wheels, spin the rear wheels, or wrest a
reticent car into a corner. When you hear this noise, you know that you are abusing your tires. So, let your aggression be tempered by this sound.

Lastly, set the master volume at a level that matches your other games. If you use the headphones with a DAC amplifier, you may wish to set the Windows
mixer volume slider to 50%, and control the loudness using the DAC amplifier’s volume knob. And if you use your HD television as the display, you may
wish to match AC’s volume level to that of the set-top box, so that you would not have to keep fiddling about with the telly’s volume setting, whenever you
switch amongst the video sources.

51
4 - Driving
4.1 - Hud & apps in general
You are free to move the in-game apps to anywhere on the screen you like. Even to a different screen, if you have a triple setup. They can be fixed in place
by clicking the pin in the top right. You have the choice from a multitude of apps that display a variety of information. Exactly how much and how detailed
that info should be, is up to you. (Image)

4.2 - Assists & ABS. Should I use them?

TC (Traction Control), SC (Stability Control) and ABS (Anti-Lock Braking System) are available in AC and can be adjusted in the driving options. The levels
of TC and ABS can be chosen on the fly during driving by CTRL+T or CTRL+A respectively. A high value for TC is less restrictive and intrusive than a low
one. Formula cars don't feature ABS and not all street or GT cars have ABS or TC. If you enable Pro settings in the driving options, all gaming aids mirror
the aids of that particular car in reality.

Professional pilots do actually use assists every day, but it depends on the racing class.

GT3 cars are designed to be driven with TC and ABS for example. Talking about F1, traction control was first introduced in 1990 because the cars were
extremely difficult to drive. As a result, it banished the driver’s fear of losing car control, at least for a few seasons. Later on in 1994, the FIA decided banned
it. However, it didn’t last long, and it came back for the 2001 season. The triumphant return only lasted until 2008, and drivers had to adapt to new driving
abilities, especially in the rain.

Meanwhile, the ABS system received its own ban in the 1993 F1 season. Once again, the sole purpose was to shift the driver away from relying on
technology and using their own skill. Even in 2021, both systems are still banned, mostly because they do little to enhance a driver’s natural ability.

Considering sim-racing in general instead, in my opinion assists only become a sort of “cheat” when they’re applied to cars that don’t have them from the
factory. If you use them correctly, there’s no reason to worry or feel bad about the help they give you.

More subjectively speaking, you'll be a better racing driver without traction and stability control. The reason is that these electronic devices interfere with the
natural handling of the car: they deprive you of important information regarding what the car is doing in a particular situation, which you need to act
accordingly, counter steering for instance.

ABS instead is very helpful and can make you more consistent.

Generally, I encourage you to drive with 'Pro' settings. In order to get used to drive without assists, you can do the following:

1. Pick a car & track combination you know well;

2. Drive with assists enabled (your current settings of stability control, etc.);
3. Drive again with Pro settings (assists off, except ABS);
4. After cursing at the gods and throwing your screen out the window, enable assists again;
5. Now slowly reduce their value (if you drove with 100% stability control, go to 90%, then 80%, etc.);
6. If you found a comfortable spot, save these settings and drive the next couple of days or a week with these;
7. Repeat in order: step 3, 5, 6, 7;
8. If you end up with 0% traction and stability control, you are one step closer to the driving level "Senna". You can just repeat the process with ABS.

And if you want to experience how it feels to drive on cold tyres that gradually warm up as you trot about, turn off the tire blankets. But if you want tires that
are already warmed up, turn this option on. To enjoy how the feel of the car changes as the tyres fall off their optimum grip profile without having to pound
round the track for many laps, raise the tire wear multiplier.

4.3 - Ambient & track temperature

Default value is 26°C for ambient and 32°C for track temperature. These are used for Pro settings and serve as a benchmark for competitive hotlap times.
More ambient temperature raises the track temperature as well, which yields more grip and thus faster lap times. Multiplayer servers always use the default
value.

4.4 - Replays

You can watch your races, in singleplayer or in multiplayer.

Assetto Corsa replays are universally appreciated for their fidelity, resulting in very realistic movements, car behaviour and camera management, but
resulting also in high requirements in terms of hard disk and memory space. Unfortunately such big files are not easily handled by players who join or
organize leagues and online championships. There are quality settings options that allow up to 4x smaller sizes and longer replays.

There are various functions in the replay menu of the simulator (Fig.): you can playback at multiple speeds up to 5x, the slow motion goes down to 12x
slower, there are markers for each lap, so you always know at which point of the race you are, and there’s also an often-forgotten built-in photo mode, if you
see something nice and you want to save it for the future generations (it’s a poorly implemented feature in vanilla, you better use CSP’s photo app or other
mods).

52
Fig. XII – The most important functions of the replay bar on PC. We have an example of a modded version too.

If you made a mistake and didn’t save the replay of a race, before starting any new session you can go to documents/assettocorsa/replay and look for a file
named “cr”, which stands for current replay; rename it and restart the game. The replay will be available to watch and saved permanently.

This “cr” file only contains the replay of the last session, whether single or multiplayer. Rename it before launching another session if you want to keep it,
otherwise it will be overwritten!!!

You can create a link on your desktop or anywhere convenient to open to the replay directory quickly.

You can save only a selection of the replay by sliding the two green corner markers to the designated beginning and end.

Pro tip: if you save a replay with modded content, it will not work anymore if the latter is deleted, and may be buggy if such content is updated with a new release (it’s often a
problem with tracks). This depends mostly on the workflow(s) of the mod creator(s).

How do replays work in AC?

4.5 - Track surface grip levels

AC supports a number of different track surface conditions. In tab. below are all the available presets with their numerical values.

Optimum Fast Green Slow Old Dusty

Session Start: 100 Session Start: 97 Session Start: 92 Session Start: 94 Session Start: 86 Session Start: 83
Ramdomness: Ramdomness: 20 Ramdomness: 20 Ramdomness: 15 Ramdomness: 30 Ramdomness: 10
Lap Gain:1 Lap Gain: 20 Lap Gain: 10 Lap Gain: 60 Lap Gain: 50 Lap Gain: 18

With the dusty condition, the track is initially very slippery due to, well, dust on the track. But as the session progresses, the rolling tyres sweep away the
dust, so a faster, grippier racing line forms, gradually. Off the line, the track is still dirty and slippery.
A track in the old condition has a worn-out surface, which is quite slippery. The surface does improve slowly, as the rubber is laid down over the course of
the session.
A slow condition track is slippery, and it may improve very slowly, if at all.
A green track is a good, clean track, but without a layer of sticky rubber on the racing line. So, it will be a bit slippery initially, but improves quickly as the
rubber is laid down. This is the condition you find a typical, modern racetrack on the practice day, the day before qualifying, and two days before the race.
A fast track has grip from the start. This is the condition of a typical track on the race day, because rubber had been laid down heavily over the past two
days, provided there was no overnight rain that washed away the rubber.
An optimum track is for those interested in setting hotlap records.

Randomness adds or subtracts a percentage to the starting grip. Example: session start at 86 and randomness at 30 means that the starting grip is 86%, but
with a random margin of +/- 3%. Think that even 1% difference is CLEARLY noticeable while driving.
Lap Gain: number of laps per car to add 1% grip to the tarmac surface.
Grip values and a 'Transfer_grip' value can be individually set in the server_cfg.ini in a dedicated server client. Example scenario:
- the session starts with 90% grip; at the end of the session, the grip is raised to 97%
- spread is 7%
now:
- if you put 100 in session transfer, you'll get 100% of that spread in the next session, so you'll get 97%
- if you put 50, you'll get 50% of that spread in the next session, so it will start from 93.5%

53
4.6 – Setup guide for simracers
Setup is the nightmare of every simracer: you started training with a car you like, with which you feel you have a certain feeling. Step by step you realized
that you were able to put together a qualifying lap, as well as maintain a decent pace for the race. Then that was the moment when you went online to
challenge real opponents, and not the traditional, as much as predictable, artificial intelligence.
After the initial euphoria of the moment and perhaps some well-deserved success... behold, you meet someone faster than you. You try to push your car
beyond the limits, but you always pay that one second difference that gives you frustration. The reason? You may already know: given the same vehicle and
track conditions, your rival has a better setup than you, which gives him the advantage you don't have.
Compared to any other video game area, if approached seriously, simracing (simulated-racing) requires specific knowledge in order to maximize the potential
of a racing car. Throwing yourself into the various screens to modify the setup without knowing what you are doing is not only inadvisable... but also
counterproductive! That is why this guide exists, and it will go through every aspect in the setup of an automobile. Let's start with the basic concepts that
every virtual driver must necessarily know.
In particular, the focus is on beginners, all those drivers who have approached driving simulators recently and want to internalize notions that may prove
extremely useful when the time comes to tackle competitions of some degree of importance.
In fact, this guide can also serve already seasoned simracers with years of experience behind them, who want to brush up on the basic concepts and, then,
the more specific ones in finding the optimal setup for their favourite car. As well as for all those drivers who, so far, have been driving with the basic setup
base provided by one of the many simulators available on the market today.
The information you will find in the various parts of this guide, in fact, may find application on Assetto Corsa as on rFactor 2, passing through sim-cade titles
such as F1 2019 or others that are more simulative such as iRacing or Assetto Corsa Competizione.
Why modify the setup?
Let's face it: the various titles that make up the simracing world are already capable of providing highly competitive basic setups in the right hands. Of course,
not every car can be pushed to the limit, but it is no accident, for example, that there are series on iRacing where the setup is fixed for everyone, where it is
therefore possible to concentrate exclusively on driving, rather than getting lost in the details of modifying the suspension or the aerodynamics.
The same can be said for Assetto Corsa's Sim Racing System, which regularly features races with locked setup: along with the "casual racing" of simcade
(simulation-arcade) titles such as F1 2019, these alternatives are definitely the best in order to learn driving fundamentals, as well as well as the various
techniques of defense and attack when it comes time to confront one's opponents on the track.
Why, then, modify the various parameters of a vehicle? The answer is: to know the true potential of the vehicle you drive.
One thing is certain: changing the setup cannot work miracles. Instantly using the setup of the best driver in the leaderboards will not allow you to obtain the
same time and to be as competitive. Before going to touch the parameters of a car, you need to know the most about its behaviour: what its reactions are in
slow turns, in fast ones, whether it suffers from understeer or oversteer, whether it bounces on the asphalt or loses grip under acceleration.
When you have found a certain feeling with the car you are driving, that will be the moment to move on and "create the setup". This procedure will allow you
to gain more confidence between the curbs, go faster and, as a result, lower your lap time considerably. Not only, modifying the basic setup will make more
pleasant to drive all those cars which, as it is, are difficult to "digest" both in qualifying and, especially, in longer stints.
How to modify the setup?
In real motorsport, and consequently also in simulators, a racing car represents an extremely complex system to manage: we are not talking about an engine
pushing a chassis and four tires controlled by a steering wheel! Many other parameters come into play, including differential, tire pressure, weight distribution,
suspension calibration, and aerodynamics, just to name the most important and widely known ones.
Working on the setup therefore represents a very complex challenge for a novice: it is not just a matter of changing a couple of settings.
In the world of virtual driving, in fact, a driver is at the same time a track engineer, whose job is to scrupulously analyse the handling of the car he is driving
to identify any possible problems that may affect his performance. Once recognized, he must be able to find the solution, acting scientifically on the setup:
this means making one change at a time and testing it with a couple of laps of the track to verify its effectiveness, keeping all other variables unchanged,
such as circuit conditions, air and asphalt temperatures or on-board loads.
Setup is conditional upon three factors:
1. Track. As examples, Monza demands high top speed, because of the long straights this track features. If you don't tune your car accordingly, you are going to be slow and
prone to being overtaken by your fellow competitors. Conversely, the Circuit de Barcelona-Catalunya in Spain demands high downforce and a balanced car, because of the
numerous and elongated corners with high lateral G-forces. With a setup designed to gain an advantage in certain areas of a track, for instance high speed corners, you
may facilitate yourself more chances to overtake someone: higher speed through the T1 corner on Silverstone GP may grand you overtakes in T3.
Inform yourself therefore about the features of a track by doing some quick research and/or drive a couple of laps and use your judgement.
2. Car. Has the car its engine in the front, middle or like a RUF in the back? As the heaviest part of a car, the placement of the engine dictates the inherent driving characteristics
of a certain vehicle. A front-wheel-drive/front-engined Abarth 500 will have inherent understeer and the front wheels are taxed with both steering and putting the power
down. A rear-wheel-drive/front-engined BMW will have inherent oversteer, but good traction out of the corners. A rear-wheel-drive/rear-engined RUF will have loads of
mechanical grip, because its engine will press the rear wheels into the ground. A rear-wheel-drive/mid-engined McLaren will be inherently twitchy, but has more balance
than the others. Be conscious of the basic layout of your car, play with its strengths and limit its weaknesses to gain an advantage over your rivals.
3. Driver. The debate that's been going on in Formula 1 over the decades, whether the driver makes up 10, 20 or 30 percent of the package is really superfluous. Even if the
true percentage were to be the former, it is still a sizable chunk of performance. In the GT classes or the BTCC, where cars are homogenised, driving prowess and style is
even more important.
This is probably worth a whole article about driving technique, however be advised to do the following: be aware of your personal attitude: are you comfortable with a
twitchy but agile car and are able to catch slides quickly and reliably? Then you would have less trouble with oversteer. Do you value consistency and stability above all
else? Then look for a compliant, neutral handling car or with slight understeer. Talk to your fellow sim-racing drivers, watch cockpit views from professional racing drivers
on Youtube and others.

54
Quick setup suggestions
The following table shows which adjustments you can make to correct the car setup as a general rule. For a very specific case you should focus more on
solutions valid for the type of vehicle you’re driving.
QUICK SETUP FOR… PARAMETERS IF THE CAR UNDERSTEERS… IF THE CAR OVERSTEERS…
Corner Entry SLOW BUMP (suspension) DON’T AFFECT increase decrease
SLOW REBOUND (susp.) CAMBER increase decrease
BRAKE BIAS to the rear to the front
DIFFERENTIAL COAST decrease increase
FRONT TOE decrease increase
FRONT WHEEL RATE (springs) DO AFFECT decrease increase
REAR WHEEL RATE (springs) CAMBER increase decrease
FRONT CAMBER increase decrease
REAR CAMBER decrease increase
TIRE PRESSURE increase decrease
FRONT WING INFLUENCE increase decrease
REAR WING THE TOP decrease increase
FRONT HEIGHT SPEED decrease increase
REAR HEIGHT AND CAMBER decrease increase
Cornering SLOW BUMP (susp.) DON’T AFFECT increase decrease
SLOW REBOUND (susp.) CAMBER increase decrease
DIFFERENTIAL POWER increase decrease
DIFFERENTIAL COAST decrease increase
FRONT CAMBER DO AFFECT increase decrease
REAR CAMBER CAMBER decrease increase
TIRE PRESSURE increase decrease
FRONT ARB (Anti-roll bar) INFLUENCE decrease increase
REAR ARB (Anti-roll bar) THE TOP increase decrease
FRONT WING SPEED increase decrease
REAR WING AND CAMBER decrease increase
FRONT HEIGHT decrease increase
REAR HEIGHT decrease increase
Corner Exit DIFFERENTIAL POWER DON’T AFFECT increase decrease
REAR TOE CAMBER decrease increase
FRONT WHEEL RATE (springs) DO AFFECT decrease increase
REAR WHEEL RATE (springs) CAMBER increase decrease
FRONT CAMBER decrease increase
REAR CAMBER decrease increase
TIRE PRESSURE increase decrease
FRONT WING INFLUENCE increase decrease
REAR WING THE TOP decrease increase
FRONT HEIGHT SPEED decrease increase
REAR HEIGHT AND CAMBER decrease increase
Factors affecting tire temperature PARAMETERS TO OBTAIN > Temp TO OBTAIN < Temp
SLOW BUMP (susp.) increase decrease
TIRE PRESSURE decrease increase
WHEEL RATE (springs) increase decrease
ARB (Anti-roll bar) increase decrease
TOE increase set towards 0°
CAMBER increase set towards 0°
Bumps IF YOU LOSE CONTROL OVER A BUMP, YOU SHOULD…
FAST BUMP (susp.) decrease
FAST REBOUND (susp.) decrease
HEIGHT increase
WHEEL RATE (springs) decrease
Height IN GENERAL AND RAKE SETUP
Adjusting the heights in a setup (as well as the wings) is critical to distinguishing a performance setup from one which isn’t.
Generally speaking, there is a tendency to reduce the height of the car as much as possible in such a way such that the
aerodynamic load of the drag-generating ailerons and the roll of the car are reduced. However, there are special settings that
generate more aerodynamic load at the cost of top speed and drag, without changing the aileron incidence, which is
particularly appreciated at medium-fast circuits like Spa and Silverstone.
In the so-called Rake set-up (widely used in F1 cars) the front nose height is smaller than the rear, thus forming an angle
from 1° to 4° and facilitating the job of the car's bottom and the diffuser, which generate load aerodynamics with very little
drag. However, it is necessary to adjust the ailerons accordingly to restore the top speed.
The cells in dark brown are parameters that influence and are affected by the car's top speed. Pay attention when changing these parameters.
The cells in green are parameters of the shock absorber, toe-in and differential, which are useful in slow cornering and in the search for mechanical grip. Do not affect camber.
Cells in beige are parameters that are affected by those in dark brown, so care should be taken attention in case of fast or slow turns. All brown and beige parameters affect
the angle of camber of the car.
In increasing camber, it is intended that the new value of camber angle becomes smaller than the previous one (e.g., go from -2.0 to -2.3 or from 0.6 to 0.3), since normally
cars have negative camber. Pay attention to the difference.

55
Setup criteria
The following criteria list serves as a reminder of what a driver may obtain and what a track may demand from a car. Important criteria are key for overall
drivability and whether a driver has confidence in the behavior of a car. Optional criteria are “quality of life” features that make a driver's life easier. This list
may not be complete.
Important: Optional:
• Suitable gear ratios (track dependant) • Top speed
• Braking stability • Lateral grip mid corner
• Turn-in willingness • Prevention of oscillation of suspension/dampers after bump
• Prevention of sudden change from over to understeer mid-corner and vice versa • Optimal tyre temperatures
• High-speed corner balance • Optimal braking distance
• Prevention of snap-oversteer on turn-in • Bottom-out of car
• Prevention of lift-off-oversteer
• Reliability of steering precision and agility
• Traction on corner exit
• Stability and agility through chicanes
• Weight transfer stability though S-corners and chicanes
• Stability during slides
• Evenly distributed tyre degredation (e.g. over a race distance)
Useful setup advice:
Camber: More negative camber means the outside wheels will have more grip during turns, but less grip during acceleration and straight-line braking.
Pro tip: in general, start with low camber values and work your way through. After a certain point, no further lateral grip can be gained; more camber will result in greater
braking distance, instability and higher (thermal) tyre degradation. Camber settings are great in tuning stability and balance mid-corner, especially through high-speed ones.
Be careful with increasing rear camber for endurance races: overheated tires will cause oversteer near the end of the race. Front camber has greater influence in braking distance
and stability, even greater for more front brake bias.
Ride Height: Low reduces weight transfer under braking, acceleration and cornering, allows stiffer springs. Generally makes you faster. Be advised of dive
and squat of the front suspension. Negative aspect: increases risk of bottom-out of the car.
High ensures the car does not bottom-out over bumpy tracks, allows softer springs. Cons: increases weight transfer under braking, acceleration and cornering.
An increase in height on the front and decrease on the rear adds stability on brake lift-off, but brings understeer.
Pro tip: a level car reacts more naturally. If the rear is higher than the front, the car will be more prone to oversteer - vice versa for understeer. Seek for a level and straight
road for ride height setups. Remember to empty the fuel tank before tweaking. For endurance races with high fuel load, consider driving characteristics at the start of the race
with ones at the end. Go from min to max fuel and watch the change in height and height balance to figure out where the fuel tank most likely sits and take action accordingly.
A lower ride height may require stiffer springs & dampers, especially higher Bump rates.
Suspensions: Softening them gives the car more grip but it may feel like a boat. Stiffening them will produce a snappier behaviour. This means that the
vehicle will be more responsive to changes of direction, but will also manifest a more frequent tendency of losing control.
Bump and rebound have a simple logic: bump is how you set up your suspension to work when it compresses. Rebound is when it expands/extends. So,
for your front wheels, bump will affect braking and rebound will affect acceleration. For the rear wheels it's the opposite, since the rear lifts up during
braking, so the suspension expands. Also it affects the steering, since turning to the right will make the car roll to the left, so the left wheels will use bump
and right wheels will use rebound. On the left-hand turns, it will be inverse. In general, I prefer to set bump and rebound to symmetric settings between
left/right sides because I don't want to overcomplicate stuff.
Let me give you a couple examples:
• Car is understeering on corner exits when I apply throttle. This means the front lifts too much and front wheels lose traction. I will make rebound for the fronts softer, in
order to give more room to the wheels to contact the ground.
• Car is understeering on corner entry. I will make bump softer on the front tyres, in order to make the weight of the car land smoother on turn-in.

The same logic can work for the rear suspension.

Fast Bump and Fast Rebound have similar usages, but they affect the very rapid movements of suspension on kerbs and potholes.
Analogous principles apply to ARB (Anti-roll bar). The stiffer it is, the less the car rolls when turning. This will make the car more responsive to change of
direction, but it may reduce traction during turning. Making it softer will result in more body roll, which will make the car sway, but also more grip in turns.
Be gentle with Anti-roll bars. Set them low first and work your way through. Be wary with the ratio 'front to rear' ARB settings. This is most evident through
high speed corners. A well tuned ratio will give you stability and predictability and therefore faster lap times.
Aerodynamics: This is probably the easiest to understand, but still there are some tricks. More aero means more downforce, which means better grip on
medium and fast corners. Aero will not play a big role for speeds below 100 Km/h.
Now here's the catch. Increasing rear downforce means that you will have more grip in the rear wheels during a turn, but this means that the weight of the
car might shift slightly to the rear. So in most cars this has a negative effect of the grip of front wheels. This will probably affect you during braking after big
straights. You will see that a higher rear downforce gives less traction to front wheels, and might slightly increase your braking distance.
For cars that have front and rear downforce adjustable, this problem can be controlled by changing both parts in a similar way (changes in wing angle). This
will let you increase or decrease downforce as a total without hurting the overall aero balance.
Keep in mind that aero also affects suspension, since it pushes the car lower, but you may not feel the difference.

56
Generally, the rear wing should be as low as possible to gain higher top speed and yes, in contrast to some other games (Gran Turismo, F1 2012) this setting
has a measurable effect in Assetto Corsa. However, you should start with a low value and increase it to gain stability through high-speed corners and S-
corners, if needed. For instance, I found the rear wing to be much too high on the BMW Z4 GT3 at default, which is surprising, because it's prone to oversteer.
A higher rear wing counters well oversteer due to tyre degradation.
If possible, the front splitter should always be on/engaged - more front-end grip with no tangible detriments.
Differential: Assuming you have a RWD car, making your diff more "open" will make the wheels spin more under hard acceleration, but they will not cause
oversteer. This will make you slower out of corners (because wheel spins instead of producing acceleration), but more stable. The technical explanation is
that if a wheel has less traction (usually the inside wheel on a corner), more power will go to that wheel, which means that the spinning tyre will not be able
to stick to the ground, and the grippy tyre will get less power. That's how open diffs work in general. They are found in most consumer cars because they're
cheap and simple.
On the other hand, making your diff stiffer will reduce slip in your diff and make it act more like a closed diff, which means that both wheels will keep getting
some percentage of power. The percentage is adjustable by the diff setting. This setting will ensure your outside wheel gets power and car accelerates
faster. The problem is that it's easier to lose control and cause a spin. Essentially, drift cars have stiffer diffs in order to help both wheels spin during the
turn, so you understand that a stiffer diff is more inclined to cause oversteer, but this is also faster for a race car.
Some cars have separate controls for the diff during acceleration and coasting (when you let off the gas). The same logic applies.
Toe: Don't mess with it. Values away from zero will make you slower.
Front:
• Toe-Out (negative) may help to compensate for negative camber on the inside wheel during
cornering. Increases grip on initial turn-in, but reduces lateral grip mid corner.
• Toe-In (positive values) may stabilise the car during lift-off and turn-in, but reduce grip on
initial turn-in.
Rear:
• Toe-Out (negative): Don't bother. Increases lift-off oversteer, makes the car prone to snap-
oversteer and is dangerous in general.
• Toe-In (positive) increases braking and straight line stability, but increases turn resistance and
understeer.
Note: Toe values away from zero create an artificial slip angle. Increasing toe-in (positive
values) at the rear is a common and effective practice to increase stability under braking.
Generally, the rear toe values have a much higher impact on handling than the front ones.
Fig. -

Brake bias: The default values for the brake bias in Assetto Corsa follow the natural driving characteristics of a particular car. The BMW Z4 GT3 for instance
has great front brake bias, because of the long bonnet and heavy front structure. Don't mess with the brake bias too much. You may shift the brake bias
towards the rear in an attempt to decrease braking distance. Do so one point at a time, until you experience instability under braking. After, apply one point
bias to the front for stability and reliability. You may apply more toe-In (postive) in order to increase braking stability, albeit sacrificing performance during
cornering.
• More bias at the rear increases oversteer.
• More bias at the front increases understeer.
• Correct bias results in stability and predictability during braking and turn-in.
Gear ratios: Correct gear ratios are achieved following these steps (use pen and paper to write down speeds):
1. Write down your gear ratios (including final ratio), gears and their corresponding top speeds you have at hand.
2. Drive down the longest straight of the track until you hit the rev-limiter in top gear (adjust top gear if needed) right at the end of the straight (just at the braking point).
3. Apply one ratio higher to your top gear (for room to gain higher speeds in slipstream) - write down your maximum speed (Vmax).
4. Look at maximum speed deltas between the gears, except 1st and 2nd, and adjust them for the lowest variance - the deltas should be as even as possible - better still if
the deltas of high gears are lower than the ones of lower gears. Play with the final gear ratio to optimise the delta variance.
5. Drive a couple of laps on the track - pay attention if you have to shift either mid corner (which in general should not happen) or just before a braking point.
6. Decide which gear to use in what corner and shorten / lengthen your ratios - repeat step 4.
7. If the speed deltas are too great, consider using another gear.
8. If you cannot find the right ratios or you run out of adjustable space, change the final gear ratio - repeat step 5, then step 6.
9. Regarding the 1st gear: put on the tyres you want to use during the race and practice starts from standstill with cold tyres - the revs shouldn't tank and shouldn't hit the
limiter immediately after the start - adjust your 1st gear accordingly.
The reasons for all this are manifold: to avoid changing gear mid-corner, which upsets the car in one way or the other - to gain enough top speed down the
longest straight, but not waste performance - to avoid changing gear just before a braking point, which costs you time on track and may divert your
concentration from the important braking point and eventual steering corrections you have to apply - to have a clean getaway at the start (1st gear), where
places can easily be gained or lost.
Concerning gear delta variance: you want to hold the revs of a car in the optimum range for best power and torque (prime example is the heavily
turbocharged Ferrari F40). Look at the corresponding curves in the car info screen.
Travel range: By decreasing it, this value negates suspension travel and numbs down suspension and dampers. Keep it close to maximum for GT cars.
Slightly lower values at the rear may grant you better traction, though.
Tire pressure: More increases precision and agility, increases the temperatures. Too much or too little pressure reduces contact patch of the tyres (Fig.).
57
Fig. -

Pro tip: Oftentimes, changing the tyre pressure shouldn't be necessary and may be considered if other settings are exhausted or are undesirable to change. Different pressures
in the front than in the rear change the handling noticeably. Keep in mind, that the combined surface area of the tyres that is actually touching the road is quite small - all the
power, suspension, differential, camber and so on goes though there.
Fuel load: This is straightforward. Look how much fuel you as an individual driver use with a particular car & track combination, multiply by the amount of
laps you want to go or have to race and there you go. Don't cut it too close, all the setup work, preperation and your race performance is for not, if you run
out of fuel just before the last couple of corners.
- Shock absorbers are crucial in chicanes.

58
4.7 – Driving techniques
The racing line
A racing car must take a bend or a series of bends at the maximum possible speed and reduce the shape of the corner to its minimum possible angle. The
best racing line can be seen as being made up of three distinct points on the bend:
A) the turn-in point, usually at the end of the braking area and the position when the car actually enters the corner.
B) the apex or the clipping point. This is the slowest part of the bend and the point where the car is nearest to the inside of the corner.
C) the exit point when the car is back on a straight line. This is usually the fastest part of the bend.
Obviously, the best racing line also depends on the driver and the car. Is he trying to overtake another car into the corner? Is the corner before or after a fast
straight? Is the track surface wet or oily? All these considerations come into play and the driver must adjust his line accordingly.

Typical corners and bends

A driver must try to use all the available space on the track, even the rumble strip-the run off area on the edge of the tarmac.
In a typical corner, for example a righthander, the driver arrives on the left side of the track, brakes, changes down, checks for his turning-in reference point
then steers the car towards the clipping point on the inside of the bend. Once past, he eases back to the other side smoothly and exits the corner.
Driver priority must be to get power back on as soon as possible to achieve maximum speed into the straight.
Here we have some of the most common types of corners you can find on any track, along with a brief explanation on how to take them.
- Fast Corner - 90 Degree Turn

Fig. XIII - Most of the racing circuits have a corner of this sort that can be taken at Fig. XIV - There are many different ways to turn into this type of corner depending on
speeds in excess of 140mph. The driver turns in at A, passes the apex at point B then whether the driver is about to overtake, but the classic approach is to turn in late at A,
keeps his line all the way through to exit point C. The driver makes no sudden turns pass the apex again late at B, and accelerate fast from that point to get a good clean
on the wheel and the whole process should be very smooth. exit at C.

- The Constant-Radius Corner - Double-Apex Corner

Fig. – There is a very long apex on this type of corner so there is no gain in taking Fig. - The key to negotiating this type of bend is to make one corner out of two. The
the entry point late. The driver turns in early at A then stays close to the contact driver aims for the ideal line and stays inside the track’s width, effectively making the
points B and B as long as possible. As he leaves the apex, he crosses the track and exit line of the first bend the entry line of the second. If the line is perfect then the
touches his exit point at C. driver does not have to correct his steering.

59
- Hairpin - The Tightening Corner

Fig. - The aim here is to turn in late to create the widest possible angle so that after Fig. - The car stays wide so that the driver can touch the apex extremely late at B,
point A the bend can be treated like a fast corner. The sharp initial turn is vital to then brake, select a lower gear, cross the track following the curve of the bend and
make the car as fast as possible out of the hairpin. When point B has been touched get a good clean exit at C.
the driver can safely put his foot down before reaching point C.

- The Opening Corner - The ‘S’ Bend or Chicane

Fig. - The driver turns in early at A, covers the short distance to the apex B then
smoothly moves to the outside. This allows the last phase of the bend to be driven
like a straight and the driver can accelerate quickly long before passing point C.

Fig. - Ideally, a good racing line can straighten out some bends without the need for
sudden turns. The driver turns in slightly at A approaching the first right-hander, then
clips points B, B, B with hardly any modification before exiting at C

60
- Tight Corner After a Fast Bend - A Long Straight After Two Identical Corners

Fig. - Take a tight line into the fast right-hander but brake as the second point B
approaches. The car must slow down to take the left-hander but this is not a problem,
for the driver has gained speed in the first two thirds of the series of bends.
Fig. - The important point about this series of bends is the approaching straight. The
driver turns in late to the right-hander and hits the clipping point well into the bend.
He then takes the fast left-hander as though the previous bend had not existed. Thus
the first corner is taken slowly to give the car as much benefit as possible from the
oncoming straight.

You spend more time in slow corners than in fast corners, so you can often gain most lap time by concentrating
on these areas.
Exit speed is important, but equally as important is minimising the time spent in the corner.
You often see drivers taking a big wide entry into hairpins to gain a fast exit speed, but due to the slow speeds
involved, this sacrifices huge amounts of lap time, in order to gain a few tenths down the straight.
The hairpin is a great example. Take the two lines taken in the same car at the same race meeting (Fig.). The
red line is 14m shorter than the blue line, meaning 0.45s less time is spent in the corner. The blue line does
gain 2mph down the straight, but this is only worth 0.15s. Therefore the gain from the shorter line is 0.3s
(0.45-0.15=0.3). This means you need to go slower into the corner, but you gain time by travelling less distance.
This compensates for the slight speed disadvantage onto the straight.
- Cornering in Wet Weather
Driving quickly on a wet track requires a very different technique compared with
driving in the dry. Depending on the track, the quickest line through the corners
may differ substantially from the accepted dry ‘racing line’.
The wet line myth
It is often quoted that the racing line becomes coated with rubber and oil which
makes it more slippery in the wet. However plausible this sounds, it is in fact a
myth and here is why: when asphalt is first laid down, there is a uniform roughness
to the surface. Over the years, as many cars pass over the same piece of road, the
sharp ridges and peaks in the road surface become worn down to a smooth surface
(Fig. ).

Fig. - Close up of tarmac worn smooth after 8 years of heavy use.

Fig. - Taking the classic right-angle corner as an example, it’s easy to compare
the dry line with the wet line. The driver takes up position in the middle of the
track, keeping off the outside line which is likely to be very slippery. The line he
drives will be cleaner and give far better grip in the rain. The car is kept in the
middle of the track as it passes the apex then steers for the outside line. The main
aim of drivers in wet weather is to look for maximum grip.
Off the racing line, it is the sharp ridges and peaks which yield greater grip in the
wet than the smoother, more frequently used parts of the track.
The two dominant forces affecting the performance of a tyre are adhesion and
deformation. Adhesion is the chemical ‘stickiness’ between the tyre and the track,
and deformation is the force which results from the rubber changing shape to fill
in the gaps in the surface.
61
With adhesion, the more direct contact there is between the tyre and the track, the greater the force. With deformation, the more distortion of the tyre there
is, the greater the force.

Fig. – (left) Smooth surface. Good adhesion + Poor deformation = good grip in dry. (right) Rough surface. Poor adhesion + Good deformation = good grip in wet.

Adhesion generally has a stronger effect than deformation, so in the dry, once the tyre is up to temperature, a smooth surface will generate better grip than
a rough surface.
However, a wet surface prevents direct contact between the rubber and the surface, completely blocking the formation of the adhesive forces that work best
on flat surfaces. Therefore, in the wet, a rough surface can generate far more grip by increasing the deformation of the tyre.
Another important factor is the tyre temperature, as cold tyres have inherently less grip than warm tyres. In the wet, it is often difficult to get tyre temperatures
high enough to give good grip.
How to find the wet line (or wettest line)
Unfortunately, there is no magic formula to working out the ‘wet line’ through a corner, the only way is through trial and error, and this is where a predictive
lap timer becomes an essential part of the process.
Here are some tips from Nigel Greensall, highly experienced driver coach, on finding the grip on a wet and slippery track:
• Get some temperature into the tyres: “I find it is important to work the tyres hard straight from the pits. I try and slide the car around to move the tread blocks about to
generate some heat. However, there is no point trying to do this on the greasy parts of the track, as you won’t be able to generate enough G forces to have an effect, so I
drive around the edges of the track trying to find some grip. It is only once the tyres are up to temperature that you can properly begin to find what the quickest line will
be”.
• Brake offline: “The track is often very smooth in the braking zone, so I sometimes try braking slightly towards the inside of the track to maximize the grip”.
• Turn in later: “I avoid the normal turning in point, and attempt to drive just round the outside of the normal racing line, leaving a later turn in than as normal. I then turn
more sharply than I normally would in the dry in order to get the car pointed up the next straight as early as possible, and get on the throttle as soon as possible. Slow in,
fast out”.
• Straight line the slippery bits: “Of course, at some point you have to cross the slippery racing line, so that is also why you should try and be as straight as possible to
avoid any wheelspin. Spend as little time as you can accelerating on the slippery part of the track - try to ‘float’ across it - and avoid the exit curbs, if at all possible”.
• Use a predictive lap timer: “A predictive lap timer displays the difference between your current lap time and your previous best. A positive number means you are going
slower, and a negative number means you are going quicker. I reset the display just before I leave the pits, and then I try a number of different lines around each corner,
watching how much time I gain or lose. As I enter the corner the display may be reading +0.50 which means I am 0.5s slower at that point, but this doesn’t matter as I am
only looking for a change in value. As I exit the corner it may then display +0.25, which means I have gained 0.25s in that section. This works on a corner-to-corner basis,
all I have to do is glance at the readout just before I turn in, and then once again as I exit. The key point is that I don’t need to wait until the end of the lap to find out if my
new approach to that corner has worked. In this way, over three or four laps I can quickly build up a picture of where the grip can be found, and then string these pieces
together to produce a quick lap. When you then sail past other people on the track, they are often left wondering how you managed to drive clean round the outside or even
up the inside of them whilst they are slipping and sliding around!”. In Assetto Corsa you do have the possibility to display the delta.
• S-bends: “On S-bends or chicanes, I tend to use more or less the same line as in the dry. This is because to drive on the grippier parts of the track in these situations
requires a lot of deviating backwards and forwards across the slippery racing line, which ends up being slower”.
Reaction of car through a corner
- Understeer - Oversteer - Neutral handling

Fig. - The rear wheels have better grip than the front ones,
so the car will not react fully to the driver turning the
wheel. Rear-wheel drive cars will begin to move towards
the outside of the track.
The driver in such a situation can do one of two things:
ease up on the accelerator, making the driving wheels
push less, giving the front wheels a better chance to grip;
if the car still does not respond, brake lightly without
locking the wheels. The car will slow down enough to give
good grip to the front.
Fig. - The front wheels have better grip than the rear wheels. Fig. - The ideal situation, as the sideways drift of the rear
This can possibly be because of too much power or because wheels is matched by those of the front. All four wheels
the car balance is poor. This tends to make the back end of slide in the same way. The driver sets up the car on entry
the car slip out towards the outside of the corner. The to the corner, so the front wheels are straight and the
consequence might be the car spinning off altogether! driver doesn’t have to steer.
To counter oversteer a driver can do one of two things:
This is typically called “drifting”.
opposite lock on the steering wheel might just establish the
car’s balance; otherwise easing up on the accelerator will
slow down the car and give the rear wheels a chance to grip.
There are also certain times when drivers might accelerate,
but knowing when to do this comes with experience.

62
Marker points
To set up the ideal racing line on a circuit you must find as many markers as possible to use as reference points. The individual tracks provide 300, 200, 100
metre boards before a bend but these are too general for most drivers; many rely on advertising boards, bumps in the track, certain trees or bushes for turn-
in points, braking zones or accelerating areas.
In fact, the driver must know every square metre of the circuit and the markers, once memorised, allow him to think ahead, to anticipate the next corner.
Imagine you are accelerating through a fast straight. When you see the marker for the braking zone into a bend, your mind will be already thinking about the
next marker for the turn-in point. As this is passed, you are thinking about the apex marker and finally the exit point. Think ahead. Look out for the next
marker. Don’t wait until you see it to react.
Braking
- Ideal Braking
In Formula One the driver aims to keep his foot down on the accelerator as long as possible. When he gets to a corner, he will wait until the last moment before braking and
then brake as hard as possible over the shortest possible distance. The only reason to brake should be to achieve the best speed for entering a bend and the only reason for
removing your foot from the accelerator must be to “jump” to the brake pedal.
Ideally, there should be no compromises with braking.
- Wheel Lock
Braking hard can present the driver with another problem; that of locking wheels. It’s possible to lock up one, two, or even all four wheels if you brake too hard in a given
situation. A locked wheel is no good to anybody. The tyre wears out excessively on the locked patch and this creates a flat spot which will feel like violent bumps when the
wheel is turning again. The tyre will be out of balance and the car almost impossible to control. To avoid wheel lock, the driver must be sensitive enough to brake hard and to
detect the first signs of lock-up.
Changing down
Changing down into a lower gear must always accompany the act of braking. One without the other is not good driving. The aim is to brake to the ideal speed
for the approaching corner then change down in order to be in the right gear for the moment you need to accelerate again. Changing down is done as you
brake. Any earlier and the car will still be at full speed; any later and the driver has too much to do in mid-corner.
Overtaking
If you’re not at the front of the grid in every race then chances are that you will need to overtake other cars at some point.
Overtaking is not just a matter of more power in your engine. It usually boils down to three factors.
1. Can you take a corner better than a rival?
2. Can you exit a corner faster and enter a straight at a greater speed?
3. Or, can you brake later than a rival at the end of a straight?
To overtake successfully, especially against a determined rival, you must be aware of the driver ahead.
1. Where is he slowest?
2. Where does he brake earlier?
3. On what part of the circuit is he the least confident?
Eventually, you will have a good picture of his strengths and weaknesses. You must make his worst manoeuvre your best, wait for the right moment then
make your challenge.
All the above assumes that the driver ahead will not make a mistake; but all drivers make mistakes during a two hour race, so take every opportunity offered
to you and wait for that error!
- Outbraking: driving faster through a corner than a rival
The driver ahead is not confident through a certain corner. If a driver has
managed to get a lead on a rival in the previous straight and is now on the
inside line for the next corner, he must try to brake a little later into the bend,
giving himself right of way.
If the rival driver stays in contention, around the outside of the track, he is in
danger of spinning off. It’s important to close the door after you exit the corner,
especially if the rival car is trying to get level again.
Choose your moment. Take a strong position off the ideal line, in the centre of
the track and make his overtaking attempt as difficult as possible (trying not to
make accidents). Leave a space between the two cars so that the opponent
can’t force you to slow down. Just enough room to let you attack the corner at
the speed of your choosing. You’ll find mirrors to be actually very useful in
these situations.
When you leave the corner you will have more speed than the other car. The
faster exit speed gives you the advantage to overtake in the following straight.

Fig. – Comparison of the outbraking trajectory with the normal path.

63
- Slipstreaming (drafting)
Yes, there is the slipstream effect in AC (Fig.).

Slipstreaming is a phenomenon that usually occurs at speeds above 70mph.

Catch a rival car on the beginning of a long straight and get very close behind him
(within a few inches).
Both of you are travelling at the same speed but you are in a small area, a few
metres long, which is free of air turbulence. The car ahead is doing all the work
while you gain mph. You can tell that you are successfully slipstreaming by the loss
of turbulence and the gain in acceleration.
By now you’re probably travelling at 140mph just inches behind the rival car. You
wait until the last possible moment then slip out to the side of the other car.
Although you will now be subject to the same forces of turbulence, your speed gain
during the sheltered period will give you the edge to move slightly ahead (Fig. ).
Slipstreaming can be very important, especially in one make racing, or in cars that
are not very aerodynamic. It can make a significant difference both to qualifying, or
trying to get that final lap overtake done, but it is not just a case of sitting behind
the other car and hoping for the best. You also get a benefit from the car in front
from quite a long way behind.
In fact, there are reports of gains 0.25 seconds down one straight alone at
Silverstone, despite being around 7-10 car lengths behind the car in front
(Racelogic VBOX Motorsport UK). This makes 3 miles an hour difference by the
Fig. - The passing of a rival car while slipstreaming. end of straight. If you can get this down every straight at Silverstone on one lap
this can be worth between 1.5-2 seconds per lap.
Naturally the closer you are the more of a slipstream you get (within reason), you will also go even faster down the straight if the car in front of you also has
a slipstream.
This may sound strange but going faster down the straight is not the only consideration when trying to judge slipstream, especially in a qualifying session.
You gain 0.2 seconds down the straight, but as you are so close going into the next corner you can’t then take it as fast as you normally would and end up
losing 0.15 seconds.
There is not really a right answer to how much of a gap you should leave when trying to get a slipstream in qualifying. It depends on several factors that all
have an influence on your decision. The circuit is one of them, and another is how easy it is to overtake without losing time. Naturally a wider circuit such as
Silverstone is much easier to get past people than Cadwell for example, so you can stay closer behind a car at Silverstone, get more of a slipstream and
then hope to overtake them losing minimal time.
Some cars will get more of a slipstream than others. The less of a slipstream the car gets, the closer you will need to be to the car in front. Both you and your
competitors’ experience level has a huge impact on how close you can stay to the cars in front without losing time. If you are inexperienced, you will naturally
feel less comfortable attacking corners while close to the car in front. You can quite often negate all the time you’ve gained in the slipstream down the straight
by being too cautious in the next corner when you are closer to the car in front. If your competitors are less experienced, they are more likely to make a
mistake when you are close to them, again undoing any straight-line speed advantage and time gained you’ve had by being in their slipstream.

Fig. – Simplified visualization of the effect of slipstreaming on the aerodynamics of two cars.

64
A slipstream done correctly on certain cars can gain you up to 2 seconds a lap, and can be the difference between being on pole or outside the top 10 at the
end of that vital qualifying session.
If you’re on a narrow circuit that is harder to overtake on, then leave a bigger gap. You will still gain a surprising amount of time from 10-15 car lengths back
compared to a normal lap without a tow. This will give you the space to still take the corners as fast as you can while gaining speed from the cars ahead.
If you’re confident at overtaking, and comfortable driving close to other cars while still attacking the corner entries, then leave a smaller gap and be prepared
to overtake cars during the lap. This will gain you the most time, but also gives you the biggest chance of having your lap spoiled through no fault of your
own.
On a side note, you probably noticed that in Fig. is written that both cars go faster. Why does this happen? Well, when a car drives forwards, it creates an
area of low pressure directly behind it where there are no (or fewer) air particles. You know how if you stand directly under an umbrella, you'll stay dry,
because the rain hits the umbrella and is moved to the sides? Same idea.
This works like a vacuum, sucking the car backwards, hindering acceleration.
If anything exists in that gap, it will disrupt the "bubble" of low-pressure air, pushing high-pressure air forward, so less fast-moving air hits the lead car's
spoiler. The result is less drag for both cars, allowing faster speeds. We see this lots of times in NASCAR, for example, where drivers are able to "bump draft"
the car ahead without ever actually touching it.
Frankly, anyone disagreeing and saying that it costs the car in front more to tow someone along is wrong and does not understand aerodynamics - there is
no argument here. (The driver in front will still be using more fuel than the driver behind, there is no free energy, but it in no way costs more than if they were
driving solo).
This also exists in F1. However, the reality is that the low-pressure zone of formula cars is fairly small, which coupled with the high speeds, makes the “bump
draft” impractical for F1 drivers to achieve in practise. Driving while in the low-pressure zone requires being more careful, especially in corners, as due to the
disruption in the onset flow, the following car has reduced aerodynamic performance. That’s improperly called “dirty air” in motorsport.
However, it is not just the pure loss in downforce that makes everything tricky under these conditions.
“One of the biggest things that will upset the driver is the change in the ‘feeling’ of the car. Aerodynamically, this means the aero balance. A loss in aero balance can occur
as disrupted onset flow will affect the front wing first and causes a significant loss in performance and efficiency.
Typically, the driver will drive to the aero balance set up to make them feel comfortable and have the confidence to turn into a corner. So, as the car starts to lose aero balance,
the driver has to back out” (Jack Chilvers, aerodynamicist at Williams F1 Racing)

Despite the common perception that the loss in aerodynamic performance is the largest detriment of ‘dirty air’, it is cooling that can often be a bigger issue
for the following car.
“When drivers are following another car, they are pushing hard and pushing components like the engine and brakes to the limits. If you start to get lower total pressure
going to the car, it starts to affect all of the cooling systems as well”. (Jack Chilvers)

This means that the radiators cannot work sufficiently, airflow going through the brake ducts are insufficient, etc. All of that causes overheating of all of the
calibrated systems and that is why the drivers have to generally back off.
For the nerds out there, my explanation is: it’s simply due to thermodynamic reasons. You can see the cars as massive radiators on wheels from that point of
view. You need to make the car lightweight, so you can’t add mass to redistribute the specific heat capacity 16 of the material the cooling fins & heatpipes are
made of (aluminum, steel or copper); moreover there aren’t new magic radiator designs 17 that give you more surface area to exchange heat. The conclusion
is that you can only improve and manage the airflow. And that’s why having less air pressure going through the system can be a problem.
While the term “slipstreaming” is often mentioned in many forms of racing from NASCAR, GT, even to two-wheelers, it is less common to hear “dirty air”
mentioned in other forms of racing than Formula One. This is why F1 have worked hard to develop a ruleset for aerodynamics that came into force in 2022
so that the cars are less affected by this phenomenon.
In the theory of aerodynamics, the phenomenon is actually called drafting, while the slipstream is actually the air stream diverted by the leading object.
Common driving errors

- Overrevving
This is possibly the most common way a driver can ruin his engine and put himself out of the race. Changing down too early before braking sufficiently is
quite common among inexperienced drivers. A driver must be a third of the way into the braking zone before changing down. It is quite tricky to get this
right in short braking bends but in longer braking areas you can use markers for gear change points.
A second common way to overrev is by exiting a corner and not changing up at the right time; quite easy to do if you’re busy controlling the car through a
difficult bend.
Fortunately, modern GT and Formula 1 cars are fitted with electronic rev limiters that prevent engine damage and bad gear changes. In AC this feature is
implemented for vehicles that actually have this kind of devices.
- Loss of control
The most common ways of losing control of your car in a race are:
1. Going into a corner too fast, giving strong oversteer.
2. Accelerating out of a corner too fast.

16
Informally, the specific heat capacity it is the amount of heat that must be added to one unit of mass of the substance in order to cause an increase of one unit in temperature.
17
The design of a radiator portrays the way the fins, pipes or canals are put together. Imagine the cooling coil on the backside of the refrigerator you have in your kitchen. That’s one of the many
radiator design types. Even the heatsink of the CPU inside your PC or laptop can be a radiator with copper heatpipes and a fan attached to it.

65
3. Under braking when there is too much bias on the rear wheels.
4. Mechanical failure. In AC mostly suspension/steering rack damage, but also complete engine failure.
5. Oil, sand, dirt or grease on the track. This is not present in vanilla AC. But tires get dirty if you go offroad and the CSP mod changes the grip until they get clean.

In all cases, as soon as the driver feels the loss of control, he must brake
hard while keeping his revs up to prevent stalling. If possible, he must keep
the car on the circuit, for once it touches the grass the spin will speed up
tremendously.

Spinning off before reaching the apex of a corner will result in the car moving
across the track to the outside of the bend. Generally, the inertia that it retains
will send it off in an arc similar to the early shape of the corner (Fig.).

Spinning off after the car has passed the apex of the corner will often give the
driver a better chance of staying on the track, for although the car will be
moving faster it is more likely to follow the exit profile of the curve.

Trying to slow down the car going onto the sand or the grass can be another
solution.

If all else fails, just lift your feet from the pedals and let the car stop its own
movement; obviously this may result in a crash.

Fig. -

- Traditional cornering techniques aren’t always the fastest

When cars and tracks are different, with varying levels of grip and surfaces, you need to be experimental and open minded when finding the fastest route.
The best way to do this is with video logging and easy to understand telemetry analysis software, synchronising the video and data. This will enable you to
easily pinpoint areas to improve.
The best technique is to try the traditional, recommended line to get some feedback and a reference time, and then see if you can better it by experimenting
with different techniques. You might just find other drivers beginning to copy you!

66
4.8 - Fuel

The estimated laps for the current fuel load in the car setup options can only be calculated after a full lap has been completed (only with enabled fuel
consumption). This estimation will gain accuracy with more laps driven in the same sitting.

4.8 - In-game telemetry

AC has a basic telemetry interface (Fig.). It’s very useful for sim-racers who want to improve their skills. Not really useful for mod creators who want a
debug tool, since the data displayed is more related to what the driver does than what the vehicle does.

Fig. – The basic telemetry GUI inside any AC track session. You can monitor brakes, speed, gas and shifting. It’s a very simple instrument to evaluate your driving skills. In this
example the interface is slightly modded, so the icons on the left of the screen may be different on vanilla.

No information will be displayed if you haven't driven the current combination. You'll see red lines representing your fastest lap. You'll see white lines after
you've driven at least one complete lap afterwards - they always represent your last full lap. A higher white line than the red one means you applied more
throttle, brake, you were in a higher gear or were faster (speed). You can compare values by hovering over them with the mouse thanks to the yellow
vertical cursor.

Remember, this plot is normalized to distance, not time or speed. More time could've been gained or lost in slower sections of the track, than on fast
straights.

67
5 – Multiplayer
How does multiplayer work in AC?

In the early stages of development, Kunos started by trying to run everything with UDP. It’s usually a big problem, as it is not 100% reliable.

If the server decides that it’s time to move to a new session (a qualify is over, etc.), it will send messages to reset the car, and similar instructions. If these
messages do not arrive, or they arrive without an order, you can end up with client bugs that are difficult to fix. So AC went to a double-channel system:

• TCP/IP for stuff that needs to be there (NaN)

• UDP for a reliable communication (positions + ping)

Hkò

5.1 - Dedicated server configuration

A simple solution to configure your dedicated server is given by the Assetto Corsa Server Manager utility (Fig.) which you can find under the path
%root%\assettocorsa\server.

Fig. – The ACSM utility, present in every installation of the simulator since version 1.2.

Pro tip: You can also modify the same settings the old school way with the entry_list.ini and server_cfg.ini scripts inside %root%\assettocorsa\server\cfg. If you use this second
method, start your server by executing acServer.exe.

Below you have examples of the aforementioned config files with explanations of their parameters.

-entry_list.ini
Specify here cars and players, if pickup mode is enabled. Leave list empty for booking mode. The former mode doesn't work, if this list is empty. The skin
name must match the folder name of that skin. GUID is the converted steam ID (see 4.10 Steam community ID) but is not required for Pickup mode to work.
[CAR_0]
DRIVERNAME=Driver 1
TEAM=a
MODEL=abarth500
SKIN=Cinnabar_red
GUID=765411978771115547
SPECTATOR_MODE=0

[CAR_1]
DRIVERNAME=Driver 2
TEAM=a
MODEL=bmw_m3_e30
SKIN=Jet_Black
GUID=FAKE_CLIENT_0
SPECTATOR_MODE=0

[CAR_2]
[…]

-server_cfg.ini
This is the actual server configuration script. The values do not have to be in a specific order.
[SERVER]
NAME=AC_Server ; Name of the server.

CARS=bmw_m3_e30;bmw_z4_gt3;lotus_evora_gtc
TRACK=magione;aosta_grand_sport_v2.0

68
% ▲ Specify available cars and tracks on the server. Their names must match the ones of the specific folder(s) in %root%\assetto corsa\content\cars (or
\tracks). Remember to distinguish them with the semicolon ( ; ), without spaces.

CONFIG_TRACK=
SUN_ANGLE=48 ; Specify the Time of Day via this value. Default value is -7.

% ▲ Some examples of SUN_ANGLE values:

08:00 = -80
09:00 = -64
10:00 = -48
11:00 = -32
12:00 = -16
13:00 = 0
14:00 = 16
15:00 = 32
16:00 = 48
17:00 = 64

PASSWORD=yourpassword ; Server user password key.

ADMIN_PASSWORD=mypassword ; Server admin password key.

UDP_PORT=9600
TCP_PORT=9600

▲ % Both UDP & TCP ports must be identical. Select your server ports and forward them in your router. The values are dependent on the individual server
configuration.

HTTP_PORT=8081
PICKUP_MODE_ENABLED=1 ; Default value: 0

% ▲ Select only if you want to use Pickup mode. Remember to fill out entry_list.ini afterwards.

LOOP_MODE=1 ; Important to enable to reduce server load. Default value: 1.

% ▲ The server will cycle through the specified sessions, if no cars are registered on it.

SLEEP_TIME=1 ; Default value: 0.

CLIENT_SEND_INTERVAL_HZ=18 ; How often the server will update the player cars’ position on the track. Default: 15. [Hz]

% ▲ Increase it for better multiplayer quality and better collision detection. Higher values cause higher server load.

SEND_BUFFER_SIZE=0
RECV_BUFFER_SIZE=0
RACE_OVER_TIME=180 ; Race end fade-out time. Default value: 20. Common value: 300. [s]

% ▲ How long the server waits to fade to black and reset all cars on track to their pit boxes after the winner finishes the race.

KICK_QUORUM=85
VOTING_QUORUM=80 ; What percentage of votes YES / NO will trigger the action in question. Default value: 75.
VOTE_DURATION=20 ; How much time the voting window lasts. [s]
BLACKLIST_MODE=1
FUEL_RATE=100 ; Default value: 100. Value in percent - adjust if needed.
DAMAGE_MULTIPLIER=100 ; Default value: 100. Value in percent - adjust if needed.
TYRE_WEAR_RATE=100 ; Default value: 100. Value in percent - adjust if needed.

ALLOWED_TYRES_OUT=2 ; Default value: 2 = normal penalty system enabled. 4 = penalties disabled.

% ▲ Values =1 and =3 have not been properly tested.

ABS_ALLOWED=1 ; Determines user freedom over the Anti-lock Braking System.

TC_ALLOWED=1 ; Determines user freedom over the Traction Control.

% ▲ For ABS and TC specifically: 0 = Always off; 1 = Factory settings, if the car features it, the user can enable/disable it, if it doesn't, it's
always off; 2 = User defined.

STABILITY_ALLOWED=0 ; Determines user freedom over the Stability Control.

AUTOCLUTCH_ALLOWED=0 ; Values: 0=no, 1=yes. Value determined by organizer.
TYRE_BLANKETS_ALLOWED=0 ; Common value: 0. Sometimes at Formula events: 1
FORCE_VIRTUAL_MIRROR=1
REGISTER_TO_LOBBY=1 ; Default value: 1. Must be enabled for either mode to work.
MAX_CLIENTS=18 ; Common value: same as max pit boxes on particular track. Default value: 25.

% ▲ Value has to maintain the number of available pit boxes for a particular track to eliminate any error messages during login.

UDP_PLUGIN_LOCAL_PORT=0
UDP_PLUGIN_ADDRESS=
AUTH_PLUGIN_ADDRESS=
LEGAL_TYRES=SV

[PRACTICE]
NAME=Practice
TIME=10
IS_OPEN=1

[QUALIFY]
NAME=Qualify
TIME=10
IS_OPEN=1

[RACE]
NAME=Race
LAPS=5
WAIT_TIME=60 ; (Buffer-) time before this session starts. [s]

% ▲ You may increase it for the race, in order for participants to load their race setup, adjust the fuel load and get ready for the race in general.

IS_OPEN=1

[DYNAMIC_TRACK]
SESSION_START=89 ; Default value: 100
RANDOMNESS=3 ; Default value: 0
SESSION_TRANSFER=80 ; Default value: 0
LAP_GAIN=50

% ▲ Values may vary between regions and events. Look up paragraph 4.5 Grip levels / Track surface for further information.

[WEATHER_0]
GRAPHICS=3_clear

69
BASE_TEMPERATURE_AMBIENT=18
BASE_TEMPERATURE_ROAD=6
VARIATION_AMBIENT=1
VARIATION_ROAD=1

[WEATHER_1]
GRAPHICS=7_heavy_clouds
BASE_TEMPERATURE_AMBIENT=15
BASE_TEMPERATURE_ROAD=-1
VARIATION_AMBIENT=1
VARIATION_ROAD=1

Server administrator commands (execute from AC console):

/help : Prints the list of the available commands
/admin : Become administrator for the server. For example, if the password is "kunos" the command is "/admin kunos"
/next_session : Moves to next session
/restart_session : Restart the session
/kick : Kick a user using the rules (blacklist etc) of the server. To kick a player named "The Player": /kick The Player
/client_list : Show the player list by CAR_ID: name
/kick_id : Kick a user using the rules (blacklist etc) of the server. To kick a player using the CAR_ID 2: /kick_id 2
/ban_id : Ban a user using the rules (blacklist etc) of the server. To kick a player using the CAR_ID 2: /ban_id 2
/ballast : Add ballast (Kg) on the CAR_ID. To add 100Kg to CAR_ID 2: /ballast 2 100

5.2 – LAN Multiplayer (wip)

Via Ethernet cable

Possible with Port forwarding

to create your own LAN-server, you must use the acServerManager.exe located here ...\steamapps\common\assettocorsa\server\acServerManager.exe

includes all settings, cars, tracks, number of players up to 32 total.

70
6.0 - Errors and Troubleshooting
This paragraph is dedicated to the troubleshooting of your AC installation. Keep in mind that if you modded your AC installation, especially with CSP, you
may encounter any kind of bug or error, and do not expect to be able to fix it! If you play with mods you do it at your own risk!

GENERAL SUGGESTIONS
If you encounter errors of any kind, you can try the following:
• Run a Steam cache integrity check for AC; be aware that an integrity check resets all modified files to their original state, and overwrites all sorts of general-purpose mods,
like weather, shader and sound mods for official vehicles!
• Launch the game and reconfigure all the options from scratch.
• Don't forget to check and eventually set the proper screen resolutions/refresh rates in the video options.
• Rename the Assetto Corsa folder located inside your user Documents, this will force AC to recreate the user settings files;
• If you didn't rename the folder above, then remove any python addon apps you've installed. To do this, delete the python.ini file in the Documents\Assetto Corsa\cfg path,
then delete the apps folder located in your %root%\assettocorsa install folder;
• If you are still facing issues, DON'T WRITE messages on any forums or social platforms reporting "I have the same issue!", because 99% of the time the same result doesn't
mean the problem is related to the same cause. Open your own thread, explaining your issue, describing the scenario the best you can, and attaching your logs located in
Documents\Assetto Corsa\logs. Many skilled users will help you as soon as possible.
• AC developers (Kunos) do not support AC anymore, so they won’t answer questions related to this software in the official forums. The support is active for Assetto Corsa
Competizione (ACC) only!
Usually, these steps fix the most common issues users are facing.
In some scenarios, unsupported or misconfigured third party software may be the cause of the problem. Try the following:
• Check that your controller is plugged in a USB 2.0 port (avoid USB 3.0 if possible);
• Update/reinstall Python software: https://www.python.org/ftp/python/3.4.3/python-3.4.3.msi
• Update/reinstall the graphics card drivers and DirectX software: https://www.microsoft.com/en-gb/download/details.aspx?id=35
• Reinstall VS Runtime (x86 & x64) with the latest: https://support.microsoft.com/en-gb/help/2977003/the-latest-supported-visual-c-downloads
• Update/reinstall Microsoft .NET 4.6: https://www.microsoft.com/en-us/download/details.aspx?id=48130
• Update/reinstall Microsoft .NET 4.5.2: http://www.microsoft.com/en-us/download/details.aspx?id=42642
• Update/reinstall Microsoft .NET 4.0: https://www.microsoft.com/en-US/Download/details.aspx?id=17718)
• If you can't reinstall .NET, please use the Microsoft's Repair Tool: http://www.microsoft.com/en-us/download/details.aspx?id=30135
• If you are on Win10 and you can't update/repair your .NET installation, open a cmd prompt with admin privileges and run the command: sfc /scannow. This will
search for damaged system files and attempt to repair them if possible.
• Close any video overlay software (VirtuMVP, Fraps, XFire, MSI Afterburner, Rivatuner and similar monitoring/video recording software);
• If you are a Nvidia GPU owner, disable Shadowplay and the Nvidia Capture Service in Task Manager. Use other programs to record your screen;
• Double check CPU and GPU temperatures;
• Check Windows user's privileges (set Steam and Assetto Corsa with admin rights);
• Temporarily shut down any antivirus or firewall (or be sure that you have exception rules for acs.exe and assettocorsa.exe executables);
• Last but not least, ask your best friend. Sometimes users can find the solution in just 30 seconds.

Many issues are discussed in section below as well.

- The server will shut down in loading screen - Make sure to type in the right password for the server.
- No text in loading screen, assettocorsa.exe will freeze – Try closing any other program open.
- Missing content, file errors - Run a 'check integrity of game cache' via steam context menu.
- kernelbase.dll error on Windows 10 – kernelBase.dll is a file stored in the system folder of the operating system. It is created automatically during the
installation of the OS and it’s used to launch .exe applications. When it is corrupt, you will get a “.dll missing or not found” error when you start the programs.
After trying without success the sfc /scannow command mentioned previously, you can follow the methods below to fix this problem.
Method 1: Register the .dll file
The file may have lost its associations with the registry keys. To rebuild them:
1. Tap on the Windows key on your keyboard and type Command prompt.
2. Right click and select Run as Administrator. This will give you the authorization to work on system files, so be careful of what you type in the prompt next.
3. Type: regsvr32 KERNELBASE.dll
4. Restart the computer and check if it works now.
Method 2: Copy the same file from another computer.
The file itself may be damaged. I would suggest you to copy kernelBase.dll from another computer running the same version and edition of Windows.
The location of the file differs in each system based on the architecture. If it is 64-bit, then it is located in C:\Windows\SysWOW64. If it is 32-bit, then it is
located in C:\Windows\System32.
Method 3: Create a new user account.
The reason might be due to user account corruption, so I would suggest you to create a local user or administrator account from the settings and check if the
issue persists.
Note: From the newly created account you will not see all your personal files under your default file location (i.e. the Documents folder). Your data will be
saved under C:\Users\Your_previous_user_name.

71
- UIAutomationCore.dll error - Check that this file exist: C:\Windows\System32\UIAutomationCore.dll. If not present, go to
C:\Windows\winsxs\amd64_microsoft-windows-uiautomationcore_31bf3856ad364e35_6.1.7600.16385_none_0c0d85465bcceb37
And from there copy/paste UIAutomationCore.dll to the C:\Windows\System32 directory.
If AC still doesn't start after copying the file, open a cmd prompt as admin, then type without the quotes "cd C:\Windows\System32" and press enter. Then
type exactly:
regsvr32 UIAutomationCore.dll

Do the same as above for C:\Windows\SysWOW64\UIAutomationCore.dll. If not present, go to: C:\Windows\winsxs\wow64_microsoft-windows-

uiautomationcore_31bf3856ad364e35_6.1.7600.16385_none_16622f98902dad32
And from there copy/paste the UIAutomationCore.dll to the C:\Windows\SysWOW64 directory. Again, only if AC still doesn't start after copying the files.
Open another cmd and run as admin then type without quotes "cd C:\Windows\SysWOW64" and press enter. Then type exactly as below:
regsvr32 UIAutomationCore.dll

- The game doesn't start at all when launched - Make sure the pre-requisite libraries have installed properly, you can find them in the AC install folder by
right-clicking on Assetto Corsa in Steam then Local Files > Browse Local Files.... Navigate to the _commonredist folder and run the setups for all the included
redistributables. Pay attention to any error messages you might get and make sure no antivirus or such software blocks their installation. These are normally
installed automatically on first run, but occasionally they will output errors which are not reported to you by Steam;
Use Steam's cache integrity check. Open your Steam games library, right click on Assetto Corsa and select Properties. Click Local files and then Verify
integrity of Game cache;
Check your installed Windows updates. If you have the KB2670838 update, please uninstall it and try if the game starts properly.
Also, some users have reported that they cannot start the sim if their main audio device is disabled. Obviously, enabling it solves the issue.
- Grey screen after introduction - Press F11. This will make the game's launcher exit full screen. In some configurations it has been reported that setting
AssettoCorsa.exe to run as administrator worked to by-pass this issue.
- The race session doesn't start when you press "start engine" - First thing to check is your video resolution in the video options. Then the windows firewall
dialog might be requesting access for acs.exe - accepting the rule exception addition can solve this. If the dialog doesn't show up, you might have to go
through the windows control panel options for the firewall and set it to allow acs.exe.
- AC runs smooth but every 3-5 seconds it freezes for half a second or less. It’s the same on high and low settings – May be a FPS problem. Make sure that
the refresh rate in your game and on your monitor are the same. Try also turning off the framerate limit and Post Processing filters. To understand if the
problem is the GPU, reduce the resolution to the lowest supported by your hardware and if you still get stuttering, you can completely rule out the video card.
That means it’s something to do with either your hard drive or the RAM. Otherwise, if you don’t, try updating or reinstalling the video drivers. You can always
try verifying the AC integrity via Steam.
- System crash while playing followed by an automatic reboot - You're likely getting a blue screen and have windows set to auto-reboot on such (you can
disable that to see the stop error by pressing Win + Break, go to Advanced > Startup and Recovery Settings and under System failure uncheck Automatically
restart).
Regardless if you disable auto-restart or not, to see which driver component is causing it, you can get Bluescreenview: http://www.nirsoft.net/utils/blue_screen_view.html
This small software will go through the minidumps Windows has recorded and it'll report the component at fault. Otherwise, you can use the built-in system
administrative tools if you know how to use them. You can find them in the dear old Control Panel.
- .NET 4.0 not installing and returns a 0xc8000222 error if invoked manually - You can find the installer in the AC install folder, navigating to the
_CommonRedist\DotNet\4.0 folder.
Before installing .NET Framework 4.0 by running dotNetFx40_Full_x86_x64.exe:
1. Press your Win key and type cmd, then right click on the result and select "run as administrator"
2. Once in the command prompt type in command "net stop WuAuServ" to disable windows update
3. Then press Win+R and type in "%windir%" at the pop-up window, it will take you to your windows installation folder
4. Find the folder SoftwareDistribution and rename it to SoftwareDistribution.old.
5. Then, go back your previous command prompt and run the command "net start WuAuServ" to restart windows update
6. Finally try again to install .NET Framework.
- User Interface too large - If you cannot scroll down to the options button to go to Options > General and then check Ignore Windows display-scaling settings
(you need to restart the launcher for it to take effect), you can edit your launcher.ini found in %UserDocuments%\Assetto Corsa\cfg and add IGNOREDPI=1
under the [WINDOW] section.
- Stuck in Steam VR Home scene. AC audio coming out from the headset when in game, only no video - First and foremost, double check to make sure the
Content Manager / AC video settings are for OpenVR/Oculus (it must not be Single Screen).
If the problem still persists, open the Steam VR settings from either the Steam VR Status Dock or while you are using Steam VR. In the bottom-left you should
see the Advanced Settings, make sure it is set to SHOW. Now go into the General tab, turn SteamVR Home and Pause VR when computer is locked to OFF.
Another thing to try if the error still occurs - in the regular Steam Settings > In-Game tab, uncheck the box labelled Use the Big Picture Overlay when using
a Steam Input enabled controller from the desktop.
Lastly if this still occurs I would suggest checking the AC settings in Steam Library and in the General tab, make sure that the Use Desktop Game Theatre
while SteamVR is active box is unchecked.

72
Almost forgot to mention, make sure you check with Task Manager (Ctrl + Alt + Del) after shutting the game down and confirm there are no instances of it
left running. Anytime you adjust settings in CM, you need to close and open the game for it to update effectively.
- 99% CPU Warning - Your CPU is at peak load. The exact percentage of your CPU’s load may not be accurate. The load indicators of the Windows Task
Manager are not necessarily correct - 100% CPU load is only accomplished by benchmark software like PRIME 95. The opponents’ AI is only calculated on
one dedicated CPU core, try reducing the race grid size or overclock your CPU (if you decide to). Also, Assetto Corsa scales with raw clockspeed very well.
Beware that overclocking your hardware components may void their warranty. Many mod tracks are not as optimized as Kunos' tracks and may require more
CPU performance. AMD CPUs seem to be more prone to this issue than Intel's ones. If you’re a mod maker, always keep in mind the optimization of your
cars or tracks.
With CSP you can hide the CPU Warning message and let Windows manage the multithreading, so that the load will be split between the cores evenly.
The problem may also be related to the FFB settings. For PC/Win users: since AC v1.12 there is a section in the controls.ini file located in your
Documents\Assetto Corsa\cfg path called [FF_SKIP_STEPS], that manages the force feedback update rate. The default value is 0 instead of 1 and it
overrides the old value located in the assetto_corsa.ini file (in the game install folder). This brings a more detailed force feedback and a better driving
feeling. If you experience CPU occupancy warnings during a driving session, please tick Half FFB Update Rate in the the UI Options > Controls > Advanced;
this will bring the value back to 1. Not all the steering wheels can manage the maximum update rate, so no worries.
In case you are using very old or cheap steering wheels like the Microsoft Sidewinder or Saitek R440, or other hand-made ones, you need to open the
controls.ini file, and set the value to 4, like this:
[FF_SKIP_STEPS]

VALUE=4

This should solve any CPU warning related to the force feedback refresh rate.
Please always double check this value if you load controls profiles created before v1.12 update! In case, please create a new controls profile with the proper
value.
- Discord app conflicts - Since July 2017, users report a conflict between Discord app and Assetto Corsa. If you have Discord installed, please fully close it
(double check it is not just in the system tray) and try if the sim works. If you use the CSP mod, this problem should be fixed.
- ASUS SONIC SUITE II conflicts - Some users report showstoppers when the Sonic Suite software is enabled. Please fully disable it in order to make
Assetto Corsa work again.
- MSI GAMING APP issues - Some users report heavy stuttering by keeping the MSI Gaming App enabled. Please kill it.
- AMD Gaming Evolved app - Some users report showstoppers with the AMD Gaming Evolved app enabled. Please close it.
- Problems with Windows 10 users that upgraded from a previous MS-OS (MicroSoft Operating System) - Sometimes just upgrading to Win10 doesn't
work with all programs or games, you need to make a clean install; this is possible in the System options > Updates > Recovery. Keep in mind that this can
delete your beloved files and folders, so always make a backup of them first!
It can also help to reinstall the C++ packages (both x86 and x64), Microsoft .NET Framework, DirectX APIs and libraries. You can find the installers in the
following path: %root%\assettocorsa\_CommonRedist. The root is the path where AC is installed.
- My wheel doesn't work as expected after Windows 10 updates - By default, Windows 10 has the "automatic drivers update" feature enabled. In some AC
updates, this created troubles with some wheels. To solve the issue, unplug your controller(s), uninstall the related drivers and software (e.g. Logitech
Gaming Software / Profiler, Fanatec Control Panel and so on), reboot, then install them again (downloading them from the official websites or using the
original CDs/DVDs). Plug in the controller(s) and you should be fine. Just to be sure, please assign controls in game from scratch. You can also disable the
auto update in the system options (only if the problem persists).
If you want to disable the aforementioned feature, please read here and do it at your own risk: https://www.intowindows.com/how-to-stop-windows-10-
from-automatically-updating-drivers/
- Controllers are not detected in game - Go in Steam client > Settings > Controller > General controller settings. Disable everything.
- How to use menus with mouse-steering enabled - Pressing CTRL+M toggles mouse steering functionality on and off so you can access the in-game UI.
- The car veers left/right even when the joystick is not being touched - Recalibrate your controller in the Windows device settings and see if you can adjust
or increase the deadzone. That should be able to fix the potential joystick drift you're experiencing. Otherwise, try with a different controller or your keyboard
to eliminate the possibility of stick drift. You might not notice an issue in other games, but different games use different dead zones (see paragraph); this is
the amount you have to push the stick to activate it. Racing games have a smaller deadline so any issue with the controller in that range of controller input
will show. A brand-new controller should solve the issue.
- Pressing a little the throttle pedal sends the engine to full revs – Calibrate the pedals. Check with the Pedals app that the input you give with your foot
corresponds to what the indicators show. You can also try moving the throttle slider axis in Content Manager up to 25%.
- No input from wheel and pedals – Try using your keyboard first. If it does work, delete the controls.ini file in your Documents\Assetto Corsa\cfg and re-
assign the controls from scratch in the AC controls settings (Fig.). Don’t worry, that file will be recreated. Then save the configuration in a preset (choose a
name). AC saves the last controller type selected, even when you don't connect it before opening the game.

73
Fig. – The Main and the Advanced wheel configuration in the vanilla Assetto Corsa launcher. To access this wizard go in the Options menu, then Controls > Advanced.

- Wheel shakes and oscillates left and right when driving - Usually this issue is related to a too high Force Feedback gain parameters. Assuming that your
Windows profiler settings are at default, you can try the following method:
1. Lower the Gain value; lower also the FFB enhanced effects, especially the Road parameter. You can try this combination for example: 50% FFB / 30% Curbs (Kerbs) /
40% Road / 5% Slip.
2. If you want to reduce rotational force, you will simply have to turn down Gain. To enhance the feel of the road, increase Road Effect. This effect amplifies the road feedback
that is already there. So, the best name for that is "Road Effect Amplification".
The explanation of this issue, that happens especially on straights, is that FFB wants to show the user that the track is bumpy, so you have peaks in both
directions that result in the shaking. In corners it’s not as bad because you have an acceleration perpendicular to the trajectory, directed to its center.
- Wheel off center in-game even though it’s centred in real life – Try recalibrating the wheel. This implies using the wheel’s software and drivers, not the AC
options. The Assetto Corsa configuration wizard is there to help out people who don't really know how many degrees lock-to-lock their wheel has and it's
highly dependent on user input (obviously, since controllers do not report degrees of rotation); there is no calibration being done, nothing of that sort:
calibration is left to the controller drivers. Think of it like a quickstart guide, a simple step-by-step approach to control configuration that helps you get the
most basic controls set up and ready. Obviously anyone with some sort of experience in setting up simulators will likely not need it at all.

74
6 – Easter eggs
Like every other game, Assetto Corsa has little details that people miss almost always; here are some of them.

Fig. – This is written on the fire extinguisher in the Mercedes-Benz AMG GT3, on the passenger side floor. Ever thought about falling into the void?

Fig. – You can find this one on the Porsche 911 GT1-98. But to understand it you need a lot of “knowdlage”. Be careful.

Fig. – Track: Monza 1966. This is the stele made in 1948 to commemorate Arturo Mercanti, the Italian aviator who decided to build the circuit when he was president of the Automobile
Club of Milano in 1922.

75
Fig. – ‘Gina, the name Sebastian Vettel gave to his Ferrari SF70H, abbreviation of “Regina”, which in Italian means “Queen”. Is there any easter egg in my manual?

Fig. – Another track easter egg, this time about the passion of Stefano Casillo for cats.

76
Fig. – Nope, I won’t tell you about this one, but it’s official; as you can see with modded AC looks 10 times better. If you want to get nuked you’ll have to find it. Hyped now?

77
7 – Curiosities
- Assetto Corsa was developed on MS Windows.
- The initial price of Assetto Corsa for Steam Early Access was 34.99 € and included the early access version, all its updates, plus the final version of the
game, without any extra charge. The price of the full game at launch (2013) was 44.99 €, without later DLCs.
- A small version of the game “Pong” had been made by Stefano Casillo, entirely playable inside AC as an app (Fig.). It’s not available anywhere.

Fig. – This was a little experiment done for an interview back in 2012 to show what AC could offer in terms of modifications (mods). The ball (the green square) is visible on the right.

- Lines of code:
Did you know that since version 1.6 Assetto Corsa has a parameter dedicated to its simulation value?
You can find the parameter that influences how much AC is a simulator in the assetto_corsa.ini file inside the assettocorsa\system\cfg folder:
[ASSETTO_CORSA]
SIMULATION_VALUE=0 ; Value that determines the accuracy of the simulation. Inputs are numbers 0-10.

% ▲ This parameter overrides the standard physics settings, fine tuning the simulation. It is advised to leave the value as is, since the feature is
experimental. A value of 10 guarantees the knowledge of the universe. Default is 0 for obvious reasons.

You feel like you need more simulation? I see only 2 possible explanations here:
1. You did not increase the SIMULATION_VALUE enough;
2. You're too good at this.
Be aware that this line of code can turn up the physics so much that you can get out of the car and have a smoke.
Obviously this is a joke. In 2016 there was a group of people that kept saying AC has no simulation value because of some issue that was solved years
before. It became a meme and this was Kunos firing back a few shots (and me too here heh). As a side note, the parameter has also been included in CM,
this time as a percentage on a slider. The authors are definitely taking it too far.
I wonder if the guys that were criticizing AC before set the variable to 1 and thought it was better. I wouldn't be surprised, because you actually have to set it
to 10…
Furthermore, in the acs.exe code there’s a little easter egg (Fig.). Was it meant to be found?

Fig. – The best error message is always the one you will never see. Apparently Lord Kunos (Stefano Casillo) did really have fun while coding AC. Don’t touch my puppies!

Another one: in the changelog.txt file that lists all the simulator’s updates (under the main install folder), you can find the following lines:
AC Early Access 0.2 - besame mucho (“kiss me a lot” in Spanish)
AC 1.1 - Suicidal server admins are now a protected species and not allowed to kick themselves anymore
AC 1.2.2 - Removed log messages for Python function "getTexture" because some python app dev thought: "Hey, what a nice function!
I will call it every frame instead of caching the result" resulting in >60mb logs and stuttering and 10 years less in the life
expectance of the AC support guys

78
8 - Photo album - a tribute to Kunos Simulazioni
A lot of work went into making AC a reality. I believe it’s fair to show and remember the people who pushed hard behind the scene. Many of these photos are from the early
years of Kunos, so things changed a lot, but I believe they show more the true passion and joy that is always there at the beginning of every project. Thanks everyone – A.M.

The Radiator Springs Racing team (RSR) meets part of the Kunos Simulazioni team back in 2012. From left to right: Maurizio Gilles, Mario Gilles, Andrea Lojelo, Luca Mosca, Mauro
Delega', Marco Massarutto, Stefano Casillo, Aristotelis Vasilakos and Fulvio "Gek" Genova holding the Assetto Corsa car plate.

Aristotelis Vasilakos, Jay Ekkel, Alex Hummler, Thomas Jackermeier, Alexander Loodin Ek, Georg Ortner and Marco Massarutto at the 2012 edition of the 24h of the Nürburgring.

79
Kunos Simulazioni (in this picture Marco Massarutto and Stefano Casillo) spent some hours at Evotek Engineering, an innovative company specialized in Automotive Design &
Research near Maranello. Evotek developed an innovative motion simulator, powered since 2011 by a prototyped version of Assetto Corsa. The Kunos team visited their partners, who
showed them some upgrades of their system and the new pedal set that will equip the cockpit.

Different timelines, different cars. And lots of wheels, it’s almost like a dispenser.

80
Fanatec CEO Thomas Jackermeier tries AC at the Kunos headquarters, with a Fanatec prototype wheel. Here you can also see what the track selection menu looked like in the beta
releases of AC (16th March 2012).

A little Pagani. Sometimes it’s nice to take a look at miniature models of the real thing. It evokes the inner child.

81
Kunos Simulazioni is a very disciplined company with proper hierarchy and great cooperation spirit. Here you can see the production manager and the physics modeling responsible
having a polite and civilized discussion...

The first journalist admitted to Kunos R&D, John Denton, having a go with the simulator for a review (16th March 2012). Guys, do not insist too much…

82
Fanatec CEO Thomas Jackermeier visited once again the Kunos Simulazioni headquarters and went for a drive on the Vallelunga track using the car of the Assetto Corsa Licensing
Project Manager, Marco Massarutto.

83
Gathering data from real Tatuus open wheeler racing cars. Testing with Giovanni Martinez and Raffaele Bocchini.

84
Another shot of the Tatuus in their natural habitat.

This is how the Imola track looked like in Assetto Corsa back in 2013. It’s quite different, right? That banner didn’t make it to the final release.

85
One of the most inspiring Sim-racing related photographs ever. Lord Kunos (Stefano Casillo) programming in a pit box, with the Pitlane in the background. That is dedication.

A stack of Thrustmaster gear ready to be tested on the Assetto Corsa development version. After Fanatec it is the second brand of hardware that supported AC in the fullest.

86
Kunos working on VR when they received their Oculus Rift development kit.

The AC sticker applied to a Tatuus PY 012 as a teaser.

87
Renders of the Pagani Zonda R and McLaren MP4-12C models during development.

Safety first. Development previews of the classic driver with helmet. The background on this presentation shot, shows us a laser scan of the historic Monza banking.

88
Working at the Nürburgring.

89
The KS development team shared a render showing the progress of the Nissan GT-R NISMO GT3 model soon after was announced a new license bringing the NISMO brand to AC.

Other preview shots showing renders of the Nissan.

One of the CAD models given to Kunos by the vehicle manufacturers, in this case, McLaren. Retrieved via Wayback Machine from the official Assetto Corsa website.
90
Preview screenshots showing a clay model render of the BMW M4. After Marco Massarutto had driven the real world car at the Vallelunga circuit, he decided to try and license the
model for use in AC.

Other work in progress teasers for the Ferrari 312T, the Porsche 937/78 Moby Dick and the Mazda RX-7 Spirit R.

91
The 1993 DTM Champion Nicola Larini testing the development version of Assetto Corsa in his legendary Alfa Romeo 155 DTM. I see a Larini immersed in memories with a slight
smile. Mission accomplished.

92
Racing and time attack driver Jeff Westphal visited the Kunos Development studios testing a virtual Ferrari 458 GT2 at the Nordschleife. It is stated that Jeff was very impressed by the
fidelity of the car on the laser scanned version of the Ring. Developer of the vehicle physics is Aristotelis Vasilakos, behind him.

Showcase of the Lamborghini Huracan GT3 model being developed. The clay render of the car shows that the outer body was already completed.

93
Professional racing driver Ken Dobson visited the Vallelunga racing circuit for a test of the Scuderia Cameron Glickenhaus car. Ken took the opportunity to have a go at Assetto Corsa
driving the Ferrari 458 GT2 and upcoming Corvette C7.r GTE on the laser scanned Nordschleife.

94
Marco Massarutto showing a development preview of the Ferrari LaFerrari.

Taking a break right on that corner of Spa may seem a bit dangerous, but don’t worry, everything will be very, very fast…

95
96
Unloading the Porsches. At this point you can recognize that garage.

97
The Assetto Corsa team at Brands Hatch to get as much reference material as possible.

I’m very tired of people who say that AC vehicles sound bad. This is one of the many sound recording sessions made by Kunos. The official website also states: “Thanks to the kind
cooperation of Akrapovič, during 2015 we have worked to improve our sound recording process involving the use of new techniques of recording and advanced technologies. All new
cars produced during 2015 took advantage of this improvement, and we also have plans to reprocess the cars that had been released earlier”.

98
The original shot for the game cover, with the Ferrari FXX K.

When Assetto Corsa launched into Early Access on Steam on the 8 November 2013.

99
Kunos at the Nürburgring-Nordschleife for the first ever laser scan of the track (2015).

The Assetto Corsa Development Team in 2016.

100
Assetto Corsa’s interface changed many times during development. On top is how the opening of the vanilla launcher looked like back in 2013. It seems like there was the idea to make
modding an integrant part of the game. On the bottom the opening in 2016.

101
102
THE SOFTWARE YOU WILL NEED

You will have to use a good amount of software through this journey: most of the following programs will let you do the same things, but each one can
make the difference, thanks to different features that you may ignore at the beginning.
What you will work with depends on how you “feel” the software and your experience with it.
Look at the list below for the programs used the most by AC modders. If I really had to choose here, I would try everything. This doesn’t mean you have to.
It shall be noted that any of the tools part of the AC SDK (Software Development Kit) won’t be mentioned here as they will be treated in detail later.
To begin with, you have to use a 3d modelling program; below are some (anything that does polygonal 3D modeling (so not CAD) can be used, as long as
it can create dummies and export correctly formatted .fbx files; for more info, see pag.):
• Blender (https://www.blender.org/download); a free and open-source 3D creation suite. It supports the entirety of the 3D pipeline: mesh modeling, sculpting in multi-resolution
or dynamic topology, 3D texture painting, rigging, scripting, animating, simulating, rendering, compositing and motion tracking, even video editing and game creation. I’d
say the learning curve is not too steep. It's just really, really, really long, although the basics are learned within a few hours. I believe it's worth the time investment. Also, I
suggest you to use Blender if you don’t have money to spend on software and you don’t want to deal with corporate licences; there’s also a huge community that can help
you if you need tutorials, guides, explanations or suggestions. It’s even available on Steam. Furthermore, some of the best AC modders work with it, as you can do more
with the built-in tools.
• Autodesk 3D Studio Max (https://www.autodesk.com/education/edu-software/overview); often called 3DsMax throughout this manual, this software is mostly used to create
and edit game models. Strange enough, it’s quite buggy. Kunos developers and AAA studios usually work with 3DsMax and other similar products of the same kind, so
now you know what professionals use. Such a program can be expensive to buy, but you can get a free licence available for students or educators on its website. It used
to be a 3 years renewal, but now you need to renew every year and supply details to prove that you’re a student/educator. Yeah, I’m not sending a corporate website my
student ID card, hell no. Just get Blender.
• Autodesk Maya (https://www.autodesk.com/products/maya/overview); being mainly a 3D animation and visual effects software, maybe you should avoid it.
• Autodesk Softimage (https://www.autodesk.com/products/softimage/overview); just avoid it. We know for a fact that the developers at Kunos did use the 2013/14 version of
this software in the old days, but it’s outdated and has been replaced by 3DsMax and Maya by the same company (Autodesk), with a last release in 2015. In the official
car pipeline 2.0 by KS (info at p.) there are still instructions dedicated to it: you can ignore them (they have been kept in this manual, but are of no use).
For textures, you can use:
• Adobe Photoshop (https://www.adobe.com/products/photoshop.html); this is probably the best and most widely known software to edit raster images; it is a paid program, but
you should be able to save a few bucks with a student license. In order to export textures from it with the DDS format that we need, you’ll need to install the free nVidia
texture plugin which you can find in the attachments of this manual if you don’t want to register to the nVidia Developer program; more details at pag..
• Gimp (https://www.gimp.org); free and open-source. DDS editing is built in since release 2.10.10 so no plug-in is needed, unlike Photoshop. Sadly its DDS filter is pretty
bad by default in terms of dithering and colour-accuracy.
• Photopea (https://www.photopea.com); want to bring modding around? This is a nice online texture editor. A lot of people every now and then complain about not having
access to Photoshop, cs2 is slow as hell and Gimp is just, well, ugh. I’ve been searching around for free alternatives since I’ve been at home 150 miles away from my
computer with a valid Adobe account for a few weeks. Has support for all the psd, png, dds etc. files that you will encounter in AC. It’s free and a decent alternative with a
recognizable GUI. The DDS will default to DXT5 without mipmapping which is nice as well.
• Inkscape (https://inkscape.org); a very useful software if you need to work with vector graphics, which are different from raster graphics (those can be edited with Photoshop
and similar instead). This will prove its worth when it comes to recreating at high resolution very detailed logos on car liveries from real photos. The paid professional
alternatives are Adobe Illustrator (https://www.adobe.com/products/illustrator/free-trial-download.html) or CorelDRAW (https://www.coreldraw.com/en).
• Adobe Substance 3D Painter (https://www.adobe.com/products/substance3d-painter.html); if you need to create textures from scratch, this is the tool for you. It’s widely used
in game and movie production as well as in product design, fashion, and architecture. It’s a go-to 3D texturing app for creative professionals. Has got a huge asset library
with thousands of 3D models, materials, and lights. Sadly, it can't export .DDS natively, so you’ll have to export to .png and import back into Photoshop. Its AO (Ambient
Occlusion) is significantly better than the one you find in the AC Content Manager showrooms.
• FontForge (https://fontforge.org/en-US); what do you do if you can’t find online the right font for your vehicle’s cockpit display text/numbers? You create a new one! As a
bonus, it’s an open-source software.
• Paint.NET (https://github.com/paintdotnet/release/releases); since apparently Microsoft Windows doesn’t like to open or preview .dds files, we’ll use it for that purpose 18. It will
also allow us a quick editing. It’s a freeware software. When making skins for cars however it’s better if you use the options above, but it’s very handy for quick fixes.
• MS Paint (MS Windows accessories); if you can, use it on Win 3.1, where you can actually improve the graphics. I hope you aren’t this desperate, after all I suggested many
other free programs; inspires nostalgia, I get it, but there are many improved clones out there, for example PicPick (https://picpick.app/en), which while mimicking the MS
Office style has more functions, contrast correction, brightness adjustment and color balance to name a few.
• Adobe provides CS2 for free now (provided you follow their terms and conditions, etc) and it is just as good as any other program. If you chose that one remember to
take note of the Serial number that they provide to you.
You’ll need also a text editor to work with the various configs all over AC’s data folders; you can choose between:
• Notepad (MS Windows accessories); there is nothing more spartan; yes, it is reliable, but that doesn’t make things easier.
• Notepad++ (https://notepad-plus-plus.org); much better, adds colours, formatting, file management along with tabs, encodings, macros, and much more; one of my favourites.
• TextPad (https://www.textpad.com/home); very similar to Notepad++, slightly better for programming.
• WordPad (MS Win app); present in every Windows installation since Win 95, it’s like MS Word, but as skimpy as possible. Notepad++ is way better.
• Visual Studio Code Editor (https://code.visualstudio.com); used mostly by software developers, it’s a professional tool and can help by finding errors (in code syntax) for
you; it’s more advanced than a text editor, and it isn’t a word processing utility at all.
• AutoEditor (https://github.com/leBluem/AutoEditor); made specifically for AC modding, may lack a lot of features you need/want. Not for newbies.
• WinMerge (https://winmerge.org); if you want to compare different configs it’s very simple. It may be more useful while swapping physics between cars. Be aware that
Notepad++ can do it too.

18
If you want to enable the preview of .dds textures in the File Explorer windows (MS-Win), you have to right-click on any .dds file, select Open with > Choose another app > in the message box
that will open, titled How do you want to open this file?, look at Other Options > select Paint.net and activate the checkbox Always use this app to open .dds files. Then click on OK.

103
For our data/reference material collection, you will have to put some effort in your research with:
• Sheets of paper and a pencil? Yeah, sometimes you’ll want to write down something quickly, the old-school way.
• A standard Internet browser. You can choose any you like, but I recommend Mozilla Firefox because it’s open-source. I like that philosophy.
• Tor Browser (https://www.torproject.org/download); when you can’t find something on Google what do you do? You stop? No, you search on the deep web darling. Use the
DuckDuckGo search engine in combination with Tor. You’re scared? I am not. Get a good VPN for your internet connection.
• qBittorrent (https://www.qbittorrent.org); This software is one of the best (others are μTorrent and BitTorrent) for downloading torrent files (if you ever need to). Using a
torrent client and downloading torrents in itself isn’t illegal, as you can be downloading things that aren’t protected by copyright. I do not encourage downloading pirated
content, but you may search for ebooks, manuals and documents of all kinds. Just keep to yourself what you find, and be aware that there are differences between
countries: in some downloading copyrighted content for personal use is permitted, while in others isn’t, or sometimes the copyright law may not be enforced at all. You
do it at your own risk, while I’m only licenced to die, like us all.
• PDF and Ebook readers. During your research, you will often find yourself in need to open digital manuals and books of any kind, so use Adobe Reader or Foxit Reader
for PDFs, and Calibre for Ebooks (.epub). However you may not be able to read titles protected with DRM.
• MS Word (MS Office Suite); the oldtimer never dies. If you have to copy some nice text from online resources and still read it nicely you can’t use a text editor, that’s too
spartan; you need a word processing software. LibreOffice Writer or Google Docs are a couple of free alternatives, but there’s more for sure.
• A multi-format media player. You downloaded a nice video of your car/track to obtain maximum quality frames for reference instead of screenshots, but Windows Media
Player has problems with codecs. What do you do? You get VLC media player, which is freeware, easily opens container formats like mkv and a huge variety of audio files.
• A screen capture software. If a web video consists of a stream that cannot be downloaded with hyperlinks (it can happen), you can record your screen with lossless
quality thanks to OBS (Open Broadcaster Software, https://obsproject.com). This is probably the most popular app used to record and stream gameplays online.
For calculations and graphs, you’ll need some worksheet editors and data analysis software:
• MS Excel (MS Office Suite); we sold our soul to capitalism, but there are always open-source alternatives, like LibreOffice Calc (which honestly I don’t like) or Google Sheets
(it seems a bit too simple for what we’ll have to do).
• WebPlotDigitizer (https://automeris.io/WebPlotDigitizer); with this program you can analyse images of graphs and obtain raw data almost automatically.
• Geogebra (https://www.geogebra.org/download); you can visualize in a Cartesian plan many mathematical functions and expressions with this software. You will need it, trust
me. I suggest you to use the Classic version.
• MATLAB (https://www.mathworks.com/products/matlab.html); a programming and data analysis software (which comes with its own language), widely employed in universities
and by engineers (even race engineers!) to work on simulation outputs. You can create programs, graphs, elaborate functions, solve problems, etc. It is designed to manage
matrices and vectors very easily (hence the name, which literally means Matrix Laboratory). Sadly it’s a payware, but free alternatives that are quite compatible do exist (e.g.
GNU Octave, which can be found here: https://octave.org). Along with MATLAB comes Simulink, a very powerful tool which you can use to create simulations very easily with
a circuit system; it can also be linked to other software, like CarSim, TruckSim and BikeSim.
• Lotus SHARK (https://www.lotusengineering.com/engineering-software); suspension design tool by Lotus. Very useful to make suspension physics. Sadly, it doesn’t have all
the existing suspension types, and you will need a licence, it’s not free.
• Lotus Engine Simulation (https://www.lotusengineering.com/engineering-software); another simulation tool by Lotus. This time it’s a freeware. The interface is not the best,
but the program seems quite powerful overall.
• MoTeC i2 PRO (https://www.motec.com.au/software/latestreleases); useful telemetry tool to check what’s up with your vehicle. You’ll have to install the AC Telemetry client app
(ACTI). More about it later.
• ParaView (https://www.paraview.org); an open-source tool to visualize and perform analysis on data samples. It gives an immediate graphic response.
• Working Model 2D (https://www.design-simulation.com/wm2d/index.php); a paid professional-grade simulation tool for many kinds of mechanisms. Used in universities as an
aid to teach applied mechanics (I can confirm from my experience), it won’t have endearing graphics and a modern interface, however it’s very powerful if given to the right
hands. Surely better than Algodoo or Phun, those are much simpler programs (they’re basically games, but a ton of fun). I just don’t believe it is the “best-selling motion
simulation product in the world” as they say on their website.
• OpenFOAM (https://www.openfoam.com); a free, open source CFD software to simulate aerodynamics on your car models.

And for the sound? To provide a custom sound to your creations, you will need to install:
• Fmod Studio 1.08.12 (https://fmod.com); it’s the AC audio engine. This specific release, because AC supports it. Don’t use an older\newer version, it will cause bugs.
• Audacity (https://www.audacityteam.org); Probably the simplest yet most useful audio editor to modify your sound samples, it has also a ton of third-party plugins available.
There are also similar audio editing programs, like Goldwave (the interface maybe is a bit confusing at first) or Wavosaur (for people that love simple, old-school GUIs).
• Adobe Audition (http://www.adobe.com/products/audition.html); very similar to Audacity in many aspects, after all you’re always editing waves. One of the professional solutions.
• ETG (Expression Tone Generator) (http://voicesync.org); Really useful to create formula-generated sounds. You can export wave files. It can be fun to experiment with
and may be useful when making noise and pure tones. Downloadable for free at https://download.cnet.com/Expression-Tone-Generator/3000-2170_4-10100942.html.
• Fmod Bank Tools (https://forum.bigant.com/thread-5237.html); This tool lets you extract the audio samples from a pre-existing Fmod soundbank in the wave format (.wav);
the export encoding should be PCM, Sample Rate 48khz, Bit Depth 16 Bits.
You may want to quickly create or edit mods sometimes, so here you have some utilities/programs that can come in handy:
• Content Manager (https://acstuff.ru/app); the best alternative launcher for AC with cool features to manage mods and edit assets, this will speed up the workflow a lot, as
you won’t have to launch the entire game every time, it will just launch the race session quickly and easily.
• 3DSimEd (http://sim-garage.co.uk/3dsimed3-download); this tool can be useful only if you know what you’re doing; if not, avoid it. An issue for example is that it disables
objects casting shadows arbitrarily. 3dSimEd is not meant to edit AC cars, it's for conversions between games. It should be avoided by beginners (experienced people
already tend to avoid it), but you can use it to reverse-engineer mods if you want to learn, for example exporting kn5 models to fbx (which is already doable with CM or
QuickBMS). This program is worth mentioning here for this very reason.
• QuickBMS (https://aluigi.altervista.org/quickbms.htm); a little tool you can use to unpack AC data.acd files and models. More about it later on.
• Ninja Ripper (https://www.ninjaripper.com); an experimental utility for extracting geometry from 3D games using DirectX 11 and exploring it in a 3D editor.
• Swatchbin Texture Converter (https://tdohmn.webnode.page/swatchbin-texture-converter); a tool used to convert tex maps from Forza games to other formats, including
DDS10, PNG and BMP.
• Race Track Builder (RTB) (http://www.racetrackbuilder.com); not recommended; this is a paid software adopted by some beginners to create circuits: it will let you get decent
results quickly, but will never go beyond that. It’s a sandbox type of editor. It's not optimized for AC (nor race circuits in particular; its strength is point to point rally), so if
you want good hardware performance and maximum creative freedom you will have to do a lot of work with external editors. Otherwise you'd be stuck with generic scenery
and other severe limitations. If you just want something you can drive on then RTB can make that happen, but if you want your track to look like a real place, or have
accurate geographical elevation, you need to use a 3D modeling software. A similar utility you may see mentioned or used by newbie modders is Bob's Track Builder (BTB,

104
 http://www.bobstrackbuilder.net). The usage of these programs is detrimental to the development of your skills with 3D polygonal modeling and will not be discussed in this
manual. Some of the issues however will be briefly covered.
When you want to download/upload mods and for general purpose, you need a software to open and eventually compress files/folders in archives:
• 7-Zip (https://www.7-zip.org/index.html); free, without advertisements and simple, yet very functional. A must-have.
• WinZip (https://www.winzip.com/en/download/winzip); how much time has passed since I used it for the last time? Probably decades, since the early years of Windows XP.
• WinRar (https://www.win-rar.com/start.html?&L=0); good, but payware: after the trial period you will be bombarded with annoying messages.

The following extras are premium and enterprise-grade tools for professionals that I can recommend if you have a lot of time and really want to go in-depth
with physics simulations for your vehicles; they are not required for modding, but if you’re interested in the engineering field and you want to know what
kind of software we use, you can try these 19 (they are expensive, but often there are student licences or free demos):
• SOLIDWORKS; from the French software house Dassault Systèmes, it’s very popular in small, mid-sized companies and universities, due to its relatively low price in the
professional CAD application market. You can use it to model components of your cars, to evaluate their physical properties (for example mass and inertia). From a pure
modeling perspective, it is much easier to use compared to programs like Rhinoceros, especially with blend surfaces and fillets. The simulation side is relevant and very
powerful if given to the right hands. You can design mainly parts and assemblies. I’d say it’s a generalist program.
• CATIA; from the same authors of SOLIDWORKS, it is one of three major high end industrial CAD software, a powerhouse: fully 3D parametric with an enormous feature
palette which makes it somehow not difficult to get used to in the early stages. This is an absolute unit. You will need months of intensive training or practice to fully master
all of it. It has more than 60 environments under 10 different classifications. But people working in CAD areas don’t necessarily have to study all the environments. It
depends on the type of job.
Given the high price of this program, which is really a suite of programs, don’t expect to be able to find it online for free easily. After all, they make airplanes with this stuff.
In fact, that’s exactly the reason why CATIA was created back in 1977. You know it’s serious when you see big names like Boeing as client and IBM as vendor. Goodyear
uses CATIA to design tires for the automotive and aerospace industries, and many vehicle manufacturers adopted it at various production levels.
• ANSYS;
• MSC ADAMS (Adams-car package);
• Comsol Multiphysics
• Rhinoceros;
• Gmsh;

Despite popular beliefs, AutoCAD (by Autodesk) is never really used when engineering products. Its workflow is mostly 2D, with very little 3D features, and
no analysis functions. Autodesk Inventor is the actual program for the job, but its feature set is smaller that a fully-fledged high-end 3D CAD system.

19
As a mechanical engineering undergraduate, I can confirm that they are all available on the machines at my university. As a side note, the MATLAB software from Mathworks is present too.

105
 PART 2:

CAR MODDING

106
INTRODUCTION
If you’re just wondering, as someone who doesn't know anything about AC modding, “Where should I get started?”, “How hard would it be for me?”, then
you came to the right place.

First, you need to have a level of insanity sufficient to commit hundreds, if not thousands of hours to creating toy cars and tracks for a video game.
This point is probably the most important. It is not a hyperbole. If you're coming here with no knowledge of polygonal 3D modeling, image editing, general
video game asset creation processes or the moderate level inner workings of modding for AC, you will literally spend thousands of hours to finish your
project, at least if you want to produce something good and satisfying. Nevertheless, having some notions of computer science speeds up the process a lot.

It’s easy to begin looking into the process of making a car, getting it in-game, and feeling completely overwhelmed by the complexity.

Still up for it? Well, maybe in this manual I will be able to help you become conscious of the various steps, making things easier and more efficient this way.

There are already tutorials on car modding for Assetto Corsa out there. However, I feel they don't treat the subject as a whole. Example - the
car_pipeline_#.pdf 20 included in the Assetto Corsa installation (usually under C:\Program Files\Steam\steamapps\common\assettocorsa\sdk\dev). It's long
and complex, and has a lot of useful information. But it concentrates too much on the graphical side and not enough on the rest. And that makes it not so
straight forward to succeed with your first car mod. I personally like to start simple and once that is clear, continue to build on it. If you're anything like me
then please, keep reading.

What you see, does NOT matter.

Well, it matters if you want to make a top mod and boost immersion, of course. And that should be our ultimate goal. But from the AC physics engine's
point of view, you could drive a cube. Or you could simply drive on thin air. Under the hood, a complete working car looks like in Fig 0.1.

Fig. 0.1 - A bunch of dummies with specific orientation and names. You probably won’t need to use them all, it depends on the car. The selected cube is for the front left wheel.

...While what you actually see, could be this. Just the pilot hovering. But still, a working "car", see Fig. 0.2.

Fig. 0.2 - Technically a fully functional Subaru Impreza huh?

20
The hashtag is the release number; the first one by Kunos was 1.03, while the latest official version was 2.0, came with the AC update 1.14.3 and is called AC_Pipeline_PUB_Rev2.0. This
document will be an unofficial 3.0 manual.

107
The point is, do not be distracted by the visual mesh. All the work is done by the dummies, also known as NULLs, helpers, empties, nodes, etc. (Fig. 0.3),
and their naming, along with their hierarchy.

Fig. 0.3 – Some examples of dummies in Blender (3D editor); the first one will be the most useful for our job, as we need to know the orientation of the axes.

For those familiar with 3d animation, AC is working in the same way: dummies act like an interface between what the user wants to see and what the graphic
engine understands. Create them, name them correctly, place them at key joint points and have fun with the result by attaching the visual mesh(es). As long
as they're part of the scene and have the proper name and hierarchy it will work.
Technically in some cases you can work without dummies, but we want to make it simple (and hopefully you too), so we’ll use them (and you will too).
Our goal is to create a fully working vehicle. Just the pilot flying around would be a little boring. So, we are going to take some steps further. As you can
see, the limit is your fantasy when you’re making a mod for Assetto Corsa (Fig. 0.4).

Fig. 0.4 – Various examples of exotic vehicles brought to AC. It flies!

Over the years I’ve seen a lot of people go down in flames after cheerfully saying they were going to do this or that regarding game content creation. Many
mod projects got deep into development then just…stopped. You can't judge others for it as long as you did not really try it yourself.
As much as modders seem to be working full time on the mods, it is usually not like that. It can take weeks to find free time or motivation to continue.
A general issue seems to be the transition from whatever 3D modeling software used to the game, so many stumble on scaling or geometry normals issues
and positioning (all forums are full of threads like that). I'm sure the reasons are often many and complex.
But I don’t want to scare you. Don't worry about all the stages which seem very difficult now, just take it step by step. You don't need to know all the skills
straight away, just dabble in what interests you most, and the rest will come with time.
As soon as you drive for the first time a mod you made by yourself, you will be hooked (or at least I was). AC is highly addictive. I can confirm that’s true.

108
TABLE OF CONTENTS
These are roughly the steps to make a car mod. You can go to each respective chapter of PART 2 – CAR MODDING for its discussion. Page numbers

1. Organization of the job; prepare and populate the folder structures. p.

1.1 – Project Development (DEV) folder p.23
1.2 – Final (FIN) folder p.
1.3 – Main template files p.

2. Modeling. p.
2.1 – 3D Modeling p.
2.1.1 – CAD Systems p.
2.1.2 – Polygon modeling p.
2.2 – The game graphics workflow p.
2.2.1 – Polygons vs Triangles p.
2.2.2 – Meshes and Shells p.
2.2.3 – Mesh Topology p.
2.2.4 – Normals p.
2.3 – Modeling vehicles: rules & techniques p.
2.3.1 – The workflows p.
2.3.2 – Reference material p.
2.3.3 – The components to model p.
2.3.4 – Faithfulness (it is a better word indeed, fix the title) p.
2.3.5 – 3D coordinate system p.
2.3.6 – Modeling budgets p.
2.4 – Vehicle meshes p.
2.4.1 – Rules p.
2.4.2 – Standard parts p.
2.5 – Modeling tips/suggestions p.
2.5.1 –
2.5.2 –
2.5.3 –
2.5.4 –
2.5.5 – Cockpit parts
2.5.6 – Baking
2.6 –
2.7 – Skinned meshes
2.7.1 – Rules
2.8 – NULLs and scene structure p.
2.8.1 – Rules p.
2.8.2 – Assetto Corsa standard NULLs p.
2.8.3 – Hierarchy p.

3. Animations and moving parts. p.

3.1 – Animations p.
3.2 – Suspensions p.

4. Model Optimization. p.
4.1 – Understanding GPU performance p.
4.2 – LODs and triangle/object budget p.
4.2.1 – Triangle count p.
4.2.2 – Object count p.
4.3 - Vehicle interiors p.
4.4 – About Simplygon p.

5. Textures and Materials.

6. Vehicle physics collider. p.

6.1 – Rules p.
6.1.1 – FAQ p.
6.2 – Manual (by hand) creation p.
6.3 – Additional creation methods (with Blender) p.
6.3.1 – Shrinkwrap p.
6.3.2 – Convex Hull p.

7. Driver model.
7.1 – Official SDK template p.
7.1.1 – Animations p.
109
 7.1.2 – Export p.
7.1.3 – Integration with Blender 3D editor p.
7.2 – Driver rigs p.
7.2.1 – 3DsMax rig p.
7.2.2 – Blender rig p.
7.3 – Scripts p.
7.4 – FAQ p.

8. Conversions: the good, the ugly and the evil: p.

8.1 – Model rips p.
8.2 – Premise to conversions p.
8.3 – Conversion process p.
8.3.1 – Example with Forza game series titles p.
8.4 – Corrections on the models p.

9. Export to FBX. p.
9.1 – General settings p.
9.1.1 – Autodesk 3DsMax settings p.
9.1.2 – Autodesk Softimage XSI 2013 settings p.
9.1.3 – Blender settings p.

10. The SDK editor. p.

10.1 – The KN5 file format p.
10.2 – What is ksEditor p.
10.2.1 – Location p.
10.2.2 – Setting up the interface p.
10.2.3 – Import FBX models p.
10.2.4 – p.
10.2.5 – The 3D viewport p.
10.2.6 – Working with objects p.
10.2.7 – Managing materials and textures p.
10.2.8 – Keyboard shortcuts p.
10.2.9 – Managing projects p.
10.2.10 – FAQ p.
10.2.11 – Curiosities p.
10.3 – The Assetto Corsa graphics engine p.
10.4 – Define the shaders p.
10.4.1 – What are shaders p.
10.4.3 – Parameters: texture slots p.
10.4.4 – Parameters: material properties p.
10.4.2 – Vanilla shader types (fix paragraph order) p.
10.4.5 – Vanilla shaders descriptions p.
10.4.6 – CSP shaders descriptions (separate paragraph for the list) p.
10.4.7 – Criteria to assign specific shaders to different real-world materials p.
10.5 – Export to KN5 (include collider reference) p.
10.5.1 – Fixing errors in KN5 models after the export p.

11. Vehicle data: Configuration files and physics p.

11.1 – Physics prerequisites p.
11.1.1 – Models p.
11.1.2 – Reference systems, coordinates, vectors p.
11.1.3 – Vehicle definition p.
11.1.4 – Vehicle basic scheme p.
11.1.5 –
11.2 - The Assetto Corsa physics engine: characteristics and features. p.
11.2.1 – The solver p.
11.2.2 – The formulas p.
11.2.3 – Physics rate p.
11.2.4 – Resource utilization p.
11.2.5 – Low-speed physics p.
11.2.6 – Engine stall & clutch p.
11.2.7 – FAQ (mmmh maybe a Paragraph?) p.
11.3 – How to create data for your vehicle mod: import, entry, organization. p.
11.3.1 – Where and how to look for data p.
11.3.2 – Import and organization process p.
11.3.3 – How to begin p.
11.3.4 – Unit system in Assetto Corsa p.
11.4 - Data files: concepts, analysis and examples. p.

110
 11.4.1 – List of configuration files p.
11.4.2 – Other files p.
11.4.3 – Explanation of each script p.

12. Adjustments during/after a race session. p.

12.1 – The AC debug console. p.
12.2 – AC debug logs p.
12.3 – Apps: all the interfaces. p.
12.3.1 – Basic apps and HUD elements p.
12.3.2 – Developer apps p.
12.3.3 – FAQ p.
12.4 – Telemetry p.
12.4.1 – What is telemetry p.
12.4.2 – How does telemetry work p.
12.4.3 – Real life vs. simulated telemetry p.
12.4.4 – In-game telemetry p.
12.4.5 – The AC telemetry interface (ACTI) p.
12.4.6 – Analysis of telemetry data p.

13. Sound. p.
13.1 – Lectures on applied acoustics. p.
13.1.1 – Emission, propagation and reception of sound p.
13.1.2 –
13.1.3 – Waves p.
13.1.4 – Other common wave types p.
13.1.5 – Periodic and aperiodic signals p.
13.1.6 – Processing signals: the Fourier transform p.
13.1.7 – Frequency response and linearity p.
13.1.8 – Root mean square measurements p.
13.1.9 – The deciBel (dB) p.
13.1.10 – Audio level metering p.
13.1.11 – Types of reproduction (move audio cabling and ground loops to SYSTEMS) p.
13.1.12 – Directionality in hearing p.
13.1.13 – The stereophonic illusion p.
13.1.14 – Hearing in reverberant conditions p.
13.1.15 – Hearing loss p.
13.2 – The audio equipment p.
13.2.1 – Sound quality p.
13.2.2 – Sound systems p.
13.2.3 – Portable equipment p.
13.2.4 – Fixed Hi-Fi consumer equipment p.
13.2.5 – High end Hi-Fi p.
13.2.6 – Professional audio: Studio Monitors p.
13.2.7 – Headphones p.
13.2.8 – Amplifiers p.
13.3 - The principles of vehicle sound synthesis. p.
13.3.1 – Surround sound and Assetto Corsa p.
13.3.2 – Means of vehicle sound simulation p.
13.3.3 – Engine sounds p.
13.3.4 – Passing vehicles noise p.
13.3.5 – Wind sound p.
13.3.6 -
13.6 – Recording samples. p.
13.6.1 – Audio recording interfaces and connectors p.
13.6.2 –
13.6.3 – Recording engine sound p.
13.6.4 – External sounds p.
13.7 – Extracting audio samples from a multimedia source p.
13.8 – Create a custom vehicle sound with samples p.
13.8.1 – Starting with FMOD p.
13.8.2 – Events and parameters p.
13.8.3 – The Assetto Corsa FMOD project p.
13.8.4 – Building the sound bank p.
13.8.5 – Editing the GUIDs p.
13.8.6 – The mixer p.
13.8.7 -
13.9 – Using sound from a vehicle already existing in Assetto Corsa. p.
13.9.1 – Vanilla method p.

111
 13.9.2 – Using Content Manager p.
13.10 – How to install sound mods for vehicles p.
13.11 – How to edit sound banks from the community p.

14. Releasing a mod to the public: think about it a little first. p.

14.1 – Packing the mod files p.
14.2 – The boundaries of a mod creator p.
14.2.1 – Copyright, licences, model ripping and conversions between games p.
14.2.2 – Discrimination of content creators p.
14.2.3 – About Assetto Corsa’s vanilla encryption p.
14.2.4 – The actual situation with CSP: the unofficial encryption p.

15. Car mods from the community. p.

15.1 - How to install car mods p.
15.2 - How to update car mods p.
15.3 – How to modify cars p.
15.3.1 – Editing models p.
15.3.2 – Editing data p.
15.3.3 – Editing the driver p.
15.4 – How to take nice screenshots of cars p.

112
CHAPTER 1 - FOLDER STRUCTURES
This is how everything begins. Your first step before doing anything else. A good, clean folder structure will always make things easier. But this is also
required, so that Assetto Corsa understands everything.

For every project you’ll have to create two separate folders: the first one is a development (from now on we will call it DEV) folder, stored wherever you want
on your PC’s hard drive, with all the main reference data (photos, documents, etc.), your source 3D models and their textures; the second one is a
definitive, "final" (we’ll call it FIN) folder, located in the %root%\assettocorsa\content\cars path 21, which will contain the assets that are actually used by the
game engine, and thus can be considered the place where the finished product will be.

Now, following the structures we just identified, you can see in Fig. 1.0 a basic roadmap of the car mod creation process in AC. Don’t worry if there are
things you may not understand. That’s what this book is for.

Fig. 1.0 – This is a simplification of the whole thing but overall this schematic is quite accurate, following a progression from left to right. The arrows going backwards refer to the
decision-making process of the mod creator: if you need to correct your errors or improve aspects of your work, you will have to retrace your steps many times.

Wow, I feel good now. Eat something ‘cause you’ll have to do some copy-paste work sooner or later.
If you have a double-screen setup, you might have some advantage by displaying each folder in a different monitor while working. The old-fashioned guys
will use two windows on the same screen (and no, I don’t care if you have a triple screen setup). However, for now just read and learn. I will see you at
paragraph 1.3, when you will start doing something.

1.1 - PROJECT FOLDER (DEV FOLDER) STRUCTURE

A vehicle project in progress normally consists in total of five models, including a high-poly model (~_LOD_A.fbx, Fig. 1.2), three additional LOD (Level of
Detail) models useful to improve Assetto Corsa’s graphic performance (~_LOD_B.fbx, ~_LOD_C.fbx, ~_LOD_D.fbx, Fig. 1.2), and a low-poly collider for the
physics engine (collider.fbx, Fig. 1.2).
All of your modeling work has to be done on the standard file formats saved by your modeling software. In Fig. 1.2 for example you can see a document
with the .blend extension 22, created with a 3D editor called Blender. If you use 3DsMax, you will work on .3ds file types. Other programs have other formats.
The problem is that you cannot bring a .blend or a .3ds file directly to AC. Later on, in order to achieve our goal that is giving life to our car, we will need to
convert our original model to the FBX format, recognizable with the .fbx extension. This is done with a process called export. This is necessary because
ksEditor reads only this kind of files.
For now we don’t need to explain much further, just remember that this procedure exists and think of the FBX files as half of the bridge that goes from your
3D editor files to the simulator’s assets (Fig. 1.1). The other half consists of .kn5 models, see the next paragraph 1.2.

Fig. 1.1 – FBX files are a part of the process that can’t be ignored nor avoided. On the left are the most popular 3D modeling software for games: Blender, 3DsMax, Cinema4D, Maya.

21
Referring to the simulator’s installation folder. See Par. of the AC User Manual (pag.) for more details.
22
In the MS-Win File explorer window shown in Fig. 1.1 the option to hide file extensions has been manually deactivated by the user in the Folder Options, so you might not be able to see the
extensions on your own PC, as they are hidden by default. You can change this setting. Open any File explorer window (e.g. Documents), click on the menu View > tick the File name extensions
checkbox. That’s it. No need of video tutorials.

113
The DEV folder has the purpose of containing all the models in this half-ready and half-sketched state, and storing reference material too. You will definitely
export your model(s) many times before actually getting satisfying results in-game, so this location is fundamental and it’s best to keep it as tidy as possible.

Fig. 1.2 – Example of a DEVELOPMENT folder structure with all the contents needed. The model you work on with your 3D editor of choice should contain all the vehicle LODs for an
easier workflow (you can use layers and collections to manage them). The persistence and project files (*.kscp) created with ksEditor will be explained in detail at Chapter 10.

The naming of the documents isn’t really important in this folder, what matters here is your ability to organize yourself. The names will become important in
the FIN folder, that’s why this is just a preparation work. The recommended way to set up your project folder then is shown in Fig. 1.2.

For now, since you just started, you can create the subfolders animations, audio, data_ref, PSD & texture, and put your fresh 3D model (highlighted in blue,
Fig. 1.2) inside the main folder.

All the LODs have been created here, but you can obtain a working car mod just with LOD A, though it won’t be performance-friendly; for more information
about LODs check Chapter 4 of this PART of the document.

The *.ini files (Fig. 1.2) are persistence files written by ksEditor and they include object and shader properties for the models. We will come back to them.

The most important thing is the texture folder: here you shall put all the textures created and used during the modeling phase (Chapter 2), so that afterwards
ksEditor will be able to find and associate them to the materials automatically (even the ones you will add while working with shaders within the editor, for
example normal maps). More about it at Chapters 5 & 10. If the texture folder is missing every model you load in the editor won’t be exported as the program
won’t find the textures.

The animations folder will store all the animations you’ll make for your mod, and at this DEV stage those are the exports from your 3D software of choice
(Blender, 3DsMax, etc.) in the FBX format.

The audio folder hosts all the sound samples, mixes and videos that you will collect and that are useful to the production of the vehicle’s specific sound.

Another important location is the data_ref folder: place here all the reference data, pdf documents, ebooks, photos, etc. that will be useful for the creation of
the car physics. Talking about mechanical vehicle data, you should place only your sources here, as it’s much faster to work with car dynamics and handling
configuration files directly on the FIN folder. However you can back-up your car mod’s physics files (provisional and old scripts drafts) from time to time under
this location. Do it regularly to not lose your work and avoid to make a mess with different versions. The _ref suffix will let you remember that the folder is
NOT the one in the FINAL archive (see Par. 1.2).

The PSD folder contains the Adobe Photoshop PSD source files for the car textures that can eventually be modified with any texture editor. If you made
several variations of a texture but you don’t use them all keep the ones you leftover in this folder. You don’t want to spend time searching for the right files
afterwards in ksEditor. This folder shall also be used to work on skins and their templates.

Pro tip: none of the aforementioned files and folders should be included in the FIN folder, as they are only part of development and aren’t necessary for the game to work, and
they will only increase the size of your upload if you want to share/release the mod publicly. Also keep in mind that with a little amount of software it’s possible (with some
time) to recover some of the DEV files from a finalized mod (for example the triangulated .fbx model from a .kn5 file), often using 3DSimEd, unless the mod is encrypted with
an unofficial standard 23 (even though it isn’t impossible at all either, it just requires some time and other tools). We will return to this topic.

23
This can actually make the mod look fine in-game with CSP (not guaranteed at all), but awful-looking in vanilla and in showrooms, especially with Content Manager showrooms, with
unsupported unofficial encryptions (like v3; sometimes those can’t even open and just report errors). You can’t edit your car, unless you use Custom Shaders Patch configs for a workaround (see,
that’s why there’s no point in encryption, as it can be bypassed in different ways). Anyway more about this near the end of PART 1.

114
1.2 - FINAL FOLDER STRUCTURE
The FIN folder has to be named so that the game understands it, always the hard way. Let’s consider a car that does exist in real-life, like the one in Fig. 1.2.

Fig. 1.2 – Look at it. It’s a cool car, isn’t it?

This is a Ferrari 250 GTO Series II; you can’t name the folder like this, spaces need to be removed: you have to use underscore to separate any word you use
for the name of the folder. Use lowercase text only. Mixing upper and lowercase text can create mismatches and errors for multiplayer. Use the latin alphabet,
without utf8- or fancy characters like “é” or similar. You have to follow these rules in order to avoid unintended errors.
Good practice is also adding an author prefix consisting of an abbreviation of 2-4 letters; nobody wants to fumble around with 3 different mods of the same
car, all named the same because you and the other authors were too lazy to add a prefix, and this is really important when you want to edit someone else’s
car and release it to the community (giving credits to the original authors though).
Let’s say your name is Steven. Then we can name our folder st_ferrari_250gto_s2, or stev_f_250_gto_series2 for example. There’s plenty of names you can
give to your FIN folder, just don’t use weird ones.
Pay attention: there are length restrictions for car folders, from shared memory definitions you have:

Max length - car folder name: 32 characters

Pro tip: date your updates! You can add the numbers of the date to the folder name, like this: 20230821_your_car_name for the version of day 21/08/2023. The year-month-
day format is the best to order the folders by name. This way you (and people, if you happen to release publicly) can’t really go wrong when you update your own mods. The
full name of a car mod (following our previous examples) would be: 20230912_stev_ferrari_250gto_series2.

In our example (Fig. 1.2), the car is called Your Car Name. Therefore, your_car_name will be the name of the FIN folder (any author prefix will be omitted for
clarity purposes). In Fig. 1.3 you can see it clearly. Everything is already in place, along with the models of the vehicle in the .kn5 format, which you’ll have to
export from the .fbx files we saw previously (Fig. 1.2). We’ll see what .kn5 files are and how they’re created later on; at this stage you can ignore them.

Fig. 1.3 – Structure of the final folder in the game directories. The names of the .kn5 models don’t have to be identical to what you see here (except for collider.kn5), because they need
to be configured properly with a small script in order to work (pag. ); you’ll make everything tidier if you follow the example, but no one is forcing you to do so.

Here all files and folders are mandatory for the finished exported car, except the data and extension directories (plus the lower resolution LODs B,C and D).

115
Without the mandatory assets, the game will likely crash. The data folder is usually there only during development or mod editing, and we will talk about the
files it contains in Chapter 5. Let's discuss the other contents below, always looking at Fig. 1.3.
We have some files…
1. data.acd: encrypted file that contains the car data for AC and replaces the data folder (which you’ll find when editing mods) when the mod is finalized.
2. driver_base_pos.knh: a file that indicates the driver position in the car. The game will crash if it is not present.
3. logo.png: logo of the car brand for the game loading screen (vanilla).
4. body_shadow.png: texture used by the game engine to apply basic shadows under the car body.
5. tyre_0_shadow.png: texture used by the game engine to apply basic shadows under the wheels, for wheel_
6. tyre_1_shadow.png: same as 5, but for wheel_
7. tyre_2_shadow.png: same as 5, but for wheel_
8. tyre_3_shadow.png: same as 5, but for wheel_
What are the .png textures (5-8) for?
Car ground shadows are not generated in real time, and sun shadows as well 24, but they are very important in order to improve the visual effect of the ground
position of the car and emulate an ambient occlusion effect on the ground (Fig. 1.4 left). That’s why for each car there are five ambient shadows textures. Four
textures dedicated to each wheel and another one for the car body (Fig. 1.45 right).
If not present, the car body texture is automatically generated once in game 25. Pre-made textures are used for wheel shadows. All the shadows must be placed
in the FIN folder.

Fig. 1.4 – (left) The result obtained with shadow textures on the Abarth 500 EsseEsse by Kunos. (REPLACE IMAGE) (right) Body shadow of the same car. In-game it looks as the left
shot. The shadow is blended with the dynamic shadow (not too clear=check). The rightmost is one of the car tire shadows of the Abarth.

The auto-generated shadow of the car is very rough. You can take the automatically generated body shadow tex and refine it with your favourite application
to obtain a smoother result. Otherwise you can generate the ambient shadows via the Content Manager showrooms, which include a lot of options (Fig. 1.7).

Fig. 1.7 – In the CM showrooms click on Update ambient shadows and adjust the parameters on the left panel; you’ll need to click on it again to confirm the result. After you set all the
values for the first time you can save a preset for all your future cars. I like to check how the result looks on tarmac. I quickly made this showroom with a track model from AC’s assets.

Updating ambient shadows can fix problems like the ones in Fig. 1.9.

24
Custom Shaders Patch introduces dynamic shadows, however they’re quite expensive in terms of performance.
25
However the CSP mod along with Content Manager may shut down AC, reporting the error for the missing texture, not letting the game generate the latter as it would otherwise in vanilla.

116
Fig. 1.9 – On the left the ambient shadow is too long, dark and misplaced; on the right the shadow is too bright, you almost can’t see it below the car.

…And we have some folders:

\animations:
This is where the animation files for moving parts like gear shift, steering, car doors, wipers, suspensions, hood etc. are stored for a car.
You can also add extra animations in this folder, perhaps for a spinning fan or an active spoiler/splitter. (huh?)
\data:
This is a key folder in your future car, as inside there are all the configuration files we need to work on for the physics. Go to par. if you want to start from
here. Once the car is ready to go public, there is a possibility to release it exactly as is, but nowadays the entire folder is packed in one single encrypted file
called data.acd. More about it at par..
\sfx:
There goes the sound. In order to have a working car mod, this folder and its contents are REQUIRED. Assetto Corsa uses the FMOD audio engine and all
the audio samples are packed in a *.bank file that must have the same name of the car’s main (FIN) folder.
The GUIDs.txt file is complementary because it’s necessary for the soundbank to work, and we’ll talk about it at par..
\skins:
This is the folder for the liveries, also called skins. Every skin has its own sub-folder with the preview of the car for the game UI, which you might want to
edit. For more info about this topic, see par. 2.13.
\texture:
Very important folder. All the car's functional textures, like flames and digital displays, must be here. To start, you can copy it from formula_k, because it
also contains some common shared textures, in the flames sub-folder. Otherwise, whatever new functional texture you create and use on your car, just drop
it directly in the texture folder.
The non-functional textures coming from DEV folder, once the model is finished, will be included in the .kn5 file you will export. (later)
\ui:
Used by the game UI (user interface), can contain these files:
- badge.png (128x128 pixels image), that is the logo of the car brand for game GUIs, only in vanilla AC; with CSP it can appear also in loading screens,
overriding logo.png in the main folder if you enable the “new loading screens” feature in CM. In Fig. 1.10 we have some correct examples.

Fig. 1.10 – Real brands’ logos.

Unless your car is fictional (which is pretty rare) I suggest you to use the real logos, not your own logo, as we don’t want to disrupt the immersion. Writing
your website in the “description” or “url” fields of ui_car.json script below will be enough to make some sleek and not disturbing advertisement. The
following (Fig. 1.11) are examples of logos you shouldn’t use if you want to be as serious and faithful to reality as possible.

Fig. 1.11 – Often this is just kitsch.

On the other hand, you can definitely use historic variations of a specific brand’s logo, but they have to be accurate for the car’s period (Fig. 1.12).

Fig. 1.12 – The progression of the Lancia logo (not all of them are present). From left to right, year 1907, 1911, 1929, 1957, 1974, 2007.

Finding a good image of the correct logo doesn’t require a lot of time and it’s rewarding. Otherwise use those already in Kunos cars if the brand is the same.

117
- ui_car.json, which contains the basic data of the car, such as name, year\era, author (of the car, for example a modder, for official content the name will be
“Kunos”), racing class, power and torque curves, etc. for display purpose only, ignored by the physics engine. You should change the car’s name, so it will
be easy to find your creation in the menu . You can edit this *.json file with the text editors suggested in the beginning of this manual. Here we have
everything you can write inside your ui_car.json (this example comes from the Giulia Quadrifoglio by Kunos):
{
"name": "Alfa Romeo Giulia Quadrifoglio",
"parent": "your_car_name",

% ▲ If you want to make multiple versions of the same vehicle, with tunes, different suspensions, etc., you can make a parent and a child car. Input the
name of the folder of the parent. You should also add an 'upgrade' png image. Just go into one of the UI folders of a Kunos 'step' car and you'll see
what I mean.

"brand": "Alfa Romeo",

"description": "The new Giulia represents the convergence of engineering […]",
% ▲ You can write anything in the car description, you can tell its history, some anecdotes, some info, just don’t leave it empty, at least prove you
put some effort in it.

"tags": [
"#Sportscars",
"rwd",
"turbo",
"manual",
"street",
"italy"
],

% ▲ Tags can be anything you want, but if you want them to be useful (as filters for session grids), use realistic tags like “race”, “GT3”, “rally”,
“F1”, “automatic”, “drift” etc. or look at those added by Kunos.

"class": "street",
"specs": {
"bhp": "510bhp",

% ▲ Incorrectly called “bhp”. It should’ve been called “hp”: only the torque at the wheels is truly meaningful for a comparison between cars, and often
that is the data reported on car magazines, user manuals, etc. If you look at the vehicle details in Assetto Corsa, the values are really the hp of the
cars, not the brake horse power (bhp). This can generate a lot of confusion. Thanks Kunos, as usual.

"torque": "600Nm",
"weight": "1595kg",
"topspeed": "307km/h",
"acceleration": "3.9s 0-100",
"pwratio": "3.13kg/hp"
},

% ▲ These specifications of the vehicle are not used at all by the physics engine, they’re here just for display. However type in the correct data.

"torqueCurve":
[[500.0,144.0],[1000.0,194.0],[1500.0,353.0],[2000.0,440.0],[2500.0,607.0],[3000.0,607.0],[3500.0,607.0],[4000.0,607.0],[4500.0,607.0],[5000.0,607.0],[5
500.0,607.0],[6000.0,593.0],[6500.0,559.0],[7000.0,513.0],[7400.0,468.0]],
"powerCurve":
[[500.0,10.0],[1000.0,27.0],[1500.0,74.0],[2000.0,124.0],[2500.0,213.0],[3000.0,256.0],[3500.0,299.0],[4000.0,341.0],[4500.0,384.0],[5000.0,426.0],[5500
.0,469.0],[6000.0,500.0],[6500.0,510.0],[7000.0,505.0],[7400.0,486.0]],

% ▲ The torque and power curves here are just for visualization purpose, and they don’t have any impact on the physics of the car. They’re the curves
shown in AC and CM GUIs (Graphic User Interfaces). If you modified the physics of your vehicle, and the graphs displayed are old, the curves can be
copied from the data files (with some formatting needed), or calculated and directly updated with Content Manager.

"country": "Italy",
"year": 2016,
"author": "Kunos",
"version": null,
"url": null ; you can write your website (if you’re the author). Use this field to advertise yourself.
}

You can read the info/specs above in the AC GUI, and you can modify it (if you don’t want to use a text editor) with Content Manager too (Fig. 1.13).

Fig. 1.13 – This is what you’ll find in the CM window: editing from here is easy, just click on the text field and write the correct data/info.

118
- upgrade.png (64x64 pixels image), that highlights in the UIs the upgraded/tuned versions of a vehicle, for example S1, S2, GT, EVO, etc. Not only that.
You can create with CM custom icons with any text, limited to what you can actually read in the few pixels of these small images.

In the image below (Fig. 1.14) I added a dark background to be able to see some examples, as they’re transparent .png files.

Fig. 1.14 – The first three are vanilla icons. The other ones come from mods.

- camera_trajectory.json, and this config file can add a custom camera sequence and movement at the beginning of any game session, customizable for the
specific car. This is a CSP additional feature. It’s quite rare to find a mod with this feature.

This is a short example of the script:

/* use Copy button in camera settings in CM to get settings for a new item */
[
{
"duration": 30, /* time is seconds */
"items": [
{ "pos": [ 8.435, 1.290, 1.851 ], "look": [ -0.897, 0.448, 1.342 ], "tilt": 0.0, "fov": 11.9 },
{ "pos": [ 8.435, 1.290, -0.661 ], "look": [ -0.758, 0.448, -1.169 ], "tilt": 0.0, "fov": 11.9 }
]
},

{
"duration": 12,
"items": [
{ "pos": [ -1.491, 1.342, -3.518 ], "look": [ 0.514, 0.235, -0.426 ], "tilt": 0.0, "fov": 52.0 },
{ "pos": [ -2.284, 1.825, -2.422 ], "look": [ 0.663, 0.116, -0.634 ], "tilt": 0.0, "fov": 52.0 },
{ "pos": [ -2.866, 1.832, -0.345 ], "look": [ 0.578, 0.123, -0.219 ], "tilt": 0.0, "fov": 52.0 },
{ "pos": [ -1.715, 0.832, 2.787 ], "look": [ 0.578, 0.123, -0.219 ], "tilt": 0.0, "fov": 52.0 }
]
},

{
"duration": 7.5,
"items": [
{ "pos": [ 2.917, 4.160, -3.222 ], "look": [ -0.222, 0.257, -0.391 ], "tilt": 0.0, "fov": 31.9 },
{ "pos": [ 3.708, 1.690, -4.283 ], "look": [ -0.380, 0.493, -0.415 ], "tilt": 0.0, "fov": 31.9 },
{ "pos": [ 1.069, 0.970, -4.674 ], "look": [ -0.230, 0.534, -0.331 ], "tilt": 0.0, "fov": 31.9 }
]
}

It can easily be created with CM Showrooms (Fig.).

Fig. – If you click on the Edit button, the script will open in a text editor.

\extension:

With Custom Shaders Patch, a folder called “extension” can also be created to add more configuration functionality. It will contain the config file named
ext_config.ini, which will handle any behaviour related to CSP.

119
1.3 – COPY-PASTE TEMPLATE FILES
This is when everything begins. Now you will be able to actually do something quite simple but necessary. We will create the FIN folder and copy most of
the files and folders we talked about in par. 1.2 from another vehicle, as there’s no point in writing them from scratch, it would be just a waste of time. In the
files of the official AC pipeline 2.0, under %root%\assettocorsa\sdk\dev\content\cars, there’s the formula_k (Formula Kunos, basically a draft copy of the
official Tatuus FA01) template car designed by AC developers for this exact purpose. You can also take parts of scripts from other vehicles if you need.
Avoid cloning the data from official vehicles and licenced mods, unless you plan to modify it heavily with the right values for your car (see Fig. 9.11).

You can either create a brand-new folder under %root%\assettocorsa\content\cars or copy the entire formula_k folder or the basic archive that comes with
this manual (where man?) in the same path. You will have to change the name of the main folder (see par. 1.2) and edit/replace the following files:

ui_car.json (ui folder):

Edit “name”, “brand”, “description” and later all the other lines that don’t match the info/specs of the vehicle. For starters, the three variables just
mentioned here will be enough to let you distinguish your mod from the rest of the content, and find it in the list of vehicles of the game launcher(s).
Anyway you can change everything from the beginning if you want to do the work only once.

.kn5 models (main folder):

You will have to replace the .kn5 model of LOD A with the one of your vehicle. If you make also the other LODs, you will have to replace those too. The
naming in the example below (Fig. 1.15) follows the logic we stated in par. 1.2.

Fig. 1.15 – Once you have all the models, you can replace the ones from the formula_k template with yours.

Maybe at the moment you don’t have any model. Then come back later, when you will have made some progress making/converting and exporting your
model(s).

lods.ini (data folder):

You will have to change the names of the models specified in this file according to the names you chose for the .kn5 models of your car. Look at chapter 5
for this config.

120
CHAPTER 2 - MODELING
At this point you roughly prepared the folders. With the word “modelling”, I am referring to the process that creates within the virtual (computer-generated)
world the 3D structures of real-world objects - that is, graphical modelling. We’re talking about CG, Computer Graphics. This is different from mathematical
modelling, which is the process of describing the dynamic behaviours of nature using equations (don’t ignore physicists!).

In the following paragraphs there will be info on how to make your models; paragraph 2.2 is for those who have average skills using a 3D modelling
software like Blender, 3DsMax, Maya etc., but need to improve their workflow while drawing cars, specifically for a game engine.

In case you are good at using 3D software and you already know how game graphics work, you can totally skip par. 2.2 and go directly to par. 2.3.

If you don’t need to create the car model at all, go directly to par. 2.4. Be aware that models taken from various games/third party sources may not be
accurate and faithful to reality. I suggest you to read par. 2.3.2 that will clear some things. If you need help with conversions, go to par. .

If you don’t know the basics of 3D modeling instead, I suggest you to start from par. 2.1 right here.

Pro tip: try to get your model into the game as early as possible, even if it’s in a rough shape. Waiting until the model’s "finished" is a mistake. Many things are easier to correct
early on, like NULL placement, scale of objects, number of materials and textures, etc. In addition, it's just nice to be able to enjoy your work early on, even if you use the
standard Formula_K template physics.

2.1 - 3D MODELING
Information technology has helped open up new possibilities for improving the design process; thus, several generations of computer-aided design and
drawing programs have been developed over the past few years. In the most recent of these programs, the physical object is configured as a virtual solid
model, that is, a mathematical representation of the object that can describe its shape, size, color, and other quantitative and qualitative characteristics.
Compared with traditional drawing, which provides a coded representation of a three-dimensional object with a series of plane images according to different
points of view, a solid model contains information about both the external shapes of an object and the internal space enclosed by these shapes.

This makes it possible to calculate physical properties such as volume, mass, center of gravity, moment of inertia, simulate assembly problems, determine
interferences, and automatically generate faithful models for structural analysis or numerically controlled machining. In the treatment of the relationship
between the physical object and the corresponding model, four main disciplines coexist, integrating seamlessly:

1. Geometric modeling, which is a processing activity on the model; it is mainly concerned with methods for mathematical representation of real objects;
2. Computer graphics, which deals with the methods and techniques for producing images from models: it basically approximates models with synthetic
images, that is, with a set of coloured dots (pixels) on a graphic display;
3. Pattern recognition which deals with the problem of recognizing an image, i.e., moving from image to pattern;
4. Image processing, which deals with the goal of enhancement or modification.

2.1.1 – CAD SYSTEMS

Why do we start from here? The answer is: the world of 3D modeling is confusing, and stating things clearly is always necessary.

The need to faithfully, completely and unambiguously communicate the characteristics of a real or imaginary object has led over the years to the search for
increasingly powerful representational schemes; thus, six generations of CAD systems have followed over the years:

1. First-generation, traditional computer-automated drawing (Computer Aided Drafting); an object is represented by its edges projected onto a two-dimensional plane (Fig.).

Fig. –
121
2. Second-generation, representation by edges (called wireframe); edges are represented in 3D, and two-dimensional views can be generated according to any viewpoint
(Fig.).

Fig. - Car 3D design at Mazda in the 1970s with the IBM 2250 Model 3 System.

3. Third-generation, representation of an object by its boundary surfaces (Boundary Representation, B-Rep); it is possible to obtain both the elimination of edges not in view
(hidden representation) and realistic images, with the appropriate choice of lights and colors, but the surfaces do not delimit a complete partition of space (Fig.).

Fig. – Example of a solid made with the Open CASCADE Technology development platform.

4. Fourth-generation, in which objects are represented by the 3-D space they occupy (Constructive Solid Geometry, CSG); the mathematical representation is unambiguous
and makes it possible to determine whether any point in space is part of the solid (is inside it), is outside the solid, or is on its surface (Fig.).

122
One of the advantages of CSG is that it can easily assure that objects are "solid" or water-tight if all of the primitive shapes are water-tight. This can be important for some
manufacturing or engineering computation applications. By comparison, when creating geometry based upon B-reps, additional topological data is required, or consistency
checks must be performed to assure that the given boundary description specifies a valid solid object.
The Quake engine (id Software, 1996) and Unreal Engine (Epic Games) both use this system. CSG is popular because a modeler can use a set of relatively simple objects to
create very complicated geometry.
Blender is primarily a surface mesh 3D editor, but it is capable of simple CSG using meta objects and using the Boolean modifier on mesh objects.
Some other programs that support CSG are: AutoCAD, Autodesk Inventor, Autodesk Fusion 360, CATIA, FreeCAD, Rhinoceros, SolidWorks, Tinkercad, SketchUp.

Fig. -

5. Fifth-generation, very popular in recent years in industry, with which it is possible to model by elements (or features) such as ribs, holes, grooves (parametric, Feature-
based systems). A feature can be defined as a physical constituent of a part that has engineering significance and is mappable to a generic shape (Fig.).
The flexibility of these systems is further increased with parametric and variational techniques. In addition, it is possible to assemble the various modelled components
through complex coupling relationships.

Fig. – (left) An example of a feature tree to create a solid model by applying five form features. (right) Some of the operations that can be done with feature-based modeling.

6. Sixth-generation systems, characterized by explicit or history-free CAD modeling, i.e., based on direct manipulation of the geometry of the object being designed,
regardless of the construction history of the 3-D model, with the advantage of allowing a significant increase in design speed and creativity (Fig.).

Fig. - In this example, a parametric model that was built using symmetric design intent. A change has been requested to create a new version that is asymmetrical. Perhaps a simple
task for an expert user, but direct editing can make this easy for a novice.

Most current modeling systems use a hybrid approach, that is, they use both parametric modeling by feature (history based) and explicit modeling, so that
changes required by the design can be made quickly to pre-existing models without having to take into account the component's construction history.
123
NURBS
CAD programs like Autodesk, Catia, Solidworks, Creo, etc. create primarily vector-based models that are of no use for games. Let’s explain this a bit further.
Nowadays most of the geometric constructions for industrial applications are based on a mix of B-rep, CSG and NURBS. There isn’t a clear separation.

Non-uniform rational basis spline (NURBS) is a mathematical model using basis splines (B-splines) that is commonly used in computer graphics for
representing curves and surfaces. It offers great flexibility and precision for handling both analytic (defined by common mathematical formulae) and
modeled shapes. It is a type of curve modeling, as opposed to polygonal modeling or digital sculpting. NURBS curves are commonly used in computer-
aided design (CAD), manufacturing (CAM), and engineering (CAE).

The key benefit of NURBS is that it isn't an approximation of a smooth shape. The math calculates an accurate definition of the surface shape which is still
smooth however closely the surface is examined (Fig.).

Fig. -

Why NURBS is used

In general, editing NURBS curves and surfaces is intuitive and predictable, and they offer unique features:

• Flexibility to create sculptural shapes;

• Tension to keep surfaces smooth and taught;
• Alignment to create smooth, invisible joins.

Designing with this level of attention to sculptural aesthetics is a specialised area of CAD modelling, typically used for premium products where elegance
and surface quality are important factors in the product's appeal (Fig.).

Fig. – A model of a vehicle made with CAD, like this one, can be used for production.
124
A NURBS surface is defined by a network of Control Points. The position of the control points 'pulls' the surface patch into a shape, like a flexible sheet.
They are said to be “parameterized”. This simply means that their resulting geometry is obtained from the input of parameters into mathematical models.

The key skill is choosing the right number of control points, and the right position of each of them to achieve the sculpted surface shape that you need.

Fig. -

NURBS allows the user to sculpt any shape, and is typically used for freeform, sculptural designs that can't be defined by dimensions or geometry (Fig.).

Fig. –

Also, Boolean operations between shapes are very often used, being extremely easy and clean (Fig.), unlike with polygons, where they tend to be avoided.

Fig. - The model of a car can be entirely created with Boolean operations with CAD software (Autodesk Fusion 360).

125
However, the surfaces need to be converted to triangulated geometries in order to be rendered by a GPU. This happens automatically while you’re working
with any CAD or 3D modeling software. Current GPUs are designed to render triangles because triangles are nice to work with.

GPUs can be made (and have been made) to render other primitives natively, but it's just not really worth it. If you tell a modern GPU to render a square or
a rectangle (quad), it splits it up into two triangles and renders those.

Not because there's a technical reason why a GPU can't render quads natively, but because they’re not worth spending compute power on. It's much more
useful to focus on rendering triangles as fast as possible, and then just emulate other primitives if they're needed.

Modern GPUs have hardware limitations so they don't work with quads, for example, but not because it's impossible to design a product which works with
quads. It'd just be less efficient to do so.

2.1.2 - POLYGON MODELING

NURBS and polygon models are typically both used to create freeform designs, but are based on completely different representations of the geometry, and
therefore have different methods of controlling the flexibility of the design.

Polygon modelling is based on meshes; it has traditionally been used in Character Animation and games modelling as it is particularly good at:

• Creating surface detail (wrinkles in a character's face, vegetation, rocks);

• Fast rendering calculations (polygon models are already tessellated);
• Easy to manipulate;
• Can have their UVs mapped out for texturing;
• Have infinite sides;
• Surface is made up of vertices, edges and faces;
• Very optimizable (triangulated polygonal faces);
• Cannot be used as a surface to draw Paint FX on;
• Generally easier to use;
• Easy to work with than subdivisions;
• Easy to attach;
• Can be modelled as a single, continuous surface.

Meshes are generally seen as easier to learn and easier to use than NURBS modelling, and because of this, it is beginning to be used more for concept
design work, but not for production quality final designs because of the lack of surface smoothness and precision.

A polygon model mesh is a collection of flat facets that approximate a smooth shape. This is adequate for rendering or prototyping (and in fact NURBS
models are converted to a polygon representation for these purposes), but not for industrial production.
The CNC (Computer Numerical Control) machine tools that create everyday products work from the accurate, smooth NURBS data instead (Fig.). You can’t
design any product for engineering and manufacturing with polygon models.

Fig. –

Since for AC we will work with game graphics (the basics of which will be explained at par. 2.2), it’s the opposite: we actually need to use polygon modeling
instead of CAD.
You can technically convert a CAD model to polygons, but it will require a lot of work to be cleaned and optimised.

126
As an example, I personally made a simple wheel with Rhinoceros 7, which I’m learning (Fig.). With the QuadRemesh command I obtained a decent polygon
(quad) mesh from the NURBS model.

Fig. – It’s important that the NURBS objects are clean, which means no cuts or open faces from Boolean operations. In fact, if the spokes and the rim were fused together this would’ve
resulted in a bad mesh. But if you keep your parts tidy and separated like this, it can be done quite easily.

The topology (see par.) of various objects will often have to be entirely reconstructed by hand, so the results are not immediate, especially if you don’t follow
a defined method (Fig.). In that circumstance it’s probably simpler to remake everything from scratch.

127
Fig. – This mesh surely cannot be used for anything, really.

Then, if you need to choose a 3D modelling software, be sure it can work with polygon meshes, and export your models to FBX up to the 2014/2015 format.
I suggest to learn about the program itself first: you can read manuals, or learn how it works with practice on simpler things, to build experience. Only then
come back to continue following this guide. Don’t worry, no one is pushing you to rush things. The next pages won’t go too deep in the subject, but are a
good recap of the things you need to know the most.
My recommendation is to use Blender, due to the fact that it is free and open-source. If you need help to learn how to use it, you can use the following
books (which you can also find online with some research):

• Blender For Dummies (by Jason van Gumster); for beginners, it has a quite relaxed approach, very well written. Can be fairly interesting also to experienced users.
• The Complete Guide to Blender Graphics Computer Modeling & Animation (by John M. Blain); there’s a ton of examples, even physics simulations are discussed.
• The Blender Reference manual (from the Blender Documentation Team): https://docs.blender.org/manual/en/latest/index.html; less discursive but includes most of the features.
•

A professional alternative (which may be more complicated) is 3DsMax, but it’s very limited in terms of applications (for comparison, with Blender you can
produce photorealistic renderings, simulations, animations, entire movies, games, 2D graphics and much more).
I do not have enough experience with other programs to recommend them, but you will find brief descriptions of the most popular ones in the modding
community at the beginning of this manual, under THE TOOLS YOU WILL NEED.

128
2.2 - IMPROVING YOUR WORKFLOW WITH GAME GRAPHICS
You’re able to draw with your favourite software but you don’t know where to start from when it comes to your favourite car. Huh?
First of all, you need to look at what you’ll be working with till the end of the days: polygon meshes. You will learn how to make your 3D models as performant
as possible in terms of graphics, because we never want to make our game slower, and there are various ways to achieve this.

2.2.1 - POLYGONS VS TRIANGLES

When playing around with meshes, in my experience over the years, the faces were always referred to as polygons in the modelling software I was having
fun with. Furthermore, the polygons in the mesh don't necessarily begin as triangles. Some may end up that way, but not all of them. It just depends on
how things turn out while I'm shaping things.
When you create 3D models, you will use “polygons” as your atomic elements. A polygon is an n-sided shape, defined by its corners (vertices) and the
straight lines between them (edges). An individual polygon is often called a face, and is thought of as the filled area defined by its vertices and edges. These
geometric entities get attached together to form the final shape of your object. Amongst all possible polygons, you will mostly use triangles (tris) and
quadrilaterals (also called quadruples or quads) for your work (Fig. 2.0).

Fig. 2.0 – Examples of tris and quads.

Some 3D-tools do not even support other polygon types (n-gons) at all. An n-gon is a face that has five or more edges used to construct it. Now, from the
point of view of AC:
1. Game engines mostly work with triangulated meshes. If you import a mesh to a game, its faces are converted to triangles.
2. For performance (GPU), the triangle count matters, not the 'poly-count'. If you have a model made of 100 quads (4 sided polys), then it's triangle-count is actually 200.
3. When animating a mesh, differences can occur. If you animate a quad (or n-gon) mesh in the modelling software, it can look a bit different in game (since the mesh got
triangulated on export/import).
And there is another nasty caveat here: a quad can be converted to a triangle in 2 ways, via a process called triangulation (Fig.). And this can have an
influence on the actual rendering of your model due to lighting calculations along the triangle edges.

Fig. – Any quad can be split into a couple of triangles. Squares and rectangles are particular types of quads. Then you have the diamond shape.

Now there are some ongoing discussions about when you should use tris and when you should use quads in your model. The most important issues with
this are related to texturing and animation. And during modelling you will face more problems with triangles than with quads especially when you plan to
use the “Subdivision Modifier” for your work. Here are some issues with triangles in your model:
• Using triangles in your model tends to not work well with subdivision.
• Triangles break edge loops. That can be bad when you try to optimize your mesh (reduce polygon count).
• Tris tend to create much more complex mesh topologies (what is 3D topology? Read paragraph 2.1.2). While easier mesh topologies can be maintained with less work.
Tris sometimes can be useful though, for example when optimizing your model or making certain shapes (Fig. 2.1). They’re really a double-edged weapon.

Fig. 2.1 – Detail of a car door geometry. Both tris and quads are used to connect certain parts together where the polygon density is different.

129
In the end, whatever you create will be converted into a triangulated mesh upon import to the target system, AC’s game engine. This process is called
tessellation. Hence it makes a lot of sense to learn how you can use different polygons for optimization purposes.
For now the guideline for making your 3d models will be:
• Use Quads as much as possible while you are in the modelling stage.
• Use Tris where using Quads would make your model more complicated.
• Use Tris when they help to optimize your mesh in the Optimization stage.
• The mesh must be (when possible) in quads. Do NOT triangulate the mesh if it is not necessary.

2.2.2 - MESHES AND SHELLS

Polygons can share vertices and edges with other polygons. You can use a large number of connected polygons to form shapes. A mesh is a collection of
polygons (a mesh is also sometimes called a polyset or a polygonal object).

A mesh can contain different types of polygons (triangles, quads, n-sided). Often a mesh consists only of connected polygons, however it can also be
several disjoint sets of connected polygons, called shells.

Edges that are not shared (they are on the outside edge of a shell) are called border edges.

130
2.2.2 – THE CONCEPT OF MESH TOPOLOGY (wip)

There’s a big difference between an optimized and a non-optimized model. Experienced modders and 3D artists think about it a lot.

Simply put, 3D optimization is the process of reducing the file size of 3D models. The size of 3D models comes from two places: geometry and textures.
Geometry refers to the actual mesh or structure of the 3D model which is made up of polygons. Textures are simply the images used to skin the 3D model.

The mesh decimation portion of 3D optimization removes or combines polys to reduce their overall amount (poly count). The file size becomes smaller and
requires less GPU power to render. This is something we’ll have to work on, because in order to produce a model that can be easily optimized (efficient)
you need to create a good topology.

When we talk about topology, we are referring to the actual structure of our meshes. How everything links together in the flow of the geometry, which can
be divided up into three types of atomic elements (Fig. 2.2):
• The first is the vertex, which is a singular coordinate in 3D space.
• The second type is the edge, which is a line that is constructed between two vertices.
• The third type is the face, which is a closed-loop of three or more edges that can create a flat surface (tris, quads, n-gons, already mentioned before).

Fig. 2.2 – The primitive (fundamental) geometric elements of your 3D space. This image shows also how you can choose which one to work with in Blender.

Mesh topology is the way in which all of your different types of geometry are formed. For example,
a good mesh topology will have plenty of quad-based faces, which allow you to evenly spread
your geometry around your model. On the other hand, bad topology could be the use of n-gons
where they are not required.

The easiest way to think about mesh topology is to divide up your geometry into a series of loops
and poles. A loop is where we’re able to select a section of our geometry that follows a specific
path (Fig. 2.3).
Fig. 2.3 – An edge loop around Fig. 2.4 – A face loop around
A pole, on the other hand, is often used to terminate that loop. In Blender for example, loops are the whole sphere. the whole sphere.
constructed from quad base geometry. The face loop that is created (Fig. 2.4) goes all the way
around our model and this is because the flow of our geometry is able to tell what direction we
want to select the next phase.
This is easy for Blender when working with foresighted faces as the geometry can go in one of a
couple of directions. In our example of the UV sphere, because we are going horizontally, Blender
knows that we are going from left to right and vice versa for our selection. So it simply has to find
the edge of the face on the opposite side of the selection, to continue the face flow. If you choose
to use anything other than a four-sided face, however, things become a little bit more complicated.
If we attempt to select a vertical loop for either our faces or edges, we find that it does not even Fig. 2.5 – A face loop Fig. 2.6 – An edge loop
reach the top (Fig. 2.5), and that’s because if we reach the look at the top of our UV sphere, we can interrupted by two poles. interrupted by two poles.
see that we are no longer working with a four-sided face. We are now working with three sided
faces, aka triangles.
Unlike the quad base geometry of a four-sided face, Blender does not know what direction to go in when a loop reaches a triangle, so instead of attempting
to guess what direction to go, it just terminates the loop at that location. This is what happens with our UV sphere. All of the faces are selected up to, but
not including the triangles, located at the top and bottom of the UV sphere. The triangle is therefore referred to as a pole a location where a loop is
terminated (Fig. 2.6).
Why are loops and poles important then?
The ability to create good 3D topology depends on your understanding of how loops and poles work, as well as geometry in general.

131
You may think that the best way to construct a model is to avoid poles altogether, but this is not true at all, as they are a necessary part of many 3D models.
The reason why you have to use them is that you actually may need to interrupt a loop. Take for example Fig..

Fig. - You are working on the rear wheel covers of the car, and you want to add an edge loop to make the shape rounder and smoother. But when you try to create it (Ctrl+R shortcut
in Blender), the detection goes all the way to the front.
You don’t want this to happen, so the only thing you can do is to add a pole at some point. If the car is modeled one panel at a time, this is much less likely
to happen, but the probability is not 0%.

wip
An example of bad topology is when geometry overlaps. This can create what is known as shading artefacts on your 3D model when you apply smooth
shading or add textures to it.
Shading artefacts can be very distracting in terms of the visual appearance and the overlapping geometry can also affect your models’ functionality if you are
attempting to animate it.
It’s easy to create shading artefacts when you are using specific tools such as the bevel and boolean modifiers. It is most common when you manipulate
your geometry incorrectly in edit mode or you use tools that significantly deform that geometry. Again, the Boolean modifier is an example of this.

132
2.2.4 – NORMALS
When you shade or render polygons, the normals determine how light reflects from the surface.

Face normals
The order of vertices around the face determines the direction of the face (whether a side of the polygon is the front or the back). This can be important
because technically polygons are only visible from the front.

The front of a polygon’s face is graphically represented using a vector called the polygon’s normal. A normal is a line representing the direction
perpendicular to a polygonal surface.

Vertex normals
Vertex normals represent the visual smoothing between polygon faces. Unlike face normals, they are not intrinsic to the polygon, but rather reflect how your
polygons are rendered in smooth shaded mode.
Vertex normals appear as lines projecting from the vertex, one for each face that shares the vertex.
• When the vertex normals all point in the same direction (called soft or shared vertex normals), there is a softer transition between the faces in smooth shaded mode.
• When the vertex normals point in the same directions as their faces (called hard vertex normals), the transition is hard, creating a faceted appearance.

You can manually manipulate normals to create the appearance of hard edges (creases) and shadows without using additional geometry.

Normals on your model can be affected by its topology, but this is just part of the story.
The normal in 3D modeling refers to the direction that your geometry is facing. Vertices can have an inward or an outward direction (Fig. 2.7).
Ideally, you always want to see the outward direction (the normal) of the geometry. The same also applies to a face where it will have an inward-facing side
and an outward-facing side.
In video game design, there is a process known as backface culling that ignores the inward-facing side of a face and therefore doesn’t render it.
If your normals are incorrect and the inward-facing side is pointing outwards towards the camera, then when you export that model into a game engine, that
geometry will not be rendered and you’ll be able to look through your asset, which you don’t want to happen.

Fig. 2.7 – How to display the vertex normals of a UV sphere in Blender: the blue lines represent with a vector each normal direction.

If normals are your primary issue, then what you can do is go to the overlays menu in the top corner of the 3D viewport, and then
select the face orientation option from this menu.

What this option will do is it will highlight your geometry in one of two colours, blue or red. The colour blue indicates the outward
facing side of your normal direction. While the colour red in the case the inward facing side of your normals.

The ideal scenario here is to not be able to see any red faces in your scene. But what you are able to do with this is select the red faces,
And then access the normals menu, which you can do by holding down the Shift key and pressing N.
133
In the normals menu, you have a variety of options, but if you have selected all of the incorrect normals then you can just select the flip
option at the top. Alternatively, you can select all of your geometry, go to the normals menu, and then select recalculate outside.

This should be able to flip all of the incorrect normals to the outside. Sometimes this option doesn’t always work, so it’s good to try this
first, and if it doesn’t work, use the flip option as the backup by selecting the faces manually.

Using normals to smooth shapes and reduce poly counts

blablabla

In 3DsMax Editable Polys have a built-in smooth modifier that allows you to smooth specific sections of the model. To use it select the faces you want to
smooth and assign them a smoothing group number (Fig.).

Fig. -

The result is shown on the right. As you can see this procedure smooths the whole face which isn't ideal as there is no definition and it would cause nasty
curving on the reflections.

To add definition or tighten up the smoothing, you have to add more detail, basically one more edge (Fig.).

Fig. -

But as you can see the flat faces still have a curved appearance. So to fix that you can either add detail once again (Fig.), (which as you can see fixes the
smoothing on the flat faces), or you can add an Edit Normals modifier and adjust the angle of the normals to affect the angle of the smoothing.

Fig. –

134
Fig. -

Fig. - As you can see it has the same smooth effect as the previous version but with less polygons.

So that's how the smooth modifier works in 3DsMax with the use of normals. You can also select other polygons on your model and assign a separate
smooth group number. This will make them smooth but have a sharp transition between other smooth groups.

2.2.3 – TYPES OF SHADING ARTIFACTS

WIP
So there are numerous ways in which we can create bad topology on our model. And some of these methods are not always going to
be intentional. Some of them are just going to be by-products of how we construct the object in the first place. But what are the best
ways to fix these options if we come across them?

Starting with the structure of our loop system, which is the actual flow of our topology. We can use tools like deleting, dissolving and
merging as a way of combining our geometry together and redefining our loops. We can also use the loop cut and slide tool to create
additional loops on our 3D models.

Shading artefacts are very easy to create because they can form as a result of either using a tool such as an edge slide incorrectly or
using another tool like a modifier to deform your geometry.

If you come across any shading artefacts, the first thing you should try and do is go into edit mode for that model, locate where the
shading artefact is and attempt to reposition the geometry there.

You can do this by pressing G twice to enter vertex grab or edge grab depending on the method of selection that you have active.

Using the decimate modifier reduces the overall amount of geometry on your mesh, but it’s going to destroy your topology as a whole. It does get rid of the
individual shading artefacts that are located on the surface, but also of your work, so avoid this modifier!

Really WIP
tessellation, seams

2.2.5 - OPTIMIZATION OF YOUR MODEL (WIP)

What is an optimized model?

You can see different applications of optimization in Fig. 2.7 & 2.8:

135
Fig. 2.7 - Examples of mesh optimization. The meshes in the top row are the initial meshes; the meshes in the bottom row are the corresponding optimized meshes. The first 3
columns are reconstructions; the last 2 columns are simplifications.

Fig. 2.8 – In this example notice how the final result is able to preserve information with a reduced amount of geometry. K here is just a parameter that influences the cohesion of the
vertices and consequently the topology of the mesh obtained. More info about optimization here: https://sites.stat.washington.edu/wxs/Siggraph-93/siggraph93.pdf

The problem is that even if our object’s shape is preserved, other important visual properties are influenced, like reflections. These are almost always
negatively affected if the optimization is done without following any rule, just applying mathematical formulas like in Fig. 2.7 & 2.8.
Our optimization will not be automatic, it will be done by hand instead, with the methods that 3D modeling topology teaches us.

What is topology?

Having a good topology helps avoiding artefacts in general, and makes optimizing your model easier. You’ll need less triangles in
general, so your models will be the most efficient.

the industry workflow is to model the car as a single piece and then start adding details like panel gaps etc once the shape is finalized
and subdivided, makes for a much easier and simpler work as you don't have to worry about keeping the topology in quads and
uneven density messing up curves.
Stereo:
I believe the main origin of that is models built to have the subdivision modifier permanently a part of the project, with 2 levels in
viewport and 4+ subdivisions for renders, to the point it stops getting smoother. For games where you aim for a polycount, it's just not
efficient to have subdivision applied to panel edges; you only want 2 or maybe 3 loops round the corner (one on the face, one into the
edge, possibly one rounding it off) but with 3x subdivision that's gonna be a minimum of 16 so the smoothing works correctly.

136
You can get much better reflections if you build the optimum edge flow without the gap, use subdivision, and then cut the gap in after.
To some extent it's better not to even have a row of edges right where the gap is, even if they're parallel; it's easier to add the corners
of a cut/extrude/bevel through the middle of faces than along edges. Since you're turning that edge from infinitesimally wide to 10-
15mm wide. So for example if a car has a door handle inset into the door, I generally aim to have a vertex at the center of where the
handle will be, so that the round-ish shape sits on the 4 quads around that vertex.

If you make your cuts and then subdivide it, you will never get normals consistent across panel seams. There can be an argument that it's more
realistic since in real life manufacturers have draft angles to contend with on their parts so the surfaces on either side of a panel gap aren't perfectly
aligned anyways, but in a digital model having a visible jog, or inconsistency, in the reflections makes the model look a bit messy. If you subdivide and
then cut the model into pieces, keeping a copy of the model that isn't cut, you can transfer the normals information from the uncut model to the
perimeter vertices of the seams in the cut one for pretty much perfectly consistent reflections. I don't know the proper way to do this in your
software, but @Stereo posted about his method while working on his Porsche model a few months ago in Blender (using a data transfer modifier,
which is better than the shrinkwrap method I've seen others use). I'm sure your software would have a similar tool/workflow to achieve the same.

You can learn "proper modeling hygiene" all you want, but until you actually do it it doesn't mean anything. Understanding the theory
and how to implement it are two completely, utterly different things. The first car I tried to model in Blender I started 5 times because
it's really easy to say how it should be done, much more difficult to actually do it. They need to make a less-than-stellar attempt to
learn from to be able to actually learn for real. Telling him to just stop now and learn is counter productive, since stopping will prevent
said learning.
The difference between my 2019 models and my 2021 models is massive and if I wasn't so preoccupied with practicing and instead
spent more time learning the theory and actually implementing it I could've improved this much in 2 months instead of 2 years.

2.2.15 - SETTINGS AND TIPS TO EASE THE JOB IN BLENDER (wip)

- There are a lot of things to come to grips with, for each piece of software. An example: viewport clipping.

Setting it like this, will stop parts of models from disappearing from the 3D view.

Fig. – Comparison of the panels dedicated to the viewport clipping in old vs new (2.9 onward) versions of Blender.

On very large track maps you will need to increase the End value quite a lot. For the clip Start value you can get even smaller, if you write 0.001mm in the
start field. However, do not go as small on large models, as not only it’s wrong, but it can cause erratic 3D cursor behavior!

- Make yourself feel at home by adding some more functions to your Blender experience:
1. Head over into the user preferences and switch to the Add-ons tab (Fig.);

Fig. -

137
2. Enable some helpful Add-ons:
• Layer Management to organize the layers, e.g. by giving them names;
• Archimesh to easily build architectural objects like rooms or complete houses;
• BoltFactory to add imperial and metric bolts and screws to your models;
• Extra Objects brings default mesh objects like Roundcubes, stars, sqorus or diamonds.
3. In the same window, ensure that the FBX export format is enabled, in order to be able to bring your models to the AC SDK editor later on.
4. Enable Import Images as Planes for an easy blueprint setup (requires pre-cutted views of the blueprint you want to use).
5. Enable UV Layout (should be enabled by default) to export the UV layout to a 2D image from Blender’s built-in image editor.
6. Enable the Pie menus for easy and quick navigation or manipulation in the viewport. Since the 3.0 release of Blender this option is enabled by default.
7. If you plan to do some character rigging (for driver models and such), make sure to enable the Rigify add-on because it gives is a powerful help.

- By default, Blender uses "generic units", which have a meaning inside Blender only. But if you'd like to use a referenced unit system, you can switch to
Metric or Imperial. Just go to the "scene" tab (right side panel, Fig.) and select what you wish. Done.

- Problems with scale? If yes, and you are using Blender, be sure to check the Apply Unit button when you export (Fig. left). It shall be noted that it is not
present anymore in the latest versions of the software.

Fig. – (left) The Apply Unit button, a little devil present in older Blender releases. (middle) From 2.79b onward, the FBX export panel has the additional option to Apply Scalings: with
the value FBX Units Scale the model is exported with 1:1 scale with respect to the scene's units (which have to be set properly in advance). (right) In the latest releases, the Apply Unit
button has been replaced with a checkbox that you must activate (it should be enabled by default).

- Useful commands / operations / tricks in Blender:

• Fill command
Let's say you have 2 edges and you'd like to fill the area between them (Fig.). To do it, select the two edges and press the F key.

Fig. -

• Use a background image as reference

There is of course the classic method of adding a plane and texturing it, but there is an even simpler solution. In the menu, click on Add > Empty > Image.
Then in right hand panel, load the image you need. Also, you can set the Transparency, Size, Offset there. By using the panel activated with the N key, you can apply all
standard modifiers like position, rotation, etc.

138
Fig. –

In newer Blender releases, an option to add a Reference or a Background image has been added (Fig.).

Fig. -

• Split object
After using the apply on an array modifier, the resulting objects will be treated as single group.
In case you don't want that, one way of ungrouping this quickly is: Select the newly created object(s), go in edit mode pressing the TAB button on your keyboard, select all
with the A key, press P and select Separate By loose parts in the context menu that opens (Fig.).

Fig. -

139
• Grouping and Parenting objects
This is very useful when working with NULLs. CTRL+G creates a new group and adds the selected object(s) to it. It is recommended to use groups just to logically organize
your scene, but the objects are together without any kind of transformation relationship. If you are looking for the later then use Parenting.
To parent objects, select at least two objects (select the Child Objects first, and select the Parent Object last), and press CTRL+P. The Set Parent To dialog will pop up
allowing you to select from one of several possible different parenting types.
You can also do the inverse operation (aka remove a parent-child relationship) via ALT+P.

• Triangulate and un-triangulate mesh command

You can triangulate a selected portion of a mesh in Edit Mode by hitting CTRL+T. This converts all quads and n-gons into tris. Keep in mind that triangulation is done by
ksEditor when exporting your model to the .kn5 format. In addition, game engines work with triangulated meshes, while we want to work with a good topology. Thus, you
should avoid this operation as much as possible.
You can un-triangulate the selected portion of a mesh by hitting ALT+J. This will only create quads so some manual clean-up may be necessary if you need n-gons. You can
do this by selecting the leftover edges, hitting X and clicking Dissolve Edges. Un-triangulating can be useful for conversions from various games, which can come with
triangulated models that are difficult to work with from the point of view of edge flow.

140
2.3 – HOW TO MODEL A VEHICLE: RULES AND TECHNIQUES
Yes, no one is able to draw anything out of nowhere (unless it’s a product of your fantasy). Let me see what I got here.
First of all, you have to draw your car from the exterior to the interior and not vice versa. This is due to few reasons:
• It is easier to find reference material for the car body, either from drawings or photographs.
• Getting the boundaries of your model right since the beginning gets you more focused on the basic shapes instead of going too detailed early on.
• The shape of the interiors depends on the exterior, as it is contained inside the latter.
• The interior, especially the cockpit, is made of many little parts which you can model separately if you have their correct dimensions (e.g. the steering wheel, the seats,
the shift lever, etc.).
• There is no point of having your pilot drive on seats running above thin air. We are not working with Ikea furniture.

Thus, the car body will be the main focus of this paragraph. Let’s immediately dive deep into the subject.

2.3.1 – THE WORKFLOWS

There are mainly two ways to create a vehicle’s exteriors, that depend on your intentions:
• If you want to design your own fantasy car, you can start by extruding and sculpting a simple cube. The shape will be the product of your imagination, and as a
consequence you will have to learn very well all the solid tools of your 3D modeling software.
This first process is actually fast (Fig.) if the ideas are clear in your mind: drawing a shape by hand on a piece of paper in advance (like real car designers do) could be really
helpful. Also, with the right choices, you can get a very clean topology where everything is in quads.

Fig. – The process of creating a low-poly exterior from a cube, using only the following tools (Blender): Mirror (modifier), Move, Rotate, Scale, Extrude, Loop Cut/Slide, Inset Faces.
• If you want to draw a real car however, sculpting from ground zero without a reference will be very inefficient to get the rough shape: you need to know which are the
lines, the curvatures, the concavities and convexities of the real-world body, and thus recreating them completely by hand can be truly painful. It means getting the
shapes right by repeatedly comparing the model with the reference images by naked eye.

141
We don’t want to start with such a high difficulty. We will ease our work with the help of the principles behind orthographic projections (Fig.).

Fig. – This is the principle behind orthographic projections. You draw an object exactly as it appears from where you look at it (with no perspective, corresponding to a focal length
approaching infinity). While modeling you will have to go in the opposite direction, from the projection to the object.

Engineers do know them very well, as they represent most of the drawings that you can usually see in any technical documentation, aside from
axonometries and sections (Fig.). They’re standardized, but we don’t care about that. Or do we? Yes, we do care, because the regulations imply some rules
that will allow you to understand what the drawings mean. (meh)

Fig. – Three schematic views of an Audi R8, which can be used as blueprints. It’s actually increasingly difficult to find this quality the older the car is.

The main difficulty with 2D projections is that they give less information to your brain, which needs to understand the conformation of an object. Having two
eyes we normally can perceive perspective and shapes in a very direct way, just by moving ourselves or the object around. But a flat image can’t do that, so
our mind has to fill the gaps. And the best way to do it is by using the imagination. Which will work only if you have seen many vehicles in your life.

It may seem naïve, but it’s true.

To model a car you need at least one view for each 3D dimension, so three drawings are required (front, side, rear). This is the absolute minimum amount
of reference images you need to model the basic shape of the body. If present, any additional view of the vehicle will help, for example a top view.

142
Keep in mind that very often the drawings (even technical ones) may be completely wrong, being made by hand! See Fig. below.

Fig. – In this example you can observe how different points on the vehicle do not align at all. While A and B are correct, C and D should be connected by a vertical line, but since the
point D is misplaced, this doesn’t happen. The point C is actually more accurate with respect to the real vehicle. The same can be seen in other spots of the schematic. On the rear end,
the bottom drawing is wrong, as the bonnet’s shape should go further ahead (see the gap between the blue lines on the real photo).

So yeah, blueprints tend not to be perfect, and often the major problem is to make the different views work together. Generally you should only really trust
the parts that are directly on sight, not more distant stuff. For example, even if you can see how high the middle of the windshield is on the side view, trust
the front view more.

Those car drawings can be useful to help get an idea of the overall proportions, or define a certain panel (Fig.).

Fig. – There is no perfection, just good proportions.

Often you won’t find good technical drawings. In that case the most useful thing you can get is a cursory schematic or a high-quality picture of the vehicle.

You can use blueprints to get rough shapes, then switch to perspective photos to fine-tune it. That’s called photomatching.

Photomatching can get you good proportions; it can't produce an accurate end result the way laser scans can, and for most photos you shouldn't expect a
perfect match, but at least it will look right (Fig. ). For example, if you don't have a real-world measurement of the exact width of some trim piece, you can at
least get it visually the same.

143
Fig. – Photomatching the same model with different photos can get very good results (Ferrari 365 GTB/4 Daytona).

In my experience so far, nothing beats camera matching. If it matches the real pics, then you're set.

You may be asking: how can I use shots taken from angles other than front/side/top/rear?

That is called camera perspective matching. You can do it with plugins dedicated to the specific purpose of photomatching (especially in Blender).

Know that photographs can be misleading as well, due to lens distortions: while 3D modeling programs' perspective is actually quite primitive, in that most
use straight lines for their perspective projection, photo cameras curve the perspective projection, depending on the focal length (Fig.).

144
Fig. -

Lens distortion can be mitigated by knowing the camera model and adjusting for lens distortion in Photoshop before using the images as reference;
alternatively you can do it inside Blender itself, by using the Node Editor to insert a Distort/Lens Distortion node between the input and output nodes of the
reference image’s shader.

If the design is symmetric, draw only half of the car, then mirror it.

Your first attempts will probably not look very good, but at times you may not notice the defects, due to the fact that you’re a newbie (Fig.). Do not worry,
you have time to learn and improve yourself.

Fig. – With his first attempt this guy is learning the shape of the car by eye, no blueprints. The geometry has been applied subdivision to, covering a bad topology, and you can see
that the surface is not even. But for a beginner, it’s not too bad.

The thing with subdivision modeling is, you line up the middle of faces to the surface you want to create and it rounds off the edges. When you're just
modeling it straight, you line up the vertices/edges to the surface you want to create. So you can't switch from one to the other without changing the overall
shape of the model.

145
2.3.2 – REFERENCE MATERIAL TO MODEL VEHICLES
You will have to search a bit to find good images and drawings/schematics of the vehicle. Do not expect to be able to find quality pictures easily, especially if
you’re making a rare or historic vehicle. Schematics are always the most helpful (Fig. 2.1).

Fig. 2.1 – A Mercedes-Benz schematic. Things like these are a must-have if you want some material to start with.

There’s a bunch of good places I can suggest to begin your research from:
1. http://britishracecar.com; you can find very detailed descriptions, a lot of car shots.
2. http://tech-racingcars.wikidot.com/circuit-cars; another quite good website to find images and specs.
3. https://www.w124performance.com; there is almost everything for the Mercedes W124. This means also a lot of images and documents for 1990s Mercedes car parts.
4. http://www.mulsannescorner.com; a lot of specs, for engines too. There’s even aerodynamic data for some vehicles.
5. https://www.ultimatecarpage.com/brandlist; many brands and models, even exotic ones.
6. Go to websites that sell or auction cars. The most prestigious ones (like RM Sotheby’s) usually have the best photographers to make a better presentation of the vehicles.
7. Find companies which create scale models (simultaneously “toys” for kids, and collector’s items, very accurate and expensive). They’ll likely know more than anyone else.
8. Look for the service manual of the vehicle. If you can’t find anything for free you may have to buy it. Repair instructions are always full of specs and illustrations.
9. Research on the deep web. It can often give more results. You will have to use Tor Browser and the DuckDuckGo search engine.
10. Take photos of the vehicle yourself. Sometimes you only have to find the right occasion. Shoot as many images as you possibly can while you have any kind of access to
the car (Fig.), because probably it won’t happen again (in a lifetime sometimes).

Fig. – Photos taken with a smartphone of a Ferrari 550 Maranello at the Brussels Museum for the celebration of Ferrari’s 70th Anniversary.

146
If your car has been made replicas of, maybe you should try to contact a guy or a company that built one. I'm sure he/they will have more details than you
do (e.g., the panels size, etc.). See Fig..

Fig. – These lads building a replica of a Ford P68 (F3L) in a laboratory, complete of CAD models. Get in touch with people like this, if you’re lucky they may share with you some data.

147
2.3.3 – WHICH PARTS TO MODEL
Assuming that now you have the reference material, it is logic to ask the following question: “Should I model every single part of the car?” The answer is:
“No, but between the visible ones, as many as possible”.
The process should pretty much resemble an artist’s work when drawing a body design (Fig.): first, get the lines and the curves right, then the shapes, then
add details.

Fig. – Sketches of cars from the prototype class. On the left a Formula 5000 race car, on the right a Ferrari 512 S. If you know how to draw vehicles on a piece of paper, you will
definitely have an easier life when trying to understand how they are built and how they can be modeled in 3D.

148
It may seem strange to ask you to be extra careful when you are modeling what are the easiest first steps, but this is most important because a careless
mistake at the beginning may spoil the whole picture at the end.

Go as detailed as you want, and if you want to include the drivetrain or the engine you can. The only limits are your ability, your creativity and the poly
counts (for this one see par.). However, you can ignore hidden parts that no one will ever be able to see, unless you really want to go that far. Obvious

I won’t stop anyone from reproducing all the tiniest bits of a vehicle, but be aware that if your model is above 1 million triangles it will have to be optimized
(already after 350k tris you should begin to worry and use the LOD shortening technique, par.).

In any case, if future Assetto Corsa titles or other racing sims/games will be able to handle (with future hardware generations) very high-poly assets (over 1
million triangles) in the future, you will always have the opportunity to add more details to your 3D vehicles.

2.3.4 - FAITHFULNESS TO REALITY (wip)

Often making models of a real object is considered an art. This is because unless you’re using photogrammetry, similar three-dimensional capture
techniques with a resolution around one millimetre, or the vehicle manufacturer design models (VERY unlikely) there’s a lot of human interpretation going
on.

For example, we have a comparison between the real Ford GT40 and the one portrayed by Kunos (Fig.).

Fig. – They’re very similar, but not identical. Many of the lights can be made functional in vanilla, but especially with CSP additional features and specific functions can be added.

Cars were made by hand, especially the body of historic racing cars. But even with mass production, car manufacturers always had the opportunity to reuse
parts from various models to make new cars. This lead to interesting character development.

Very often there are very subtle car-to-car design variations that can be a challenge to notice if you are not an expert in the field, or in that particular vehicle.
Let’s take the Bugatti Type 35 as an example and let’s make a little analysis.

Launched in 1924, little change was made to the Type in 1925, but that would soon be a year that passed, and a wide range of specification and model-
range developments from early 1926 would appear. 1926 was the year when Bugatti finally accepted the concept of the forced induction engine and devised
the fitting of a supercharger – but only after he had enlarged his standard engine to 2.3 litres (100mm stroke crank), but still unsupercharged, to create the
1926 modelyear Type 35 T – for Targa as in the race Targa Florio.

The Type 35 series radiators changed as engines changed and design evolved (Fig.). Many feel that the earlier narrow radiator was more elegant, yet the
later, wider type is more recognizable today and is seen on the current range of modern Bugattis.

149
Fig. – (top) The radiator and new horseshoe-shaped grille/cowl became the Bugatti hallmark - yet the original, slim, tapered radiator and cowl/shell had to be widened to fit the new
modified engine and chassis space of the Type 35T, and then enlarged again for the Type 35B - to increase cooling once the bigger engines manifested. This was known as the Miramas
radiator. (bottom) Later model Type 35 leads an earlier car down the Prescott Hillclimb return road. Notice the mudguards.

Detail developments saw modifications such as the number of screws around the alloy wheels’ circumference was also changed in later production (32 6mm
studs to 24 studs). Manufacturing issues with these Dunlop-made safety tyres of special size saw Bugatti revert to Michelin tyres at standard 28in x

150
4.75in/711mm x 100mm. Later Type 35C wheels had a large brake casting aperture or 330mm over the prior 270mm – to allow for bigger brakes. Just the
thing for the 3D modeler to be aware of (Fig. ).

Fig. – (top) Two of the world’s most original, remaining Grand Prix Bugattis, seen at Prescott on Bugatti Terrace. Note the beaded edge race tyre/ wheel combination on the pale blue
car. The red car is the famous T35C Genie 26. Note the low and lean build of the Type 35. (bottom) (From another angle) Three types of the series. Left (pale blue) is the eight-cylinder
1926 Grand Prix spec car with ‘race’ tyres, centre (red car) is the famous and original-condition 1927 Type 35C ‘Genie’ and right (dark blue) a Type 37 four-cylinder car.

26
“Genie” – now wearing the correct red paint – is original, unmolested and has not been denuded of its patina or its story. Thankfully, it has not been made ‘perfect’. This was a Bugatti works car
of 1,991cc supercharged, and the spare team car, chassis #4423 (originally 4899 but over-stamped by the factory), which still holds the hill-climb record at Prescott and is still used on public
roads despite being worth millions.
151
Visually, the single fuel cap looks good, but later cars had twin fuel caps (one to fill, the other to inspect the contents level?) and some earlier cars have
been retrofitted with them as well (Fig.).

Fig. - Twin filler caps were not unique to the Type 51 and some Type 35s were retro fitted with them.

Cars (T35B) with the larger 330mm brake drums, more power and bigger wheels, featured an extra leaf (inverted) as a stiffener in the spring and these are
clipped over at the rear, not just at the front (Fig.).

Fig. – (left) Vital suspension and brake design elements of the Type 35 series. (right) Later cars had the leaf springs clipped at both ends.

Other notable developments to the cars included extra fairings being added over the open cockpit, carrying straps for bags and extra spare wheels were also
added. Headlamps, tail lamps and even a map reading lamp could all be fitted.
The Michelin tyres were also substituted and today Engelbert tyres often appear on Type 35s, as do those of other tyres manufacturers.
152
Hillclimb variants are uncommon too (Fig.).

Fig. - A very rare example of twin-rear wheels fitted (for extra traction) to a Type 35 series. Also seen on the later Type 50/59B of Wimille. The Scuderia Lemon Burton was well known
in British Bugatti racing. (Photo: Bugatti Owners’ Club)

(wip)

153
2.3.5 – COORDINATE SYSTEM: THE VEHICLE IN THE 3D SPACE
Let’s see where you should draw your model in the virtual space of your modelling software. The reference point is the origin of the scene (or world) here,
so make sure that the three axis, X (red), Y (green), and Z (blue) are always displayed. Blender shows a horizontal grid along with the axis by default.
Pro tip: Assetto Corsa does not have limits regarding the location and orientation of the vehicle geometry in the 3D space: on the graphics side everything can be adjusted with
distance and rotation offsets, specified in the data files of the mod, but from the point of view of physics things are a bit different: all the coordinates have a pre-determined
“starting point”, determined by the CG (Centre of Gravity) of the vehicle.

This origin (that we will explain going forward) specifies which is the
“forward”, “up” and “lateral” direction respectively, so we are limited by it.
In other words, we must align the car correctly if we want everything to
work as intended. In the event that such ruling is not adhered to, we may
be able to fix the model further down the road, but everything else (car
dynamics-wise) will be a complete disaster that could drive you crazy
(imagine having the front suspension in place of the rear one, but
mirrored longitudinally, or having the entire physics compartment
sideways).
In order to keep your mental sanity, a very good practice, recommended
by the game developers, is to position the car as shown in Fig. 2.10: the
Z axis must portray the forward direction.

Fig. 2.10 – 3D model origin of the Abarth 500 EsseEsse by Kunos.

You can either start modeling the car aligned like that from the beginning, or work with the default convention of the axes in your 3D editor (x, y, z), but the
important step is to make sure the model adopts a Z-forward, Y-up reference system when exporting to the FBX format (see Fig. Blender export).
The vehicle model’s bounding box must be centred in (X, Y, Z) = (0, 0, 0) in your 3D editor. Make sure that the wheels are touching ground on the Z=0
coordinate. It will give you an easier time when working on the physics, especially suspension linkages, center of mass location and inertia. Otherwise, if the
wheels don’t touch the ground, graphics offsets (see ) will become essential. Below we have other rules.
• The measurement units must be meters, in other words 1 unit = 1m.
• The 4 different LODs (pag.) must share the same position and orientation.
• Pay attention to the scale of your objects: it must be set to 1, otherwise you may get bigger or smaller objects, portrayed in Fig. . This implies “applying” the scale (Blender)
or setting it to 100% (3DsMax).

Fig. – …Yeah. Newbies make pretty cursed stuff. The car on the top left corner is mine, back when I started my own experience.

You can find an example model, TEMPLATE_CAR_demo_V1.fbx under %root%\sdk\dev\car-pipeline-1.03 folder, but it’s quite old.

154
2.3.6 - MODEL BUDGETS
According to the original Kunos pipeline 2.0, the ~_lod_A.kn5 model (fully detailed, see par.) of an official car must stay below 44 MB, including all textures
and meshes.
I would say a 70-80 MB .kn5 is still fairly reasonable for modern hardware. In any case, the textures have to be very well optimized. You won’t get the
model below 50 MB without compressing most of the textures.
It's probably reasonable to go up to 50% past the official suggestions on poly count (those in the KP 2.0), but then on the release mention that the mod is
going to perform worse than the vanilla content (e.g. lower framerate).

2.4 – MESHES: THE FUNDAMENTAL PARTS OF A VEHICLE

A vehicle must be divided in many components in order to manage static, moving, animated objects and other features present in game.

Static parts are the chassis, the body, all the bolted/welded/riveted panels that do not move whatsoever (including the dashboard), and the car upholstery.
Pro tip: Few static parts can become moving parts, for example a bumper upon impact. This behaviour is part of the basic damage model in AC.

Moving and animated are two different concepts: for example, wheels are moving (rotating due to physics), while wipers are animated (by hand).

With the next paragraphs we will explore the methods that can be applied for the creation of vehicle components, going for the maximum quality and
performance of our assets.

2.4.1 – RULES FOR MESHES / 3D OBJECTS in AC

At paragraph 2.4.2 you will find a list of names for visual meshes (= objects). Those “labels” are suggested and recommended in order to avoid any trouble
identifying common objects in your model. You can use the following guidelines to name your vehicle parts without encountering problems later on.
1. Single objects must not exceed a total of 65.536 (65k) VERTICES. Anything above that number will not be opened by ksEditor (which may crash). The same limit applies
to faces, but you will almost always hit vertices limit first. This does not influence the budget for the entire model; we will talk about that one later, (with respect to
triangles, not vertices) at par.
2. The AC engine does not support 2 OBJECTS with the same NAME in the same model. This will likely cause the game to crash (due to standard model encryption, more
about it later). While Blender adds a progressive number to objects with the same name by default, 3DsMax allows the use of duplicate names, so pay attention to it.
3. Be consistent in naming meshes within your scene. When you have multiple LODs in the same scene, make sure you keep the same names for functional objects (lights
and emissive, etc.) and dummies throughout the entire scene for all LODs (details about LODs in 2.F) to ensure that the game scripts work as intended for each one of
them. However there must not be matching names inside the same export (within ~LOD_A.fbx for example).
4. Do not use spaces: underscore has to replace those in the labels (Fig. 2.11).
5. Use lower case text; empties/dummies require upper case text, so this trick will let you avoid misunderstandings and confusion. This also implies that you mustn’t name
objects the same as the dummies.
6. If you make groups/parents of meshes, you can add a number like this: wiper_1, wiper_2 and so on. The numbers can be added also if you have multiple objects of the
same kind (window_glass_1, window_glass_2, etc.).
7. The names can be anything (within these rules). In theory, if you respect the dummy hierarchy we’ll introduce later (2.C), you can even name your front tires Johannes
and Johanna, but what’s the point? I don’t want to imagine the end of those poor fellas.
8. You can use a prefix like EXT_ (for car exterior body parts) or INT_ (for interior objects), to differentiate them from NULLs. The Kunos pipeline suggests to use prefixes
such as MESH_ or GEO_. Those can work well too.
Avoid long names and prefixes life VISUAL_ for the objects (Fig. 2.11), they are just a futile complication, a shorter prefix and lower-case text is enough. (check)
9. You may not need all the objects in par. 2.4.2, it depends on the car you’re making the mod of, but the main ones are usually required.
10. The names in par. 2.4.2 begin with a capital letter; you can avoid using it, just type the whole text in lowercase (like in Fig. 2.11, if you remove the prefixes).

Fig. 2.11 – Don’t use long prefixes and names like this; the simpler the better. It helps to keep things tidy. The scene hierarchy and the model in this example are incomplete.

155
2.4.2 – LIST OF STANDARD AC VEHICLE PARTS
For starters, below we have a list of the most common parts you can find in a vehicle (modelled for AC). More details about them will be in the paragraphs
that will follow.

VEHICLE PARTS:
Main_body ; also called BODY; must be present in LOD A and LOD B.

% ▲ Everything that will be under the main body mesh will be static and attached together like a brick.

Doors ; only in LOD A (with animations), if present on the car. In LOD B the doors are welded to Main Body.

% ▲ Use Door_right (driver side) and Door_left (passenger side) as names. An animation for each one of them is required, don’t
make a single animation for 2 doors.

% ▲ Mandatory names of the exported door animations are: car_door_L.fbx and car_door_R.fbx.

Windscreen
Motorhood ; also called Hood or Bonnet; must be present in LOD A and B.
Exhaust
Trunk ; also called Boot; must be present in LOD A and B.
Front_bumper ; must be present in LOD A and B.
Rear_bumper ; must be present in LOD A and B.
Wheel_hub_# ; also called simply Hub, contains the brake calipers, must be present on LOD A and B.

% ▲ You can change the name from wheel to wheel adding its position: Wheel_Hub_RF (right front wheel), ‘’_Hub_LR (left rear
wheel), ‘’_LF, ‘’RR.

Wheel_rim_# ; you can call it Rim; it must be present in LOD A and B. In LOD C the wheels are simplified.

% ▲ You can apply the same naming rule seen with Hubs for rims: Wheel_Rim_RF, Rim_LR, and so on.
% ▼ Use the same method for blurred rims (Rim_Blur_RF_mesh), tires (Tire_LR_mesh) and brake discs (Brake_disc_mesh).

Rim_blur_# ; it’s a low poly version of the rim with a blurred texture; must be present in LOD A and LOD B.

% ▲ 2500 triangles for blurred rims should be the reference. There’s no point in making blurred parts high poly.
% For different wheels use the suffixes for the corners of the car (LF left front, RF right front, RR right rear, LR left rear)

Tire_# ; must be present in LOD A and B. In LOD C the wheels are simplified.

% ▲▼ Like wheels and rims, use the suffixes LF, RF, RR, LR.

Brake_disc_# ; sometimes they’re called Disco, which is the Italian word for disc. Must be present in LOD A and B.
Caliper_#
% ▲ Like wheels, use the suffixes LF, RF, RR, LR.

Front_light ; you can call them also Headlight, Light, etc.; must be present in LOD A, B and C.
Rear_light ; you can call them also Tail_light, Brake_light; must be present in LOD A, B and C.
Reflector
Wipers ; must be present in LOD A, B and C.

Front_wing ; splitter. must be present in LOD A, B and C.

Rear_wing ; spoiler. must be present in LOD A, B and C.

Diffuser
- STEER_PADDLE ; must be present also in Low Resolution (LR) and LOD B.

- SHIFT ; must be present also in Low Resolution (LR) and LOD B.

- Arrow ;
- Seatbelts ; to be included not only in COCPIT_HR, but also in Low Resolution (LR), LOD B and LOD C.

156
2.5 – MODELING SUGGESTIONS (wip)

2.5.2 -

2.5.3 - TIRES
Do not draw the tyre grooves, as it would require too many polygons. Keep the tread almost flat (a bit curved because you may want to represent the flexion
due to inflation pressure) and use normal textures for grooves. Below you can see the correct way to make your tyres (Fig. 2.12 & 2.13 & 2.14).
Be aware that since the source files of official content aren’t publicly available, the models in the pictures (Fig. 2.12 & 2.13 & 2.14 & 2.15) are triangulated
as a consequence of the export to the .kn5 format.
Fig. 2.15 instead shows what you should not do, which is keeping the grooves as a 3D modeled mesh in the final product.
3D modeling the tread is useful, as you can bake it to the diffuse and normal textures. This can actually be a very good technique if you want to create
detailed, high quality patterns on your tex. See par. for more details.

Fig. 2.12 – Front tire of Ferrari 312/67 by Kunos: the mesh doesn’t have any drawn groove. This tire has 40 outer sides, and some are highlighted.

Fig. 2.13 – Front tire of Ford GT40 by Kunos. Same story, with a different tread pattern. The tread effect is given by normal textures. This tire has 48 outer sides.

Fig. 2.14 – Front tire of Alfa Romeo Giulia Quadrifoglio by Kunos. This tire has got 80 outer sides. I think you got the point.

157
Fig. 2.15 – The perfect example of what NOT to do. The tread has been kept with every single groove modeled in the final product.

An exception are Formula 1 tires (Fig.), for which the grooves (if present) are very simple and give more depth to the rubber. Normal tex are used anyway.
The same applies to offroad tires, where it’s necessary to add some detail on the outer edges, just to make the lugs noticeable from a 3/4 view, or in case
they are very exposed, try to keep the poly count low if you really want to model the entire tread (Fig.).

Fig. – (left) Example of a Formula one tire model in 3DsMax. (right) This offroad tire is made of around 9000 triangles.

Examples of good and bad topology on the wheels

sdfsfda

158
Fig. – (top) This 3D wheel for a Tyrrell P34 has a poor topology, even if the geometry is entirely in quads: the tire and the rim are not aligned well (see the red arrows). The numbers
give an idea of how many sides you may use before subdivision. (bottom) Subdividing the surface doesn’t hide nor solve the problem, since a visible gap is created (highlighted in the
yellow zone); moreover, the modifier has increased too much the number of polygons on the rim. These issues can be fixed however.

2.5.4 – VEHICLE LIGHTS

Each car must have individual objects. The light mesh objects must be separated and detached from the body of the car and use specific naming
conventions. The mesh name must be controlled from the lights.ini script. The same scripts include the instructions for the ON/OFF conditions, as well as
the light emission colour.

The mesh of the light is made from different parts, which are divided according to their function (Fig. ).

Fig. – Example of light meshes

Some examples: Position lights, brake, rear, standard front lights, high beams etc.

159
There is no need to split the lights up as “right” and “left”. They can be one mesh because they turn on together. This is important to reduce the number of
separate objects of your model.

Please do an extensive research about light functionality, and strive to implement as many functions as possible. Each light source must be detached as a
separate object, avoid keeping all the different reflectors and bulbs in one object. This way, each element can be controlled individually to achieve realistic
results. A good example is shown in the image below:

2.5.5 - COCKPIT PARTS

(for more info about cockpit LODs, par.)

- Cockpit_hires ; high resolution cockpit mesh(es), the one(s) you see in cockpit view.

Cockpit_hires doesn’t need to be one object, and most of the times it consists of the dash, the seats, the interiors of the car basically. Every mesh of the
interiors must be linked as a child of the NULL COCKPIT_HR (par.). Keep in mind that a low resolution (LR) version of the interiors is required for
optimization purposes (see Cockpit_lowres below).

- Cockpit_lowres ; low resolution cockpit mesh(es), the one(s) you see from far outside the vehicle.

Cockpit_lowres can and should be made of the smallest number of meshes and materials possible, to keep the object count low (and so the number of
draw calls); it has to be included and linked as a child of the COCKPIT_LR dummy (par.), and included in LOD A, B and C. It is not required for LOD D and
would only add unnecessary complexity (it would not be visible anyway from that far).

- Steer ; steering wheel HR and LR interior, LOD B and LOD C.

SEATBELTS
The interiors can have two different mesh objects for the seatbelts: one for the belt ON and another for the belt OFF (Fig.).

Fig. –

They must be linked as a child of the COCKPIT_HR empty (see par.) and must be named as follows:

CINTURE_ON for the belt on the driver when is driving,

CINTURE_OFF for the belt on the seat, without driver (showroom view).

160
The names are in Italian (CINTURE = SEATBELT).

For LOD A, both ON and OFF positions are REQUIRED (COCKPIT_HR and COCKPIT_LR). For LOD B & C only the ON position model is needed.
Also keep in mind that the ON/OFF positions are needed only for the driver seat, not for the passenger seat.
Pro tip: For COCKPIT_LR you only have to show the low-poly seatbelts on the driver, without the need to separate them from the rest of the cockpit mesh.

To create the proper mesh of the belt on a driver, place the driver first, then animate it and verify how the arms move in order to avoid interpenetration with
the belt mesh (Fig.).

2.5.6 – BAKING DETAILS TO NORMAL TEXTURES

The idea is that small and very complex vehicle surfaces can be created with whatever detail you wish at first, basically very high-poly, but then later all of
the tiniest surface features are converted into a normal map, based of that high resolution geometry.

You are basically “projecting” the 3D wrinkles, hollows/concavities and grooves of the surface onto a 2D texture. The term that defines this procedure is
“baking”.

It is very useful for tires and headlights, where you have many small details that would destroy the graphics performance otherwise.

Let’s see how you can do it with 3DsMax.

I built the part I need from a top-down perspective and perfectly flat, as if they had been unwrapped onto a flat surface. Here is an example of a front
headlight modeled in such a way.

Fig. -

Once you have finished your model create a camera and place it directly above the model. Make sure to set it to Orthographic projection to avoid and
distortion.

Then open the Render Dialog window and adjust the resolution so you have a square image with an aspect ratio of 1.0

Turn on safe frame to correctly view your model and adjust the camera position till your model fits nicely in the frame.

You will need to download a plugin for this next part. You can get it from here- http://www.scriptspot.com/3ds-max/scripts/normaltexmap
Once you have the script close max and place it in Autodesk/3ds Max 2013/stdplugs/stdscripts
Restart max and you should have the script installed. Create a new standard material and assign the NormalTexMap under the materials diffuse slot. Set the
materials self illumination to 100, then assign the material to your model.

161
Next open up the environment settings under the rendering tab and set the color to the below values.

That should be it. Now if you render you model from the camera it should look something like Fig. left. The normal map obtained shall be added to your car
model’s texture atlas (UV map). See Fig. right in this example.

Fig. -

162
Once you have your texture put together and saved out as either a .png or .dds time to apply to a material (I'm using .jpg for now, I'll convert later).

Add a Normal Bump texture under the Bump slot. In the Normal Bump texture add a Bitmap and select you Normal texture.

This part is just 3DS max specific but if you want you can configure your display diver to better display the texture on your model.

163
Now assign your material to your object and when you render you should get something like this.

Now we have a low poly object that looks high poly. There are other ways of doing normal maps but this is my favorite method. Here are some more
examples of models to give an idea how they were made.

In Blender things are quite easier: you need to set up the Render options correctly, then

Here we have an example of how you can create tires for your car (Fig.).

164
Fig. – (top left) the profile of the tire modeled in all its details. (top right) The whole tire created with an Array modifier. (bottom) After baking, the tread has become a normal map.

165
INTERNAL WINDSCREEN AND DOOR GLASS REFLECTION (move to tex)
A specific shader is used for the internal of the cars, made specifically to emulate the sun reflection effect when the surface is not completely clear. This
effect can be increased or reduced by editing the glass texture provided.

The shader to apply at the internal glass is KsWindscreen.

NOTE: the internal GLASS must be not part of the cockpit HR.

Internal GLASS objects on the doors must be linked to the appropriate EXTERIOR door nulls. When the cockpit LR switches, the internal glass must remain
visible on the LOD A.

Shader parameters are shown in the image.

An example of the shader effect is shown here.

The texture for the INTERNAL GLASS must be saved in DDS and it must have an alpha channel and the following layout.

166
The left image shows the diffuse of the glass texture. The right image shows the alpha channel.
A soft shadow of the cockpit dashboard is painted on top of the texture. This trick allows an emulation of the internal reflection of the dashboard on the
glass when the sun is in front of the car.
Note: The internal glass mesh is just a copy ot the external polygons of the glass, but it should have the normals pointing to the interior. Do likewise for all
the internal windows.

DAMAGED GLASS (move to tex/ dummies)

The car can have 2 kinds of damage: damage to glass objects and the body.
For the glass we have to do the following:
Duplicate the glass object, assign to it a new material and map it using the texture you can find in the Texture common folder called Glass_Crack_00.psd.
Then, move it away (0.5mm or less) from the original glass to avoid clipping. See here:1

Try to map the glass approximately as shown here (at least for the front windscreen), because the broken glass must allow the driver to see the road in the
game.

167
The cracks must be more visible in the corners and less so in the center (see image above).
You can map other glass objects on a different area in UV, such as the bottom part. Use the radial or fragmented cracks depending on the shape of the
object.

Radial is good for rounded headlight glass, while the fragmented pattern is usually used for square-shaped headlights or side windows. You can see an
example for the side glass: Note that we taken also the mirror glass, because it part of the glass objects that can be broken during side impacts.
Once you have extracted your glass damage mesh you must place them under the appropriate nulls that use the following naming conventions. NOTE: the
numbers must always be present.
DAMAGE_GLASS_CENTER_1 central glass, usually windscreen
DAMAGE_GLASS_FRONT_1 front headlight glass or similar
DAMAGE_GLASS_REAR_1 rear/brake light glass or similar
DAMAGE_GLASS_LEFT_1 left side windows of the door and near
DAMAGE_GLASS_RIGHT_1 right side windows of the door and near

Above you can see an example for how to separate damage glass parts.
For the windows you usually have to create more than one object. The same can happen when there are glass objects on the main body as well as on the
front bumper. In this case, you can create a new dummy/null and call it DAMAGE_GLASS_FRONT_2. Place this dummy/null as the child of the
FRONT_BUMPER null to force the broken front bumper light glass to move along with the FRONT_BUMPER object. Do the same for other glass objects
located on various moving parts.
You can create as many damage_glass nulls as objects as you need. (for better optimization, use as few as possible….)
Once you have created, UV mapped and linked the objects, you must assign the proper material with the parameter indicated in the image.

168
Every object of damage glass must be set TRANSPARENT under the object settings and must not cast shadows.
As the diffuse and normal map we must apply a PROXY TEXTURE. The Proxy texture is a placeholder texture that substitutes the texture that the game loads
automatically from a common folder.
For txDIFFUSE use the DDS named DAMAGE_GLASS_color.dds in the Common Texture folder

For txNORMAL use the DDS named DAMAGE_GLASS.dds in the CommonTexture folder

After you have set up the material, you must change the draw priority. Select every DAMAGE_GLASS dummy/null (not the object!) and set the priority to -2
and press REORDER.

You can check if the damage glass works correctly by pressing the appropriate button in the editor.

169
The shortcut to see DAMAGE GLASS in the editor is F4.
In the editor you should see the DAMAGE glass as in the image below:

For naming the mesh objects, use a naming convention that is easy to follow, such as MESH_DAMAGE_GLASS_FRONT_1 etc.

DAMAGEABLE PARTS / CAR BODY DAMAGE

Certain body parts must be detached and placed under a NULL that acts like a pivot/center of rotation for the element when it receives damage. Upon
impact, a script is activated that makes the parts vibrate/rotate on the basis of the location and pivot of these nulls. We’ll see which are the empties we’re
talking about later.
Keep the nulls and also these parts separate in LOD B. In LOD C, the elements can be attached to the main body and they do not have to be movable. If the
damaged parts are significant in size (massive front and rear wings on formula cars, you can keep the most important items on the LOD C to make sure
there is no visible LOD switch when the car is damaged.
Use the following guidelines:
1. Make sure that you have closed the mesh in the interior. You put a black texture or something very dark to ensure that there is no gaping hole behind the moving objects.
2. Place the dummy/null in the rotation point that is logical for the part. For the MOTORHOOD it can be the hinges, for a FRONT_BUMPER it can be a point that allows
rotation but avoiding any intersection with the main body mesh.
3. Detach parts only that don’t leave holes in the car when moving, or carefully cap the holes.

Parts that take damage may be:

Front bumper, rear bumper, front and rear hood, exhaust, wing and the extractor (diffuser) on various GT cars etc.

It depends on the model at hand. After the parts are done, you must set up the material properly and edit a script.

170
Damage needs 4 different textures to work properly:
The damage feature to work properly you need the following textures: DAMAGE_NORMAL map, DAMAGE_SCRATCHES map, a DUST map and a
DAMAGE_MASK map.
The DAMAGE MASK must be called DAMAGE_Mask.dds and must be created in the following way:

171
The WHITE part indicates the front of the car (painted in the alpha channel), the RED the left-hand side, the BLUE the right-hand side, and the GREEN the
rear of the car. We use this mask to control which areas are affected by the damage. The mask must be painted as shown here:

Remember to blend the colors, do NOT create sharp transitions. Never paint the roof and the top of the bonnet.

Assign this texture to the slot txDamageMask

Resolution must be 512x512 pixels and the texture can be exported as DXT5.
For the NORMAL MAP texture we must create a normal map with the metal deformation as shown in the example.

172
You can use your preferred tool, such as Mudbox, Zbrush, or anything else you’re familiar with.

Look at the example: in the alpha channel you must paint the part of the chassis with scratches, which becomes less reflective, to visualize better the
wrecked appearance.

This texture must be assigned to the slot called txNormal.

Texture must be done in DXT5 and size can be 512X512 pixels.
For the DAMAGE SCRATCHES texture you must paint a texture that, working along with the normal map, shows scratches and damage on the surface. Have
a look at example image.

173
The scratches appear in front of a red background here but in the texture use a grey background shown in the texture example below.
The scratches on the edges must have a highlight and they must be visible on the sides, too.
Scratches appear over the car paint texture so the texture needs an alpha channel to use as a mask for opacity.

This texture must be assigned to the slot called txDamage.

The texture must be exported as DXT5 and the size must be 2048x2048 pixels.

The last texture is the DUST texture that shows dirt on the car after driving off-road. We must draw a dust layer to visualize dry dust.
Texture must be done in DXT5 and size must be 2048x2048 pixels or 1024x1024 if the car is heavy on textures.
This texture must be placed in the slot called txDust.

174
To visualize the global effect of the damage you can use the show damage button in editor:

175
FUNCTIONAL ELEMENTS: LEDs and DIGITAL DISPLAYS
It is possible to have various LEDs and indicators lighting up in the cockpit (usually on the dashboard, Fig.) while driving. It is recommended to make the
cockpit dynamic with as many functional items as possible.
It is very important that you do extensive research about dashboard functionality and digital screens (if present) and prepare the model for dynamic displays.

Fig. – An example of a digital panel for a GT racing car.

Below we have the list of all the functions supported by the game engine (vanilla), separated depending on which script they are configurated into.

Digital instruments functions:

• Speedometer
• Current Gear
• Current Gear (color change)
• RPM
• Any RPM-dependent status indicator
• Tachometer
• Tacho Limiter
• Fuel level (bar graph)
• Fuel level (litres)
• Fuel economy (km with current fuel left)
• Fuel warning light/LED
• Estimated fuel
• Headlight indicator
• Ambient temperature
• Water temperature
• Current timing
• Time of day (clock)

176
• Lap time (current)
• Lap time (last)
• Delta (difference from previous lap)
• Total laps
• ABS level
• TCS level
• G-Force meter
• Max Speed
• Max RPM
• LED single RPM value
• LED Delta bicolor
• LED single Fuel value
• Tire pressure
• Turbo boost (bar graph)
• Turbo boost (pressure)
• KERS charge - battery level % (bar graph)
• KERS charge readout (number)
• KERS input (bar graph)
• KERS usage - amount of energy used
• KERS max usage per lap
• DRS LED warning
• DRS On/Off LED
• DRS level - wing °
• Gear change indicator
• Placeholder script for any static text or numbers
• Other

Each individual LED (such as for RPM, boost or KERS) or bar TAG must be a separate object and numbered in a series:

LED_RPM_#
TAG_RPM_#
KERS_CHARGE_#
KERS_INPUT_#
TURBO_#
% ▲ Where the hashtag (#) is the number of each specific item in a series.

Some cars have multiple displays and it is possible that certain items (such as RPM) are shown in more than one screen. In this case, make sure that you
differentiate between the two readouts: LED_RPM_1_# and LED_RPM_2_# etc.
For functional LEDs or warning lights, each item must be a separate object, using the following naming conventions:

LED_LIGHT ; Headlight indicator light

LED_FUEL ; Fuel warning light
LED_KERS ; KERS status light
LED_IGNITION ; Ignition status light

There are two ways to control specific items on the dashboard.

The first one is where the mesh is always present and the script controls the emissive value on a per object basis. This is the method used for RPM LED
series, headlight indicators and ignition status lights.

177
With the second method the mesh is disabled by default and the script controls how and when it should appear with the shader and object properties set up
in the editor. It should be noted that the meshes appear in the editor and the showroom. This is used for dynamic RPM bar graphs, boost bar graphs, fuel
level bars, shift indicators, fuel warning lights and KERS bar graphs.

NOTE: If in the second case the item is a light with emissive values, it must also use an individual material with the desired emissive
value set in the editor (e.g. fuel warning light).

When creating the texture for the digital display, you must take into consideration the dynamic readouts that are supported by the engine and must not
include them in the static diffuse texture.

NOTE: Do NOT use the convention _01, _02, _03 etc. for single digits for the suffix of tag object names, always use _0, _1, _2 etc. E.g.
LED_RPM_0, LED_RPM_1 etc.

IMPORTANT: If there is a digital display, create a NULL called DISPLAY_DATA with the orientation shown in the image below. If there
are more displays, use a serial number (DISPLAY_DATA_1 etc.) to specify each individual screen. The DISPLAY_DATA null is the
reference for the items in the digital_instruments.ini, it serves as a reference point and makes sure the text appears on the same
surface as the display. For this reason if the display is rotated/tilted, the null must follow the same orientation. To avoid clipping, place
the null so that its pivot point is in front of the mesh by a few millimetres and not directly on it.

Fig. - DISPLAY_DATA null orientation and example for KERS bar graph (3DsMax).

NOTE: When the display is located on the steering wheel, the DISPLAY_DATA null and all the TAG/RPM mesh objects must be a child of
the STEER_HR null to make sure they rotate along with the steering wheel.

178
DIGITAL PANELS

Digital panels can be used for two functions: Push-to-Pass status and on-track Position. This feature requires a digital_panels.ini in the car’s data folder and
pre-drawn numbers textures in a your_car_name/texture/display_panel folder that you’ll have to create. As an example, take a look at the
content/cars/ks_audi_tt_cup/texture folder in your game install folder.
You will also need a parent NULL (e.g. DISPLAY_PANEL), with the same orientation rules that exist for the digital instruments (see above).
For the explanations of the Push-to-Pass and Position functions, see the digital_panels.ini config file at pag.

179
2.7 – SKINNED MESHES
FBX skinned mesh objects are supported by the game engine. Skinned objects can have as many bones as necessary but no more than 4 bones influencing
a single vertex.

A good example of skinned mesh is the driver (explained later) or the gearshift lever with a fabric skirt at the base of the lever (Fig.).

Fig. - This example shows what kind of things you can do with skinned meshes.

2.7.1 - RULES FOR THE CREATION OF A SKINNED MESH

1. All vertices must be influenced by at least one bone. If a vertex is not influenced by a bone, its world coordinates will be 0,0,0, resulting in a long polygon that spawns
from the center of the 3D world to your space position.
2. A non-skinned object can be linked with a skinned mesh. Connect the non-skinned object as a child of the skinned mesh. In the above image, the skin has 2 bones but
the handle is a parent of the non-skinned yellow null.
3. Every material with a skin rig must be unique. A material cannot be used on a standard mesh and at the same time on a skinned mesh. Two different materials must be
created, one for the standard mesh and another one for the skinned mesh.
4. The skinned-mesh dedicated shader must be KsSkinnedMesh or the KsSkinnedMesh_NMDetail. The animation works only when the skinned shader is assigned to the
skinned mesh.
5. The skinned mesh must have the pivot in the 0.0.0 coordinates of the world. It can be child of another dummy, but this dummy must also have the coordinates of 0.0.0.

We usually put the skinned mesh of the gearshift or something else in the cockpit as the child of the cockpit dummy/null. And the cockpit Dummy/null is
usually in the 0.0.0 coordinates. Or you can simply leave the mesh free without linking it to any node.

NOTE: Do not use this shader on a standard mesh without bones. Avoid using skinned mesh on suspension parts! For
springs and rubber parts use scale animation.

180
2.8 – NULLs & SCENE STRUCTURE
After you drew your model from scratch or you converted it and now it’s ready to be used in your 3D modelling software, you labeled the objects (=meshes)
to distinguish them; now, if you remember what was written in the INTRODUCTION about the empties/NULLs/helpers, you must create an interface between
the visuals and the functions of your vehicle.

To recap:

NULLs are objects; they’re called dummies in case of 3Ds Max, transforms / locators in case of Maya, helpers in case of Blender (Fig.).

Fig. – A really basic set of helpers in Blender, to begin working on the vehicle.

These are objects that act like "empty" objects (hence the name empties), and what you really care about is their name, position and orientation. The visual
meshes are parented to them in most cases.

During this phase, placing and naming dummies correctly will be the key to success. In order to work in-game, the car needs specific NULLs to be present
in all the LODs, so it’s important to make sure that all car parts are functioning properly.

2.8.1 – RULES
1. Make sure to set up the system units BEFORE creating the dummies and exporting the car (about the export process later).
2. All dummies must have Z-axis pointing forward and Y-up (Fig.).

Fig. -

3. Remember that every NULL is also a possible center of rotation (pivot point). The pivot point of the dummy must be identical to pivot of child mesh (or vice-versa). If a
rotating mesh is not properly placed under a NULL with a correct center of rotation, the mesh will rotate the wrong way. See Fig.: the geometry of the wheel is centred
exactly on the helper.
4. Each dummy can contain multiple objects. An example scene is provided in the folder (nnnghhHHHH) with a folder structure and hierarchy to follow (Scene
templates/scene_nosuspanim_example_max).
5. Make sure you keep only one set of helpers in your scene and that you use a clear layer structure to hide/unhide layers for exporting various LODs (see example scene).
6. When we use NULLs the names are a key factor, so always respect them. This time you MUST use uppercase/capital letters (CAPS).
7. Never scale the nodes once created. Doesn't matter what size they are, but scaling them afterwards can cause all sorts of issues. (just ‘applying’ the scale in Blender
works? check)

181
2.8.2 – THE EMPTIES REQUIRED (location/position!)
Below you have all the dummies you need to create a vehicle mod in vanilla AC. For CSP additional objects, later.

MAIN NULLs:
The following main empties must be present in all LODs (except where it’s specified otherwise).

- NULLs that control the wheels (1 null for each wheel; LF stands for Left Front, RR for Right Rear, etc):
WHEEL_RF ; Right Front wheel.
WHEEL_LF ; Left Front wheel.
WHEEL_RR ; Right Rear wheel.
WHEEL_LR ; Left Rear wheel.

Position: pivot points of the respective wheels. Each one is parent of the respective TYRE_#, RIM_# and RIM_BLUR_# empties.
These dummies are removed from the car during pit-stops (if you change the tires).

- Dummies controlling the suspended parts which do not rotate but should steer according to the wheels, for example the brake calipers (one dummy for
each suspension of our car):
SUSP_RF ; Right Front suspended parts.
SUSP_LF ; Left Front suspended parts.
SUSP_RR ; Right Rear suspension.
SUSP_LR ; Left Rear suspension.

Position: pivot points of the respective wheels, identical to the WHEEL_# dummies. Avoid placing these empties anywhere else, otherwise you will have to play with the
offsets in suspensions.ini.

- Empties that manage brake discs (one for each corner of the vehicle):
DISC_RF ; Right Front Brake disc.
DISC_LF ; Left Front Brake disc.
DISC_RR ; Right Rear Brake disc.
DISC_LR ; Left Rear Brake disc.

Position: pivot points of the respective discs, MUST BE THE SAME as the wheels’ pivots. These dummies rotate according to the wheels, and are NOT removed from the car
during pit-stops.

- Helpers that control high (HR) and low (LR) resolution interior LODs (go to section for more info):
COCKPIT_HR ; High Resolution cockpit node. (LOD A only)
STEER_HR ; High resolution steering wheel node. (LOD A only)

Position: It doesn’t really matter where you place the COCKPIT_HR dummy. Just keep it inside the car. The steering wheel instead rotates around the STEER_HR dummy's Z
axis. Place the latter accordingly then (Fig.).

Fig. – Example of a STEER_HR empty placed correctly in Blender. Be aware that to display the NULL’s orientation correctly, the Transform Orientations must be set to Local, not Global.

COCKPIT_LR ; Low resolution cockpit node.

STEER_LR ; Low resolution steering wheel node.

Position: identical to COCKPIT_HR and STEER_HR.

182
SECONDARY NULLs:
These dummies are required to complete the car, but are not essential, and their presence is limited to LODs A and B only:

RIM_RF ; Right Front Rim.

RIM_LF ; Left Front Rim.
RIM_RR ; Right Rear Rim.
RIM_LR ; Left Rear Rim.
RIM_BLUR_RF ; Blurred Right Front Rim.
RIM_BLUR_LF ; Blurred Left Front Rim.
RIM_BLUR_RR ; Blurred Right Rear Rim.
RIM_BLUR_LR ; Blurred Left Rear Rim.
TYRE_RF ; Right Front Tire. (highly optional)
TYRE_LF ; Left Front Tire. (highly optional)
TYRE_RR ; Right Rear Tire. (highly optional)
TYRE_LR ; Left Rear Tire. (highly optional)

Position: pivot points of the wheels, identical to the WHEEL_# dummies.

Pro tip: Every secondary NULL shall be child of the respective WHEEL_# empty. Also, the RIM_BLUR_# empties can cause conflicts with the lods.ini data file, if the latter is
not properly set (e.g., if the NULLs are present in the script but missing in the 3D model). For a lengthy explanation of the rim blurring effect in AC, see p..

NULLs FOR ANALOG INSTRUMENTS:

To animate a needle on the dashboard, the arrow_# meshes (see p.) need to be placed under the following empties:
ARROW_SPEED ; Arrow for the speedometer.
ARROW_RPM ; Arrow for the engine tachometer, also called rev (=revolution) counter.
ARROW_TURBO ; Arrow for the turbo pressure.
ARROW_FUEL ; Arrow for the fuel level.
ARROW_WATER_TEMP ; Arrow for the engine water temperature.
ARROW_TIME ; Arrow for the car clock.
ARROW_LIMITER ; Arrow for the engine max RPM.

The ARROW_LIMITER is a tell-tale found for example in the Lotus 49 and Lotus 72D cars, showing the maximum RPM in a given stint. The rotation of the ARROW_LIMITER
null must be the same as the ARROW_RPM null, and it requires NO script, as it is controlled from within the core engine. See analog_instruments.ini (p.) for more details.

Each ARROW_ node must be linked to (child of) the COCKPIT_HR helper.

The needle mesh must be created in neutral position and linked as child of a specific null. The arrow must then be rotated to the 0 position as shown in
Fig.. The Y axis determines the arrow position on the gauge and must be placed at 0 (ZERO) or the start of the gauge at hand. The Z axis of the node must
always point FORWARD.

Fig. – Proper placement of the ARROW_# dummies (Autodesk Softimage, similar to 3DsMax).

Every instrument is controlled by specific values in the analog_instruments.ini script, located inside the your_car_name/data folder. You can use the Data
Scripts tab in ksEditor to set up the analogue scripts (see EDITOR section).

To ensure compatibility in the future, if present, set up gauges that are currently not supported by the engine in a similar fashion, with name conventions
that are consistent with the existing rules and the function of the instrument:

ARROW_VOLTAGE
ARROW_OIL_TEMP
ARROW_OIL_PRES
ARROW_FUEL_PRES
ARROW_WATER_PRES
183
NULLs FOR DIGITAL INSTRUMENTS AND DISPLAYS:
DISPLAY_DATA
DISPLAY_CLOCK
DISPLAY_RPM
DISPLAY_SPEED
DISPLAY_TEMP

NULLS FOR THE BROKEN GLASS MESHES:

DAMAGE_GLASS_CENTER_1 ; (A and B)
DAMAGE_GLASS_FRONT_1 ; (A and B)
DAMAGE_GLASS_REAR_1 ; (A and B)
DAMAGE_GLASS_LEFT_1 ; (A and B)
DAMAGE_GLASS_RIGHT_1 ; (A and B)

The number at the end of name can increase if other nulls/dummy are present. The implementation of damage glass is fully explained
in the DAMAGE GLASS section.

NULLs FOR DAMAGEABLE CAR PARTS:

For the DAMAGE of car elements, the following nulls must be placed in the PIVOT point of the object around which the object rotates upon impact.

FRONT_BUMPER (A and B)
REAR_BUMPER (A and B)
MOTORHOOD (A and B)
REAR_HOOD (A and B)
FRONT_WING (A and B)
REAR_WING (A and B)
REAR_EXTRACTOR (A and B)

NULLS FOR ANIMATIONS / MOVING PARTS:

When it’s necessary to manually animate the suspension (always, if you make a high quality mod), or the car has Dion axle suspension, you’ll have to
include some extra nulls in your scene:

REAR_AXLE ; For the center of rotation of the Dion Trunk axle.

HUB_LF ; Hub for the Left Front suspension.
HUB_LR ; Hub for the Left Rear suspension.
HUB_RF ; Hub for the Right Front suspension.
HUB_RR ; Hub for the Right Rear suspension.

Read par. 2.7.2 for more details about suspension NULLs.

Additional dummies for animated parts are:

WIPER_# ; for wiper animation (A, B and C)

% ▲ Position: rotating pins of the windshield wipers.

FRONT_LIGHT (_?) ; for headlight animation (A, B and C)

DISPLAY_DATA ; for digital displays (A only)
DOOR_L and DOOR_R ; for exterior door animation (A and B)

% ▲ Position: door hinges.

DOOR_L_1 and DOOR_R_1 ; for interior door animation (A only)

SHIFT_HD ; for a hardcoded movement of a H-pattern shifter (for more details see p., driver shifting animations)

NULLS USED BY THE VANILLA SHOWROOMS’ CAMERAS:

FLYCAM_L_0 ; The farthest camera from the car, on the left (driver side).
FLYCAM_L_1
FLYCAM_L_2
FLYCAM_L_3
FLYCAM_L_4
FLYCAM_L_5 ; Driver’s seat view (after you press ENTER in the showroom).
FLYCAM_R_0 ; The farthest camera from the car, on the right side (passenger side).
FLYCAM_R_1
FLYCAM_R_2
FLYCAM_R_3
FLYCAM_R_4

184
% ▲ There is no number 5 for FLYCAM_R because there is no passenger view, you can only move the driver camera once inside the vehicle, and that’s enough
for vanilla showrooms.

These dummies (Fig.) are required for the animation of the camera from exterior to interior view of the vehicle in the vanilla showrooms.

Fig. – Only four of the ten FLYCAMS are highlighted (with yellow arrows) here. It’s a mess near the car but it works.

Without the FLYCAM empties your mod can be considered incomplete, as that nice and smooth transition will not work and you won’t be able to enter the
car, even if you have the door animations (Fig.). A file with the empties will be available in the extras of this manual.

Fig. – No matter how hard you push ENTER or click on the IN/OUT CAR button. Without the FLYCAMS you won’t be able to get in.

185
2.8.3 – GENERIC DUMMY / MESH HIERARCHY (wip)
Any object that is not a child of a NULL will be managed by the AC engine like part of the car chassis.

This means that you need to make every mesh that’s not part of the car body a child of an empty that has a specific purpose. For example, if we want the
wheels to rotate, we need to make the wheel meshes children of the various WHEEL dummies: the wheel_LF mesh is a child of the WHEEL_LF empty.

Now, since you will have parent and child objects, you’ll have to respect this rule: all the pieces of the geometry that belong to the car must be placed in a
HIERARCHY to define the specific properties of each mesh object in the game.

If we don't respect the hierarchy, the car may load fine, but nothing will move. In the example before the wheels will be stationary as if part of the body.

In the same way you must place all the others pieces like children of the correct NULL that is designed for the part that you are
creating. So for the rim there is a dedicated NULL and so on for all the other parts.

Fig. - Wheels objects are linked to the wheel null/dummy.

In the car example file you'll be able to explore how we placed all the NULLs and the relating mesh objects. In some cases naming
correctly an object works without using nulls: for example if you name the left front rim mesh “RIM_LF” you can make it child of the
WHEEL_LF empty without adding the RIM_LF null.

186
CHAPTER 3 - VEHICLE ANIMATIONS AND PRIMARY MOVING PARTS
Long story short, I went back and forth on whether or not I should make this topic a separate chapter, and given the importance, I decided to do it.
Animations have always been controversial for Assetto Corsa mod creators, and it’s time to clean up the mess that is the official pipeline.

3.1 - ANIMATIONS IN AC
BLBAJLBK

Pro tip: there is no restriction on how many frames you can use for any animation in Assetto Corsa. You are free to do whatever you want. The rules are there to provide the
minimum quality standards, which you should stick to. If you overdo it, no problem.

3.1.1 -
3.1.2 - RULES AND SUGGESTIONS
Once you have animated your empties inside your scene, you will have to export them to the .fbx format, and afterwards, using ksEditor, you will need to
export them a second time to an AC-specific clip format, called file_name.ksanim 27.

Some rules must be followed:

1. To generate a clip, you only need to animate the nulls.

Animating the mesh itself is not needed. You can also export the mesh, but the editor will only export the objects/nulls that have animation keyframes. As we mentioned
before, it is a good technique to animate only the NULL/DUMMY so that you can change your animation independently from the actual 3D mesh.
2. When you export an animated null, you must also export the hierarchy tree above it, as the name of an object inside the editor is determined by its position in the
hierarchy tree.
3. Always export using the FBX format, as it is the only format that supports animation. Do not use any other formats.
In the example shown in the image above, we have two null hierarchies that contain meshes as their children. We have animated the shift and steer paddle and we need
to export the animation.

Fig. - We cannot export the SHIFT PADDLE_L null only. We must take the entire hierarchy from COCKPIT_HR, including STEER_HR and SHIFT paddle_L. This way the editor will
define the null related to the position of SHIFT PADDLE_L in the hierarchy.

4. Only if you’re working with Blender, you can skip the step with ksEditor by using a .ksanim exporter plugin:

- Optimizing anims
• The frames are interpolated in the game. You don't need to export an animation with all the keyframes. For simple animations, like doors, gear levers and so on, you can
export just the important frames only. For a simple door animation, the “close” and “open” frames are enough, the game will interpolate the rest. When you have more
complex doors, with pistons, vertical openings, like those in a Mclaren P1, you can add more frames to animate the door in a more precise way. But always keep in mind
that the less frame you use, the more optimized the result will be, because the engine interpolates smoothly between the keyframes.
• Identical frames are optimized. If you create multiple identical frames, and the variation between them is 0, the frames will be optimized. Example: A gear lever starts
animation at frame 15 of the complete animation, because during previous frames it stays fixed to its position, waiting for the driver’s hand to first reach it. A keyframe
must be placed to frame 0 and another one at frame 14, both in static position. The animation of the gear lever starts at frame 15.There is no need to place more
keyframes between 0 and 14.

- Clips and naming conventions

There are two types of pre-programmed playbacks:
• Ping-Pong: The animation played reaches the end is then played in reverse from back to start.

27
The .ksanim extension stands for Kunos-animation, if it wasn’t obvious. You can find all the file types common to the AC modding world at the beginning of this manual.

187
• Loop: When the first frame match the last frame and the animation restarts the loop.

The specific playback type is chosen during mod development by adhering to a standard naming convention, so that the game knows what to do.

Below follow all these standard clip names.

Driver animations clip names:

steer.ksanim ; Loop for the rotation of the driver’s arms on the steering wheel.

shift.ksanim ; PingPong for the anim. of the driver’s arm to the gearshift lever (usually a simple animation, check the fbx example).

shift_dw.ksanim ; PingPong for the anim. of the fingers that operate the paddle to shift down (usually left).

shift_up.ksanim ; PingPong for the anim. of the fingers that operate the paddle to shift up (usually right).

Vehicle animations clip names:

car_shift.ksanim ; PingPong to animate the car gear lever.

Important: this clip must have the same number of frames as the shift.ksanim to match the arm movement with the shift animation. If in the driver animation,
the shifting movement begins at frame 10, the shifter must also start to move at the exact same frame.

car_susp_LF.ksanim ; Controlled by engine for the animation of the Left Front suspension.

car_susp_LR.ksanim ; Controlled by engine for the animation of the Left Rear suspension.

car_susp_RF.ksanim ; Controlled by engine for the animation of the Right Front suspension.

car_susp_RR.ksanim ; Controlled by engine for the animation of the Right Rear suspension.

Animated suspensions above are interpolated with the physics frame by frame by AC, that’s why they’re controlled by the engine.

car_door_R.ksanim ; PingPong for the anim. to open the right-hand side door.

car_door_L.ksanim ; PingPong for the anim. to open the left-hand side door.

lights.ksanim ; PingPong for the animation of the car lights that are dynamic (e.g. Ferrari F40, Opel GT, etc.).

For doors and hidden/pop up headlights the closing animation is the open animation in reverse. Do not animate the closing sequence!

car_wiper.ksanim ; Loop for the animation of the wiper (here you must animate the full animation back and forth).

car_shift_up.ksanim ; PingPong for animating the paddle shift up.

car_shift_dw.ksanim ; PingPong for animating the paddle shift down.

Pro tip: You can create all the animations needed for your vehicle. You can also use new custom names and then engage them from a script (such as active DRS, wings etc.).
The names listed above are recognized automatically and managed by the game engine for the basic, most important features.

For example: the anim car_wing.ksanim below is a custom name. On certain cars Kunos created animations called wing_rear.ksanim or wing_side.ksanim. These optional
animations are managed from the config scripts, e.g aero.ini, extra_animations.ini, etc.

car_wing.ksanim ; PingPong for the custom animation of dynamic wings (animate only opening sequence).

3.1.3 - EXPORTING AND CHECKING ANIMATIONS FROM THE AC EDITOR

Follow these steps to export animations:

1. Open the car FBX in the editor.

2. Open the ANIMATION with the Open FBX Animation option under the File tab (Fig.):

Fig. -

3. Find and load the FBX animation that you had previously exported to the “animations” folder.
4. When an animation is loaded it automatically saves a clip_name.ksanim file in the same folder where your FBX file is located, there is no need to manually export the
animation clip.
5. Select the Animations tab at the bottom part of the editor UI. Drag the animation slider, and you should see the animation playback.

188
6. You can load multiple animations into the scene. Every time you load an animation, a .ksanim file is saved with the same name as the source FBX.
7. If your fbx is not named properly, you have to rename your clips to match our name conventions, for example steer.ksanim for the animation of the driver arms etc.

There are some important things to keep in mind when exporting animations, especially door animation clips. When exporting a door clip, the following
hierarchy should be present:

Complex door animations may include a higher number of nulls, make sure that the naming conventions are consistent and that you export every null that is
animated (per side).

Note that the meshes and nulls of the interior door elements are under the null, COCKPIT_HR. This is needed because the cockpit switches from high to
low resolution. The LR door will be hidden. So we have duplicated the door animation nulls with animation included, and placed them outside of
COCKPIT_HR.

When you export, remember to include all the cockpit door nulls (left image)

NOTE: When exporting the animation of the paddle shifters (car_shift_dw and car_shift_up), make sure that you export the parent nulls as well. If the
paddles are on the steering wheel, for each animation you have to export either of the paddle nulls (SHIFT_R or SHIFT_L), the null for the steering wheel
(STEER_HR) and the HR cockpit null (COCKPIT_HR).

To animate wipers, you may use a number of nulls depending on the complexity of the wiper. Usually a wiper with 2, maximum 3 pivot points (and thus 2
or 3 dummies) is sufficient.

The wiper nulls must be located in the root of the scene and they must be present in LOD A through LOD C.

3.1.4 - CHECKING CAR ANIMATIONS

When all your suspensions clips are exported to the proper animation folder (see “Project Structure” section), you can load your car.fbx in the editor and
check if the animations work properly.

You can do this only after you have created the animation clips and by loading them into the editor.

NOTE: LOD B must contain the same null hierarchy and names of animated nulls as LOD A for the exterior (suspension, wings, pop-up lights), but not for
animations in the HR interior (paddle and shifter) and the doors nulls under the Cockpit_HR null.

Open you car_name.fbx

After the car is loaded, you can load the clip of the suspension that you want to test.

In the tab called “Car Animations” you’ll find sliders. These are designed to help you test the animation of the springs, the constraint of the arms and the
wheel rotation.

189
The sliders allow you to check the suspension in the editor and detect any issues, frame by frame. Here you can see an example: Moving the slider you can
check the hub behaviour.

190
3.2 - SUSPENSIONS
Suspensions can be made in various different ways, and depending on the method chosen you get varying accuracy in the display of the setup adjustments,
and in the response of the visual objects linked together. One can create hand-made deflections and movements, or let the physics engine do almost everything
by itself. We can start exploring the abyss then.

3.2.1 - ANIMATED SUSPENSIONS (ANISUS)

With very complex designs the 3D suspensions of a car can be animated by hand if needed, with a number of frames defined by the user. This method (called
ANISUS, which stands for Animated Suspension(s)) is handy when an entire system with lots of arms shall be moving.

ANISUS do have some disadvantages however. They follow predetermined arcs and movements, so the setup values chosen by the player in game are not
visually represented at the wheels correctly. For example, camber angles might differ visibly from the values selected in the setup screen.

In order to enable this kind of suspension anims, you have to edit the following line in the car.ini script (for more details about this parameter, see pag.):
USE_ANIMATED_SUSPENSIONS=1 ; This value controls the suspension animations. 0= disabled (default), 1= enabled.

Makes no difference if anything is animated at all, just set it to =1 in car.ini, but the dummies need to be there and all correct and you can just export them
empty.

To create an ANISUS, you will have to follow these steps:

1. Set the number of frames in your timeline (for example 20 frames).

2. In frame 0 the suspension must be in the lower position.
3. The frame in the middle of your sequence (in our example frame 10) will have the suspension in the neutral position.
4. In the last frame (the 20th frame in our case) the susp. will be in its higher position.

We use a NULL hierarchy to animate the suspension geometry (par. 2.7.2).

How do ANISUS work?

The engine verifies the position of the suspension along the Y axis and finds the
right frame to match the animation to the position of the physical suspension. It
will interpolate the frames to generate a smooth movement.

AC will search for the following NULLs:

SUSP_LF
SUSP_LR
SUSP_RF
SUSP_RR

The dummies must be placed and oriented to move the suspension on the Y axis.
Example of how to animate a suspension correctly in Fig..

NOTE: Before exporting the FBX, timeline needs to be set with the same number
of total frames as the number of animated frames created.

Example: If you animate 20 frames, do not export with a timeline of 30. This will
cause a crash.

Remember to set the timeline to 20 if you have animated 20 frames. Empty

frames will cause a crash and are not supported.

Fig. -

3.2.2 - SUSPENSION HIERARCHY

The suspension must have the hierarchy identical to one of the two FBX examples provided: TEMPLATE_Suspension_EASY.fbx and
TEMPLATE_Suspension_COMPLEX.fbx
191
The first scene contains a simple suspension hierarchy, made for a car with simple suspension system. The second is prepared for complex suspension
hierarchy, like 60’s Formula 1 cars, with more complex arms and particular suspensions. Those examples contains more empties. Some names can be
customized and we have named the customizable dummy in an appropriate way, inside the template.fbx ”Custom_name##”. (where # is a number).
All the NULLs are used for animated parts. Their use is optional. You can create the necessary number of empties as you desire.
The WHEEL_# and the SUSP_# dummies are mandatory for the ANISUS.
The engine recognizes also 4 other nodes for the hubs of every wheel, namely HUB_#. These nodes are designed to allow the hub to rotate in accordance
with the camber of the wheel. If those aren’t present the car will not load in-game while animated suspensions are enabled.

In the above image example, the hub is the parent of the steer arms.

This way you can animate up and down movements of the hub or the suspension and during the animation you can change the camber of the hub as
required by the actual physical suspension layout.

Inside the TEMPLATE_Suspension_COMPLEX.fbx you can find an example for the correct hierarchy.

Note: The SUSP_ node must always match the position of the Wheel_ node. The AC engine verifies the position of the suspension in 3D space by checking
the SUSP_ node. The wheel bounding box is recognized between the SUSP_ node and Wheel_ node. Those 2 positions must be the same.

Again the FBX file TEMPLATE_Suspension_COMPLEX.fbx is a perfect example.

3.2.3 – STEER ARMS, DIRECTION CONSTRAINTS and PHYSICALLY RESPONSIVE SUSPENSIONS (PRS)
We can animate many different parts and just import the animation to the editor and from that export to the game, but the STEER arm cannot be animated.
Its position changes in the 3D space according to the HUB rotation (due to user steering input).

In order to constrain the movement of the steer arm to the HUB’s position and rotation, there is a construction strategy which employs special empties,
namely the DIR_ ones 28. It is an Assetto Corsa internal convention, not too well documented.

The convention name DIR_customName must be used. This indicates the direction of the X negative axis of this mesh, and the null called “customName”
will point the X axis to the correct direction.

Example: a null called SteerArm_L will point the negative X axis in direction of a null named DIR_SteerArm_L.

This convention is active even without ANISUS enabled on the car.

Pay attention to the rotation of the null which the animated mesh is linked to. In the image below the right-hand side Null point has a positive Z axis. The left
Null point has a negative Z axis. This allows the -X axis to point to the center of the car or any other direction required by the mesh. Inside the
TEMPLATE_Suspension_COMPLEX.fbx file under, you can find a proper hierarchy example.

28
DIR(s) stands for Direction Constraint(s).

192
Fig. -

Note: You can create more constraints, if you have more objects to constraint to the HUB by simply giving them different names. Nevertheless, it is always
good in terms of optimization to use the lowest possible number of constraints.

- If you don’t want to animate the suspension manually, you can technically make an entire suspension with DIR dummies, called a FULLY CONSTRAINED
SETUP in the official pipeline. From now on, it will be called PRS (Physically Responsive Suspension) for the purposes of this manual (and for general
modding practices 29).

You can use the DIRECTION CONSTRAINTs logic to force your suspensions to work automatically without animating them. The movement of the wheel will
determine the response or the linkage arms, bars and springs. An example of this kind of suspension setup can be found in the example files provided with
the SDK:

• Costraint_suspension_Only.fbx for generic FBX 2014 version

• Costraint_suspension_Only_XSI_2014.scn for XSI 2014 version
• Costraint_suspension_Only_MAX_2013.scn for 3ds MAX 2013 version

Pro tip: PRS is good with suspension geometry where you may just have arms, and nothing else, but the main disadvantage is with springs and anything on the chassis side
(e.g., heave springs and rockers), where it is not really possible to use it, as AC does not handle spring transformations with DIRs.

You can animate your custom nulls in the following vectors: Rotation - Translation - Scale.

Inside the TEMPLATE_Suspension_COMPLEX.fbx example file, you can see the animation of the suspension spring, on SCALE Y .

Note: Never animate the mesh. Always animate the NULLs only! With this approach you can change and update your mesh every time you want without re-
exporting the animations. Use the same technique to create animations for any NULL that has to be animated. For example, doors, gearbox levers, or any
other parts.

At this point, if you have the front or the rear wheels attached to a unique piece of metal (Fig.) you may be asking: what’s the hierarchy between my
suspended axle and the NULLs? I can’t make the left and the right hubs both parents of the same mesh. The solution is simple, you split the axle in half,
and animate both halves together as one single piece. Take a look at the Maserati 250F by Kunos (Fig. &).

29
Since often modders don’t give appropriate names to things.

193
Fig. – (top) The rear suspension of the official Maserati 250 F by Kunos, rendered with Blender (the selection highlights that the steel bar is cut in half). (bottom) Behaviour in a race
session (Vallelunga). The problem of this split system is that each wheel acts separately in AC, like an independent suspension would behave. In real life, the points A and B in the
picture are welded together (the metal bar is one straight solid piece), and the rear has got a DeDion axle (see suspensions section where man?).

How can we solve this problem? wip

194
3.2.6 - TRANSMISSION

In some cars, the transmission shafts might be visible, and thus should rotate along with the wheels. So in AC there is a convention to animate these
objects automatically, using NULLs with the following names:

TRANSMISSION_L_1 for the Left shaft

TRANSMISSION_R_1 for the Right shaft

If you have more transmission pieces to animate, you can use progressive numbering. For example:
TRANSMISSION_L_2, TRANSMISSION_L_3 and so on. The same applies to TRANSMISSION_R_2 and
so on. The engine recognizes the prefix “TRANSMISSION_L_” and looks for a sequential number after
it. There is no hardcoded limit on the number of transmission parts that can be animated 30.

The transmission nulls rotate on the X axis and needs to be oriented like in Fig.. Also, in order to have a
correct direction of rotation, the Z axis of the transmission nulls must always point forward.

This node is useful for animating the joint on the Y axis according to the suspension animation, and the
engine automatically rotates the transmission according to the wheel on X axis. Avoid animating on the
Z axis, as it is not used.

Pro tip: the TRANSMISSION_ empties work only if you have USE_ANIMATED_SUSPENSIONS=1 in the car.ini
data file (see pag.). Keep in mind that the car won't load properly with this line set to 1 if there are no suspension-
specific (SUSP_ or HUB_) empties on any corner of the vehicle.

If you want to create a rotating engine fan you can parent your fan to a TRANSMISSION _R or _L Null. But being dependent on wheel speed, it’s better if
you use extra_animations.ini for that.

30
Which is pretty weird, given the fact that AC runs physics code only for four wheels, and that’s deeply rooted in the simulator.

195
CHAPTER 4 – MODEL OPTIMIZATION
In this Chapter you will learn why 3D assets for games must be efficient, and how you can improve your own mods in this regard.

Optimization has been a very important part of the videogaming world, with its peak at the beginning of everything in the 1980s, with consoles that had 4
Kilobytes of RAM (Random Access Memory), like the Nintendo NES from 1983.

Back then all titles were pretty simple and had to fit within the limitations of the hardware. Sometimes you had to sacrifice detail, sometimes entire levels,
sometimes even colours, to make use of all the data space on cartridges and push everything to the limit.
This challenge was on the software developer obviously. And it still is nowadays, only that you can make basic stuff work with no effort, but more attention
must be put on critical applications, like simulators, where every frame is important.

Our mods should be performance-friendly in order to offer and ensure the best end-user experience. Let’s see what this concept means and which precautions
should be taken.

4.1 - UNDERSTANDING GPU PERFORMANCE (WIP)

When C# code runs too slowly, you can profile it to see where the time is being spent.

Graphics programmers are not so lucky. If you work for a big commercial studio and have access to an Xbox devkit, the Xbox version of PIX (see
https://devblogs.microsoft.com/pix/gpu-captures) gives nearly as much information about GPU performance as profilers can tell you about the CPU, but for
the rest of us the GPU remains a mysterious black box which cannot be so easily measured.

I like to think of GPU performance investigation as a Sherlock Holmes mystery:

• Performance is dead.
• Who killed her?

We must gather clues, form a hypothesis, and then confront the villain to make them confess.

We do have one advantage though, and that is the ability to rewind time and run our program again with minor changes. This is an incredibly powerful tool.
Let's say the evidence leads us to suspect Performance was killed by Colonel Mustard, in the library, with the candlestick. To confirm this theory, we can
comment out our candlestick rendering code, and run the program again. Is Performance still dead? If she lives, we know the murder weapon was the
candlestick, so should probably investigate how many polygons that is built from, and how expensive a shader it is using.

To be successful with this kind of investigation, two things are required:

1. You need an accurate way of measuring whether Performance is alive, dead, or merely in a coma. Display the framerate, and turn off Vsync. You normally want those on,
but should temporarily turn them off any time you want to check Performance's heartbeat.
2. You need a good mental model of how GPU hardware works. What made me suspect the candlestick? How did I know it wasn't the lead piping? Without some
understanding to guide our suspicions, we could waste a lot of time randomly investigating one thing after another. GPU performance is highly nonlinear, so you will
often find that removing an entire model makes no difference at all, but then making a seemingly minor change to a different model can double your framerate. To the
uninitiated, these results can seem pretty random.

Many people have a mental model of how computers work that goes something like:

"A computer is like a small cardboard box. Inside this box lives an elf. The elf obeys instructions from my program, in the order they are given. Some instructions tell the
elf to draw pictures onto the screen."

Functionally, this description is correct. If computers really did work that way, they would behave exactly the same as they do today, and could run the same
programs. It is not enough to understand graphics performance, however. It oversimplifies to the point of uselessness. Here is a more accurate model:

"A computer is like a cardboard box inhabited by a pair of elves, Charles Pitchwife Underhill plus his younger sibling George Pekkala Underhill (both more commonly
known by their initials). Charles is smart, well educated, and fluent in dozens of languages (C, C++, C#, and Python, to name a few). George, on the other hand, finds it
difficult to communicate with anyone other than his brother Charles, prefers to plan his day well in advance, and gets flustered if asked to change activities with insufficient
warning. He has an amazing ability to multiply floating point numbers, especially enjoying computations that involve vectors and matrices.
When you run a program on this computer, Charles reads it and does whatever it says. Any time he encounters a graphics drawing instruction, he notes that down on a
piece of paper. At some later point (when the paper fills up, or if he sees a Present instruction) he translates the entire paper from the original language into a secret code
which only he and George can understand, then hands these translated instructions to his brother, who carries them out."

This second mental model explains performance characteristics that might otherwise seem rather odd. For instance, if we use a CPU profiler to see what it
is doing, then draw a model containing 1,000,000 triangles, we will notice the CPU takes hardly any time to process this draw call. How can that be? Is it
really so cheap to draw a million triangles?

The explanation is that it didn't actually do any work when he got this instruction, merely jotting it down on his "instructions" list. You can write down an
instruction which says "draw a million triangles" just as quickly as one saying "draw 3 triangles", although these will seem quite different to the GPU when it
later gets around to processing them.

This parallel nature of CPU and GPU is tremendously important when it comes to understanding how they perform. In a perfectly tuned game, both
processors should be running flat out doing useful work, something like Fig. left.

196
Fig. - Time is along the vertical axis, increasing down the page.

Notice how the GPU doesn't start processing the draw instructions for frame 1 until after the CPU is entirely finished with that frame, and the CPU is busy
with frame 2 at the same time as the GPU is drawing the previous frame.

In the real world, it is hard to make your CPU and GPU workload exactly equal. If you have more CPU than GPU work, the timeline looks like Fig. center.
Notice how the GPU is sometimes idle, after it has finished the work from the previous frame but not yet received any instructions for the next.

This is called being "CPU bound". The interesting thing about this situation is that if we optimized our code to reduce the amount of GPU work, that would
make absolutely no difference to anything. The GPU would be spending less time drawing and more time idle, but the CPU would still be running flat out,
so our final framerate would stay the same. Even more interesting, if we can find a way to do more things on the GPU without also costing any extra CPU,
we could add more graphical effects entirely for free!

The other way around, look at what happens if you have more GPU work than CPU work (Fig. right). In this situation the CPU has finished with frame 2, and
is ready to hand it over to the GPU, but the GPU says "hey, wait a moment! I'm not ready for that yet; I'm still busy drawing the first frame". So the CPU has
to sit around doing nothing until the GPU is ready to receive new instructions.

This is called being "GPU bound". In this situation, optimizing our CPU code will make no difference, because the GPU is the limiting factor on our final
framerate. We could add more CPU work "for free", replacing that idle time with useful game processing.

In order to optimize successfully, you must understand whether your game is CPU bound or GPU bound. If you don't know this, you might waste time
optimizing for the wrong processor. But once you do know it, you can improve your game by adding more effects to whichever processor is currently sitting
idle.

So how do you tell which is which? People sometimes oversimplify this to something along the lines of "graphics calls run on the GPU, while physics and
gameplay logic runs on the CPU", or even "my Update method runs on the CPU, while Draw runs on the GPU".

Not so! Don't forget that your drawing instructions must be translated into a format which the GPU can understand. If there are many instructions, it will take
a long time to translate them all. If you have a small number of instructions which draw a large amount of stuff, this will be quick for the CPU to translate but
slower for the GPU to draw. But if you have many instructions that each only draw a small amount of stuff (for instance a million draw calls with a single
triangle per call, or many changes to settings such as renderstates or effect parameters), this may end up taking longer to translate.

Even if your program contains nothing but drawing instructions, with no update logic at all, it is still possible that it might require more CPU time than it
does GPU time, depending on how much translation and coordinating work is required.

Here is what usually happens:

• Your Draw method issues graphics calls, which are recorded into a buffer
• Your Draw method finishes
• The XNA framework calls GraphicsDevice.Present
• This calls the native IDirect3DDevice::Present
• The DirectX runtime does some translation, then calls the graphics driver
• The graphics driver does some more translation, then hands the final translated commands over to the GPU

Using a CPU profiler, you will see:

• Some time in MyGame.Update

• Some time in MyGame.Draw
• Some time in GraphicsDevice.Present

That last part is where the translation takes place. If your profiler is able to dig below the .NET code to see what is going on in the native layer, this will show
up as a mixture of d3d11.dll, kernel32.dll, and the graphics driver for your card (typically nv4_disp.dll or ati2dvag.dll).
197
You might think measuring how long Present takes would be a good way to see how much translation work your game is causing. Or you may have
cottoned on by now that things are rarely so simple. There are a couple of other reasons why Present could take a long time:

• If your game is GPU bound, Present will spend time waiting for the GPU to finish drawing the previous frame
• If you have vsync enabled, Present may spend time waiting for the next monitor refresh

Because it can mean several different things, profiling the Present call does not tell us anything directly, but it is an important clue.

People are often surprised to see how long Present can take. They protest: "I would understand if my Draw method was slow (I am drawing a lot of stuff,
after all), but surely it is a bug that the framework spends so long in this method I never even directly called?"

This can be confusing because drawing graphics is a play-now, pay-later kind of a deal. The time spent in Present is directly caused by the drawing
commands you issued, but the true cost of those commands didn't show up at the time you called them.

There is one case where a drawing command may pay an unduly large cost, and this is if the internal graphics command buffer fills up in the middle of a
frame (ie. CPU runs out of room on his piece of paper). If this happens, Direct3D will call into the driver, translating a batch of commands and handing
them over to the to GPU, without waiting for the final Present call. This will show up in your profile as an arbitrary drawing call taking an unusual amount of
time. If you find yourself wondering why the first 1,000 renderstate changes were almost free, but then the 1,001th took a long time, that call is probably
paying a deferred cost for all your previous drawing operations.

Understanding how this works can teach us some things about graphics drivers. You know how newer drivers often claim to include optimizations that
boost overall rendering performance? If you think about it, this only makes sense for games which are CPU bound. If a game is GPU bound, speeding up
the translation code in the graphics driver will make no difference, since that CPU code was not the limiting factor in the first place.

It is also interesting to think about this from the perspective of a GPU hardware designer. One of the big questions faced by silicon designers is how closely
to mirror the behaviour of the D3D API. If they keep their hardware close to the D3D spec, the translation work will be simple, so their driver won't require
much CPU, but this might complicate the silicon and slow down the GPU side of things. On the other hand, if they optimize their silicon purely to be as fast
as possible, they are likely to produce a better performing GPU, but at the cost of more complex translation which will increase the driver CPU load.
Benchmarks don't talk about this much (I guess because not many people would understand the distinction) but there can actually be differences where one
card is more likely to be CPU bound, while a different design tends to be GPU bound.

Santa’s production line

I oversimplified when I described the GPU as a single elf named George.

In fact, a modern graphics card has a complex pipeline with hundreds of elves working in parallel. In the same way that the CPU records drawing
commands into a buffer, then the GPU processes them while the CPU is free to get on with other work, each of these internal GPU pipeline elves is reading
input data from a buffer, doing some computations, then writing output data to another buffer which is consumed by a different elf further down the chain.

This lets us subdivide the concept of being "GPU bound" based on which particular elf is causing the bottleneck. In the same way that optimizing your CPU
code makes no difference if you are GPU bound, successfully optimizing GPU rendering depends on knowing which part of the pipeline you are trying to
speed up.

So what exactly does happen inside the GPU? The details vary from card to card, but these are the most important stages:

1. The vertex fetch unit reads vertex data from memory

2. The vertex shader processes this data
3. The rasterizer works out which pixels are covered by each triangle
4. The pixel shader calculates the color of each pixel
5. The texture fetch unit looks up any textures that were requested by the pixel shader
6. The depth/stencil unit reads, tests, and updates the depth buffer
7. The framebuffer stores the final output color, and applies alpha blending

Any of these may be your performance bottleneck, and it is tremendously useful to find out which. For instance if we learn our game is limited by vertex
shader processing, we know to optimize that rather than wasting time trying to reduce the number of texture fetches. Or if we are limited by pixel shading,
we could increase the number of triangles in our models without affecting the framerate!

So what factors affect the performance of each pipeline stage? Here they are:

1. vertex fetch: number of vertices / size of each vertex / whether vertices are well ordered for cache coherency
2. vertex shader: number of vertices / length of vertex shader program/ whether triangle indices are well ordered for cache coherency
3. rasterizer: number of pixels rendered / number of interpolator values passed from vertex shader to pixel shader
4. pixel shader: number of pixels rendered / length of pixel shader program
5. texture fetch: number of pixels rendered / how many texture lookups per pixel / amount of texture data read from memory / mipmapped textures have way better cache
coherency / DXT textures are smaller than uncompressed formats
6. type of filtering: anisotropic is the most expensive / trilinear is usually only a little slower than bilinear / bilinear and point sampling are often identical
7. depth/stencil: number of pixels rendered / whether multisampling is used / read/write vs. read-only mode
8. framebuffer: number of pixels rendered / whether multisampling is used / size of each framebuffer pixel (including MRT) / read/write (alpha blending) vs. write-only
(opaque)

198
To identify the bottleneck, we need some way of altering just one of these contributing factors, and without changing our CPU code in any significant way (if
a change affected CPU performance as well as GPU, that could invalidate our results).

Try running your game in a tiny resolution, say 640x480. This makes no difference to the CPU, vertex fetch, or vertex shader performance. Does the
framerate improve?

If reducing the resolution does not affect performance (and assuming you are not CPU bound), your limiting factor must be vertex processing. You can
speed up both vertex fetch and vertex shading by using fewer triangles in your models, or you could try to simplify the vertex shader.

If reducing the resolution speeds things up, you must be limited by one of the pixel processing stages.

Try enabling multisampling. If this makes no difference, you are limited by the rasterizer.

To obtain maximum parallelism between different stages in a pipeline, you should ideally buffer up an entire frame of data in between each stage. This is
exactly what happens when sending data from CPU to GPU, but the buffers between the internal GPU pipeline stages are much smaller, holding at most a
few hundred triangles or pixels.

This means the GPU bottleneck can change over the course of a frame. For instance you might find your terrain rendering limited by texture fetches, while
animated characters are limited by the vertex shader, and bloom postprocessing is limited by pixel shading.

If you use the techniques from my previous post to examine such a game, you will find it speeds up when you shrink the textures (because this makes the
terrain rendering faster), and also when you simplify the vertex shaders (because this makes the character rendering faster). Performance of the game as a
whole is affected by more than one thing, but each individual piece still has just one bottleneck. We would see no performance gain if we optimized our
terrain vertex shader, or compressed the character textures, for instance.

To diagnose such a case, we must split the game into pieces and examine each part individually. But this is easier said than done! Sherlock Holmes is of
limited use here: instead we must call in Dirk Gently to understand the fundamental interconnectedness of all things.

For instance you might think we could examine terrain performance by temporarily commenting out the character and bloom rendering, letting us measure
the terrain in isolation. Trouble is, if we make that change our game is likely to go from being GPU bound to CPU bound, at which point we can no longer
experiment with GPU performance at all!

A better technique is not to remove anything, but instead add a loop that will repeat the same terrain rendering 100 times in a row. The framerate will
plummet (if it doesn't, that proves terrain rendering must be an insignificant part of the overall performance profile) and this new lower framerate will be
entirely dominated by terrain. By increasing the amount of terrain being drawn, we can dwarf the other scene elements into insignificance, letting us use the
techniques from my previous post to measure the terrain while basically just ignoring everything else.

If you split a game into pieces and measure each one in isolation, then put everything back together and measure the final result, it is common to find the
whole runs faster than the sum of its parts. This is because, even though the GPU pipeline buffers are limited in size, they do offer some parallelism from
one task to the next. You might find that out of 10 characters, 9 are limited by vertex shading, but the vertices for the first are being processed in parallel
with the last few hundred terrain pixels, so you are effectively getting that first character for free. It is also common that the amount of such parallelism will
change in unpredictable ways if you swap the order in which things are drawn.

There are no hard and fast rules here. Measure everything you can. Try to break out different parts of your rendering and measure them in isolation. Don't
expect everything to make perfect sense: all things are interconnected when they run in parallel, so a seemingly trivial change in one place can have
unexpected performance implications somewhere entirely different. It often takes a leap of intuition to look at a collection of measurements and figure out
which contain important clues, which are just side effects of the measurement process, and which were caused by the fundamental weirdness of parallel
processing.

Normally, the CPU and GPU run in parallel. Framerate = max(CPU time, GPU time).

If your code causes a pipeline stall, however, the processors must take turns to run while the other one sits idle. Yikes! Now framerate = CPU time + GPU
time. In other words, programs that stall can be both CPU and GPU bound at the same time.

The easiest way to cause a stall is to draw some graphics into a rendertarget, then GetData on the rendertarget texture to read the results back to the CPU.
Think about what happens if you do this:

• The CPU is processing your drawing calls.

• It has filled the RAM with instructions for the GPU.
• The CPU reaches an instruction that says "copy data from GPU back into this array".
• But the drawing instructions haven't actually been processed by the GPU yet!
• The CPU cannot just note down the GetData call on a piece of paper. The next instruction might use values from the array, so the CPU needs that data right away.
• The CPU has no option but to immediately hand the incomplete list of drawing instructions over to the GPU , then wait around twiddling his thumbs in boredom until the
latter has finished drawing everything, at which point it can resume processing the GetData instruction while the GPU becomes idle.

One of the great successes of the Direct3D API is how it hides the asynchronous nature of GPU hardware. Many graphics programmers are writing parallel
code without even realizing it! But as soon as you try to read data back from GPU to CPU, all this parallelism is lost (one reason it is hard to accelerate
things like physics or AI on the GPU).

199
4.2 - LODs AND TRIANGLE / OBJECT BUDGET
LOD means Level of Detail, and is a method of defining, via different variations of a model, how high or low the viewable quality of the model should be,
and how it should interact with the environment.

Resolution LODs are 3d models visible in-game to the player from the outside view. There should always be more than 1 resolution LOD (unless it is a low
poly object). In open-world 3D games it is standard practice to swap out high-resolution models with medium or low-resolution ones at far distance from
the observer. This is done to prevent excessive demand of computing resources. Without the resolution LOD technique, the games would be unplayable
due to bad performance. It’s a compromise between computing power and attention to detail of the human eye.

The switching of different resolution LODs happens automatically, based on various in-game conditions (e.g., view-distance, number of objects, video
quality, CPU utilization, etc.). In Assetto Corsa there’s a dedicated config file (lods.ini) that manages this with a simple script. The algorithm needs enough
different resolution LODs to be effective. Therefore the modeller needs to provide multiple resolution LODs with different polygon density. They should be
ordered according to their polygon count. In the official Assetto Corsa content the highest poly count LOD has letter A, the second one letter B, and so on
until LOD D, look at Fig. 2.11.

Fig. 2.11 - Here are some examples of the progressive degradation of the mesh for each resolution LOD in AC.

200
In addition to reducing the polygon density, it is best practice to also reduce shader complexity and the number of textures used - those too eat valuable
resources. The lowest resolution LOD won't need a normal map and not even a specular or gloss map.

With the recent progress of CGI technology, upcoming games will probably stop using LODs. Unreal Engine 5 by Epic Games introduces the Nanite
technology, that is a new internal mesh format and rendering technology to render pixel scale detail and high object counts. It intelligently does work on
only the detail that can be perceived and no more. Nanite's data format is also highly compressed, and supports fine-grained streaming with automatic level
of detail.

A Nanite mesh is still essentially a triangle mesh at its core with a lot of level of detail and compression applied to its data.

The whole rendering process is a lot faster, so probably LODs will become a technique of the past. However AC uses them, so let’s dive into it. It shall also
be noted that Assetto Corsa Competizione does employ them too (Fig.).

Fig. – The LOD structure of the Mercedes AMG GT3 from ACC by Kunos. Screenshot of a 3DsMax window from an interview with Marco Massarutto (Youtube). You can see how the
structure is quite similar to AC.

4.2.1 – LOD TRIANGLE COUNTS

Assetto Corsa uses LODs to manage both exterior body and interiors of cars.

The following triangle-counts are the recommended in most cases 31 for each LOD:

LOD A: 150,000 - 350,000 tris

- Well-made cars can reach higher poly counts, but are performance demanding!

LOD B: 20,000 - 50,000 tris

- LOD B must have the same null hierarchy as LOD A, except for the following NULLs (and their respective child meshes):

• COCKPIT_HR (which becomes COCKPIT_LR)

• STEER_HR (becomes STEER_LR)
• FLYCAMS, which aren’t present (those are missing in LOD C and D too).

LOD C: 5,000 - 15,000 tris

- LOD C can just have cylinders with 2d faces for wheels and tyres.

LOD D: 2,000 - 4,000 tris

- Go as low as possible for performance, while you can keep the main shape of the vehicle. Remove the interiors.

31
You may be asking: why are these numbers slightly higher than those in the original KP 2.0? Well, because with the performance of recent generations of hardware the sim is decently playable
even on low-end hardware if you don’t crank up the video settings. The latest version of the pipeline was released back in 2016. PCs are far more powerful after what, 7 years? AC’s content is
below the current modeling standards for next-gen titles.
201
Of course, these numbers are generic and apply to most top-tier cars with elaborate interiors. The truth is that there is no real limitation (to go higher or
lower). It's just that going too low might hurt detail, going too high might hurt your FPS and the optimization of the game (unless you think everyone has
very powerful graphics cards, idea far from being accurate).

Pro tip: there is also no explicit limitation on how many LODs you can create, be aware of that. A number of four is the minimum according to the Kunos official standard, but
adding more is often an unnecessary complication, unless your first-level model (LOD A) is very high poly.

A nice rule you can apply is to go as low poly as you can without cutting down on detail.

THE LOD SHORTENING TECHNIQUE:

If you have well made LODs, you can even shorten switch distances, changing the values in lods.ini (pag.). Keep in mind that the LOD B shall be visible at a
distance of 15 meters or closer. If you create a good LOD B, you can reduce the distance of the LOD A switch to LOD B and increase graphic performance.
To achieve this, try to reduce the model keeping the curved parts smooth, parts that create evident reflections, such as glass or curved parts of the body.
Try to see how it works in the game and refine it. The switch between the LODs must be almost seamless, as smooth as possible without any visible “jump”
or flash.

Another aspect of modelling performance-friendly cars is the detail of the wheels.

Sometimes, you can get away with lower detail on the car body, but very well-made wheels. So here are some numbers to help in this direction as well.
Budget for a wheel (tire + rim) should be around 5-8k tris (for normal-looking rims, see Fig.). 3k would be very low. You can go as high as 12k per wheel
in case of a complex geometry.

The recommended number of outer sides on the tires and rims (what is an outer side? See Fig. 2.12) is 80, but it can vary depending on the size of the
wheel (typically from 50 to 90), and reduced by half in each lower LOD (C and D can easily have just cylinders with 2D faces as wheels). The rims can have
even double the number of outer sides compared to tires, depending on how many spokes you have and the size of the wheel.

Fig. – Wheel of the Ferrari 312/67 by Kunos. You can take these numbers as reference, or look at other official content. The colours highlight different meshes here. You can work with
as many of them as you want, but keep in mind the budget for your object count. Join them together if they’re too numerous.

4.2.2 - LOD OBJECT COUNTS

When producing the LODs, the most important guideline to follow is to reduce draw calls (number of objects) as well as the number of separate materials.
In AC amount of draw calls (objects/materials) scales almost linearly with FPS and is extremely important as you often have large grids of cars. Cars
shouldn't exceed 200 objects for LOD A unless there's a lot of animations requiring separate objects, or in some specific cases like very complex digital
clusters, but that can be somewhat alleviated using CSP. Exceeding a number of 300 is almost always inexcusable. The lower the object count, the better,
period.

Note: To save file space LODs B, C and D don't include separate copies of every texture, so those are just loaded from LOD A, and if you rename/remove
textures there you'll break the other LODs. Export all the models with the same materials in your 3D editor, and with the same shaders/persistence in
ksEditor (about it in section).

Also, LOD B must contain the same null hierarchy and names of animated nulls as LOD A for the exterior (suspension, wings, pop-up lights), but not for
animations in the HR interior (paddle and shifter) and the doors nulls under the Cockpit_HR null.
202
You can look at these numbers as reference for object count:

LOD A: 200 objects

LOD B: 50 - 100 objects
LOD C: 20 - 40 objects
LOD D: 2 objects
By LOD C, the number of materials and objects should drastically drop, while for LOD D no more than a maximum of 2 materials and a similar number of
objects (no rotating wheels are required) should be used. Based on how visible the elements are, it is up to your judgement to remove other non-essential
nulls, such as wings, bumpers, hood etc.

Pro tip: For LOD C ensure you still have the emissive objects for lights so you don't have casting lights without emissive on car mirrors or at a distance at night for cars behind,
or noticeable missing brake/rear lights for cars ahead. This affects replays too. However, you don’t need to put this in practice for LOD D, as the cars are too far for the lights
to be actually seen/rendered.

Let’s take look at some car models. All the examples in the next pages are “properly” working in AC (which simply means they load in sessions); some are
part of the official content by Kunos, others are mods made from scratch or conversions; check the triangle and object counts 32.

Fig. 2.16 – This model is a conversion. It has got more than 1 million triangles but there aren’t LODs, and that means big trouble for performance. You might experience sudden frame
drops and lag. The FPS drop is noticeable to the naked eye if you have multiple cars like this on the race grid; you can also verify it with an FPS counter. Look at the triangle counts for
wheels: you can fit entirely another car’s LOD A in these values, because every wheel is too high-poly, as in Fig. 2.15. That’s the main problem here. Remember: for tyre grooves use
normal textures, do not keep them modeled in the final product. I wouldn’t recommend playing with 20 opponents (or even less) with this mod on your PC.

32
Also bear in mind that LODs A, B, C, D in Content Manager showrooms correspond to LODs 0, 1, 2, 3.

203
Fig. 2.18 – This mod is performance friendly because the LODs are present, but they were generated with Simplygon, a software which can produce artefacts; just look at the crests
and the deformation on the LOD D model. More about Simplygon later.

Fig. 2.19 – The Alfa Romeo Giulia Quadrifoglio by Kunos. Being part of the official content, there is not much to say. LODs are obviously present, and the triangle count is on average.

204
Fig. 2.20 – This car comes with LOD A and B only. The latter is well made (most likely by hand), so it gets the job done; adding LOD C and D would be even better, in order to
complete the mod, however quality speaks for itself, you can’t see much difference indeed, even if the triangle count of LOD B is just 1/5 of LOD A.

205
Fig. 2.21 - Few details must be preserved even in LOD D: the most visible parts. From this point of view the LOD D of this mod may even be too much detailed for Kunos standard, but
look at the triangle count: we’re past the recommended values but not too much, so it’s fine. Keep in mind that lower LODs take the textures from LOD A.

206
4.3 - INTERIORS
In LOD A, the cockpit has 2 resolution LODs for interiors, one High Resolution (the Cockpit_hires meshes under the COCKPIT_HR NULL) for the cockpit
camera and showroom view, and one Low Resolution (the Cockpit_lowres meshes under the COCKPIT_LR NULL) LOD for most exterior cameras, replays,
and distant views (Fig. 2.22).

The following triangle-counts are recommended for interior LODs:

HR Cockpit: 120,000 – 150,000 tris

LR Cockpit: 9,000-20,000 tris
LR Cockpit in LOD B: 5,000 tris ; as low as possible while keeping a decent quality
LR Cockpit in LOD C: 2,000 tris ; some detail must remain above window/windscreen level (roll bars, mirror…)

Fig. 2.22 – Models from Abarth 500 EsseEsse by Kunos. (left) Cockpit HR interior LOD example (~125,000 tris). (right) Cockpit LR LOD example (~7,000 tris).

Always bear in mind that the budgets for the cockpit are to be considered WITHIN the entire model’s LODs (LOD A, B, C, D, etc.)!

You have to make a few compromises then. For example, you shouldn’t make a vehicle with a total of 400k tris and dedicate only 30k to the exterior and the
rest to the interior or vice versa. I would recommend splitting your budget in half between cockpit and vehicle body (maybe slightly less for the interiors).
Depending on the type of vehicle the proportion can obviously change. Open-wheelers with small cockpits can use less triangles for the interior and more
for details on the exterior, such as the engine and suspension. It is up to the judgement of the modeller to use the poly budget in accordance with the
complexity of the model, but it MUST be optimised as much as possible without hurting the overall quality. Try to reach a balance between the poly counts.

Pro tip: This should be obvious, but do not model parts of the interiors that no one will ever be able to see, unless you plan to make them visible in the future (e.g., the engine
under the hood, which you may show with an animation of the bonnet).

The HR and LR cockpit LODs must always fit the exterior LOD A, because while driving, the EXTERIOR MESH that you see is LOD A (Fig. 2.24). When the
camera moves farther away, the cockpit LR will switch and you’ll get a simplified version of the cockpit, with only one material (in most cases) and a look
similar to the HR version.

Fig. 2.24 – As you can see, once everything is inside, it just stays inside.
207
Both LOD B and LOD C must have a separate COCKPIT_LR mesh that matches the reduced topology of each exterior mesh and replaces completely
COCKPIT_HR. The interior mesh must fit the exterior mesh and the outlining vertices must be snapped. Do NOT use the same COCKPIT_LR mesh for LOD
A, LOD B and LOD C. Make sure there are no gaps between the interior and exterior mesh.

On the LR Cockpit, see Fig. 2.25, you must keep the most visible parts relatively detailed to ensure that the switch is smooth. In tin-top cars this includes
the top of the dashboard and the frame around the side windows and the rear window. In open-seaters the sensitive parts are usually the area around the
steering wheel and behind the driver.

Talking about materials, as a general rule the number of materials should be as low as possible, so the LR interior should only use 1 material, but if the car
has a customisable interior with multiple colour options, more than 1 material is allowed. As a consequence, it is possible to use the detail textures defining
the colours too.

LOD A

LOD A

Fig. 2.25 – Other examples of LOD progression for interiors and cockpit of cars.

4.4 - ABOUT SIMPLYGON

Simplygon is 3D CG software for automatic 3D optimization, based on proprietary methods for creating levels of detail (LODs) through polygon mesh
reduction and other optimization techniques. It enables game development companies to set up automated workflows to generate LOD chains. It is used the
most for character models rather than vehicles.

Pro tip: since the use of Simplygon has become quite popular in the AC modding community, we have to warn the reader that it is a bad practice.

Auto-generated LODs should not be used for your vehicles. Yes, they may actually work and sure, adding LOD models is better for performance, but an
important step in creating them is that you can get rid of objects and materials in total. Much of the cockpit, the instruments, chassis details etc. should be
progressively reduced and deleted, basically thinning out the object tree (called Outliner in Blender and Scene Explorer in 3DsMax). You can easily increase
performance by just removing all those tiny details that require not only a handful of vertices, but more importantly a lot of materials.

That can only be done manually if you want to obtain a good result, because the object removal algorithm isn't very smart: the software cannot discriminate
automatically between the small bolt that should disappear and the head/tail lights that shouldn’t 33. It can't tell which part of the model is least visible to
players. Thus, as a software, it should be simplygone.

Merging “by distance” the way Simplygon does will also often mess up the UV maps which can be very obvious on LOD transition in-game.

The following example (Fig. 2.26) is (from left to right) a 114k tris mesh, subdivided to 615k, decimated to 38k and merged to 49k (numbers differ because
the modifiers are based on face count, not tris). Simply by looking at the mesh of the merge operation, you can see that the normals will be all over the
place.

33
Most of the time you see the front or the rear of the car from further away. Also, the headlight casting effects brought by the CSP mod would disappear too soon in the distance if the actual
glass meshes are deleted in low LODs (B and C; D or lower should be set to load so far that they don’t need headlights).

208
Fig. 2.26 -

The topology will be obviously heavily damaged (Fig.). It's a lot better already when using decimate options (or whatever the tool is called in the 3D
programme of choice), as that can keep edges and wheel arches smooth and not mess up the geometry.

Fig. – (top) The model of a Ferrari 488 Pista mod (a conversion), after triangulation. On the left processed with Simplygon, on the right the original geometry. (bottom) Comparison
between two LOD D for the same vehicle, generated with Simplygon on the left (5.6k tris + 74 Objects) and hand-made on the right (2.4k tris + 2 Objects).

For things like interiors and rims, it’s best to switch to a completely different, simpler mesh rather than attempt to reduce the existing ones (Fig.).

209
Fig. – (left) A wheel mesh obtained with Simplygon from a high-poly object. (right) A simplified wheel mesh that approximates the original geometry with much less polygons.

210
CHAPTER 5 - TEXTURES AND MATERIALS
This Chapter will teach you the basics of digital images and textures, that you will be able to apply when working with them. Materials will be treated later.

Epilepsy warning: the next pages contain pictures with very bright colours. At least they’re not flashing.

2.11.1 – THE PRINCIPLES OF TEXTURES: RGB COLOURS

Each tone that our eyes see can be interpreted as the combination of different base colours, named “primary” because they make up the visible spectrum.

Color theorists since the seventeenth century, and many artists and designers since that time, have taken red (R), yellow (Y), and blue (B) to be the primary
colors (Fig.).

This RYB system, in the "traditional color theory", is often used to order and compare colors, and sometimes proposed as a system of mixing pigments to
get a wide range of colors. In color printing we have a slight variation of the same theme: the usual primary colors become cyan, magenta and yellow
(CMY), often with an additional black colour (CMYK) for inkjet printers and mass production (newspapers for example).

Fig. – The RYB system (on the left) predates the modern scientific color theory and is very often taught in schools, being considered part of the art education. You can see also the
CMY system in the middle.

The additive colour model instead is based on the human perception of colours as studied by science. Every colour can be obtained mixing the shades of
Red, Green and Blue (RGB). These are called additive primary colours (Fig.).

Fig. – From left to right, the additive primary colours.

The result depends on the proportions in the mix. It is customary to define these proportions by an integer between 0 and 255 for each primary colour. So,
the product is a triplet of real numbers between 0 and 255 as you can see in the table below.

Color R G B Why? Because in computers the component values are often stored as integer numbers in the range that a single 8-bit byte
Red 255 0 0 can offer, to save memory. The interval for each individual colour is 0-255 (as in binary 28 = 256 possibilities 34). These
Green 0 255 0 are often represented as either decimal or hexadecimal numbers. The number of possible combinations is
Blue 0 0 255 28 ∙ 28 ∙ 28 = 256 ∙ 256 ∙ 256 = 224 = 16.777.216.

High-end digital image equipment is often able to deal with larger integer ranges for EACH primary color, such as 0-1023 (10 bits), 0-65535 (16 bits) or
even larger, by extending the 24-bits (three 8-bit values) to 32-bit, 48-bit, or 64-bit units. This allows for much more shades of colour to be stored and
displayed. For normal use, one byte per colour is enough, so it is used the standard called True color (24-bit) or direct colour, shown in Fig..

34
Where does the number 2 come from? Well, in binary you only have two numbers, 0 (off, false) and 1 (on, true). They are called bits. And the 8? Well, you have eight bits (so 1 byte). One byte
for example is the following binary number: 11111111 = 255. With 8 bits, this is the maximum value you can obtain, because all of them are set to 1. Zero instead is equal to 00000000 in binary.

211
Fig. - All the 16,777,216 colors of the True color (24 bit) system.

The human eye can discriminate up to ten million colors, and since the gamut of a display is smaller than the range of human vision, this means this should
cover that range with more detail than can be perceived. However, displays do not evenly distribute the colors in human perception space, so humans can
see the changes between some adjacent colors as color banding (that you may be able to see in the image above).

If you see that in the system video settings there is a 32-bit depth under the display mode selection, it’s because 8 bits are for the alpha (transparency)
channel, which is not a color, but rather instructions for how to blend multiple colors together. An alpha intensity of 0 is totally transparent while an alpha
intensity of 255 is totally opaque. Knowing this last information will become useful to understand Assetto Corsa’s shaders later on.

When the proportions of all three primary colors are the same, the result is a shade of grey. With [0, 0, 0] one obtains black, with [255, 255, 255] white
(see Fig.).

Fig. - Black [0, 0, 0], dark grey [128, 128, 128], light grey [220, 220, 220], white [255, 255, 255].

We are going to use this colour model for everything related to graphics, especially textures.

Guessing RGB codes is not easy. If you need to find the numbers representing your favourite color, the best way is to google for "rgb color palette". You
will find many pages that translate colors into RGB codes. Fig. shows three "easy" colors from the CMY system, along with their RGB codes.

Fig. - Cyan [0, 255, 255], pink [255, 0, 255], yellow [255, 255, 0].

212
2.11.2 - MATERIALS AND ksEditor
In the following section you will find information about how to use the AC editor and guidelines for setting up materials.

MATERIAL NAMING CONVENTIONS

In practice there are no rules on material names, as they have NO effect on the physics.

However, to unify the modding world with a common standard compatible with the official content, please use the following conventions for naming them in
your 3D software:

- Firstly, ALWAYS indicate whether it is for the interior or exterior (INT_ or EXT_), then indicate the name that is straightforward (usually indicating the
texture it is using) and lastly indicate if it has to use a certain transparency property, such as AT for alpha test. When possible, use the following names:

EXT_Caliper
EXT_Carbon
EXT_Carpaint
EXT_Details_AT ; for labels and logos (use alpha test mode with transparency OFF)
EXT_Details_Chrome
EXT_Details_Metal
EXT_Details_Plastic ; Details=using the exterior details texture
EXT_Disc
EXT_Engine
EXT_Lights_Chrome
EXT_Lights_Glass
EXT_Rim
EXT_Rim_blur
EXT_Rim_blur_Alpha ; transparent blurred rim part (use alpha blend mode and transparency ON)
EXT_Tyre
EXT_Window

INT_Details_AT ; for labels and logos (alpha test mode with transparency OFF)
INT_Details_Plastic ; Details=using the interior details texture
INT_Details_Chrome
INT_Details_Metal_Black
INT_Details_Metal_Flat
INT_Details_Gauges
INT_OCC_Carbon ; OCC=using the ambient occlusion texture
INT_OCC_Leather
INT_OCC_Alcantara
INT_OCC_Plastic
INT_OCC_Metal
INT_BELT
INT_LCD ; ALWAYS keep the digital display on a separate texture (for racing cars)
INT_FUEL_INDICATOR ; material with emissive for the fuel warning light

If needed, you can use multiple materials (for multiple carbon patterns), in this case, make a distinction with numbers or name (e.g.
INT_OCC_Carbon_Flat and INT_OCC_Carbon_Refl). In any case, strive to differentiate exterior and interior materials.

NOTE: For a more comprehensive guide and community tips to use the editor, see the following thread on the official
support forum: http://www.assettocorsa.net/forum/index.php?threads/ac-editor.10964/

NOTE: to find useful information and request help for general editor and shader-related issues, see the following thread on
the official support forum: http://www.assettocorsa.net/forum/index.php?threads/car-materials-shaders-modelling-stuff-add-
your-knowledge-here.19704/

213
2.11.3 – UV MAPPING (WIP)
GSAGAG

You have to make sure that in the UV map the different UV parts are using the same scale to make sure that any detail texture (metal flakes or carbon)
appear correctly without any stretching and distortion!

Pro tip: always check that your meshes don’t have multiple UV maps, because the first in the list will be the one exported (Fig.).

Fig. -

It is recommended that you use a checkered detail texture for mapping the body and interiors.

214
2.11.4 - GENERAL TEXTURING GUIDELINES (wip)
The supported texture format is: directX DDS

DDS can be compressed and decompressed on the fly as it enters the video memory, which helps reduce strain on VRAM and I/O for the memory. It's also
similar in image quality to PNG, although there are different options to make it more efficient than PNG.
There are also some lossless DDS formats (which will be the same quality as a PNG) but the file size will end up bigger as those are uncompressed.
Most GPUs can hardware decode DDS, they cannot hardware decode PNG.

This format can be outputted from Photoshop (for example) using the specific nVidia plugin, available here: https://developer.nvidia.com/legacy-texture-
tools

As a general rule, we recommend using the DXT5 format with high-resolution textures (with or without Alpha) and 8.8.8.8 format for textures with sensitive
gradient information (RGB maps, detailed normal maps) or small-size detail textures and 8.8.8.8 where Alpha information is included.

We need for every texture a PSD source with layers inside. The layers must be placed inside layer folders with consistent and user-friendly names.

Inside every folder we need a base layer that allows us to change important features of the texture.

Main Texture rules:

1. If the texture has an ALPHA CHANNEL, do not collapse transparent features, keep the transparent features in a specific layer.
2. If there is a normal map, provide in the layer also the greyscale texture so that it can be re-generated with the nVidia tool
3. ALWAYS work with DOUBLE resolution (no more no less) of the target image and shrink it to the right size only when you export the DDS. Test your
results to be sure that the reduction does not spoil the image too much (this could happen with tiny texts or symbols).
4. All PSD files must be in RGB Color 8 bit for channel mode.
5. Name the tex following the naming conventions below. You aren’t forced to, but it can help keeping things in order.

Texture naming conventions for PSD source files:

Skin.PSD ; contains the main body textures
Ambient occlusion
Wireframe (UV)
RGB Map (material specular-gloss-ref map)
Material IDs and zones
Alpha channel

Ext_Details.PSD ; contains rivets, bolts, logos, and decals on the exterior

Diffuse
Normal map
Ambient occlusion
RGB Map (material specular-gloss-ref map)
Alpha channel

Rims.PSD ; contains rim base and rim blur texture plus the blurred spokes
Diffuse
Normal map
Ambient occlusionRGB Map (material specular-gloss-ref map)
Alpha channel

215
Calipers.psd ; contains the brake caliper texture
Diffuse
Normal map
Ambient occlusion
RGB Map (material specular-gloss-ref map)
Alpha channel

Lights.psd ; contains the light texture

Diffuse
Normal map
Ambient occlusion
RGB Map (material specular-gloss-ref map)
Alpha channel

Mechanics.psd ; contains the underside, engine and every part that is not included in the Skin
Wireframe (UV)
Diffuse
Normal map
Ambient occlusion
RGB Map (material specular-gloss-ref map)
Alpha channel

Glass.psd ; contains the glass texture and all similar parts such as black frame
Diffuse
Normal map
Alpha channel

Grids.psd ; contains tileable grids and similar textures (use more if needed)
Diffuse
Normal map
Ambient occlusion
RGB Map (material specular-gloss-ref map)
Alpha channel

Tyre.psd ; contains tyre textures with blur and dirt

Wireframe (UV)
Diffuse
Normal map
Ambient occlusion
Alpha channel

Disc.psd ; contains the brake disc texture and the glow texture
Wireframe (UV)
Diffuse
RGB Normal mapGlow map

Windscreen.psd ; contains the fake internal glass reflection

Diffuse
Alpha channel

INT_Decals.psd ; dials, dashboard symbols, cockpit details and logos, plates, interior bolts and stickers
Diffuse
Normal map
Ambient occlusion
RGB Map (material specular-gloss-ref map)
Alpha channel

INT_Details.psd ; contains coloured gradients and other details to use for smaller objects
Diffuse
Normal map
Ambient occlusion
Alpha channel

INT_Occlusion.psd ; contains the cockpit ambient occlusion texture

Wire frame stamp
Diffuse
Normal map
Ambient occlusion
RGB Map (material specular-gloss-ref map)
Alpha channel

Belts.PSD ; contains cockpit belts

Diffuse
Normal map

Seams.psd ; contains stitching, seams, and similar textures in tileable form

Diffuse
Normal map

INT_cockpit_LR.psd ; contains cockpit LOW RESOLUTION texture

Ambient occlusion
Wire frame stamp
RGB Map (material specular-gloss-ref map)
Material ID and zones
Alpha channel

All the extra textures that can occur and are not mentioned here can have a name that explains in brief what they contain. To see
how to manage textures you can see examples in the example folder in the SDK.

TIRES

CAR MIRRORS
In order to make car mirrors work, a material must be created (the name is not important), and assigned to the mirror mesh objects. The mesh must be UV
mapped with the common/shared texture called MIRROR_PLACEMENT.jpg (Fig.) that you can find in the AC Software Development Kit (SDK), under the
%root%\assettocorsa\sdk\dev\car_pipeline_2.0rev\Common Texture path.

216
Fig. – The shared texture for the configuration of vehicle mirrors. It will be invisible, so it doesn’t matter that it comes with the JPG format instead of DDS. The tex itself has no impact
on the quality of the reflection: the latter is set in the AC graphic options.

This texture is mirrored and the UV must be mirrored as well to make sure it appears correctly. The texture is divided in three areas. CENTRAL must fit the
central internal mirror of the car. The red shows the left, while the blue shows the right-hand side mirror. The 2 points at the center of the lines indicate a
point that must be placed in the center of the mirror to make sure that the cars behind can be clearly seen.

Remember to keep the correct aspect ratio of mirror UV, otherwise the image of the reflection will be distorted. The image ratio of the template is 4:1.

In Fig. below you can find some examples of the MIRROR_PLACEMENT.jpg texture being correctly applied to various mirrors.

Fig. – As you can see, the UV map has been mirrored.

Pro tip: Use MIRROR_PLACEMENT.jpg only for UV mapping, the actual Diffuse tex in ksEditor has to be another shared texture named Mirror.dds, that you can find in the
same path mentioned before.

You should also be aware that in an older version of the AC SDK 35 the template texture for UV mapping was different (Fig.). Avoid using that one, as the
aspect ratio is wrong - it's 2:1, while the mirror ratio used in-game is 4:1; you’d need to scale things vertically by half (0,5) if you used it. We want to keep
things simple, so adopt the updated template discussed previously and shown in Fig.. The old, wrong one is worth of being mentioned because it’s often
shown in old video tutorials you find online from 2015-2016 (it was correct back then).

Fig. – The outdated template for UV mapping AC car mirrors.

COCKPIT DIALS
Cutting photographs to obtain a texture is not ideal at all when trying to capture all the tiny details of the complex dials present on the dash of a vehicle: you
would need a true photoshoot to get the right light, resolution and overall image quality. Most of the time you can’t access a real car, and the only option is
searching online, resulting in a pile of blurry mess, if you’re not lucky enough.

An alternative is found in vector graphics: you can take your photo and give new life thanks to programs like Inkscape or Adobe Illustrator. Drawing the
shapes is very easy, dials are circles most of the time. The output can be at any resolution, due to the mathematical nature of vector graphics. Thus you
have maximum customizability, aside from the fonts, which may be hard to find at times. But you can always draw the numbers by hand if you want.

35
More precisely, the 1.03 release.

217
Fig. – From left to right: original image from photograph (UV mapped); dial vectorized with Inkscape (the “Berlin” font was chosen); font adjusted while still in vector, then dial resized,
colorized and needle removed with Adobe Photoshop; final result in ksEditor.

There is another option however: making them in your 3D editor, alongside the rest of the vehicle model, especially if you are more familiar with the
software. You build them in layers and then bake the diffuse, normal and AO from them (with a surface underneath; Fig.); it obviously does take longer.

218
2.11.6 - EXPORTING TEXTURES AND OPTIMISATION
According to the original Kunos pipeline 2.0, the ~_lod_A.kn5 3D model file of a vehicle must stay below 45 MB (Megabytes), including all textures and
mesh. I'd say a 70-80 MB .kn5 is still fairly reasonable for modern hardware.

In any case, the textures play a huge role in determining the final size, so they have to be very well optimized. You won’t get the model below 50 MB
without compressing most of them (if not all).

When the PC runs out of memory, the graphics engine starts to reduce texture size automatically, however this is done in a way that does not ensure high
quality, so we have to avoid it in all cases and stay below the 44MB limit for the LOD A .kn5 model. Since the textures are directly taken from the LOD A,
lower resolution LODs (so B, C, D, and lower if present) should be a lot smaller. See the following values as reference, depending on the type of vehicle.

LOD A: 35 - 50 MB (any official car)

LOD B: 850 KB - 2,5 MB (Alfa Romeo 155 v6 – Ferrari SF70H 36)

LOD C: 170 – 900 KB (Ferrari 458 GT2 – Ferrari SF70H)

LOD D: 50 - 500 KB (Ferrari 512T – Ferrari SF70H)

NOTE: As a general guideline, you can use the DXT5 compression for high-resolution textures. Use AL (8.8, alpha luminance) mode for grayscale textures
with sensitive gradients. Use RGB (8.8.8) mode for map textures and ARGB (8.8.8.8) for NM textures with fine details. Remember to keep a complete set of
ALL of your textures without compression as a backup so that if they have to be outputted again, there is no quality loss due to the added compression.
NEVER use the DXT1 compression mode. Keep the PSD files organized and updated so that they can be used to re-output textures if a change is necessary
after the delivery of the model. Do not work on compressed DDS textures, always make your changes in the PSD and keep it updated along with the
exported textures so that the latest version of each PSD file corresponds to the latest DDS output.

Below you can see some examples of textures, along with a reference size in pixels. Taking into consideration priorities to maintain a high-quality look, you
can use larger textures provided that you optimize other textures better and you do not go over the limit:

Skin_00.dds ; (the main body) must be 2048x2048 when it have sponsor and livery on. If is flat, can be 1024x1024 and saved as 8.8.
Skin_00_map.dds ; 512x512 ARGB

Rim.dds ; 512x512; It can contain a base material for rim blur non-transparent parts.
Rim_map.dds ; is half of the rim size and saved as ARGB.
Rim_Spokes.dds ; 256x256

INT_Occlusion.dds ; 512x512
INT_Occlusion_map.dds ; 512x512 saved as 8.8.

INT_Cockpit_LR.dds ; 512x512 or 1024x1024 depending on the car roof if open or close. DXT5 compression is enough.

INT_Decals.dds ; 1024x512 DXT5

INT_Decals_NM.dds ; 1024x512 in DXT5 or ARGB.

Lights.dds ; 512x512 ARGB

Lights_NM.dds ; 512x512 ARGB
Lights_Map.dds ; 256x256 ARGB

Tyre_D.dds ; 1024x1024 DXT5

Tyre_NM.dds ; 1024x1024 DXT5

Tyre_blur_D.dds ; can be 512x512 or 256x256

Tyre_blur_NM.dds ; can be 512x512 or 256x256, save as ARGB.

Disc_D.dds ; can be 512x512 DXT5 when very visible and half the resolution when the disc is small/not very visible or there are no details.
Disc_NM.dds ; can be 512x512 ARGB when very visible and half the resolution when the disc is small/not very visible or there are no details.

Disc_Blur_D.dds ; half of the non-blurred disc textures.

Disc_Blur_NM.dds ; half of the non-blurred disc textures.

Disc_warm.dds ; always 128x128.

Damage.dds ; 2048x2048
Damage_NM.dds ; 512x512
Damage_Mask.dds ; 256x256

Dust.dds ; 1024x1024 DXT5

INT_Materials_D.dds ; 512x512 or less, depending on image content.

36
Take the cars from the last DLCs to have an idea of the highest standard followed by Kunos. The quality of the models in AC had been increasing as years went by. Moreover, F1 cars are
commonly more expensive in terms of file size, given the amount of details they have.

219
INT_Materials_NM.dds ; 512x512 or less, depending on image content.
INT_Materials_map.dds ; half of base texture resolution, save all as ARGB (especially NM and RGB map) to keep the quality of the gradients.

Mechanics_D.dds ; can be 1024x1024 if it contains a visible engine. If not, it can be half. Save as DXT5.
Mechanics_NM.dds ; can be 1024x1024 if it contains a visible engine. If not, it can be half. Save as ARGB.
Mechanics_map.dds ; always half of the diffuse one. Save as RGB.

Belt_D.dds ; can be 128x256 ARGB and must be vertically tileable.

Belt_NM.dds ; can be 128x256 ARGB and must be vertically tileable.

Stiching_D.dds ; can be 256x128 vertically tileable, save as ARGB.

Stiching_NM.dds ; can be 256x128 vertically tileable, save as ARGB.

Calipers.dds ; 256x256; in some cases can be part of the Mechanics textures if your car is a ‘60s open seater racing car. Save as DXT5.
Calipers_NM.dds ; 256x256; in some cases can be part of the Mechanics textures if your car is a ‘60s open seater racing car. Save as ARGB.
Calipers_map.dds ; is always half the size of the diffuse. Save as RGB.

Grids tileable and various similar 256x256 or also half, depending on the image detail, export as ARGB.

OPTIMAL USE OF TEXTURE SPACE

When you use the space in the textures, you must make sure to optimize everything the best you can. Maximum means that all available space must be
used. You have to plan before you start to make sure that you use your texture space in the most efficient way.

An example for the decals diffuse texture with a good use of space is in Fig..

Fig. -

Include the alpha channel both in the diffuse and the NORMAL MAP to make sure it suits every shader type.

In Fig. you can see the normal map texture with the alpha channel visible. The uncompressed alpha channel defines the outline of the details.

220
Fig. -

Look at the following examples for the occlusion or the car skin textures to see how to optimize the available texture space:

The parts use the maximum space available and and the padding (extension borders) fill up the remaining space. This arrangement allows us to reduce the
texture to as low as 512x512 (uncompressed) but keep the occlusion gradients at an acceptable level of quality. It is recommended that all interior objects
with an AO map be mapped on a single texture.

The same material groups must use the same scaling to make sure the detail textures appear correctly.

Fig. - especially on the exterior, textures must be well organized.

2.12 - BAKING THE AMBIENT OCCLUSION

This topic deserves an entirely separate paragraph due to its importance.

221
To have a more realistic illumination effect, we need to bake the ambient occlusion map for the exterior of the car, the rims, the lights and the interior of the
cockpit.

Fig. –

Take the exterior, and remove all the DECALS objects. If you have a movable wing move it a bit far from the body. Bake the Ambient Occlusion at double
resolution (4096x4096).

For the cockpit: remove all the DECALS for logos and the stitching. For baking the interior, place the doors like in the image. For baking the steering wheel,
remove everything else and bake it facing UP.

NOTE: look the pink pieces, they don’t take occlusion, but they influence the cockpit for them. They will be placed under a different material.

Fig. –

Keep the doors far enough to avoid a dark occlusion on the borders and the doorsill.

A baked texture is never how we want it in the end. We suggest to edit it in Photoshop and create softer intersections with objects. Random pixels can
create a bad effect when they are in a visible place. Use Photoshop to make the transitions smoother where necessary. The AO textures are globally a kind
of soft gradients. Avoid sharp, pixelated and unclean transitions.

222
Fig. -

IMPORTANT: when baking make sure you use a wide-enough padding to avoid bleeding black artifacts around the edges with low-resolution textures.

NOTE: With high-quality occlusion maps, such as those baked using V-Ray, will require less retouch in PS later on so it is worth spending more time on
how to bake the textures at the best possible quality.

Substance Painter AO is better than CM’s one.

223
2.13 - SKINS and LIVERIES (still very WIP)
So, you want to paint cars. Where can you start from? It depends.

• If you want to make liveries for official content or mods from the community, your starting point consists of templates.
• If you’re the creator of your model and you have all the source files, you can make skins very easily, and you should include templates if you want to
share your mod and let people create their own liveries.

You will work with textures both ways, so first of all you need a tex editor. Some of the programs you can use are listed under THE TOOLS YOU WILL NEED
at pag. For the examples you see here I will be using Adobe Photoshop for the most part. Feel free to use other image editors.

You will also have to grab the NVIDIA Texture Tools for Photoshop (latest version available in the attachments of this manual). The reason you will need this
is to save your template into the DDS file format.

2.13.1 – SKIN FOLDERS AND FILES

The final products (the liveries’ textures and files) will be archived in subdirectories under the FIN\skins folder of your car mod (remember? See par. 1). That
is also the path where you will have to install any skin mods you can find online for that specific car.
The skins folder has a subfolder for each livery, and its name must respect the same rules as the FIN folder, so you must use the Latin alphabet and
underscore to replace spaces between words. There are no particular rules about uppercase or lowercase text, and you can use capital letters. Do not
overcomplicate things too much, keep in mind that there’s a 32 (or 30?) character limit on the folder.
Pro tip: You can also give a specific order to your skins: AC looks for numbers which are in front of the folder name. The newer cars from Kunos have skins structured like
this: 00_clubsport, 01_cup_01, etc.
If you want your favourite skins to be chosen by the AI more often, you need to have a lower number there. For example, if you use a structure like this: 00000_axa_91,
00001_loeb_racing, etc., in the File Explorer window, sorting by name, the 00_clubsport skin will be between them, but the simulator will choose 00000_, 00001_, 00002_,
etc. one after the other. With more digits you won't get overlapping, even with many skins. Usually three digits are more than enough.

For our example we will work with the Ferrari 458 GT2, under %root%\assettocorsa\content\cars\ferrari_458_gt2\skins. Our livery will be called Your Skin
Name, under the your_car_name\skins\your_skin_name folder.
Inside the folder of each livery several files must be included:
- skin.ini
Sahfdhòsaf
[driver_70]
SUIT=\sparco\white
GLOVES=\sparco_racecars_tide_rg9\white
HELMET=\helmet_1975_grey\plain

[CREW]
SUIT=\type1\grey_black
HELMET=\grey
BRAND=\lamborghini

- ui_skin.json
Open this script with any text editor. Here you can manipulate the info on screen in the game UI, for example the name of the pilot, the racing team and
other details.
{
"skinname": "",
"drivername": "",
"country": "",
"team": "",
"number": "1",
"priority": 3
}

If you put the skinname as “Undefined”, the name of the skin will be the name of the folder the file is under. In our example it would appear in-game as
your_skin_name instead of Your Skin Name. Priority?

- preview.jpg
This is the image for the preview of the vehicle in every GUI of AC and CM. It’s basically the car’s business card.

CARPAINT.dds

Whenever you make a new skin you will want to copy ALL the files from another pre-existing skin folder of the same car.

224
2.13.2 - WORKING WITH TEMPLATES (wip)
How do liveries work in AC?
The way the texture system in AC works is that every car loaded in a session with a determined livery uses the default textures present in the 3D model,
unless the skin folder for that livery has got a replacement. The name of the tex file must be identical to the tex present in the model. So if the default texture
for the car's paint scheme is called "Skin.dds", your replacement must be named identically for it to be loaded.
The same goes for all the other tex: they can be replaced/overridden with an individual skin. This means that for example tires work the same as car bodies,
and that you can make whitewall tires for cars that don’t fit them by default 37 (Fig.).

Fig. – Editing the tire diffuse texture of the Ferrari 250 GTO. With Paint.NET it’s really easy to work with DDS textures. In this case the tex is called Tyre_Diff.dds. Ferrari, forgive me.

This allows for an easy and quick edit of the colours of any part of the car, without changing anything on the model 38. That’s why they’re called skins.
To discover which texture is used in the diffuse slot of the body paint, using the CM showrooms is very useful (Fig.), but will not take you much further,
because knowing the name of the texture is one thing, having it UV mapped is another.
If you’re editing a vehicle made by another person you don’t have all the source files, so you will want to pick up a car template, if the creator made it available.
All the official cars by Kunos do have the templates (thanks to the devs!). They are located in your AC install folder, under the
%root%\assettocorsa\sdk\dev\skin_templates path (Fig.). Good mods do include the templates in their files, and the highest quality ones will put them in the
skins folder, or in the aforementioned path if you install them correctly.
For our example, let’s take a look at the folder for the Ferrari 458 GT2 by Kunos. Figure shows the template file (Carpaint_00.psd), along with some convenient
textures for changing the rims’ and headlights glass colour separately.

Fig. – The folder of the Ferrari 458 GT2’s official skin template, from the AC SDK.

At this point the question is obvious: what is a template?

It is a file which contains the car body AO (Ambient Occlusion), which being obviously UV mapped, allows us to create car liveries with correct proportions
and without distortions of the various sponsor logos. It comes in the PSD format, typically (natively) created and saved with Adobe Photoshop.
Hopefully your editor will be able to open the .psd file. Do not worry about the other files for now. The users of Paint.net might have to install a plugin to be
able to use psd files.
I recommend making a backup copy of the original template folder/files before starting to modify it/them. You may accidentally delete textures or save your
PSD project with collapsed/rasterized levels and not be able to revert your changes.
To optimize the workflow, you can move the aforementioned copy anywhere you want on your PC where you are comfortable. If you’re working on your own
mod, use the PSD folder under the project’s DEV directory we talked about at par. , see Fig. . Put also all your reference material there.

37
Remember that tires have also a texture for blurring, so you have to change the color of two textures.
38
Other application examples: clean windshield dirt with totally transparent texture; change brake calipers colour, tint the windows.

225
Getting started with texture editing: Layer Management
We will continue the explanation on our example with Adobe Photoshop. You should see something like Fig..

Fig. – UPDATE PHOTOOOOOOOOOO

Photoshop is an advanced image editing program that relies heavily on the use of layers. A layer is a 2D plane on which you can operate freely. Layers are
stacked on top of each other according to a hierarchical order that you can establish and change at will, in which the top layer covers the lower ones.
To make a metaphor, it is as if we first spread a coat of paint on the bodywork (first layer), and then lay another layer on top of the first layer (second layer).
Obviously the most superficial layer will cover with its own parts (where the paint was placed) only the relative parts of the layers below.
The layer list is shown on the right column of Fig.. The layer that is highest in this list is the one that is most superficially located, compared to the other
layers below it. You can change the order of the layers by dragging them with the mouse.
A layer can be shown or hidden. This is especially useful when working since we will have often need to look at the contents of the underlying layers. The
icon that indicates that the layer is shown is the small eye (Fig. , by clicking on it you can change the status from shown to hidden, and vice versa). Levels
hidden at this stage will not be shown in the final skin either, so make sure that you have activated all the levels you intend to show (and vice versa, that you
have hidden all the ones you want not to be visible), before saving the file.
It is possible to create or remove layers: clicking on the Create New Layer icon will allow us to create a new layer, while clicking on the icon of the trash can
will delete the selected layer.
To work on a layer, simply select it (make sure you have hidden the upper layers first) with the mouse. The layer we are working on is always the one
highlighted on the layer list. Layers also present a preview image showing what that layer contains.
Layers can also be contained in folders, and in this case to access them you will need to open the respective folder.
Going back to our Ferrari 458 Italia example (Fig.),
• The first layer is the w226ireframe layer. It basically shows you how the car is shaped and UV mapped. Use the grids to line things up.
• The OCCLUSION layer includes the shadows on the car and blocks out the regions of the template that you will not see on the car.
• The Side Panels layer contains the side panels. Easy right?
• The base color layer that allows you to change the colour easily may or may not be present, depending on the vehicle. For example, the template of the official Ferrari
458 GT2 doesn’t have it.
• The Note layer is only there to display the note. The note says “Note: Alpha channel controls detail map application, black=detail”. This layer can be ignored or deleted, as
it does nothing here.
Pro tip: some templates contain a pre-made skin, for example look at the official template of the Tatuus FA01. This is to simplify the work of correlation between the body parts
of the 3D model and the 2d template, since in some cars this step is not immediate. It is therefore necessary to delete the layers of the pre-made skin first, if one wants to work
on a completely bare and clean body. In the case of the Tatuus FA01 template, these layers are called Color base, Color add and sponsor.

226
You will find out that you will want to keep your work space tidy from the beginning to insure a nice and streamlines process while you work on your
project. Practicing good folder management will enable you to help with this process. It is not uncommon that you could have over 60 layers in your PSD
file. You don’t want all those just floating around. It would take you forever just to find a logo you want to move over by a few pixels, for example. Here I will
show you how I take care of my layers so that they are neat, tidy, and if I share my work with someone else they will be able to get to work instead of taking
a really long time just to learn what everything means.

Fig. –

Part 1: Color
First of all I delete any layers off of the template that I know I will not need. In the case of Assetto Corsa this almost always mean deleting the Note layer.
After that I establish where the base color of the car is. I make a folder called ‘Color’ and but the base color inside of that. That folder will contain all the
color layers for the car. In the case of a Corvette it may just contain a layer that is colored yellow. If that Corvette is in the GT2 class, for example, then a
Black Layer would be present too so that I can paint the stripes.
Part 2: Logos
Above the Color folder would be the ‘Logos’ folder. Within the Logos folder I usually have folders called ‘Left Side’, ‘Right Side’, ‘Center’, ‘Hood’, ‘Back’, etc.
Within each of those individual folders I would have a logo named ‘Dunlop’ for example. Of course it would make sense if that logo was a Dunlop logo. If
there happens to be two Dunlop stickers on that part of the car then I would name one Dunlop_upper and the other Dunlop_lower. Personally I try to name
them in relation to the template, NOT in relation to the driver. That choice is up to you.
Part 3: Number plates
Above the Logos folder is where I put my numberplates. Sometimes I have to make my own nameplates and other times I am able to get them from another
source. If you are doing a series of cars it is OK to use logos and numberplates from the other cars. I would recommend it in order to preserve the
similarities between the cars, as this is what usually happens in real life. If you are in the position that you must create a multi-part logo I would suggest that
you put all the individual parts in their own folder. Because of the nature of logos on cars there is a good chance that you might use hat logo on another
part of the car. If it is in a folder that you will be able to manipulate it faster and more reliably than 4 separate layers.
When I work on the car I typically only work of half of the car at a time. The reason I do this is because car are fairly semictrical down the center. Once I
have completed my work on the left side of the car I can just copy all the stuff I need for the right side of the car. This usually means that I will copy the
‘Right Logos’ folder and rename it ‘Left Logos’. I would then drag the entire group of logos to the other side of the car and then rotate and adjust each one
individually as needed. Using this technique will decrease the time it takes to make a skin my quite a lot. You can also use this method with numberplates
and even color designs that you may have made earlier (this is why I like using the pen tool with its easily adjustable masks).
Remember that the most effective way to manage your folders and layers is the way that YOU decide. I remember that I used to group folders by the rename
of the sponsor and that worked quite well for me. Once I got better with the pen tool I found out that I could streamline my process by doing only half of the
car at a time. That decision ultimately changed the way I organize my sponsor logos. It is always p to you and the way that you like to do things. The way
you create cars will change throughout your growth as you learn new things.
Part 4: Rip and Trash Folders
Extras: a Rip folder and a Trash folder.
I have recently implemented a Rip and Trash folder into most of my projects. Let's start with the Rip folder.
A Rip (pronounced the same as when you rip a piece of paper) is when you take a piece of material from something else. Like the internet for example. In
my case I use Rips for reference while I paint the car, helmet, gloves, etc. I put these Rips (images of the car) in a folder on the topmost layer. The reason it

227
will be on top is to ensure that the Occlusion layer does not get in the way of the rip. Remember that in many cases the Occlusion layer contains shadows
which may produce errors when you are trying to sample colors from the rip.
The Trash folder is what it sounds like. It is where you put the stuff you no longer need. You many think, "Can't I just delete that stuff?" Well, you can if you
want to. The usefulness of the trash layer is that you can throw things away like the original sizes of logos for example. If you size your logo too small then
you can barb the larger one out of the trash and start anew. You can also put old or failed designs in the trash. If the time comes when you want to revert to
an old design just go trash diving! The trash layer is at the bottom of the PSD and hidden.
Well, you have now completed your first skin. Go ahead and try painting on the base layer with other colors. Can you make the roof green? How about a
purple bumper? Can you get the door handles to be yellow? Take some time and explore. For now you can paint on the base layer any way you want. For
the more experienced folk try making new layers just above the base layer. Make a new layer for each color for more control. Experiment with the shape
tools and the pen tool.

Getting started with texture editing: Photoshop basic commands, tips and tools
In Fig. are presented the basic Photoshop commands useful for making a good skin.
1. Move selected area: allows you to move a selected area with the mouse. (hold down the left mouse button).
2. Rectangular area selection: allows you to select a rectangular area on a working layer (hold down the left mouse button).
3. Polygonal area selection: allows you to select any irregular area on a working layer (we will see later how best to use this command).
4. Color picker: allows you to choose a color that is on the working layer, and to select it as the color of tool 11 to be used for tools 5 and 6.
5. Brush: allows you to lay down a color using the mouse cursor (hold down the left mouse button). The color is selected in tool 11.
6. Bucket: allows you to color in the same color (selected in tool 11) an area previously selected with tools 1 or 2.
7. Text: allows you to write text on the working layer.
8. Rectangle (shapes): allows you to create a rectangle (or lines, circles) on the work layer of the color selected in tool 11.
9. Pan: allows you to scroll the working plane (hold down the left mouse button)
10. Zoom: allows you to zoom in or out on the working layer (to zoom out click right click on the work plane and then "zoom out")
11. Select colors: allows you to select up to 2 colors. These colors are used by the other tools
12. Clone stamp: allows you to clone some painted sections on the body to paste them in a new location.
Important: holding down the left mouse button on a command will open a window showing the other commands related to it (which are selectable by clicking
on them).

Finally, there is the command to undo one operation, which is activated by pressing once the key combination CTRL+Z .

- You can plot paths without holding a key. Just use the Pen tool and make sure it is set to the correct type (in the top ribbon you can set it to draw a path
only, or make it a shape, etc.).

Hide the wireframe layer by clicking the eye next to the layer and save your psd. Remember, it should be already called ‘CARPAINT.psd’ and located in the
‘My_First_Car’ folder.

Texture export
Now it is time to export the PSD project as a DDS. This is the most experimental part of this Lesson. There are hundreds of setting combinations that will
work. I’ll show you what settings I use (it might be a good idea to Flatten your image before you export it).
In Photoshop go to File > Save As. In the Format drop-down menu chose the D3D/DDS option and click save. You might get an overwrite warning.
Overwrite it. Now a new menu should pop up titled NVIDIA dds Format.
'DXT5 ARGB 8 bpp | interpolated alpha' . The ‘Generate MIP Map’ radial button should be selected and the number in the box should be set to '6'. Click the
MIP Map Filtering button and chose the Blackman Filter type then press ok to confirm.
Photoshop should take a few seconds to create the DDS file. It took my computer about 2 seconds for this orange skin. The amount of time will increase
depending on the complexity of the skin.
NOTE: If you are using Photoshop CS2 and you are getting the image below then unckeck the box that has to do with 'Alpha' when saving the file. (Thank
you to many people for finding this out and to JMNick1 for the image. In simple terms, CS2 was not made to deal with alpha layers and DDS files at the
same time.
If you are using Gimp you will want to use the 'Export' feature to get your DDS. In Gimp navigate to File > Export As. In the Name: field remember to
rename the file extension. In this example blahblahbhal. Navigate to your desired export location and then click Export. After you do that a window will pop
up with some options. I suggest using the options in the image below.
Pro tip: The DDS export of GIMP is not the best, but if in doubt you can always export as PNG and convert the tex to DDS with another tool (e.g. DXTBmp).

A note about the saving format: What are the differences between the two export types?
Type: ‘8.8.8.8 ARGB 32 bpp | unsigned’ vs 'DXT5 ARGB 8 bpp | interpolated alpha'
Full Racing Grid PC Stress: Very High vs Medium
File size (per file): 21 MB vs 5 MB
Quality: Best vs Good
Colors: Excellent vs Good
Saving time: 2 seconds vs 12 seconds
It is your choice which one you use.
228
Showroom setup and skin preview
How do we look at the result on the car after working on skins? The program that you will use for the time being is the showroom found in AC itself
(acShowroom.exe, located in the main folder of your install). You can open it using the 360° button when you are viewing the specific car info in the
launcher (AssettoCorsa.exe, Fig.).

Fig. – In yellow is highlighted the vanilla showroom start button. This method is quite tedious, as you need the launcher to be open at all times.

It can also be launched manually, without having to start the entire game. However, you will have to view the desired car and skin combo in a race session,
at least the first time, before using this shortcut. Doing so creates a “pointer” that acShowroom.exe uses later (needs further research). For better
accessibility when skinning you can link acShowroom.exe to your desktop or even bind a key on your keyboard if you want.
If you use Content Manager, you can also launch a new type of car visualizer via the Showroom button in the lower part of the screen, visible when you’re in
the Content > Cars section (Fig.).
Be aware that the experimental showrooms brought by CM shouldn’t be trusted when working on your vehicles. This is valid physics and visuals wise.

Pro tip: If you want to use directly the game to view the car instead, especially when working with CSP, using CM is easy, just start the session every time from the Drive tab.
But what can you do if you don’t have Content Manager (the old school way)? You can launch the session directly, adding the lines below to race.ini (file under the path
%root%\ssettocorsa\cfg).
[AUTOSPAWN]
ACTIVE=1

Then start AssettoCorsa.exe. Obviously you have to specify the right car and track. This is a really old method, but once set properly it works every time and you don’t need
extra tools/launchers. Keep in mind that if CM is already installed and set for the race it overrides race.ini with its own parameters, so this method won’t work as intended.

Protip #2 - Want to have your own music in the showroom or silence it completely? Navigate to C:\...\assettocorsa\content\showroom. Open the showroom
folder of your choice and you will see track.wav in there. Have fun listening to those beatz, or not!

Protip #3 - You can window the AC Launcher with F11.

Install good mod showrooms. The official ones are not too useful.

2.13.3 –
If you don’t have a template, you will have to extract the body paint diffuse texture from the 3D model and modify it.

There are sometimes problems due to poor quality mods which don’t employ UV maps and texture atlases.

229
FAQ
QUESTION [1]: My Ferrari is always a shade of red no matter what color I paint it! What's going on?
ANSWER [1]: You need metal_detail.dds in your skin folder. It can be found in one of the default skin folders. I suggest using the one from Blanco Avus.

Q [2]: My preview.jpg does not work in the game.

A [2]: If the folder of the skin has a space in the name then replace the space with an underscore. There is also a 30-character limit on the name of the folder.
Example: Rename 'Red Hot Ferrari 458' to 'Red_Hot_Ferrari_458'

Q [3]: Should I create and use skins for my vehicles with a 2K or 4K resolution?
A [3]: The key for skin resolution is your graphics card's video memory (VRAM), rest of the specs of your system are relatively unimportant. 4K skins take up four times as
much memory as 2K skins (typically 20MB vs. 5MB each), so if you have a race with 20 cars, multiply the numbers and you're using up a good chunk of memory which can
be a problem.
My advice would be to mix 2K and 4K skins: if there's a livery you know you like and will definitely use for racing or that's very stylish/iconic, create/use a 4K variant. If the
skin is only used to get more realistic looking AI opponents use the 2K variant. This way you will rarely run into performance problems.

Q [4]: Which DDS settings do I have to use?

A [4]: Typical Settings: DXT5 ARGB 8 bpp interpolated alpha or 8.8.8.8 ARGB 32 bpp unsigned, with Mitchell Filtering, generate 6 MIP Maps.
However you find the settings at pag.
It shall be noted that with any sort of DXT compression there are always artifacts, as the whole texture is split in 4x4 pixels and is then compressed. In Fig. there’s a
comparison between different texture sizes and DDS compressions (8.8.8.8 is no compression).

Fig. -

Q [5]: Do I have to make a different skin for each "step" or "drift" variant of my car?
A [5]: No. The model is the same, so the texture names should be identical. Just copy the skin folder to the appropriate "step" or "drift" folder.

Q [6]: What keyboard shortcuts can I use while I am in the Showroom?

A [6]: See par. of PART 1: AC User Manual, equal to pag. of this book.

Q [7]: How can I see a thumbnail preview of DDS files in Windows Explorer (like as if I was looking at my pictures folder)?
A [7]: Install Paint.net, even if you might not use it. There are other visualizer software (even paid, like MysticThumbs), but that’s the easiest solution.

Q [8]: After exporting my skin texture in DDS with DT3/DXT5 compression from GIMP there are artifacts in the paint (Fig.). How can I fix them?

Fig. – (left) If you don’t see the banding in the paint, you’re blind. (right) I’m joking. Here’s a version with exposure and threshold adjusted to see the artifacts clearly.
A [8]: In this example, the Alfa Romeo GTA skin template has got four AO layers: Wireframe, Chrome, Layer 1 & Layer 9.

230
PSD files are Photoshop specific and only reverse engineered to GIMP (plus GIMP doesn't support modifier layers and some other PS things) so to some extent you do
need to change how the layers are set up. To make it work you may need to remove one/some/all of the AO layer(s) from their group(s). In the Alfa there’s a group called
"Ambient Occlusion" but only "Layer 1" is the actual AO (Fig.).

Fig. - 'color' is the new layer for painting the skin onto. The layer group in Photoshop (right) does something with transparency that GIMP (left) isn't displaying correctly, and here it
has been removed.

Q [9]: There are unwanted numbers on a custom paintjob. I started painting a livery for the Huracan GT3 but for some reason the game insists on slapping #63 and the
Italian flag motif on top of the skin (as seen in Fig. ). They appear both in Showroom and in game. Needless to say I'd very much like to know how to get rid of them.

Fig. – Illustration of the problem.

A [9]: Look in the Kunos vanilla skins for an image named extra_logo.dds... probably you need to make it transparent.

If you just want simple colours: edit the metal_detail.dds rather than the skin.
2.13.7 - CONVERTING SKINS
A special mention for conversions has to be done, since some people were wondering if it is possible to convert skins from other games to AC.

Yes, it is possible, but not always. Porting skins does only work if the 3D model for the car is the correct one; more precisely it must have an UV mapping
that corresponds. This should only happen if the same car mod is available for AC and another title with an identical model, or if we’re talking about a
conversion. There are some cases where the same model is used between multiple games, then you could potentially use the same skin with little work. But
that’s very rare (almost never happens). Not to mention that materials and shaders are usually handled differently between several games/simulators.

I have tried a few and it had worked but some textures do not line up correctly. At times it was just a matter of renaming the files and they appeared in-game
on the car without issues. But this is easier said than done.

231
CHAPTER 6 - VEHICLE COLLIDER
Collisions between vehicles are one of the most resource-demanding activities of any game, especially if 20 cars collide in a turn at the same time. Physics
calculations are very CPU intensive (especially when everything needs to happen in milliseconds). Therefore using a high poly mesh for collisions would be
almost impossible. To optimize such scenarios, a simple collider shape is used to calculate collisions between car bodies and track objects (Fig. 2.27). The
collider shape must be a simple solid object with as low polygon count as possible (40-60 triangles), without any UV or texture.

Fig. 2.27 – Comparison of collider meshes for two different cars.

6.1 - RULES FOR VEHICLE COLLIDERS

At this point let’s see which are the main principles we’ll have to follow to make a correct collider model:

1. The collider’s pivot point (=its origin) must be in the 0, 0, 0 coordinates and have the same orientation as the wheel dummies. This is fundamental if you want to avoid
any trouble with positioning the mesh correctly (especially if you have to adjust its location).
2. Do not use empties, the only thing that matters is the mesh. Do not set any dummy as parent of the 3D collider.
3. The collider should have no more than 40-60 triangles.
4. The collider must not extend below the floor of the car (so DON'T go as low as the ground); look at Fig. 2.28.
5. The collider must have no holes. The mesh must be completely closed.
6. The mesh must have a material without textures called “GL”. Make sure you add NO textures!
7. Once the mesh is done, simply export the kn5 from the editor, using the name collider.kn5.
8. The collider must be placed in the same folder as the car LODs, so the FIN folder.
9. A shader called “GL” must be assigned to the collider inside the SDK editor, look at Fig. 2.29. This is a special shader specifically made for a mesh that is not rendered
in game and used only for collisions.
10. AC reads colliders differently than any other .kn5 model: every object transformation is ignored/skipped, so the vertex coordinates have to line up with the car while
having 0 rotation and 0 translation, except if you use Blender. Any "change XYZ to X-ZY" settings in FBX exporters does not apply.
11. When testing colliders, it is highly recommended to disable CSP.

Fig. 2.28 – Visualization of the correct placement of the collider. There mustn’t exist vertices under the floor, as the collisions of the 3D mesh with ground are buggy. Those are
managed via secondary types of colliders, in the colliders.ini script (see p.).

232
Fig. 2.29 – Selection of GL shader for a generic car collider; geo_collider is the name of the mesh, and it may vary if you named it differently.

Pro tip: Blender's fbx exporter automatically adds a 90-degree rotation to every root object to switch to the fbx coordinate system, so you'll have to pre-rotate it the other way
to fix that, in Edit Mode (Fig.). This is necessary because the 3D collider is an exception in AC.

Fig. – The direction of the rotation depends on the Y axis, in fact I applied a -90° rotation along the X axis. Based on the orientation of the car, you’ll have to rotate the collider of ±90°.

When doing so, in ksEditor the collider mesh will appear rotated vertically (Fig.). Do not worry about it, everything will be fine after the .kn5 export.

Fig. – Before and after the KN5 export from ksEditor.

- You can check with CM showrooms if the position is correct (Fig.), but do not rely too much on them: they’re quite buggy, and it is best to use the Test
Pad track (available in the attachments of this manual, or here: https://www.racedepartment.com/downloads/test-pad.10703) to check the collider model extensively.

233
Fig. – Screenshots taken in vanilla AC (CSP disabled). Testing all the various curbs and roof heights to determine whether the collider is positioned correctly or not. Aside from car-to-
car contact, this is still the best way to check.

- Just to remind you rule #11, avoid testing colliders with the CSP mod enabled. In my case, when I enabled it, often the car went through the wall(s), or
manifested other various collision detection bugs, especially with the roof test (Fig. left). I don’t believe the track itself is buggy, because in vanilla it works.

- The collider.kn5 is also used (within the car-related assets) to check for DLC presence; DLC collider models have a tag in the file checked by AC against
the Steam (Valve Corporation) licencing service, so if a mod uses a collider copied from a DLC car, and you do not own (or do not have installed) said DLC,
your game will crash.

But why do modders do this? Well, because it requires the lowest effort possible. Copying is much faster and easier than creating a brand-new mesh.

You can try swapping the collider.kn5 with one from another car (possibly not from a DLC pack) just to check. If that's what solves the issue (i.e., the game
crashing), then replace, edit, or create your own collider. I'm pretty sure you can just zero the tag out in the file, but you'd have to understand the .kn5
format because there are differences: .kn5 version 5 has no tag and .kn5 version 6 has it. Sometimes (luckily) the logs are pretty clear:
LOADING MODEL content/tracks/ks_nordschleife/25.kn5
VERSION=6
[CSP SAYS] Required DLC might be missing

However, it’s easier to not worry at all about .kn5 versions and just do everything properly, from the beginning. Ideally no mod should require DLC packs,
but there is an exception to this rule, that is when someone creates a tuned version of an official Assetto Corsa vehicle, thus models or data are used as part
of the project, but they can’t be redistributed due to copyright; see page for the discussion of this topic.

It shall be noted that taking a collider from a car and copying it to a different one can cause misalignment due to possibly different reference systems in the
models, and thus collision detection issues, which you can’t fix with the data files 39. I recommend to avoid swapping colliders entirely. That’s another bad
modding practice on our “list”.

Low quality mods keep having DLC-tagged colliders that prevent users from enjoying the assets freely, while an accurate collider takes 10 minutes to
model. When you encounter problems like these, avoid the content from these kinds of authors.

Now, there are many ways you can make a 3D collider from scratch, sculpting it from a cube or using some tools. In the next paragraphs I will consider
some methods, either by hand or semi-automatic. Two software will be used: 3DsMax and Blender. Obviously the explanations will be pretty slow to let you
understand everything; you will find plenty of shortcuts to do this or that.

6.1.1 – FAQ
QUESTION [1]: My collider mesh shows up rotated 90° in CM showrooms.
ANSWER [1]: You shouldn't trust the CM showroom to show you where colliders are. But if it works that way ingame too then you have to open the collider
model, rotate the mesh (not any other object, it has to be the mesh 40) and re-export it.

QUESTION [2]: What’s the difference between the collider mesh and the colliders configured with colliders.ini in the vehicle physics data files?
ANSWER [2]: The mesh adopts the collision detection system of the simulator’s graphics+physics engine, and is used for impacts with other vehicles and
track surfaces with the -WALL tag; the boxes managed with the script are strictly for ground collisions with the track’s invisible physical road mesh.

39
In the data scripts there are no offset parameters for the 3D collider. Its placement depends completely on the model itself.
40
Or even the geometry, especially with Blender (i.e., you have to use Edit Mode, as shown in Fig. ). The same principle works for scaling the mesh. Colliders don't use the object transformation
matrix at all, AC directly reads the vertex coordinates and uses those. So if want to scale the collider you just have to scale the geometry itself, with the tool in Edit Mode (switch from Object Mode
using the Tab key).

234
6.2 - HOW TO CREATE VEHICLE COLLIDERS
This is probably the best way to get the job done, using your rock-solid mouse and keyboard along with some reliable Neolithic tools. The best part is that
you can achieve the result you really want, you make your own choices and take all the responsibility of your actions.

This method is very simple, so it can be applied to basically any 3D modeling program.

We will create a cuboid, basically a carton box, and sculpt it with some patience. We will also take advantage of the symmetry of the car.

Tools: 3D editor (in this example 3DsMax), ksEditor

Steps:

1. In 3DsMax you will have the model of the vehicle. Set the view to Orthographic, this will make things way easier. Move the viewport to the top of the car so that you see
everything (Fig. 2.30).
2. Draw a simple rectangle on-screen with the Box tool which you can find under the Create tab. Encircle the model (Fig. 2.31), staying with a bit larger margin to be sure.
3. Change the point of view to the side of the vehicle; in the Modify tab (Fig. 2.32), right-click on the on the mesh name (here Box) and set it as Editable Poly.
4. Set the selection method to vertices (Fig. 2.33). This will allow us to manipulate the mesh easily. With the Select Object tool, select only the top vertices of the box, then
press W on your keyboard to activate the Move function. At this point you can extend the collider to the top of the vehicle. Use the snap feature to make every movement
follow the axes (Fig. 2.34).
5. If you didn’t already, enable the Swift Loop tool in your user interface (Fig. 2.35).
6. Create some loops in each direction, one (or more) to manage the length of the car, and another, located at x=0 to use as a reference for the mirror modifier that will be
applied soon (Fig. 2.36 & 2.37).
7. Delete half of the collider’s geometry, then apply the Mirror modifier (Fig. 2.38). This will allow us to work on half of the car and do double the work. It doesn’t matter if
the car is not perfectly symmetrical, like the Alfa Romeo 8C in this example. You will still be able to edit the vertices later on. The vast majority of cars will not suffer this
problem.
8. You can extrude some parts of the mesh to ease your work, even if not mandatory (Fig. 2.39). The more important strategy is to go into Wireframe view to see all the
vertices (Fig. 2.40). At this point you can just move the latter around to your liking, by selecting them and dragging them to the right spots (Fig. 2.41 & 2.42).
9. After your first attempt (Fig. 2.43), you can switch the view and adjust every side of the vehicle (Fig. 2.44 & 2.45). With some patience you can get something similar to
what is shown in Fig. 2.46.
10. Be careful to move the origin to the right location before exporting the mesh to the FBX format (Fig. 2.47). The mesh completed for our little Alfa can be seen in Fig. 2.48.
11. At this point, just apply a basic material without textures and export. You’re done!

Fig. 2.30 – In the Orthographic view there is no perspective effect, so you can clearly see the true boundaries of the car from each point of view.

235
Fig. 2.31 – Begin from the top view, that way you will cover most of the car right from the start.

Fig. 2.32 – Converting the mesh to Editable Poly will allow you to edit its geometry.

Fig. 2.33 – The rectangular selection is easier done than said. You can use the Edge or Face selection method too, but you will later work with vertices, so I want you to get used to it.

236
Fig. 2.34 – The snap is a very cool feature present in most CAD and poly modeling programs: it lets you move along the axes, use geometric elements as constraint points for all the
editing purposes. It speeds up everything. You better learn how to use it.

Fig. 2.35 - Enabling Edged Faces is fundamental, if you don’t you won’t be able to see the Swift loops you’re about to generate.

Fig. 2.36 - You will probably need only two or three swift loops. I suggest to create one for the front and one at the rear, to manage both ends better. Here I will draw only one of them.

237
Fig. 2.37 - Deleting half of the collider will allow us to use the symmetry and work only on half of the mesh. We don’t want to spend more time than necessary for these things.

Fig. 2.38 - Depending on which side (left or right) of the collider mesh you deleted, you may need to tick also the Flip checkbox. This is due to the X-axis orientation. The X value must
be set to zero in order to align the collider’s and the vehicle’s symmetry axes.

238
Fig. 2.39 – Extrusion is easy, click on the faces and push or pull them inwards or outwards. Be careful: avoid creating non-manifold geometry with this tool.

Fig. 2.40 – Wireframe will let you see very well the boundaries of your model. We have to look at them in order to define the shape of our collider.

Fig. 2.41 – The selection method is the same as before, only that this time you NEED to use vertices.

239
Fig. 2.42 – Working with the snap is important. You want to move the vertices only in a fixed direction, here from left to right or vice versa (so along the Y axis).

Fig. 2.43 – Rounding the edges. This is a first sketch, and it’s already starting to acquire the right shape.

Fig. 2.44 – Switch the view to the front or the rear of the car and do the same as before: select the vertices and move them to your liking around the vehicle body.

240
Fig. 2.45 - This is our second stage. Now you have to think about the possible contact points to redirect your attention to the most important areas and waste less time.

Fig. 2.46 – After more work, this is the result. It may be not the best, but that’s what I managed to do considering all the points where the collisions may happen, mainly the wheel covers
and the front. For other surfaces, like the sort of roll-bar and the windscreen in this case, you can create extra colliders in the colliders.ini config file (par.), without complicating things
too much on the mesh. I used the swift loop tool again, to add other vertices in the middle of the vehicle. We are exactly at 60 triangles, and it’s difficult to make a very detailed mesh.
Probably I could move a couple vertices on the engine hood. Anyway this is perfect, according to the rules. Note that the counter must be set to Count Triangles, not Count Polygons.

241
Fig. 2.47 – Always remember to set the origin/pivot of the mesh to the (0,0,0) coordinates. Otherwise you will have problems with the position afterwards.

Fig. 2.48 – The finished product. In my opinion it doesn’t look bad at all, although it doesn’t matter, as it won’t be visible in-game.

242
6.3 – OTHER METHODS TO CREATE COLLIDER MESHES
In order to make colliders the best option will always be drawing them by hand, starting from extruding and sculpting a simple cube, like we saw with
3DsMax. It can be easily done in Blender with the same techniques (box, swift loops, mirror and extrusion).

If you don’t have much time or experience, you can practice with other small exercises that will satisfy you. The results are immediate and rewarding enough
to keep you wanting to learn more and get into modifying any asset. We will take a look at a couple examples, this time with Blender.

Please note that these methods are good because they give you almost automatically the general (basic) shape of the collider, but in order to respect the
rules of paragraph 1 (especially rules 2, 3 and 4), you MAY NEED to slightly edit by hand the mesh you’ll obtain. You can’t say I didn’t tell you, even if these
should be lazy tutorials.

6.3.1 - SHRINKWRAPPING WITH A ROUNDCUBE MESH

This process, explained with simple words, is similar to taking a table cloth to wrap our vehicle model and capture a very simplified impression of it, that
vaguely resembles the original form. And we’re indeed talking about the Shrinkwrap modifier in Blender.

First of all, to keep things as simple as possible, let’s exclude all the NULLs (they will otherwise cause problems) and the objects that don’t define the
generic shape of the vehicle. For example the shape of your collider should not encompass a radio antenna or other particularly protruding decorative or
less important exterior parts. We can exclude the mirrors too; in any case you’re free to decide on what to keep, just don’t overcomplicate your work.

Tools: Blender, ksEditor, and for testing purposes you need also the Test Pad track mod available in this manual’s resources, or here:

Steps:

1. Start with your model in Blender’s Object mode, exposing the orientation of the geometry; select all the NULLs and press H to hide them (Fig. 2.35).
2. Skip this step if you’re working on an open-wheeler vehicle. Always in Object mode, select all the wheels (along with all of their meshes) and hide them too.
3. Do the same with mirrors or protruding parts, if you want them to be excluded from the collider’s shape or if they cause trouble (Fig. 2.36).
4. Select every mesh visible from outside the vehicle, or press A to select everything, and join all of them into one single object.
5. Spawn a mesh that will engulf the model, and afterwards will become the actual collider. Although it may be done with a simple cube, subdividing it, I prefer using the
Round cube mesh to enwrap the cars. It’s part of the Extra meshes add-on that already comes with Blender, but you probably need to enable it (Fig. 2.37).
6. The Round cube is spawned on the location of the Blender’s 3D cursor (in Fig. 2.38 the latter is located at the world origin). A small tab with the configuration options for
our newly created mesh is on the bottom left of the screen. Don’t miss it.
7. Change the radius size to make the Round cube engulf the whole vehicle. You can also determine how much geometry subdivisions should be used. Keep the number of
subdivisions low. To have a better look at what you’re doing use the wireframe view, like in Fig. 2.39. In addition, don’t forget to assign a material to the new mesh; do it
immediately, any material will be fine. You’ll change the shader later in ksEditor, to make the collider invisible.
8. Now on to the main part, that involves the Shrinkwrap modifier. Orbiting, panning and zooming in, move your viewport inside the wrapping mesh (our Round cube),
select the pipette in the modifier’s options and click on the vehicle mesh (that’s why we joined all the objects together in step 4) to choose it as the target of the modifier.
9. The mesh will be wrapped around the vehicle. The default settings are good, but you can adjust them to your liking (Fig.).
10. Apply the modifier (Fig.). Check the result for airtightness and triangle count. In case the mesh needs a clean-up, especially if you used a high number of subdivisions in
step 7, read step 11.
11. To clean-up. Select the Roundcube mesh, press Tab to enable Blender’s Edit Mode and click on the empty 3D space to deselect everything. Via the menus, select all the
non-manifold geometries and merge them by distance (Fig. 2.43).
12. On final inspection hide the vehicle mesh and look for inverted faces on the collider, which you can see with a red colour (the backfaces). In Edit Mode flip the normals
on those faces so only the blue faces (the front-oriented faces) remain outside of the collider (Fig. 2.44).
13. Check again the collider, until you’re happy with the result.
14. At this point press Tab to exit Edit Mode and with the Roundcube mesh being the only selected object, export the final product in the .fbx format (Fig. 2.45).
15. After exporting the FBX start ksEditor and load the new FBX. Normally the collider will appear horizontal over the camera and with its rear side immediately visible. Right-
click on it and in the Material tab set its shader to GL.
16. Then save the .KN5 as Car (No textures) in your FIN folder, with the name collider.kn5.
17. Check the collider on the Test Pad track mod against the various walls and kerbs.

243
Fig. 2.35 – This time our example vehicle is a truck. In this screenshot you can see the first steps in detail. Just follow the numbers. The false colors are blue and red by default.

Fig. 2.36 – Joining all the parts that form the general shape of the vehicle, without the protruding elements. You can choose what to keep and what to remove (by hiding it).

244
Fig. 2.37 – If you don’t find the Round Cube mesh in the Add menu (Shift+A), you have to enable it via the Extra Objects add-on in the Blender Preferences.

Fig. 2.38 – Add the Round Cube to your scene.

245
Fig. 2.39 – The configuration settings let you define also how many divisions of the Round Cube should be done. The value must be low; keep in mind rule 2 for colliders: the mesh
must have no more than 40-60 triangles.

Fig. 2.40 - If you prefer a closer matching of the vehicle’s shape you need to subdivide the Roundcube mesh before using the Shrinkwrap modifier. This implies that afterwards you will
need to merge densely packed vertices and decimate the result, to clean up the collider’s geometry. I do not recommend subdividing, keep things simple.

246
Fig. 2.41 – The inside of the Roundcube mesh is red because those you see are the backfaces. In 3D modeling, every face has a front and a back side; this is called face orientation.

Fig. 2.42 – You can choose any wrapping method you like. I suggest to use Nearest Vertex. Beware: after you apply the modifier you won’t be able to change its settings anymore.

Fig. 2.43 - If needed, the cleanup can be done easily selecting all the non-manifold geometries and merging them by distance. Hold the left mouse button and drag over the slider until
the problems shrink down to a dot. Then repeat the airtightness check. The face count for this example is 90 tris. It is sufficiently low, according to the rules.

247
Fig. 2.44 - If you subdivided, the more faces the more you will have to adjust in these additional steps. That’s why I recommend to abstain from subdividing and tightening up the
collider, to save editing time and CPU cycles in-game. 90-tris colliders are better than 146-tris ones when AIs or players pile up or hit the walls on the track.

Fig. 2.45 – These are the settings to export the collider model in the .fbx format from Blender. Apply Transform is required if you want to avoid the collider to be rotated when opening
the model in ksEditor.

248
6.3.2 - USING THE CONVEX HULL MODIFIER
Probably the ultra-fast version of a milkshake, only that we’re drinking it while on fire, approaching the edge of a crevice, without brakes. Yeah, that fast.
Let’s explain it VERY quickly.

Tools: Blender, ksEditor, and for testing purposes you need also the Test Pad track mod by Stereo.

Steps:

1. Select the body mesh and enter Blender’s Edit mode pressing the Tab button (Fig. 2.46). If you have more meshes, before anything, select all of them (except the wheels
and mirrors) and join them into one object. While still in Edit mode, press the letter A on your keyboard to select all the geometry of the body object, then press Shift+D
immediately followed by Esc to duplicate it. Go to the Mesh menu and click on Convex Hull. You can configure the transform parameters in the tab that appears in the
bottom-left corner of the screen.
2. Right-click on the already selected geometry and choose Separate > Selection. The collider geometry will be separated into a new object.
3. Press Tab to exit the Edit mode and go back to Object mode. Click on the empty space, then click on the collider. You may want to look for it in the Outliner and change its
name, since Blender adds a progressive number. Give a new material to the mesh you just created, with no textures.
4. At this point with the collider mesh being the only selected object, export the final product in the FBX format. The settings are the same as METHOD 1 (Fig. 2.45).
5. After exporting start ksEditor and load the new FBX file. Normally the collider will appear horizontal over the camera and with its rear side immediately visible. Right-click
on it and in the Material tab set its shader to GL. Then save the .KN5 as Car (No textures) in your FIN folder, with the name collider.kn5.
6. Check the collider on the Test Pad track mod against the various walls and kerbs.

Fig. 2.46 - Since I made this model for testing purposes, it is pretty simple. I already have every part of the body joined together.

Fig. 2.47 – After the duplication in Edit mode, apply the transform.

249
Fig. 2.48 – Separate the collider object from the car body object by Selection.

Fig. 2.49 - Rename the collider and give it a new material. There’s a hidden COLLIDER mesh, as you can see. That’s because I had already made my collider by hand. I’m not lazy.

You can follow some of the tricks we applied in METHOD 1 to this second procedure. Checking normals is always a good thing, and some protruding parts
of the vehicle body can be excluded from the collider. Always pay attention to the wheels! For open-wheelers you MUST include them!

The cons of this method are that the collider you obtain may have a too complex geometry. If you do, you can always edit by moving and merging the
vertices.

As you can see, there are many ways to create a collider model. If you want, you could place the vertices by hand. But that would take quite a few hours.

HEADROOM FOR MORE ABOUT COLLIDERS.

Content finished badge, for now.

250
CHAPTER 7 - THE DRIVER MODEL
Assetto Corsa follows the philosophy of including the driver in the simulation. Some titles do, others don’t. But we have the guy, so be it (Fig.).

Fig. – I’d say I’ve seen them all. This is art. Here the axes for the driver mesh were not Y up Z forward, but Z up and Y backwards.

A pilot’s model is totally separated from the vehicle, as a mesh, but his “being there” depends on variables that must be properly set on the car model. Most
importantly his position, and his movement. There are animation cues, the so-called “keyframes”, that determine where should go the head, the arm, the foot,
etc. Very simply, the mesh and its textures can be anything you like, but its bones and joints are standardized and you can’t really change them. All these
invariable parts regard animations.
So bear with me. First you’ll learn how to work with the SDK template and the rigs for pre-existing drivers, then we will look at how to make custom ones.
The only purpose of the template and the rigs is to set up anims and position of the driver, thus they can be associated with any official Kunos driver or any
other modded one with almost no additional work, via the nametags in the driver.ini car config file (see p.). This allows for an easy setup and model replacement
if needed.

7.1 – THE OFFICIAL SDK BASE TEMPLATE DRIVER

This is the “official” way to set up your pilot model in AC, given that it is explained by Kunos themselves. I included this for completeness, but the next
Paragraphs 2.15.2 & 2.15.3 will describe easier, better methods (with the aforementioned driver rigs). What you find here was originally made with Autodesk
Softimage XSI 2013 but is still valid for the animation rules & the various export procedures for 3DsMax / Maya users.
A copy of the basic AC driver with the bones skinned, animation of the steer rotation, helmet and some textures, is provided as the example template
DRIVER_BASE.fbx under folder (Fig.). It can be placed inside any custom car, and used for testing.

Fig. – The basic driver from the AC modding SDK template files (Autodesk Softimage XSI 2013).
251
- For a proper placement of the basic driver in your car model follow these steps (for Maya / 3DsMax users):

1. Import the template file DRIVER_BASE.fbx in your 3D application. You should see the driver as in Fig..
Inside the template, a basic steering wheel rotation animation is provided. The animation consists of 200 frames. The neutral position is on frame 100. From neutral (100)
to 0, the steering wheel rotates to the left. From neutral (100) to 200, it rotates to the right.
2. Place the pilot on the seat, with his hands on the steering wheel. Probably some modifications of the animation will be necessary. Fig. shows an example placement: the
driver’s model can now be exported to FBX and it will contain the correct hierarchy, names and positions for the bones and various objects.

Fig. – The driver model adequately sitting in the cockpit.

Pro tip: remember to set the unit in Export (for the provided driver) to meters (Fig. ).

Fig. – Import/export settings for the driver (Autodesk Softimage XSI / 3DsMax).

If you don’t, ksEditor will produce a wrong positioning of the bones. Keep the same units in your 3D software (1 unit=1m). This is needed because the original scale of the
Kunos pilot is 1 and must remain 1 even when exported. For a bone created with scale=1 in 3DsMax or Maya, this problem should be not present.

(Correct?) Note that the template is originally in centimeters, just import this in centimenters and export as meters, this will solve the problem with scale.

7.1.1 - ANIMATIONS OF THE OFFICIAL SDK TEMPLATE

The provided template file DRIVER_BASE.fbx contains a basic example of a 360° steer rotation loop animation. This animation will probably not match the
steering wheel of your car’s design. The animation must be modified to match your custom steering wheel dimensions and placement.

Note: The animation must be 200 frames where frame 0, frame 100 and frame 200 match to allow a LOOP animation.

After editing the animation, save the keyframes of the arms NULLs only and export the FBX with ONLY the animated parts. Animating the pedals is not
supported yet (it is doable with other methods). Fig. shows the hierarchy.

The bones of the arms are highlighted in the blue and red area in the image, and every bone is parent of the RIG_Clave_L and RIG_Clave_R bones.
To animate the hand that does the shifting, animate the arm bones from RIG_Clave_L/R up to the fingers. To animate the paddle gear change, animate the
fingers only.

For every animation you must export a copy of the driver.fbx with ONLY the animated parts needed for the desired clip. Example: Export driver.fbx with the
steering wheel animation only, then another one with gear animation only etc.
Store the driver animations with the names indicated below in the animation folder of your car project folder with all the fbx files and textures.
Steer.fbx for the 360° steer rotation
Shift.fbx for the gearshift animation
Shift_up.fbx for the paddle shift up
Shift_dw.fbx for the paddle shift down

See the section EXPORT ANIMATIONS FROM THE EDITOR for instructions on how to create a clip.

252
Fig. – Animation hierarchy of the official template driver (Autodesk Softimage XSI 2013).

Warning: there is typo in the name of the “neck” bone, which is spelt as “nek” by error. Albeit being grammatically incorrect, the game works with this name,
so please do NOT correct the typo and keep it “nek”.

Pro tip: always verify that the car shift animation and the driver shift anim have the same number of frames so that they are perfectly synchronized in the game. Example: when
the driver changes gear, on frame 0 his arm starts with the hand slightly away from the steering wheel (Fig.). On frame 10 the hand is on the gear lever. On frame 20 the hand
moves the gear lever. Be sure that the gear lever anim is synchronized with the hand. For example, if the hand needs 10 frames to reach the gear level, the gear lever must
have 10 frames in the static position before it starts to move.

Fig. – The hand movement animation sequence.

7.1.2 - EXPORT THE DRIVER POSITION FROM KSEDITOR (mandatory for 3DsMax / Maya users)
This is valid for all drivers; it doesn’t matter if they come from the template or the rigs. To export the driver in-car position file (driver_base_pos.knh) from
the AC editor you have to:

1. Load the FBX model with only the driver mesh in the correct base position.
2. In ksEditor go to the menu File > Save Driver Base Pos. A file named driver_base_pos.knh is then created and stored in the same folder where the source FBX is located.
3. This file must be placed in the following path: %root%\content\cars\your_car_name, so the car’s FIN folder.

The game engine will load the driver model and place it using the correct position information stored in the driver_base_pos.knh file.

253
7.1.3 - THE BASE TEMPLATE DRIVER and BLENDER
Just avoid importing the SDK template in your Blender scene. It won’t load properly. See Fig. below.

Fig. – (top left) The SDK template imported directly into Blender. The mesh loses all the rigging. (top right) Trying again with different import settings, the helmet becomes enormous.
Scale it by 0.01, rotation should be obvious. (bottom) The SDK template imported into 3DsMax and exported again, then loaded in Blender. The bones seem to be rotated 180 degrees,
but it’s much worse. That’s something weird happening with an FBX model created with Autodesk Softimage XSI 2013.

Just look at Par. 7.2 if you’re a Blender user. Don’t even bother trying to do this, someone else already did it for you.

254
7.2 – DRIVER RIGS
There is a system that is a bit different (and simpler) than what Kunos suggest: the use of the driver rig.

7.2.1 – 3DsMax RIG

The first rig we will consider is the one made by @the_meco (converted from the official template) for 3DsMax users (Fig.), which you can find in the extras
of this manual or at this website: https://www.assettocorsa.net/forum/index.php?threads/custom-steering-animation-rig-1-7.18201

Fig. – The 3DsMax driver rig by @the_meco, made in collaboration with @yashugan (Lead modeller and animator of AC).

It's a biped in 3DsMax, a solid base that you can tweak and customize. The driver is by default 1.85m tall, quite the guy as for race driver role.

Instructions

1. Move the driver into position by selecting and moving Bip001 and Wheel Main. Auto Key must be selected and the animation on frame 0 when moving Bip001. To avoid
any trouble with selection in 3DsMax if you go in the selection properties you can turn off "select children".
2. With the driver in position adjust his posture but orientating the biped bones again with auto key selected and on frame 0.
3. When the driver is in the correct position disable auto key and align Wheel Main to the cars steering wheel.
4. Move Land Hand Fix and Right Hand Fix to match the circumference of the steering wheel.

Optional steps

The driver animation should now line up with your cars wheel. Depending on the wheels shape some fine tuning may be required. You can animate on top of the current
animation and make what ever adjustments you want, but this will be a bit more challenging.

OUTPUT

1. Once your animation is ready to be saved for engine go into the layers tab and unhide the driver dummies layer.
2. Open the schematic view and locate the DRIVER : DRIVER hierarchy. Select all the helpers apart from the DRIVER : DRIVER root.
3. With the helpers selected go to the Motion Pannel and select Trajectories.
4. Set end time to 200 and samples to 201 and press Colapse. This will convert the inherited position and orientation transforms from the Biped bones to the Kunos driver
helpers.
5. With the helpers still selected go to file/export/export selected and save as .fbx 2012 with animation checked.
6. Open up the KSEditor and select Open FBX and load in the newly exported steer fbx.
7. With that loaded select Open FBX Animation and again select your fbx
8. It won't look like anything has happened but check where you saved you fbx and there should be a .ksanim file with the same name.
9. Rename to steer.ksanim and copy over into the car animations folder and you should have a working steer animation.
10. You can also select the DRIVER : DRIVER helper in 3DS max and export as an fbx, no animation required, load that into the editor and Save Driver Base Pos for your car.

- The animation needs to be made in PAL not NTSC as it will end up dropping the last few frames otherwise. Then animation should be 200 frames long,
otherwise it will skip 20 frames either side of the center point. Make sure to set your scene length to 200 frames PAL and when outputting set End Time =
200 and Samples = 201.

255
- The rig is set to 250 frames, 200 for the steer animation and 50 for the shifting. Use the correct frame settings on the timeline. Make sure the format and
number of frames is correct before importing the driver, just to ensure you avoid any issues.

At the end of the animation at frame 210 is when the shift part starts. So you need to set the 3DsMax timeline to start at frame 210 and end at 230 so when
you export the animation this is it's start/end point. There are two sticks for either side, you only need to do which ever one is suited to the car you are
doing. You just need to move the yellow circle called Shift Left Base01 or Shift Right Base01 to the correct position to line up with your shifter and the
driver should follow and change gear. As shifters can be in all different places and sizes it may need a bit of tweaking to get the anim exactly how you want,
arms may go through doors etc but it's pretty hard to make a one size fits all animation.

So after you have the animation how you want it you repeat the same export process as you would for the steer animation except you only select the
DRIVER:RIG_Clave_L or DRIVER:RIG_Clave_R (depending on side) and the helpers below them when going file/export selected.

- To keep one hand static in the animation, when you do the export, export the hierarchy for one arm only. Same story when you export the shifting, you
export only one arm although both of them are animated.

- You can scale the driver by change the biped height. Don't forget, if you change the driver size (too much) you will probably need to adjust the
animations.

- It seems to be impossible to correctly scale the driver model. It turns out, you can scale your whole scene in 3DsMax to solve the driver size. Without
having to mess with the driver scale itself (no bone scaling, no animation messing up etc., Fig.).

Fig. – How to “scale your driver model” in the 3DsMax driver rig.

1. The scene with your driver alone, without your car, change the scale to 0.9 instead of 1 (so it's 90%. Make it 0.95 if you want 95% of the 185cm =
175cm and so on - 90% makes a 166cm tall driver.)
2. Then only then > merge the necessary parts of your car to place the driver correctly. The mesh of your car coming from a scene with the default
system unit scale being 1 for 1.
3. You can then adjust your driver position, still in your "0.9" scene.
4. Same process than written in the first post, just collapse the animation of your 200 frames.
5. Export in FBX (i kept FBX export settings the same, did not change any scale parameter). KsEditor for the .ksanim and there you go!

Note: if you change into 0.9 to an existing working driver animation, it won't work. I mean it doesn't break anything, just that the position will be different
because it scales down from the origin (or so i think). So you have to import the car from the default scene, and move driver position, and scale steering to
match yours.

WIP

256
7.2.2 – BLENDER RIG
The second rig that comes to our magnifying lens is the Bone Animation Rig made by @Stereo (Fig.). It is specifically dedicated to Blender users and is
much easier to work with. It can be found along with this manual (in the tools), or downloaded here: https://www.assettocorsa.net/forum/index.php?threads/bone-
animation-rig-blender.34594

Fig. – The Bone Animation Rig for Blender.

How to use it:

1. Make a copy of it for each mod to keep things straight.
2. Use File > Append to add the relevant objects from your mod (steering wheel, seat, pedals, shifter).
3. Select the skeleton (DRIVER_DRIVER) and go into Pose Mode (ctrl+tab, or from the interface).
4. Pose the back bones, in order - DRIVER_RIG_Center (in his butt), DRIVER_RIG_Hips (in his stomach), DRIVER_RIG_Cest (tiny one at the end of Hips),
DRIVER_RIG_Nek. Ideally you'd only have to move Center, just use rotations for the rest - but if you have to move them to give him a more reasonable spine length,
go for it.
5. Move Wheel_Position (the root level empty) to line it up with your wheel.
6. Rotate Wheel_Orientation (next level down empty) to get the steering wheel angle.
7. The torus representing the rim is entirely unnecessary, you can delete it. The cylinder at the center of the wheel is animated with the actual rotation so leave it alone.
8. Move the Hand_Grip_L and Hand_Grip_R objects so they're on the rim (yellow cubes inside his hands).
9. Move+rotate the Gas_Pedal/Clutch_Pedal objects. (yellow, to be helpful) IK was weird with these, so it's attached in a slightly nonintuitive manner - just alternate
moving and rotating until they end up in about the right place.
10. Pose the fingers - should be pretty easy to see what these are.
11. Go to frame 0 and export driver_base_pos with the entire armature selected.
12. Select the animated bones: RIG_Clave_L/R, RIG_Shoulder_L/R, RIG_Arm_L/R, RIG_ForeArm_L/R, RIG_ForeArm_END_L/R
13. Export to steer.ksanim with the following options selected: Selected Bones, Reverse Animation, Fix DRIVER: Objects.

Suggestions:

• The yellow bones have IK (Inverse Kinematics) constraints enabled on them, you can disable it if you just want to pose them manually.
• If the arms are 'snapping' too much (IK solver having trouble animating smoothly) then try rotating the Hand_Grip_L and Hand_Grip_R to give his wrists more ideal
angles. These both come with some keyframes - you should make sure frame 0, 50, and 100 are identical, other than that, add whatever is necessary to get him moving
smoothly.
• One weird problem is he has really short forearms, this makes it hard for him to reach the wheel as it gets larger... not sure if the import has the skeleton wrong or if it's
just like that. I haven't found a good way to fix this yet.
• Layer 2 has a bunch of the helper animation targets in it, you might want to move Reverse_rot_L_target and Reverse_rot_R_target to adjust where he puts his hands
while 'let go' of the wheel, and possibly tweak their rotation keyframes so his hands don't have to spin as much.
• Don't trust the skinned mesh too much - for one thing it's the old DRIVER model, and for another, I manually twisted a lot of the bones. Check ingame that things are
working correctly.

257
• If you need to make him smaller, scale the root bone (base of his spine, DRIVER_RIG_Center) in Pose Mode, which shrinks everything. You can scale the neck bigger to
keep the helmet size. Works ok although his arms are sort of short relative to his torso at any scale.
• Width of the wheel should be adjustable by moving the yellow cubes in his palms. (just go to frame 0 and drag them sideways)
• To make a custom shift animation with this rig you can delete all the animation data, then just create a new animation for the "right hand cube", and the shift stick all in
one go. Export the stick on its own, and then the driver with the same settings for steering animation.

Pro tip: if you are a Blender user you should also adopt the Blender ksanim/knh exporter from the same author, useful to export animations and driver position files directly:
you can’t use the AC Editor for that with Blender (necessary with 3DsMax / Maya instead). It works also as a general-purpose .ksanim exporter.
The addon is compatible with Blender 2.80, 2.81, and works correctly on Blender 3.5 too. Be sure, if you are using the “Selected bones” option and you experience crashes
when exporting, to use Pose Mode and select the bones you want to export from there. If the selection is empty, then it'll give error. Also, you can't use it on root level
nodes, only objects with parents.
You can find the addon in the attachments of this manual or here: https://www.racedepartment.com/downloads/blender-ksanim-knh-exporter.30388
Installation: download the zip file, open Blender > User Preferences > select the Addons tab > Install from File... > select the zip archive.
Enable the addon by checking the checkbox on the right of the filter (you may need to search for “Assetto Corsa” to find it).
Usage: the exporter is available in the File > Export submenu. Features:
• Use: All / Selected Bones / Selected Objects - pick what you want to export. I would recommend "Selected Bones" for steer/shift animation, "Selected Objects" for
wing/light/suspension/etc. animations.
• Reverse Animation: Lets you export an animation with the frames in reverse order. Because of an issue with left and right, the pre-rigged driver animation is reversed so
you'll need this.
• Fix DRIVER: Objects: the Blender fbx exporter won't let object names contain colons, so in the Blender file DRIVER:DRIVER is renamed DRIVER_DRIVER and so on. This
option will change them. Used for exporting driver animations; for car animations you shouldn't need them because you can't export a car object with one of these names
anyway.
• Export driver_base_pos.knh: A helper feature. Normally you would generate this in ksEditor by importing the driver fbx, but due to the above object name issue, you can't
use drivers exported from Blender. Set frame to zero, select the posed DRIVER_DRIVER, and export this with "Selected Objects" enabled.

7.3 - DRIVER SCRIPTS

For a complete documentation of which parameters you can configure for the Assetto Corsa driver, including shifting animations and head movement, see
page of the car .

You may then infer that the behaviour of the pilot is car-specific. And in fact it is.

7.4 - FAQ
QUESTION [1]: I fail to move the driver. I edit the driver_base_pos.knh in ksEditor just fine, but it's not affecting any change. I tried a different steer.ksanim
and it changes the driver position, but also only to a specific one - and then editing the driver_base_pos.knh again has no effect.
ANSWER [1]: The steering animation does override the body position, so my advice would be just to do the steering animation. What I do is use
@the_meco's brilliant driver rig for steering animations, and also use it to export the driver position at the same time. This always seems to work for me,
and both the animation and driver position don't conflict.
It seems like the steer animation fixes the position of the driver in the car, and the driver_base_pos.knh fixes how the body of the driver bends on those
coordinates. The steer animation itself is then again dependent on the STEER_HR Null's position too.

QUESTION [2]: Why do we need exactly 200 frames for the steering animation?
ANSWER [2]: The animation was originally 120 frames. Later it has been extended to 200 frames to ensure the drivers hands stay on the wheel for longer.
In reality there is no restriction on how many frames you can use for any animation in Assetto Corsa, and for the steer/shift ones those are just the numbers
the prebuilt animation files use, so you can do whatever.
QUESTION [3]: The animation looks wrong in the Content Manager Showroom.
ANSWER [3]: NEVER check driver animation in CM Showrooms.
QUESTION [4]: Is there a simple method to make the gear lever move without animating it by hand?
ANSWER [4]: There is a method that will allow you to set up an H-pattern gear lever with a movement hardcoded in AC. You have to use the SHIFT_HD
dummy. Place it where the lever attaches to the car, with the Z-axis forward Y-up and make it parent of the lever (Fig.). There is nothing else to do. When
in-game you’ll see that the 6 different gears (including reverse) will be engaged. There is also a bit of vintage-style wobble of the lever, according to engine
RPM. You can check how it is done in the Lotus 49 by Kunos. I believe it's the only car which has this.

258
Fig. – EDIT IMAGE

The driver_base_pos.knh file is a sort of single frame animation that determines where is the driver with respect to the ride.
it's unlikely, but your shifting animation might be messed up because of driver3d.ini setting INVERT_SHIFTING_HANDS=1

259
CHAPTER 8 – CONVERSIONS
Why is this chapter here? The answer is: because you deserve it to be here. After all, you’re not doing a lot of work, which means that you don’t have the
priority over scratch-made content. Someone may ask: but aren’t they illegal, demonic artifacts to be censored and thrown into the pit of hell? Yes, unless
you have an agreement with the copyright owners (their explicit permission, and it’s better if you have it written down on paper). Information by itself is not
malicious, but it should not be misused. There are tutorials on the net for making gunpowder at home, what can a mod for AC be in comparison?

The main focus of this chapter (and the inner meaning of the term “conversion” in this manual) is allowing you to convert third party (with respect to AC)
game assets to a format which you will later be able to manipulate with your 3D editor of choice. You will also become more aware of the possible
consequences of using converted models, from the point of view of realism. More about the legal downside will be explained at par.

After any conversion, you will need all the information written in Chapter 2 to make it work in AC; take a look at it before and after coming here. Depending
on the type of game you’ll convert from, you will need different tools. They will be specified, but you can find them also at the beginning of this manual,
under THE TOOLS YOU WILL NEED.

8.1 - MODEL RIPS

What are model rips? What does the word “ripping” mean in the digital world?
The former origins of ripping involve taking data from a physical CD or DVD optical disc and putting it onto a hard drive or other similar storage media.
Once data has been ripped from a disc, it can be played back without requiring the original disc to be present. These processes allow the duplication of data
in order to back up CDs or to put audio, video or other content onto some other platform or device, legally or not. Thus ripping is also known more formally
as Digital Audio Extraction (DAE).

While "ripping" sounds destructive, the process does not affect the original data. However, the copied data may be decoded, decrypted, decompressed,
converted or modified during the process, so that it can be played on a computer via basic means (including open-source software, which amplifies the
freedom of choice). For example, DVD ripping programs may convert .vob encoded video files (which are specifically formatted for DVD players) to standard
.mpg or .mp4 files. The resulting video data can be played back using a simple video player program.
Over the years, the term has gained a more generic, less formal meaning, especially in the communities, involving the copy, decryption and edit of any kind
of digital asset, including 3D models, which are our main focus here.

8.2 - THE PREMISE TO CONVERSIONS

At this point we shall make a significant premise. It’s important to keep in mind that the models you will find in games or online often aren’t accurate or
faithful to reality at all. You may get different models of the same vehicle but you may not be able to tell the difference because you don’t know very well
how the real thing is. You may also find low quality assets that are more faithful to reality (Fig.) than higher quality ones; sadly people tend to choose higher
poly models than opting for realism, and that’s pretty much wrong.

Fig. 3.0 – These models should portray a Nissan Skyline GT-R R32. A (top-right) is much more accurate despite being lower poly and having an uneven topology. B comes from Forza.
260
Moreover, it can happen that the 3D artists get the proportions completely wrong. Game developers can’t always get CAD models and drawings of the
vehicles, due to licences, industry obfuscation of the designs, or the accessibility to the real vehicles (especially if historic, vintage, rare, expensive, exotic or
owned by privates: not everybody allows strangers to take measures on their 200.000-dollar Duesemberg or their 20+ million-euro vintage Ferrari), so they
“eyeball” them, which means they make the model from photos, looking at the proportions with the naked eye. We’re humans, and all kinds of things can go
wrong with a model (Fig.). And sometimes the authors just don’t care.

Fig. 3.1 – Same models as Fig. 3.0. Here you can also see that B’s roof is flatter (and that’s wrong).

Following the masses is not our goal. We aim at realism, so unless you know exactly what you got your hands on, you better wait and look at some car
reviews, magazines and photos, to understand which model is portrayed in the game you made the conversion from.

Even an untrained eye can see the difference

261
8.3 – HOW TO CONVERT FROM VARIOUS GAMES
The title is self-explanatory. But things are not really straightforward.

Most of the times you can use 3DsimEd to import the files from the games and convert them in a format that you can open with your 3D editor of choice.

Since the procedures are very similar for different games, this manual won’t cover all of them; only one example will be provided. After all, you can find
instructions and tutorials on this topic very easily online, as there aren’t many racing titles that’s worth ripping from. Use conversions to learn modding, not
to make profit on someone else’s work!

8.3.1 - Example with FORZA titles: Horizon 3 & 4, Motorsport 7 & 6: Apex
To convert assets from these games to a usable model in your 3d editor, you will need 3DSimEd and possibly Swatchbin Texture Converter. The result of
this method will be a .3ds file compatible with both 3DsMax and Blender.

You will also be able to get the LODs for each vehicle, since Forza assets include them. Don’t miss that part. More about LODs at par. 2.9.

About textures, you will have to reapply them in your 3d software. In addition, the converted cars may not have the tires, which you’ll have to add by hand.

STEPS:

1. Obtain the assets you want to use. You can either rip them by yourself if you have the games installed on your PC (under the install folder\media\cars), or download them
pre-ripped from this website (you’ll have to create an account though): https://gamemodels.ru/files/category/1162-forza-motorsport-series
2. If your source is on the web, always scan with your anti-virus of choice the compressed archives you get in your downloads folder. It’s just better than nothing, because
this doesn’t always guarantee safety (if you don’t want to put your personal files at risk you shouldn’t go online, that’s the rule).
3. Choose a location you’re comfortable with, anywhere you want on your hard drive. But not on your desktop, please. You will have to adopt a subfolder system, based on
the games your models are from (Fig. 3.2). This will allow us to make 3dSimEd believe that it is working in the original game installation folder, when in fact we are
simply in a dummy location. If you don’t follow this structure or use wrong names, the program will import an empty scene.

Fig. 8.2 – The subfolders you should create to make everything work.

Inside each folder of the games create a subfolder called media, then inside media create a folder called cars. Then extract all of your ripped or pre-ripped contents there.
The final path will be like this: %root%\FH3\media\cars\your_ripped_car_folder (Fig.).

4. The internal structure of the ripped folder (or the extracted pre-ripped archive, which usually includes all the files from the original game) should be like in Fig. 3.3. Keep
in mind that here may be more or less files and folders.

Fig. 3.3 – You can see the final path on top. This example uses the 1932 Alfa 8C assets from Forza Motorsport 7.

5. You need to rename the model's folder using the same name of the .carbin file inside. This step is necessary or 3DSimEd won't recognise the folder. In our example the
alf_8c_32 folder (Fig. 3.3) will be renamed to ALF_8C_32.
6. Now open 3DSimED31w and press on Import in the top left corner. Look for the .carbin model and make sure to select the correct import method from the menu (Fig.
3.4). This will allow you to choose which car LOD to import. Load the model and select these settings when this window pops out. Then click "OK"

262
Fig. 3.4 – For starters, you want the full detail model (for Forza it is Lod0), and the conversion of the swatchbin textures to the DDS format.

7. The model you choose will be displayed (Fig. 3.5).

Fig. 3.5 - LODs are a lot useful for optimization. Forza has even six of them. Don’t waste this opportunity! Many mods could have them but they don’t because of the creator’s laziness.
You will have to edit the models however, to make them fit the poly requirements, or adjust the behaviour of the LODs (see par.2).

8. Now go in the Tools tab and click on Split Objects by Material. A brief message will appear, then press Ok, and the software should now tell you that the objects number
has increased.
9. At this point create a new folder inside your Forza model’s location, and call it however you want. Here it will be named 3DS.
10. Go into the Export tab of 3DSimEd and click on Save to .3DS.
11. Select the new folder that you have created in step 9 and click on Save, then tick the boxes in the window that appears and then click on Ok (Fig. 3.6).

263
Fig. 3.6 – After you click Ok, it may take a while to save, especially on low-end machines. Please wait until it finishes.

12. You will now have the .3DS file inside your folder. Import it in 3DsMax, so that you’ll keep the model in quads (this way it’s possible to use some modifiers, like
smoothing, without the need to edit its topology) (Fig. 3.7).

Fig. 3.7 – As you can see, the model is still in quads. The wheels will have to be fixed or replaced entirely (if you don’t want to draw new tire meshes).

Now that you have the model you can also export it as a quadded .obj model from 3DsMax in case you want to work on it in Blender or any other software easily. If you
import the .3DS directly with Blender, the quads will otherwise be converted in triangles (even though the add-on has been removed in the latest releases). That’s not what
we want. Instructions about this at the end.

13. Now let’s export the textures. Go back to your previously created folder and create a new folder inside for the tex. Here we will call it Textures, however you can name it
however you like.
14. Go back into 3DSimEd and, in the Export tab, click on Plugin Export, select the Textures folder created and choose Wavefront Obj as the file format (Fig. 3.8). Click on
Save, keep the export settings the way they are by default and press Ok (Fig. 3.8). This .obj model (you can see it in Fig. 3.9) is triangulated, not quadded, so don’t use it.
We’re just exporting it to get the textures automatically. Delete it afterwards to avoid confusion, especially with step 12.

264
Fig. 3.8 – As you can see, there are also .kn5 export formats. You may be tempted to use them, but DO NOT. The car model, coming from another game, won’t have all the AC
dummies, the correct object names, the proper shaders, etc.; the exports simply won’t work or you may get any kind of error.

15. Now our Textures folder will contain the textures in the .dds (dx10) format which you will have to convert in other formats like 8888 or dxt5 (Fig. 3.9). Most of them are
detail tex. From now on you can use or replace them with others (paint colours, Alcantara, carbon fiber, etc.).

Fig. 3.9 - These are all the tex we got from our Alfa Romeo model.

16. You will need the normal-map textures; in case they appear red, they will have to be inverted and colour-keyed to make them look like the correct blue-ish ones (Fig.
3.10).

Fig. 3.10 – On the left is the original tex. On the right the modified one. This shouldn’t be necessary too often. Here Adobe Photoshop was used to invert and change the tone.

265
17. The model may not be immediately ready for use, some parts may have to be moved and placed in the right spot and the rims may have to be resized manually. These
adjustments can change depending on the game the model is from (in our example FM7; models from FH4 usually need more fixes).
18. There may be missing textures in the exported files. These are mainly shared Forza textures or detail textures that weren’t converted in step 14. You can either use your
own detail textures or download the shared textures from here: https://gamemodels.ru/files/file/8377-textures-and-materials-pack-forza-horizon-4
To convert the .swatchbin textures of this archive (if you download it), use the Swatchbin Texture Converter: load the textures and save them as .dds.
19. For the missing tire meshes, use those from an official Assetto Corsa vehicle that shares the same rim size, or make your own.

- Remember to follow the AC modding guidelines for object names, dummies/empties and everything else. You can find most of the rules in this very
manual.

- Two more things worth mentioning are that Forza models aren’t fully mapped, so you will need to remap most of it, and you will need to manually merge
the objects that share the same material for a better optimisation, as we detached them all in step 8.

HOW TO OBTAIN A MODEL FOR BLENDER

- As mentioned in step 12 of the conversion procedure, while you have your quadded model open in 3DSMax, you can go to File, Export and select the
.OBJ file type, then Save, wherever you want. The .obj model saved in step 14 is triangulated, not quadded, so delete it after you obtain the textures, to
avoid confusion. Use the export settings in Fig. 3.11 to export the quadded .obj from 3DsMax. In this example we will save this model in the 3DS folder we
previously created. The model will keep its materials but will lose the tex; that’s not a problem: we can always put them back on later, since we saved them
in the Texture folder.

Fig. 3.11 – The export settings for the quadded .obj model. They’re basically the default settings. Once it's all set, click on Export. You may get some texture errors, click on Don't
bother me again and then on Skip.

Once the export is done, you can close 3DsMax and open Blender. Inside this program, import the quadded .obj model with the settings in Fig. 3.12.

Fig. 3.12 – The Blender import settings for the quadded .obj model. Remember to select Split by Object and Split by Group.

You should now have your quadded Forza model in Blender (Fig. 3.13).

266
Fig. 3.13 – You will obviously have to rename a lot of objects. And re-assign textures to materials. But with patience you can do it. You can thank me later.

8.4 - MAKING CORRECTIONS ON THE MODELS

First of all, often when you rip a model from a game it will be already triangulated to be rendered in that software, so if it is necessary to modify the 3D, it
shall be un-triangulated, otherwise any attempt to work on the geometry may result in bad topology, especially if you subdivide a mesh (Fig.).

Fig. – Avoid using subdivision on triangulated meshes as much as possible. If you do it on large areas, you’ll get really bad results.

Follow other examples of what you may find in Fig. below.

267
Fig. – (left) Steering wheel and part of the cockpit. (right) Component of the exhaust pipe.

If you un-triangulate, you will obtain a product mostly in quads (some triangles might still be there), much more manageable for any 3D modeling (Fig.).
Ideally, the polycount will be halved, while the tris count should stay the same.

The result won’t be a perfect copy of the original model in quads made by the 3D artist; nonetheless, it will get pretty close, almost identical.

Fig. – Comparison between two versions of the same wheel from the Ferrari 312/67 by Kunos. On the left, the original triangulated version, on the right the un-triangulated one.

Sadly, at times un-triangulating is not enough, as the geometry may be too dense (Fig.).

Fig. – The same exhaust pipe from Fig. , un-triangulated and manually edited.

At that point it’s better to remodel the parts from scratch.

268
Here we have an example of probably the worst topology you can possibly get on a car model (Fig.).

Fig. – This will be an offense to any 3D artist, even newbies. Partly triangulated, partly in quads, with different distributions of polygons for every panel and curve of the body,
incompletely subdivided surfaces, not to mention the fact that the tire treads are modeled. Look at how dense are the geometries of the rear headlights, the rims, everything! This looks
like (and realistically is) a Frankenstein model, a collage of various parts, put together by someone who was likely under the influence. I can’t explain it otherwise.

269
CHAPTER 9 - EXPORT YOUR 3D MODEL(S) TO .fbx
“Blender’s FBX exporter is notoriously funny, crazy, but most of all ineffable and cryptic” – A.M.

After all the drawing, the naming and the structuring you did on your model (hoping you did it correctly), you can finally export it to a .fbx file which
ksEditor will be able to read. Let’s see.

9.1 - EXPORT SETTINGS

We’re going to export our 3D drawings (.blend for Blender and .max for 3DsMax) in the format supported by the FBX version up to the 2014/2015 plugin
(for Autodesk Softimage XSI and 3dsMax). Avoid using attributes that are not supported by this export format (such as physics constraint or mesh smooth
operators etc.). The 2016 plugin is unsupported and your mesh will not import in the KS editor.

The FBX data used by the AC engine are the following:

• Polygon mesh
• Normals (custom normals are supported)
• Texture coordinate UV (one layer only is read from the AC engine)
• Bones with vertex weight
• Nulls/dummies/nodes
• Hierarchy structure
• Animation data
• Basic mesh transformation (scale, rotation, position)

Reminder: The AC engine does not support two OBJECTS with the same NAME in the same MODEL. This will cause the game to crash (due to the .kn5
encryption). Make sure that you pay attention to this rule. Of course, when you have multiple LODs you have to use the same names for functional objects
and dummies, but there must not be matching names inside the same model export (e.g. within LOD A). Each LOD is a different model.

As a reprise from Chapter 2, make sure to set up the system units BEFORE creating the dummies and exporting the car!

Every mesh MUST have one TEXTURE UV set. The mesh must be (when possible) in quads. Do NOT triangulate the mesh if it is not necessary. For a
skinned mesh you can have as many bones as needed, but every single vertex can be influenced by up to 4 bones and not more. During the import process
the AC Editor ignores all unnecessary data included in the FBX.

In the next paragraphs are the settings to use to correctly export the assets with each of the supported programmes. Again, remember to set up your system
units before exporting (in Autodesk XSI it is not required). Did I say it enough times?

9.1.1 – Autodesk 3DsMax SETTINGS

In Fig. you can see the System Unit settings for 3DsMax.

Fig. 4.0 – The correct System Unit set up.

As a limitation of 3DsMax, if the System Unit Scale (Fig. 4.0) is wrongly set to mm or cm, even if the dimensions are correct, the dummies of the exported
model will still have the wrong scale. If the model and the dummies have been created in the wrong scale, one remedy is to export the model as .fbx and
re-import it in a scene using the correct system unit scaling. To avoid the trouble, please use the settings in Fig. 4.0 above.

270
NOTE: Make sure that you reset Xform after every modification that affects scale. It is advised not to scale suspension and wheel
nulls/dummies. (check)

In Autodesk 3DS MAX 2013 use the following export settings:

1. To export the base asset with no animation (Fig.) 2. To export animated NULLs/dummies (Fig.). (DELETE shorter)

Fig. - kkkk Fig. - kkk

Important:

The mesh must be scaled 1:1, rotation must be frozen on the mesh (reset Xform in 3DS Max) and objects should not have animated transformations. Only
the dummies/nulls may have different transformations. When they are animated they can be rotated and scaled, and some of them can act as bones for the
skinned mesh.

271
9.1.2 - AUTODESK SOFTIMAGE XSI 2014 SETTINGS

9.1.3 – BLENDER SETTINGS

(wip)

272
CHAPTER 10 - THE SDK EDITOR: FROM THE .fbx EXPORT TO .kn5 FILES
After you exported your models in the DEV folder as .fbx files, you’ll have to convert them in the .kn5 format that AC uses for its 3D assets; you’ll have to
define the shaders of your models too. This is not the end for you. Stay tuned.

10.1 - WHAT ARE .kn5 FILES

.kn5 files are mainly the models that the simulator is able to load. They consist of an encrypted container format, which exists because the game has to be
able to read the model quickly, without relying on FBX which tends to be quite slow to load in comparison.

File format overview:

A .kn5 file contains 3 main sections:

1. Textures: Simple file blobs with a name.

2. Materials: Defined by multiple properties like what shader to use ("system\shaders") and properties for the selected shader. They also contain a list of texture names as
input for the shader.
3. Nodes: They define most of the game objects. There are three main node types:
• Base node: Only has a name and a transform matrix.
Base nodes are sometimes only containers and sometimes game relevant locations.
A .kn5 file has at least a root node that contains every other node. Every node has a list of children, but only base nodes are allowed to have them.
Base nodes with special names like "AC_START_0" define the location and orientation for certain game objects. This one would place the start location for car 1 on
tracks.
• Mesh node: Defines a mesh with vertices, indices, a single material and some other drawing optimization values
• Skinned mesh node: Mostly like a normal mesh but also contains bone definitions.

10.2 - THE SDK EDITOR (ksEditor)

KsEditor is part of the software development kit (sdk) made by Kunos. It’s a small program than lets you export .fbx models to AC .kn5 game files (Kunos
proprietary format), allowing the configuration of shaders and textures for each material.

You can also use it to check and convert the .fbx animations of your vehicle to the .ksanim format (ksanim stands for Kunos animation).

It is a WYSIWYG editor, which means “What You See Is What You Get”, so the results you obtain in its viewport will look the same in-game. This is because
it uses the same graphics engine of the game. Obviously vanilla.

Keep in mind that there are no undo/redo functions! Everything you do in the editor, if not saved, can be lost forever if you don’t screenshot or note it down!

10.2.1 - LOCATION
You’re asking yourself where to find this program on your machine; you have three alternatives:

1. Use the one included in your Assetto Corsa Steam install folder, usually under Steam\steamapps\common\assettocorsa\sdk\dev\editor; otherwise read PART 1: AC
MANUAL of this book to learn how to find your install folder.
2. Use the one you can find in the attachments of this manual (which has also new shaders included).
3. Launch it directly from Steam. You’ll have to search for and install the so-called AC SDK (Fig.).

Fig. – How to install ksEditor from your Steam library.

I suggest you to use the first two methods that involve File Explorer, that way you can create a shortcut on your desktop 41 to launch the program
immediately, without having Steam open in the background every time.

41
Simply right-click on the ksEditor.exe in your AC install folder > click on ‘Send to’ in the drop-down menu that appears > click on Desktop (create shortcut). Done.

273
10.2.2 - SETTING UP THE INTERFACE
When you open the editor for the first time, make sure you open the window in full screen, then save the layout (open layouts > cursor on one Layout >
change the name > click on Save Current layout > Restart editor under File menu).

Fig. 5.0 – How to create interface layouts. If it’s the first time you open ksEditor, you just have to rename the first Layout already selected. You can create plenty of layouts for all your
needs, but to be honest, this is a set-and-forget feature.

Each Layout saves the editor window’s size, resolution, and the layout (disposition) of the panels on screen, especially if you detached them. Yes, because
you can detach the panels of the editor from the main window to manage your screen space (Fig. 5.1).

Fig. 5.1 – How to separate panels from the main window of ksEditor.

Also, set your editor preferences under Utilities > Data Editor (Fig. 5.2).

Fig. 5.2 – Editor configuration. The default Default Weather (sorry for the repetition) should be fog. Change it immediately.

For curious people, these settings are saved in the user.config file under C:\Users\Your_user\AppData\Local\Microsoft\ksEditor.exe_Url_xxxxxxxx\1.0.0.0. I
found this folder when I was looking for an entirely different thing.

10.2.3 - IMPORT .FBX 3D MODELS

This operation is very easy, as you just have to open the .fbx model from the menu (Fig.).

The loading process may take from few seconds to several minutes, depending on the complexity of the model.

Once imported, the viewport will be positioned at the (0, 0, 0) 3D coordinates of your model. The location in space corresponds to the origin of your scene
in Blender or 3DsMax. This is valid both for tracks and vehicles. That’s why when you open a car model you’re always positioned at the bottom (Fig.).

10.2.5 – USAGE AND PARAMETERS OF THE 3D VIEWPORT

274
You can navigate the scene using the left mouse button to rotate the viewport and the arrow keys on your keyboard to move it in four directions. With the
up/down arrows you can move forward/backwards, with the left/right arrows you can strafe left/right.

To move the viewport vertically, use the Page up/Page down keys.

There are three movement speeds:

• Normal, the default one when using the arrow keys;

• Slow, activated holding the Shift key while moving;
• Fast, activated holding the Ctrl key while moving.

To select an object in order to look at its properties, use the right mouse button. When selected, it will glow with a purple colour, and its name will be
highlighted in the Scene tab (Fig.).
Fig. -

Double-clicking an object with the right mouse button will make the viewport look towards it.

The mouse scroll wheel modifies the FOV (Field Of View), it does not move the camera.

The scene light in the editor can be changed under the Illumination tab, Fig. 3.6:

Fig. 3.6 – Sun position, weather and post-process filter can be selected from this panel.

10.2.6 – WORKING WITH OBJECTS

When any object in the viewport is selected, its properties will appear in the Object tab in the lower part of the screen (Fig.).

Fig. – The Object properties editor.

These properties are related to the active object only. Let’s explain what each of them does:

• CastShadow: whether the object should cast a shadow (True) or not (False).
• Center:
• IsActive:
• IsRenderable:
• IsTransparent:
• Layer: picks the minimum “detail level” the game shall be on to render the object selected. For example, 3D grass is usually all in the highest detail level only. The detail
levels range from to.
• LodIN: distance at which an object should load (spawn) in view.
• LodOUT: distance at which an object should de-spawn from view.
• Material: name of the material for the selected object.
• Name: name of the selected object.
• Position:

275
• Priority: the graphics engine renders the objects according to the object list (left column) from top to bottom. With the priority setting you can change and sort it to your
needs. The higher the number, the higher the priority. You can also use negative numbers.
• Radius:
• Scale:
• Triangles:
• Y- and Y+ buttons:
• Reorder and collapse buttons: For the object priority

Pro tip: LodIN and LodOUT have nothing to do with resolution LODs (A, B, C, D, etc.) for cars. Those are configured in lods.ini, part of the vehicle data files.

Another very important aspect of ksEditor is the ability to manage entities: it can already be done within the Object tab, but the Node Grid tool (Fig.) found
under the main menu > Utilities is much more flexible, allowing instances to be found, filtered and sorted quickly. Clicking the icons in the first column of
the list will teleport the camera to the object and highlight it. Thus it is very helpful when working on large projects.

Fig. – The Node Grid utility that comes with ksEditor. This is the list of objects of the Imola track map.

10.2.7 - WORKING WITH MATERIALS AND TEXTURES

The SDK editor can use various texture formats: DDS, PNG, JPG; use always .dds textures, as they’re the recommended format, look at SECTION 2.E.

JPG is a compressed format, so avoid it. PNG has the best quality, but DDS is faster, has better compression, uses less memory and has pretty good quality
too.

These formats for example won’t work if you try to import them in the editor: TGA (will assign and export but crash the game on load), BMP, TIFF.

All the tx must be in the texture folder of your project, which should be in the same path as the .fbx model (so under DEV\texture). You can review them
using the Texture Review tool under Utilities/Texture Review (Fig., option visible only when a model is loaded).

276
Fig. -

It is recommended that you keep your texture folder organised. You can back up unused textures with the “Move Selected in backup folder” button.

- It is mandatory that every mesh/object in your model has a material attached, otherwise when opening the .fbx model (which you will have to export later)
with ksEditor, you will encounter the following error (Fig.):

Fig. – The mesh, in this case named “Roundcube”, doesn’t have a material attached. This error will make ksEditor crash.

- When working with materials and textures, all the objects with the same material will be affected.

- When a texture is not assigned to a material slot, the value will appear as NULL.

- You can use a Copy&Paste tool to copy existing shader properties to a second material. Note that first you need to select the correct shader (if source is
ksPerpixelMultimap, the target needs to be a multimap material as well and so on), then fill in the shader slots manually! After these steps are done, you can
use the tool under Material Tools to copy and paste the shader values, as follows:

- Transparencies and cast shadow settings can be applied globally to materials under the Materials tab:

277
Fig. -

Persistence files
Let’s say that our project is finished. We assigned all the materials, we are happy with the results and we want to save our work. At this point you want to
create a persistence file.

What is a persistence file?

Persistence files store all the shader settings and object properties of your model. They can be saved under the File menu (Fig.). Be aware that they don’t
work like an undo button, because they save the last changes you made, not their history, so you can’t go back.

Fig. -

You can also load existing persistence files from higher LODs. Note that loading a persistence file on a new export will only transfer shader settings,
transparencies and cast shadow settings will have to be set manually. However, for later persistence updates using the load function (once the
transparencies are set), the transparencies will not have to be set again.

Pro tip: it is not possible to load persistence files from completely different models that do not share anything in common. If you want to copy material settings from another
persistence file, just open the .ini with a text editor (see ) and copy the parameters. Nowadays you can also use Content Manager Showrooms to check the values, especially
for cars.

General guidelines to using different alpha modes:

Where possible try to avoid using Alpha Blend mode. Blend requires transparency, which can cause issues with draw priorities, because some objects can
be viewed from two directions.

A common issue is the interior: interior objects sometimes (such as the transparent interior windshield banner) need a priority set to 1 to avoid the object
being drawn before the external glass objects when viewed from outside. However, from cockpit view, this can cause issues with the blurred rim on
opponent cars, because the blurred spokes object with a priority of 0 will draw before the interior banner, if for example it goes around the windshield.

Of course, Alpha Blend mode is still required for glass objects and the blurred rim spokes. When using priorities, make sure the priority is applied on the
object level, not the sub-object level.

Additionally, if the transparent object is linked to a helper, you have to assign the priority on the highest level in the hierarchy, thus the helper itself (see the
section about Damage Glass).

278
It is recommended to detach all transparent object as separate objects in your 3D software before exporting. AVOID including transparent objects in a group
object with multiple material IDs. This is very important because otherwise adding a new materiaI ID later on could cause the transparency and cast shadow
settings to “migrate” to another subobject, incorrectly assigning transparency to otherwise opaque pieces of mesh.

Alpha Test mode usually works to a satisfying level when the alpha has no gradient. Alpha Test requires no transparency, which is why no issues will arise if
more layers are in front of one another. In Alpha Test materials, transparency is defined by the Alpha channel in the Normal Map.

Alpha Test mode can also be used to hide certain objects using a simple texture (make sure you disable shadow casting for those objects). Remember that
you control transparency with the Normal Map alpha channel.

Opaque mode is required for non-transparent objects, or where the shape of objects is defined by the mesh. Make sure you don’t group objects with
different properties in this respect under the same material.

If you have objects that require the alpha channel to define their border, group them under a new material. As a general rule, keep alpha and non-alpha
objects in separate materials.

10.2.8 - USEFUL SHORTCUTS

Specific shortcut keys have been added to the editor that allow faster work and quick feature testing:

• F1 switches from RIM to RIM Blurred. The effect becomes visible and can be tuned faster.
• F2 (hold pressed) shows the 3d model’s origin.
• F3 switches from COCKPIT_HR to COCKPIT_LR (if exist) and vice-versa. Useful to check if the switch of the cockpit models is too abrupt.
• F4 shows the GLASS damage mesh on and off. This command works only if the glass damage mesh NULL exists.

10.2.9 - MANAGE YOUR PROJECTS

To make modding easier, you can use the built-in Project Manager to save and manage projects: after you set up your DEV and FIN folders (more about
them in Chapter 1 P2 or pag.) and you exported your models (LODs included) to .fbx (info Chap.) you can define all your folder paths, to be able to
immediately find all the models of the car you’re working on, without searching for them every time you open the editor (Fig. 5.3, 5.4, 5.5). Your project
settings will be written as a .kscp file inside the KN5 Output Folder you select.

279
Fig. 5.3 – If you already set up your DEV folder click on Edit Project to create your first project in ksEditor.

Fig. 5.4 – This window will open when you click on Edit Project (Fig. 5.3); insert all the paths and filenames requested (clicking on the buttons with the dots, File Explorer will open and
you will be able to select your files). Pay attention to the difference between LODs.

Fig. 5.5 – After you click on Save Project, you’ll be able to open and edit your project; you will find all of its LODs in the drop-down menu under Car Project.

10.2.10 - FAQ
QUESTION [1]: Why does ksEditor have bad graphics? “I just started modding, and I want to play a little with textures but, it’s really hard because the editor
has a low resolution in the viewport, and textures look the worst possible, like in Fig. 5.13. My PC is a nuclear power plant, has 128GB of RAM and three
GPUs, so I don’t think it depends on what specs I have”.

Fig. 5.13 – You can definitely see the model (a track), but with this poor resolution it’s pretty useless if you want a somewhat faithful representation of what will appear in-game.

280
ANSWER [1]: Follow the first lines of paragraph 5.2.2. That should fix it. You can also edit the video.ini file in the %root%\assettocorsa\sdk\editor\cfg path.

QUESTION [2]: The viewport camera moves really slow, even while holding the CTRL button on my keyboard. How can I fix it?
ANSWER [2]: Change the camera speed value in the Data Editor configuration, see Fig. 5.2.

QUESTION [3]: When I import to ksEditor my model is invisible.

ANSWER [3]: Most likely you did not apply any material or texture to your mesh(es); this is obvious if in the Materials tab of the SDK editor there is nothing
under Textures and all the materials have the NULL value. Select some texture files, a white 128x128 .png for example, and your model will appear.

QUESTION [4]: The model shows completely black.

ANSWER [4]: The shaders are working but you need to play around with the values, for example raising Ambient and Diffuse. Leaving them at 0 will of
course result in just black, that’s based on the principle behind how they work.

QUESTION [5]: Whenever I load the persistence of the current car/track, the AC editor displays an error regarding a node that is not selected (Fig.).

Fig. – The error mentioned in our question.

ANSWER [5]: As long as the FBX model is in the same folder as the saved persistence file (the latter with same name but different extension), the config file
should load automatically when you open the 3D assets in the editor. For example: your_car_name.fbx will have your_car_name.fbx.ini as persistence file.
If you want to load by hand the persistence file (maybe you have an old backup copy), make sure you have the model selected in the object tree (TreeView)
on the left side (Fig.).

Fig. – In this example the car model is called kat.fbx. You will be able to load the persistence from the menu only if you select the correct node.

WIP

10.2.11 - CURIOSITIES AND AMENITIES (you better know this info, you might get confused in the community otherwise):
A modded ksEditor exists, made by x4fab: ksEditorAT (version 6). Keep in mind most likely it’s outdated, or at least SOME SHADERS ARE MISSING,
ksBrakeDisc for example. It’s possible to add them though by copying from ksEditor resources, but I think it really ain’t worth the effort to do so. ksEditor is
perfectly fine for what you need to do. Also, as Ilja says, “be aware that if something fails, ksEditorAT is maybe somewhere in the background, window not
on screen or taskbar, and you may have to kill it in task-manager; then...its a good idea to test in normal editor first”. It has some cool little features, but isn’t
immune to crashes (like the original program). You can download it from this website: https://ascobash.wordpress.com/2015/07/22/kseditor/

281
10.3 – THE ASSETTO CORSA GRAPHICS ENGINE
The Assetto Corsa graphic engine does not have a very creative name: in the code it is called KS DX11 RENDERER.

It is mainly a tailored Yebis-based shader system. The following are the main post-processing features of a Yebis shader system.

YEBIS Features:

Glare

• Bloom (Soft Round Glare)

• Star
• Radiating Lights and Cross Filters
• CCD Smear
• Anamorphic Lens Flare
• Ghost
• Afterimage
• Soft Focus
• Light Shafts (Godrays)
Lens Effect (Optical Simulation)

• Depth-of-Field (Defocusing)
• Aperture (Bokeh with realistic lense aberrations simulation) Open/Close Simulation of Diaphragm Blades Lens Aberration/Correction Simulations
• Autofocus
• Focus Breathing (Inner / Rear / All-group Focusing, etc.)
• Airy Disk Simulation (Small Aperture Blur)
• Lens Distortion
• Barrel / Pincushion
• Fisheye Lens Effect
• Chromatic Aberration
• Vignetting
• Natural Vignetting
• Optical Vignetting
• Image Circle (Representing Scope)
Film/Photogalvanic Effect

• Tone Mapping
• Auto-Exposure
• Photosensitive Simulation
• White Balance
• Motion Blur
• Camera Motion Blur
• Object (Velocity Map-Based) Motion Blur
Others
• Anti-Aliasing
• Ambient Occlusion
• Color Grading / Gamma Correction
• Various Input / Output Color Spaces
• Various EOTF methods for HDR Output

- Tests conducted on 01.05.2014 showed data for various rendering modes (AF and AA):

The following measures were taken in order to exclude outside factors from influencing the test results:

• the specifications of the testing PC weren't altered, hardware or software wise

• the game version stayed the same during the test
• the car was the same (BMW Z4 GT3)
• the track was the same (Nürburgring GP curcuit)
• the position of the car on the track was the same (in the box) - the car wasn't moved
• the versions of the testing programs were the same
• no other benchmarking programs ran in the background during the test
• the tests were done in quick succession
• CPU and GPU temperatures were within normal values, no down-clocking took place
• other visual quality settings in AC stayed the same (like smoke quality and resolution), these were:
o Resolution: 1920x1080 at 60Hz
o Rendering Mode: Single sceen
o Fullscreen Rendering: checked
o Vertical Sync: unchecked
o Framerate limit: 200fps
o Shadow Resolution: High

282
 o Disable HDR: unchecked
o Motion Blur: off
o Color saturation: 100%
o World detail: Max
o Smoke generation: ultra
o Show smoke in mirrors: checked
o Field of View: 54°
o Hide driver arms: unchecked
o Hide virtual steering wheel: unchecked
o Mirror Resolution: High
o High Quality Mirror Reflection: checked
o Cubemap Resolution: Low
o Faces per Frame: 1

Further notes on testing philosophy

• The screenshots were taken by pressing the 'print' key and inserting them into Irfanview, a small picture viewer.
• Further, the screenshots were taken approximately 30 seconds (or more) after loading into the game in order to acclimatise the CPU and video card and read stable values
(as proven by the red timer at the bottom-left of the screen).
• The values of interest are displayed on the right hand side of the graphs, their association obove of the particular graph.
• The screenshots were uploaded to 'postimage.org' (a site I trust (so far) and the images are not going to be taken down due to inactivity or time constraines).
• The first datapoint (the first screenshot) represents neutral settings (AF=0, AA=0). This is equivalent to the 'control group' in scientific experiments.
• Afterwards, AF and AA settings were tested seperatly, at low and at maximum settings. Fast Approximate AA (FAAA) was also tested at max value for perspective sake and
for comparison with normal AA. Then, AF and AA were tested together to see their influence on each other. Lastly, maximum AA, AF and FAAA were tested
simultaneously.
• The Nürburgring was chosen as track, mainly because of the roller-coster-esque object and trees in the background in order to test and visualise the effects of Anisotropic
Filtering.

Hardware and software specifications

• CPU: AMD 1055T, TDP: 125W (hexacore at stock speed 2,8ghz, undervolted to 1,37V from stock 1,47V)
• GPU: HIS AMD HD7850 OC, 2GB RAM (stock, performance wise comparable to a NVIDIA GTX 660)
• Mainboard: Gigabyte GA-770TA-UD3
• PSU: BeQuiet! 480W Straight Power CM
• OS: Windows 7, SP1
• Video card driver version: Catalyst 13.1
• Fraps 3.5.9 and MSI Afterburner 2.2.3
• Assetto Corsa, Steam Early Access version 0.8.7

Limitations of the experiment

• This scenario was conducted with only one car on track. The car was stationary. The test values of FPS and GPU Memory Usage (GMU) may vary with AI
or multiplayer opponents on track and under race conditions.
• The test values of FPS and GPU Memory Usage (GMU) may vary when testing on a different track.
• Critically, all values for the GMU stayed under the maximum of 2000 mb the graphics card could accommodate.
• The test values (FPS, GMU) are not to be taken 100% accurate and are subject to fluctuations.
• The impact of graphical options other than AA, AF and FAAA on FPS and GMU are not subject of this article.
• The observation of graphical qualitly and its differences between AF, AA and FAAA settings has to be judged by the individual user.
• The impact of FAAA on FPS and GMU may change during driving and playing with AI or multiplayer opponents.

Results
0xAF - 0xAA - FPS: 114 - GMU: 1202
2xAF - 0xAA - FPS: 112 - GMU: 1215
4xAF - 0xAA - FPS: 106 - GMU: 1222
8xAF - 0xAA - FPS: 100 - GMU: 1231
16xAF - 0xAA - FPS: 94 - GMU: 1220
0xAF - 2xAA - FPS: 105 - GMU: 1258
0xAF - 4xAA - FPS: 100 - GMU: 1325
0xAF - 8xAA - FPS: 95 - GMU: 1455
0xAF - 0xAA - 8xFAAA: FPS: 101 - GMU: 1242
2xAF - 2xAA - FPS: 102 - GMU: 1287
4xAF - 4xAA - FPS: 94 - GMU: 1338
8xAF - 8xAA - FPS: 83 - GMU: 1472
16xAF - 8xAA - FPS: 75 - GMU: 1465
16xAF - 8xAA - 8xFAAA - FPS: 69 - GMU: 1479

Findings

• As expected, all FPS values decreased and almost all GMU ones increased, if a single or both values of AA or AF were increased (effects of FAAA are exluded at this
point).
• Higher AF settings resulted in a non-linear and non-exponential impact on FPS or GMU.
• Higher AA settings resulted in a reasonably small impact on FPS.
• AA settings have the biggest impact on GMU.

283
• Changing AA settings from 4x to 8x had a big impact on GMU.
• The bigger the increase of AF and AA, the higher the drop in FPS.
• This drop is almost the same if maximum AF and AA are applied seperately.
• The bigger the increase of AF and AA simultaneously, the bigger the increase in GMU, primarily because of AA.
• The addition of FAAA had a reasonable impact on FPS and a small impact on GMU (See last sentence of chapter 4 'Limitations of this Experiment').

Recommendations

Raising a single value, AF or AA, may not result in optimal resource management and overall high graphical fidelity.

Since AF and AA have almost the same impact on FPS, and AA a high impact on GMU, a high AF and a low AA setting provide a compromise in FPS,
graphical fidelity and resource usage.

284
10.4 - DEFINE THE MATERIALS: SHADERS
10.4.1 – WHAT ARE SHADERS IN AC
Workflow: tracks can use both specular and metalness; cars use metalness.
Main rule: never trust CM showrooms. Always look at the results of your work in a-game session. Also sometimes ksEditor is not good
at showing the final result with shader edits, always be aware of this.

CSP shaders work on top of vanilla ones?

10.4.2 – VANILLA SHADER TYPES

AC has got different shaders you can use for any type of material; below we have the list of all the accessible vanilla shaders. The ones which are not
mentioned here (and that you will never see unless you search for them) are hidden even from the sdk editor, as you don’t need to use them, being
hardcoded or outdated. To make it short this is what you’ll work with: (add page numbers)

1. GL p.
2. GL2D p.
3. ksBrakeDisk p.
4. ksBrokenGlass p.
5. ksCarPaintSimple p.
6. ksClouds p.
7. ksColourShader p.
8. ksFlags p.
9. ksGrass p.
10. ksMegaShader p.
11. ksMSDepthResolve p.
12. ksMultilayer p.
13. ksMultilayer_fresnel_nm TRACKS p.
14. ksMultilayer_objsp p.
15. ksOrenNayar p.
16. ksPerPixel p.
17. ksPerPixelAlpha p.
18. ksPerPixelAT p.
19. ksPerPixelAT_NM p.
20. ksPerPixelAT_NS p.
21. ksPerPixelMultiMap p.
22. ksPerPixelMultiMapSimpleRefl p.
23. ksPerPixelMultiMap_AT p.
24. ksPerPixelMultiMap_AT_NMDetail p.
25. ksPerPixelMultiMap_damage p.
26. ksPerPixelMultiMap_damage_dirt p.
27. ksPerPixelMultiMap_NMDetail p.
28. ksPerPixelNM p.
29. ksPerPixelNM_UV2 p.
30. ksPerPixelNM_UVMult p.
31. ksPerPixelReflection p.
32. ksPerPixelSimpleRefl p.
33. ksPerPixel_dual_layer p.
34. ksPerPixel_nosdw p.
35. ksPostFOG_MS p.
36. ksShadowGen_debug p.
37. ksSimpleShader p.
38. ksSkinnedMesh p.
39. ksSkinnedMesh_NMDetail p.
40. ksSky p.
41. ksSkyBox p.
42. ksSkyCubemap p.
43. ksTest p.
44. ksTree p.
45. ksTyres p.
46. ksWindscreen p.

While below there are extra shaders that come with CSP:

1. ksMultilayer_fresnel_nm4 p.
2. ksMultilayer_objsp_nm4 p.

285
 3. ksPerPixelAT_NM_emissive p.
4. ksPerPixelMultiMap_AT_emissive p.
5. ksPerPixelMultiMap_emissive p.
6. ksPerPixelMultiMap_NMDetail_emissive p.
7. smSticker p.
8. stPerPixelMultiMap_specular p.
9. stPerPixelMultiMap_specular_damage_dirt p.
10. stPerPixelNM_UVflow p.
11. st_multimap p.

EXTRA ++ SHADERS

stFlow

10.4.3 – COMMON SHADERS PARAMETERS: TEXTURE SLOTS

While working with ksEditor you will find several tex slots for each shader (Fig.). Let’s see what they’re used for. We will explain all of them here, but each
shader will use specific ones.

txDiffuse: it is your main texture. The color of an object is defined by this slot. It is the diffuse map, often called colormap.
The pixel values given by the colormap are influenced by two slots, the ksAmbient and the ksDiffuse.

normal map = similar to bumpmaps (affects lighting only and creates a 3d-ish look on flat surfaces)

detailmap + variationmap = blends details or variation into a colormap

alpha channel = black&white map is usally used for transparency and specular highlights

The map texture's green channel controls both reflection and specular sharpness

10.4.4 – COMMON SHADER PARAMETERS: MATERIAL SLOTS

ksAmbient and ksDiffuse are added to give the color, not multiplied.

ksSpecularEXP is basically the roughness of the object.

ksAlphaRef is only related to shadow generation, not to transparency. There's no way to control alpha test threshold in AC.

isAdditive is a parameter very important to reflection properties.

isAdditive=0 means that the maximum reflection sharpness is only achieved with a specular power of 255. Think of this like a
simple material - plastic, rubber, whatever. It's only reflecting at one layer so specular + reflective sharpness are tied together (to
get technical, the specular spot is the reflection of the sun - it's just that the sun is so much brighter that it needs special
casing).

isAdditive=1 is literally true, it sets reflections to additive (instead of the default fresnel mix). I think this is for glass. Same deal,
specular power of 255 is sharp reflections.

isAdditive=2 means that reflections are almost always sharp - specular power of 8 or higher will do it. It's also back to the
original case of fresnel mixing. Think of this as something with a clearcoat - the undercoat of paint can have a metallic specular
setting, the clearcoat still has sharp reflections.

detailUVMultiplier entirely depends on your UV map

shadowBiasMult is a parameter that can be used to fix problems related to the shadows of the car (Fig.).

286
Fig. – The shadow projected by the suspension arms is wrong, make sure that the body shader has a shadowBiasMult value of 5 or higher, it gets rid of these artifacts (it's an engine
limitation, not the model's fault).

Boh is a variable that is useless for graphics but it's used for performance balance. It has to be there... just ignore it. You will see it on few shaders.

10.4.5 - VANILLA SHADER DESCRIPTIONS (wip)

1. GL
This is the shader assigned to car colliders. It requires a material in order to work, but no textures. Simply give a generic material to your mesh in your 3D
modelling software of choice.

In ksEditor after you assigned this shader to the mesh, it will appear rainbow-coloured (Fig.), while in game the object will be completely invisible (but
collidable).

Used for tracks?

Fig. – The collider mesh after the GL shader has been assigned to it.

287
2. GL2D

3. ksBrakeDisk
The shader for the glow effect when the brake discs reach extremely high temperatures.

Brake glow textures should be entirely black except for the actual glowing part of the texture. Otherwise the entire texture will light up, rather than just the
glowing disc.

Fig. – dfsaf

The glowing is controlled by the brakes.ini data file (see p.).

This shader is required for the CSP brake disc FX, which is added in the ext_config.ini script. CSP just changes the shader to a better looking one with extra
features.

4. ksBrokenGlass
This is a shader for, obviously, broken glass on the windscreen/windows/headlights upon car impact/accident. It is a simple method, as there is no
shattering glass in AC.

You need 2 objects on the same position, one for the glass itself (with its shader parameters correctly set) and another for its damaged version (as the
damage meshes need their own separate material).

Assign to the damage meshes the shared damage_glass.dds texture you find in SteamApps\common\assettocorsa\sdk\dev\car-pipeline-1.03\Common
Texture. This allows the damage model to work as intended and behave the same for all cars.

The meshes for the glass damage must follow the naming explained at chap.

In the object parameters in ksEditor set Is transparent=true and Cast shadow=false, as usual for all glass objects.

To adjust the behaviour of the glass when the car takes damage you can tweak the damage.ini script as well. More about it in chap.

CURIOSITIES AND AMENITIES:

- Broken glass is so annoying, and in AC happens with slightest contact even door to door or rear end crash, and disturbs you the whole race.

Well, it’s only your fault if you drive badly! Maybe for a car with a vinyl/plexiglass windscreen you can avoid adding glass damage because it looks out of
place. Always aim at realism. If you don’t drive with dust in your face you aren’t badass!

- I don’t like the default shared broken glass texture. Don’t worry! There are mods for this too! (Fig.)

Be aware that changing the common glass damage texture will change it for all cars in AC.

288
Fig. – Here you can see the vanilla glass damage on top. It is not really high resolution, but looks quite realistic. Obviously you can create your own texture. You can find this mod (by
@Xerox) here: https://www.racedepartment.com/downloads/hd-windshield-damage.10965.

Fig. – Other texture mods, this time by @JackCY (left) and @RealAKP (right). The second one is my favourite, not too intrusive and quite realistic. In any case you can find them here:
https://www.racedepartment.com/downloads/a-broken-glass.4783 and https://www.racedepartment.com/downloads/new-damage-and-dirt-textures.13531.

289
5. ksCarPaintSimple

6. ksClouds

7. ksColourShader

8. ksFlags
Shader for track flags, that makes them wave back and forth in the wind (Fig.). It lets you specify the frequency and the intensity of the distortion. The boh
value is just a filler. There is nothing physical in the vanilla weaving. It’s purely visual.

Fig. -

The UV map is correct only if set properly from left to right. You assign the ksFlag shader, and the UV mapping must have the left edge of the flag attached
to the pole, along with the texture (Fig.). The left side of UV is still and as the texture coordinates go towards the right side, it moves.

Fig. – Here the frequency and distortion parameters are set to zero, you just set them to your liking. You can see the behaviour in the editor, one of its few dynamic things.

You might come to the conclusion on your own that using a texture with 16 nation flags from left to right is bad, because the rightmost flags get waved
excessively. If you want to put more things, the tex must be vertical (Fig.) and flags have to be single row from top to bottom, with the reverse side as well.

290
Fig. -

You can use this shader for cars too, for example if your vehicle has got national flags (Fig.).

Fig. –

CSP brings the ksFlagsfx shader, which responds to the wind speed as well as direction. That’s what is used to make trees move on tracks.

9. ksGrass
ksGrass doesn't use a mask texture.

Making grass surfaces using ksGrass is just not right. This shader is only meant to be assigned to 3D grass and foliage objects, not terrain, and CSP never
included a caveat for tracks that don't use it as such; low effort mod tracks often use ksGrass for terrain for some reason, which causes issues with the
retrofitting of CSP features: GrassFX does not work on ksGrass shader indeed.

With a track that uses ksGrass as the ground/terrain shader, GrassFX makes the ground go invisible.

You better apply another shader, like ksPerPixel to the grass surfaces, and then use correctly CSP configs. Keep things as simple as possible and avoid any
trouble.

291
10. ksMegaShader

11. ksMSDepthResolve

12. ksMultilayer

TEXTURES:

txDiffuse: main diffuse texture. Alpha channel works as specular map.

txDetailX: four detail textures. Their appearance is controlled through txMask.

txMask: RGB+Alpha image. R, G and B values control how much txDetailR, txDetailG and txDetailB show upon the main texture. Alpha brightness regulates
txDetailA: the more white it is, the more txDetailA will be visible.

SHADER VALUES:

multR, multG, multB, multA options scale the detail textures. They don't follow the mapping on the diffuse texture, they use a simple planar one.

multA is the only one that can be scaled separately on X and Y (or shall I say U and V).

292
magicMult: still can't sort this out. Zero makes the texture black, 1 makes it extremely bright.

13. ksMultilayer_fresnel_nm
Kunos used this shader in official tracks for the road tarmac mesh, featuring diffuse(&alpha), MASK(RGBA) Normal map(&ALPHA), all DXT5 DDS.

A multilayer diffuse, with fresnel lighting and a normal map. This is the ksMultilayer_fresnel_NM shader. The specular is contained within alphas of all
texture. The reason for this shader is as the view (camera) gets closer to the object more detail appears. So it blends between the information on the diffuse
and the detail. the downside of using this is zero reflection property. So it is mainly used for non-reflective objects.

Mask system. It places a new texture as camera gets closer. Nice blend into diffuse. Each channel RGB or A is drawn independently. There can be 4 detail
textures. In the ksEditor you can select all of the textures and any other detail textures.

The normal map follows the same size and automatic (LINEAR) UV arrangement the mask places it with. The scaling is configurable. All linear UV work
within the UV that the diffuse is using. So on a UV mapped road it will flow. On a massive tile of scenery it doesn’t need to fit the detail UV system. Very
configurable depending on the modelling layout chosen.

Detail textures are tileable within the UV map of the diffuse. A detail texture may span 1m square or whatever you want but within the UV mapped model. As
we get closer the tarmac grain and detail appears; as we get away from it in game it blends to the main diffuse.

Here are the settings from ksEditor.

Let's go through all those textures and how to set them up to produce what you see above.

1. txDiffuse

This texture should be 1024x4096. You want as long a texture as possible to limit the amount of times it repeats. Shown
below is the diffuse with the alpha channel next to it. Basically, the alpha channel here is your specular level. White is 100%
and black is 0%. What I simply do is make the alpha channel a copy of the diffuse and adjust the levels how I want them to be.
The format of the diffuse should be DXT5 and with about 4 mipmaps.

In general you only want to use one single diffuse for your entire road. You may ask "how do I get color variations and such?"
The answer is in the detail textures which I will get to that in a later post.

293
2. txMask

My mask is fairly small at 128x512. It does not need to be as large as the diffuse. Mine looks like this and is in DXT3 format with 4
mipmaps.

The red is where the main road detail image is shown and the purple is where the main red channel detail is mixed with the blue channel
crack texture. You can play with this bad boy all day long and even mix in the green channel if you want with another detail texture. I only
used the two channels. You shouldn't need to use the alpha channel with this so it should be 100% black if it is not used with a detail
texture.

3. txDetailR

The main detail image (in this example).

Fig. -

It should be 1024x1024 in DXT5 format with 4 mipmaps and it looks like this. The main texture is on the left and the alpha channel is on the right. This
alpha channel is also specular so here you want it fairly dark with only some pebbles light to light up by the sun.

4. txDetailG

The green channel.

If you are not using any of the color channels in the mask you can simply repeat the main detail image just to complete the form in the editor. In my case I
don't use green so it gets the main detail again.

5. txDetailB

The blue channel.

Used in this example for the cracks texture. It should be 512x512 and DXT3 with 4 mipmaps. Again the alpha channel is specular. You will have to fine tune
it so it matches the detail texture it blends with.

6. txDetailA

It is not used in our example, so it can be set to the main detail like the green channel.
294
7. txDetailNM

Normal map.

It should be 1024x1024. No alpha is used on this and it can be DXT1 with 4 mip maps. You adjust the normal map resolution with the two numbers in
"detailNMMult".

SIDE NOTE: Photoshop exports a full black alpha as full white somehow. Making the alpha #010101 fixes this. It doesn't matter if you use a black detail
texture, though. But it's worth mentioning for people who experience weird results inside the Editor.

So there it is, asphalt in all its glory. If you get this to look right, it's a huge step in bringing your track to "AC standards".

Mip maps get added automatically BUT it increases load times substantially.

14. ksMultilayer_objsp
ksMultilayer_objsp is the same as ksMultilayer, but in this the detail textures are not planar-mapped, they share the same UV from the diffuse. Also, all 4 are
adjustable in both dimensions.

15. ksOrenNayar

16. ksPerPixel
This shader is basically for plastic surface types, but it is one of the most used shaders in AC, being really versatile, so it’s not limited to that purpose.

- ksPerPixel (and some other shaders) can be alpha blended, it means that the shader performs semi transparencies. An alpha blended object will ALWAYS
create a sorting problem with the Z buffer: some pixels are at a certain distance, some pixels (the ones semi-transparent) are at 2 different distances, so the
GPU doesn't know where is the exact position of the pixel. An alpha blended object needs to be sorted in the drawing order. The flag Is Transparent tells the
GPU to draw the object as last in the order. A transparent-flagged object is excluded from the motion blur (because motion blur needs to know the distance
from the camera of an object).

17. ksPerPixelAlpha
It’s just a version of the ksPerPixel shader with the control of the level of transparency (adjustable alpha strength), that can be changed by the game engine.
Obviously if you don't want the engine to have control over the level of transparency, use ksPerPixel, it has less functions to be calculated.

For Multiple transparent object-layers set "IsTransparent=True".

Disable casting shadows for skidmarks, dirt, etc.

ksPerPixelAlpha usage for track skidmarks (grooves):

1. Create a mesh on top of the road surface and map it with a semi-transparent dirt, rubber, tiremark texture
2. In the AC-Editor apply the following shader settings
shader: ksPerPixelAlpha
alphablended: true
castshadow: false

Play around with the alpha value and note the best min/max values for the given case.

3. Edit the grooves.ini:

[HEADER]
GROOVES_NUMBER=3 <--- number of individual objects

[GROOVE_0]

295
NAME=Rubber1 <--- name of the object
MIN=0.05
MAX=0.6
MULT=5

% ▲ The multiplier defines the change of saturation of the texture with every car crossing. Strangely higher values result in slower buildup of rubber.

Using ksPerPixelAT for skid marks causes some pixel artefacts and visible steps in gradients. ksPerPixelAlpha is the better choice, it's smooth and gradients
work fine. MULT=5 works for 5 laps (w/ 16cars) perfectly.

If you are using multiple groove layers, don't forget to set your object transparency (isTransparent=True).
More about track grooves in ()
18. ksPerPixelAT
This shader is commonly used for plastic fences. It’s the ksPerPixel shader with alpha test properties (AT=alpha test, for “transparent” stuff), given the
AlphaTest flag for ksEditor. It uses alpha as ON/OFF; there is no transparency: either a pixel is drawn or not. It can be alpha blended (gradient instead of
ON/OFF), but it's a waste of calculations.

My suggestion: use of alpha blending should be very limited: if it can be done with alpha test, use alpha test.

19. ksPerPixelAT_NM

20. ksPerPixelAT_NS
It is basically the ksPerPixelAT shader without the rendering of the shadows (No Shadows) on it and a different filtering of the texture. It's an old shader, I
think no more used in any content.

21. ksPerPixelMultiMap
This shader is the basic car paint shader, but it’s really multi-purpose. It has standard diffuse, gloss, reflection, specular (specular always black and white, no
colour ever in AC). If you’re working with body paint, it’s preferrable to use ksPerPixelMultiMap_damage_dirt which includes all the features, with dust and
damage on the vehicles.

296
The NM texture slot is for model details and is always displayed.

22. ksPerPixelMultiMapSimpleRefl

23. ksPerPixelMultiMap_AT

24. ksPerPixelMultiMap_AT_emissive

25. ksPerPixelMultiMap_AT_NMDetail

26. ksPerPixelMultiMap_damage

27. ksPerPixelMultiMap_damage_dirt
297
The standard shader for body paint. The NM texture is for damage, not for model details, so it is displayed only when the vehicle takes damage. There are
also slots for dust/dirt on the car.

The damage shader is hardcoded in AC, and it only applies damage if the shader name is exactly ksPerPixelMultiMap_damage_dirt.

FAQ
QUESTION [1]: How do I get dirt to appear on glass? Only the ksPerPixelMultiMap_damage_dirt has the dirt feature, but it doesn't support alpha.
ANSWER [1]: You don’t.

28. ksPerPixelMultiMap_emissive

29. ksPerPixelMultiMap_NMDetail
Sandtrap shader which switches to different nm texture at close range although that might look really weird. It is used on sand traps so
one nm texture creates the sand dune effect while the other texture creates the sand nm effect at closer range.

30. ksPerPixelMultiMap_NMDetail_emissive

31. ksPerPixelNM
txDiffuse = main diffuse colormap

txNormal = normalmap

Notes: This shader is used for rocks and similar surfaces with a large amount of normalmap-details

32. ksPerPixelNM_UV2

33. ksPerPixelNM_UVMult

34. ksPerPixelReflection
Make sure your external glass is ksPerPixelReflection, internal ksWindscreen; make sure your faces aren't flipped to the inside on the ext_glass.

35. ksPerPixelSimpleRefl

36. ksPerPixel_dual_layer

37. ksPerPixel_nosdw

38. ksPostFOG_MS

39. ksShadowGen_debug

40. ksSimpleShader

41. ksSkinnedMesh

42. ksSkinnedMesh_NMDetail

43. ksSky

44. ksSkyBox

45. ksSkyCubemap

46. ksTest

47. ksTree

298
ksTree is like the ksPerPixel shader, the only difference is that materials don't receive environment object shadows. You can use ksPerPixelAT for trees (close to the
track/track cameras). It's recommended to use Y-tree meshes for correct lighting. X-trees have some lack of edgepoints.

It seems to have an "auto-normals function". Meaning that if you have the origin set somewhere on the trunk axis, it will automatically orient normals around, in a sphere-like
manner in order to achieve the best lighting; hence making the trees NOT look like cardboards.

Works like ksPerPixelAt_NS but with a better filtering (=?).

48. ksTyres
Which alpha layer should one use for tire rubber textures? What does the alpha actually do?

With ksTyres alpha is a specular map (white = more specular, black = less) so basically the glossy parts (sidewall outside of text) have high alpha, tread has
low alpha, grooves in the tread even lower.

If you use normal map it has more effect then what the specular does, but for things like the logos, the alpha layer works really well, and even more for the
grooves in tread, you get really nice dark lines. It's also good for adding texture, especially when a sharp normal map looks too puffy in reflection/specular
highlights if you try to add little rubber bumps (eg. a slick tire).

49. ksWindscreen
ksWindscreen is a shader for smudges, dirt, etc. on the windscreen of the car.

For the inside mesh of the windshield, use a separate material with the ksWindscreen shader, so you don't get weird reflections of the asphalt. Texture for
that looks like the reflections of the dashboard + dirt etc. on the window. May automatically do the shattered glass too, idk. Although that does need the
objects named in damage.ini so it knows which side of the car they're on.

299
Fig. – For the exterior windshield mesh use the ksPerPixelReflection, alphaBlend with isTransparent=True. This is with a texture ~4% transparent, fresnel settings depend quite a bit on
the texture's alpha channel.

Make sure your external glass is ksPerPixelReflection, internal ksWindscreen; make sure your faces aren't flipped to the inside on the ext_glass.

(any windshield is basically two layers of glass with two different shaders)

WIP

10.4.6 – CSP SHADERS DESCRIPTIONS

1. ksMultilayer_fresnel_nm4
Shader which is very similar to ksMultilayer_fresnel_nm, but with four separate normal map textures aligned with the detail maps (instead of one texture
mapped to the main UV), and masked with txMask. Has four separate options for fixed tiling, instead of using ksEmissive trick. Good for landscapes.

Tiling fix

Unlike the original multilayer shader, this one has proper options for tiling fix, separate for each channel: tilingFixR, tilingFixG, tilingFixB and tilingFixA. To
enable tiling fix, change according option from 0 to 1. Please keep in mind tiling fix requires an extra texture sample, do not use it for textures which are too
high res.

2. ksMultilayer_objsp_nm4

3. ksPerPixelAT_NM_emissive

4. ksPerPixelMultiMap_AT_emissive

5. ksPerPixelMultiMap_emissive
This shader is an exact copy of the vanilla ksPerPixelMultiMap, but with an extra txEmissive map used as multiplier for emissive color. You can use a black
and white mask in there, or add color. Original shader multiplies txDiffuse by ksEmissive (similar to “Multiply” blending in Photoshop), this one also adds
txEmissive multiplication step.

Few examples:

• White txDiffuse, red txEmissive, ksEmissive set to (1, 1, 1): red glow.
• Red txDiffuse, yellow txEmissive, ksEmissive set to (1, 1, 1): red glow.

Set emSkipDiffuseMap to 1 to stop txDiffuse from affecting emissive color.

Multi-channel mode

To enable multi-channel mode, set emChannelsMode option to 1. In that mode, shader will use red channel of txEmissive as a mask for ksEmissive, green
channel is mask for ksEmissive1, blue is for ksEmissive2 and alpha is for ksEmissive3. Later, in either car or track config, you can bind different emissive
variables to different events, allowing you to use a single mesh for, for example, braking, parking and reverse lights without splitting.

If you have a symmetrical mesh, you can use more than four channels: for example, if you set emMirrorChannel3As4 to 1, anything on one side of
symmetry plane would use ksEmissive4 instead of ksEmissive3. Use emMirrorDir and emMirrorOffset to setup symmetry plane (default value for mirror
direction would be 1 0 0, to mirror from left to right; also, keep in mind it uses local mesh coordinates). With this option, you can get all car’s rear lights
from a single mesh: use three normal channels for brake, parking and reverse lights, and third+fourth for turning lights (so map for turning lights would be
set in alpha channel of txEmissive).

6. ksPerPixelMultiMap_NMDetail_emissive
This shader is an exact copy of the vanilla ksPerPixelMultiMap_NMDetail, but with an extra txEmissive map used as multiplier for emissive color. For a more
detailed explanation, see the description of the ksPerPixelMultiMap_emissive shader above.

7. smCarpaint
smCarPaint is made to work with ksPerPixelMultimap or ksPerPixelMultimap_damage_dirt; anything else won't look quite right.

8. smSticker

9. stPerPixelMultiMap_specular

10. stPerPixelMultiMap_specular_damage_dirt

11. stPerPixelNM_UVflow
300
12. st_multimap

10.4.7 – SUMMING UP: WHICH SHADER TO USE

Materials/surfaces:
Aluminum

Carbon fiber

Carpaint: ksPerPixelMultiMap; ksPerPixelMultiMap_damage_dirt (if you add scratches/dust effects)

Chrome: ksPerPixelReflection

Leather and fabric: ksPerPixelNM_UVMult

Paint (flakes)

Plastic

Glass

Rubber

Steel

Tires: ksPerPixel_NM

WORKING WITH CSP SHADERS

With the beta test update 0.8.2441.39642 of Content Manager, a new CSP 0.1.78 showroom mode has been introduced, that allows you to visualize the car with the modded
shaders and additions. Apparently, this is achieved with the creation of a special race session that replaces the vanilla showrooms.

301
10.5 - EXPORT YOUR MODELS TO .kn5
I never drink coffee; I don’t like it. Personal preference. However you shall drink something now, as you’re almost ready to do bring your .fbx files into the
AC format. After all the settings you changed for your shaders (hoping you saved the persistence quite often) you should be ready for it.

It’s just a small part of the work when making a mod, but you will have to do it quite often while testing and editing your creations
(especially if you do a lot of trial and error), so you probably will get used to this operation, which consists of the following steps:

1. Open with ksEditor your .kscp project or your single .fbx file
2. Check if every shader/material has its respective textures assigned
3. Click on the File menu and in the cascade menu that opens go to Save KN5, then select Car.
4. In the File Explorer window that appears, open the FIN folder and give the name you chose to the file.
5. Done

10.5.1 - GUIDE TO THE VARIOUS ERRORS IN KN5 MODELS AFTER THE EXPORT
There isn't too much you actually can do wrong on the model. If it’s got all the needed Nulls/Empties, and if every mesh object has a corresponding material
assigned to it (can be the same for everything), and if it loaded into KsEditor and you exported from there as kn5, it should be fine.

- looking in the proview_nodes.ini (which the game creates automatically), you can check your kn5 model: in the following example it
appears that most of the mandatory empties are missing or incorrectly written:
[NODES]
WHEEL_rR=0
____wheel_RR=0
WHEL_RF=0
____wheel_RF=0
WHEEL_L=0
____wheel_LF=0
BODY=0
wheel_LR=0

- Giant wheels suggest that you have scaled the dummies at one point or another - either reset xforms in 3DsMax, apply the scale in Blender or just create
new empties - doesn't matter what size, as long as they are never scaled.

FAQ
QUESTION [1]: In my 3D editor the wheels and tires look exactly the same on both sides of the car but when I open the model in KsEditor, when looking at
the passenger side of the car, the outer sidewall of the tire is missing and the texture on the wheel is incorrect, see Fig.

Fig. – (left) How the wheel is incorrectly displayed. (right) How it should look.

ANSWER [1]: This may happen if you mirror a vehicle part, it will look correct in 3DsMax and wrong in ksEditor/AC. Check if the scale of the object is -1
(minus 1), as it needs to be set to 1. In the example the tex is actually correct, but the normals of the tire and the rim are inverted after the export due to the
mistake. To solve it, the easiest way is to apply the scale. In 3DsMax it’s done with the Reset Transform (XForm) utility. But since you have textures on your
rim, the best method is to change the scale back to 1 and rotate the object around. Then, if needed, apply that rotation. Use Symmetry, or mirror, never use
negative scale, that will screw up normals. For Blender users: applying rotation/scale (not location) to empties + objects and then fixing any mis-mirrored or
inside-out object in Edit mode (using mirror & 'flip direction') is probably the way to go.

The same error may cause lighting issues, which may be also a symptom of a backwards or badly baked normal map.

302
CHAPTER 11 – PHYSICS, VEHICLE DATA AND CONFIGURATION FILES
At this point the AC graphics engine knows how to communicate with our visual 3D model, but we still need to define all the nice technical data around our
vehicle that the physics engine will use for the simulation.

The files inside the data folder of any car (or the packed/encrypted data.acd file) are responsible for every behaviour, from physics to animated graphic
elements; it’s important to understand that each one has a very specific function here. However the subject will be treated as a whole, since all these
configuration documents influence the entire driving experience (the so-called “feel”) of your vehicle in a different way.

The data examples and explanations of Par. 6.3.3 are dedicated to vanilla AC, but there also explanations about modded CSP features (extended physics).

If you want to work with vanilla data/physics properly, I would recommend to disable Custom Shaders Patch.

Be aware that you may encounter bugs or crashes of any kind after disabling the mod, especially with assets that require its features to work, cars or tracks.

To disable it completely, delete or move in another folder the dwrite.dll file the patch puts in the AC root folder during the install process. It is the hook for
the patch's files, and the extension folder is its companion resource directory where it actually stores all the default settings along with the modified shaders.
Another way you can deactivate CSP, if you have CM, is by unticking the Active checkbox in the settings dedicated to CSP (Fig. 11.0).

Fig. 11.0 - How to disable CSP in CM. Keep in mind that AC may crash with specific mods that aren’t supported on vanilla (CSP only).

Keep in mind that many CSP features can be added without altering vanilla data, via a config override in the extension folder of your mod, but in some cases
lines of code have to be added in the original AC vehicle files, which therefore must be as correct as possible in advance.

Pro tip: You could complete the vanilla part of the physics/data first, and later “build on it” with CSP, but the mod actually fixes some bugs that are present in AC, so you should
use it from the beginning if you want a more bug-free experience and minimize the need of backtracking errors.
Here is a list of the fixes:
- Fix for anti-effects suspension geometries (anti-squat, …)
- Fix of the mass bug for STRUT suspension types
- Fix for progressive rates of suspensions (springs and bumpstops)
- Fix for
Be aware that the mod itself is under development, so other non-bug-fixing features may be buggy. It is a compromise, so there are diminishing returns the more you use it.

Unlike all other features focused on compatibility with original AC, all physics extensions require specifically modified car data: this way, none of existing
cars behave any differently. Cars utilizing new features (extended physics) won’t work in AC without the patch.

303
11.1 – PHYSICS PREREQUISITES
This paragraph (very loosely defined as such) will show you many concepts that will be taken for granted in the continuation of this book. It may be an occasion
to revise for those who already know them.
Just to summarize, below are the topics that will come into play when going deep into vehicle physics. They are considered prerequisites when taking this
subject as a university course.
• From Mathematics courses: trigonometry; limits, derivation and integration of functions; Taylor series and Maclaurin series of common functions; linear differential equations
with constant coefficients; partial derivatives; derivation of implicit functions; matrices and vectors, linear systems; reference systems; eigenvalues and eigenvectors; rotation
matrices; parametric equations of curves; conics and quadrics.
• From Physics courses: kinematics and dynamics of the material point. Energy and momentum. Relative motions. Centres of gravity and moments of inertia. Kinematics and
dynamics of the rigid body in plane motion. Cardinal equations. Lagrange equations. Basic elements of fluid mechanics.
In the next pages we will take a look at the theory of vehicle physics, with practical applications (where possible). If you are not well versed in all this, I advise
you to study further; if you take things too quickly here you won’t comprehend anything. Some theoretic concepts may require not only the knowledge of
mathematic operations like derivatives and integrals, but also basic physics principles, like vectors and fields, to be fully understood, but don’t worry too much
about them (at least for now). If you’re a physics nerd, like me, you will have fun either way.
Along the line you may find also reflections and insights of the engineer’s or the scientist’s thought process (e.g., how we solve problems). This will be the
sum-up of various years of study and passion of mine into few lines.
Obviously my explanations won’t replace a good textbook, and may lack the necessary depth, but I hope they will stimulate you enough to become curious.

11.1.1 – PHYSICS IS MODELS

Let’s admit it. We’re lazy, very lazy, and we have a hard time when it comes to understanding the world around us. But we created many tools with our mind.
One of them is math. The quantification of a property allows us to write down (in our computers store) variables and treat them with common rules, for example
addition or subtraction, multiplication or division. Many operations can be done with numbers, and we invented some of the latter to solve specific situations.
Take for example imaginary numbers, they come in handy when you operate a square root on a negative number, that for the math level of a middle-school
student is impossible to solve:
2
√−4 = �(−1) ∙ 4 = √4 ∙ √−1 = 2√−1 = 2𝑖𝑖
The 𝑖𝑖 is our friendly imaginary number. Often called imaginary unit, 𝑖𝑖 is equal to √−1 , and 𝑖𝑖 2 = −1. Seems absurd, right? Squared numbers are always
25 25 625
positive (e.g. 52 = 5 ∙ 5 = 25, or (−12,5)2 = (−25/2)2 = �− 2 � ∙ �− 2 � = 4 = 156,25). But that’s exactly what this symbol is for.

Now, math and physics do not explain the world, they just try to do it, with various tricks such as the one we just mentioned, fruits of our creativity. This means
that there is a lot going on behind the scene. Allow me to elaborate further.
When we have a system composed of many parts, each one with an almost infinite number of features (imagine how many things we still don’t know of the
universe!), we do not consider an object “as is”, in the sense that we do not include all the characteristics that determine its existence. That would be painful
and philosophically contorted, while we need to be pragmatic.
The objective is to represent any type of body (even things that aren’t really bodies) with the lowest effort possible, in order to focus on the properties we’re
interested into. Based on our experience, nature is quite reliable and lets us divide problems into various parts.
The question then is: how can we create a mathematical model of a complex natural phenomenon and simplify it as much as needed, without losing any piece
of the puzzle (ergo, without being inaccurate)?
Engineers (but also physicists and any kind of scientists) can proceed this way: you try to understand completely the experimental evidence, and you formulate
some of the following hypothesis:
• Some effects cancel each other: an example is the weight of a pen on your table and the constraint reaction force of the table which “pushes” it upwards: this depends on
Newton’s Third Law of physics, where every action (force) causes a reaction of equal intensity (later, magnitude) and opposite direction. This is called EQUILIBRIUM.
• Some effects have so little (negligible) impact on the general behaviour that they can be ignored. A lot of trouble is caused by this part, involving mostly guessing and
tolerances. Yes, engineers do still guess many things. And sometimes become mad scientists. Try delving into metallurgy & steel alloys and tell me how much empiric stuff
is there. Very often (read: always) companies have their own recipes, literally handed between professionals.
• Assumptions can be made.

To apply these principles, we can consider the Brownian motion: it is the random movement of a particle (most of the time atoms and molecules) suspended
in a medium (a liquid or a gas). Fig. clarifies the problem, which tries to give an explanation to a chaotic system.

304
Fig. – Sample drawings of the Brownian motion. This path is given by the interactions (collisions, but more correctly repulsions, since they don’t touch) between atomic elements.

This motion is very complex and it happens every day in our life at a micrometric [μm] scale, in the air we breathe, in the water we drink, in our blood, in the
fuel mixture of internal combustion engines. Its laws can be applied to other contexts too, mainly statistic. But race car engineers and our simulator, both
working with aerodynamics, couldn’t care less about it. The movement of one molecule has almost no impact on the downforce generated by the rear spoiler
of our prototype. What we care about is the total behaviour, the movement of the fluid volume net of intermolecular forces, not what the singular molecules
do. That detailed part is reserved to chemists, physicists and probably very specialized surface aerodynamics engineers.
We use the Gas laws based on experimental evidence to do all the calculations then. These rules simplify with few parameters the properties of a fluid and
significantly reduce the number of operations we need.
The same happens with tires. WIP

11.1.2 - MODELS ARE “SIMPLE”: REFERENCE SYSTEMS, VECTORS, COORDINATES

For our purposes, physics steal concepts from geometry and algebra, since in our reality everything happens into a space. The three disciplines are actually
made from and for each other.

So as our first instance we have the need to specify where our object is and where it is going, if it’s moving. Thus, we’re going to explain the following
definition:

“Coordinate systems Ki are introduced as orthonormal systems, where the coordinate axes xi; yi; zi are defined as being perpendicular to each other. Unit or base vectors
exi; eyi; ezi, having a length of 1, belong to their respective axis”. (Schramm et al., 2014)

Let’s imagine three grids, like tiled floors, that cover various directions, perpendicular to each other, the latter we call axes x, y, z (Fig. left). These grids are
indefinitely long and intersect each other at a place that we call origin O.

Fig. – It’s just like the corner of your room.

We can assume that the side of each tile is one unit long; they can be metres, miles, centimetres or anything you want. If we forget about the unit, we can
associate a pure number to every line of the grid (Fig. right). We call this number coordinate.

This is what we call reference system of our 3D space. Every calculation, either done by hand or by the computer, depends on it. To represent it with math
symbols, we could write S = (x, y, z), but a more appropriate notation is 𝑲𝑲1 = �𝑂𝑂1 ; 𝑒𝑒𝑥𝑥1 ; 𝑒𝑒𝑦𝑦1 ; 𝑒𝑒𝑧𝑧1 �, where O1 is the aforementioned origin. The number
1 appears because it is the first system we considered. This will become useful later, as Assetto Corsa uses many of them, at least two.

305
If we want to highlight a point in space, we can do it with a dot, and call it “A”; that is not enough if we want to actually define our position. We must use the
coordinates like a ruler, and write down the numbers we get. In Fig. left below our point in space is defined like this: A (4,5; 3; 2,5)

Fig. -

Because A is moving, let’s just draw a straight arrow pointed towards the destination, long enough to cover the entire distance. The tip will be at a “B” point,
���� you just drew a vector, that shall be indicated with the symbol 𝑣𝑣⃗ (Fig. right).
defined as B (3,5; 1,5; 1,5). There you have it; within the segment 𝐴𝐴𝐴𝐴

In this example, since the direction is negative (towards left), it is the result of the following sum: 𝑣𝑣⃗ = 𝑣𝑣 𝑣𝑣𝑎𝑎 If the origin of 𝑣𝑣⃗ was on B and the tip on
����⃗𝑏𝑏 − ����⃗.
A, we would have had 𝑣𝑣⃗ = ����⃗ 𝑣𝑣𝑏𝑏 This highlights the importance of sign (+/-) and direction of vectors (Fig.).
𝑣𝑣𝑎𝑎 − ����⃗.

The beginning and the end of a vector must be distinguishable then, and its arrow cannot be missing in the drawing (meanwhile the arrow in the symbol 𝑣𝑣⃗
is often omitted in textbooks and such, so we’ll use the following notation: 𝑣𝑣). In our case, we can measure the length with this formula:

|𝑣𝑣⃗| = �(𝑥𝑥𝐴𝐴 − 𝑥𝑥𝐵𝐵 )2 + (𝑦𝑦𝐴𝐴 − 𝑦𝑦𝐵𝐵 )2 + (𝑧𝑧𝐴𝐴 − 𝑧𝑧𝐵𝐵 )2 (hjgkhk)

Where |𝑣𝑣⃗| is called modulus or norm 42 of the vector, its absolute length, and 𝑥𝑥𝑖𝑖 , 𝑦𝑦𝑖𝑖 , 𝑧𝑧𝑖𝑖 are the coordinates of the points in the 3D space. We obtain a
length of 2,062 units.

At this point you also probably understood what the base vectors are for: they determine the “size” of your tile. In Fig. is a more serious drawing of our
orthonormal coordinate system.

Fig. -

Elementary algorithms for vectors

The introduction of the term vector is illustrative, as the vector itself always has a geometrical or physical meaning. The following elementary algorithms are
applicable:

• Sum and product:

𝑎𝑎 + 𝑏𝑏 = 𝑏𝑏 + 𝑎𝑎 commutative law,
𝑎𝑎 + (𝑏𝑏 + 𝑐𝑐) = (𝑎𝑎 + 𝑏𝑏) + 𝑐𝑐 associative law,
𝑎𝑎 ∙ (𝑏𝑏 + 𝑐𝑐) = 𝑎𝑎 ∙ 𝑏𝑏 + 𝑎𝑎 ∙ 𝑐𝑐 distributive law.

42
Euclidean norm.

306
• Scalar product:
𝑎𝑎 ∙ 𝑏𝑏 = |𝑎𝑎||𝑏𝑏| cos 𝜃𝜃
𝑎𝑎 ∙ 𝑏𝑏 = 𝑏𝑏 ∙ 𝑎𝑎 commutative law.
• Vector product or cross product
• Scalar triple product
• Vector triple product
• Vector quadruple product (LAGRANGE’s identity)

As you can see, vectors can be summed and subtracted (𝑢𝑢 �⃗ + 𝑣𝑣⃗ = �𝑢𝑢𝑥𝑥 + 𝑣𝑣𝑥𝑥 , 𝑢𝑢𝑦𝑦 + 𝑣𝑣𝑦𝑦 , 𝑢𝑢𝑧𝑧 + 𝑣𝑣𝑧𝑧 �); they can also be multiplied by numbers (𝛽𝛽 ∙ 𝑣𝑣⃗ =
𝛽𝛽𝑣𝑣⃗ = (𝛽𝛽𝑣𝑣𝑥𝑥 , 𝛽𝛽𝑣𝑣𝑦𝑦 , 𝛽𝛽𝑣𝑣𝑧𝑧 )) or with each other 43, and you can determine their angle.

In any computer-graphics engine, included Assetto Corsa’s one, calculations such as these are processed multiple times per second for each point, that can
be a geometrical vertex (meshes, empties) or a physical location (centres of gravity, suspension linkages and joints), to define the position of every entity
with coordinates. Geometry data is merged, compared or overlapped with physical data; this happens at high rates, especially in a simulator.

Everything works on a scale of million and billion times per second, with tons of vectors, and to optimize this huge work programmers usually adopt a matrix
system (array), that can be stored, loaded and manipulated quickly at the machine-code level, unlike the formulas we commonly use and see in the physics
literature. A matrix is a group of numbers (elements) that are arranged in rows and columns. In general, an m × n matrix is a rectangular array of mn
elements arranged in m rows and n columns. If m = n the matrix is called a square matrix. The basic and complex mathematical operations are adapted to
this scheme, that is managed via normal coding languages such as C, C++ and C# which are then compiled and translated into functional assembly code
that can be directly read by the CPU of our computer.

Going back on topic with one of the most important concepts, the origin O of the 3D grid is our reference point, where you, the one who is observing a
body, are. It can also be considered as the vector whose length is zero, with the symbol �0⃗ = (0, 0, 0), or a generic vector multiplied by zero (0 ∙ 𝑣𝑣⃗ = 0 �⃗).
The previously mentioned reference system is based on your point of view of the phenomenon, while it’s happening. If you don’t have one, you can’t tell
who is who and where it is going, thus your vector is meaningless.
Is the sun moving in the sky or is it the Earth rotating on its axis? No-flat-earthers zone. Is the train travelling or the landscape flowing? It depends on the
perspective of the observer.
The origin doesn’t necessarily have to be where he is located, but for now I won’t overcomplicate it (you’d need to understand the basics of Galilean
relativity).

The number of axes can be assimilated to the dimension of the space considered; written more appropriately, with two axes (x, y) a two-dimensional plane
is obtained, often called Cartesian plane; with just one (x) you obtain a mono-dimensional space, basically a line.

With four or more you get a n-dimensional space (if it can still be considered a space), and as n goes to infinity:

S 𝑛𝑛 = {(𝑎𝑎1 , 𝑎𝑎2 , 𝑎𝑎3 , … , 𝑎𝑎𝑛𝑛 ) | 𝑎𝑎1 , 𝑎𝑎2 , 𝑎𝑎3 , … , 𝑎𝑎𝑛𝑛 ∈ 𝐑𝐑}

Where Sn is the vector space, ai is the vector coordinate, and R is the field of real numbers that includes whole numbers (3), rational numbers (-16/7)
13
and irrational numbers ( √17, π, e, etc.).

Usually in physics a four-dimensional space has time as the fourth variable, even though it’s not mandatory: S 4 = {(𝑥𝑥, 𝑦𝑦, 𝑧𝑧, 𝒕𝒕)}. This is called space-time.

With vectors you can represent almost anything. There are few exceptions, but those are not really our business. Since the vector is just a segment, its
length, called magnitude, can really be whatever you want, from the force on a suspension to the gravitational field in the proximity of a planet.

Let’s see then what a vector can portray that is of our interest:

• Position: coordinates, displacement

• Velocity: linear, angular (rotational)
• Acceleration: linear, gravitational, centrifugal, centripetal
• Force: weight, elastic, friction
• Momentum: inertia, angular

WIP

43
There are two types of multiplication between vectors, one of them involving trigonometric functions such as sin(θ) and cos(θ), where θ is the angle generated by the directions.

307
11.1.3 - VEHICLE DEFINITION
Before embarking into the development of mathematical models, it is perhaps advisable to discuss a little what ultimately is (or should be) a driveable road
vehicle.
Since a road is essentially a long, fairly narrow strip, a vehicle must be an object with a clear heading direction, which as we already saw can be portrayed by
a vector. For instance, a shopping cart is not a vehicle, since it can go in any direction. Another common feature of road vehicles is that the driver is carried
on board, thus undergoing the same dynamics (which, again, is not the case of a shopping cart).
Moreover, roads have curves. Therefore, a vehicle must have the capability to be driven in a fairly precise way. This basically amounts to controlling
simultaneously the yaw rate, that is the angular velocity changing the direction of motion of the vehicle, and the magnitude and direction of the vehicle speed.
To fulfill this task a car driver can act (at least) on the brake and accelerator pedals and on the steering wheel. And here it is where vehicle dynamics comes
into play, since the outcome of the driver actions strongly depends on the vehicle dynamic features and state.
An example of proper turning of a road vehicle is something like in Fig. (left).

Fig. – (left) In blue, a vehicle’s expected (ideal) behavior when negotiating a curve. (right) In yellow, acceptable (real) behaviors for a road vehicle.

Small deviations from this target behavior, like those shown in Fig. right, may be tolerated. They are pretty much the understeer and oversteer conditions
you can find explained at pag. of this book (PART 1: AC User Manual). On the other hand, Fig. shows two unacceptable ways to negotiate a bend.

Fig. – Unacceptable behaviors for a road vehicle.

All road vehicles have wheels, in almost all cases equipped with pneumatic tires. Indeed, also wheels have a clear heading direction. This is why the main
way to steer a vehicle is by turning some (or all) of its wheels 44.
To have good directional capability, the wheels in a vehicle are arranged such that their heading directions almost “agree”, that is they do not conflict too
much with each other. However, tires do work pretty well under small slip angles and, as will be shown, some amount of “disagreement” is not only
tolerated, but may even be beneficial.
Wheel hubs are connected to the chassis (vehicle body) by means of suspensions. The number of possible different suspensions is virtually endless.
However, as we will see when discussing Assetto Corsa’s vehicle configuration files (pag.), suspension systems can be broadly classified into two main
subgroups: dependent and independent. In a dependent suspension the two wheels of the same axle are rigidly connected together. In an independent
suspension they are not, and each wheel is connected to the chassis by a linkage with “mainly” one degree of freedom. Indeed, the linkage has some
compliance which, if properly tuned, can enhance the vehicle behavior.

44
Roughly speaking, the wheels’ location does not matter to the driver. But it matters to engineers.

308
11.1.4 – INTRODUCTION TO VEHICLE DYNAMICS
A land vehicle has three main aspects that will be the subject of our studies:
• LONGITUDINAL dynamics;
• LATERAL dynamics;
• VERTICAL dynamics;
Longitudinal dynamics deals with the laws under which the vehicle moves according to a rectilinear trajectory, making uniform, accelerated or decelerated
motions. The basic aspects related to longitudinal dynamics concern:
- Powertrain sizing;
- Sizing of the braking system and distribution of braking forces to the axles;
- Selection of transmission gear ratios;
Lateral dynamics studies the laws by which a vehicle moves along a curved trajectory (usually by setting a law of motion). The curved trajectory, the object of
study, can be set by the steering system (steering), or by an external perturbation. Depending on which way the curvilinear trajectory is set, different objects
of study are identified:
- the oversteering or understeering behavior of the vehicle if the curve is set by means of the guidance system, as is the case in the study of a motor vehicle;
- the ride stability at high speeds and the vehicle's cornering attitude, if the lateral dynamics is due to an external perturbation. This field of investigation
generally arises in the study of the lateral dynamics of a railway vehicle.
Vertical dynamics studies the vibratory motions by which the vehicle reacts in the presence of road irregularities. This study is related to both comfort and
ride safety issues, in relation to the phenomena of wheel detachment or rollover.

Finally, one should talk about all aspects related to the control of driving dynamics. Increasing the performance of a motor vehicle today is closely connected
with the use of appropriate control systems, both on the road (ABS, traction control, ESP, active suspension & steering systems, etc.) and on railways (anti-
skid, active suspension, etc.).

The forces that are exchanged in the motion of the vehicle are of various kinds:
• forces at the wheels;
• aerodynamic forces;
• driving forces generated by the powertrain;
• braking forces due to the action of the brakes.
The latter two types of forces are properly internal forces in the system, but because they generate work, they must be taken into account when evaluating
vehicle dynamics.

309
11.1.4 - VEHICLE BASIC SCHEME
We’re back to models. A mathematical model of a vehicle should be simple, yet significant. Of course, there is not a unique solution. Perhaps, the main point
is to state clearly the assumptions behind each simplification, thus making clear under which conditions the model can reliably predict the behavior of a real
vehicle.
There are assumptions concerning the operating conditions and assumptions regarding the physical model of the vehicle. Concerning the operating
conditions, several options can be envisaged:
• Performance: the vehicle goes straight on a flat road, possibly braking or accelerating (nonconstant forward speed);
• Handling: the vehicle makes turns on a flat road, usually with an almost constant forward speed;
• Ride: the vehicle goes straight on a bumpy road, with constant forward speed.

Obviously, real conditions are a mixture of all of them.

A significant, yet simple, physical model of a car may have the following features:
1. the vehicle body is a single rigid body; we can find exactly the latter in Assetto Corsa thanks to the ODE solver’s basic features (pag.)(inertia+CG>>>>car.ini).
2. each wheel hub is connected to the vehicle body by a one-degree-of-freedom linkage (independent suspension);
3. the steering angle of each (front) wheel is mainly determined by the angular position δv of the steering wheel, as controlled by the driver;
4. the mass of the wheels and axles (unsprung mass) is very small if compared to the mass of the vehicle body (sprung mass);
5. the wheels have pneumatic tires (remember AC’s empirical tire brush model);
6. there are springs and dampers (and, maybe, inerters, see bumpstops in suspensions.ini) between the vehicle body and the suspensions, and, likely, between the two
suspensions of the same axle (anti-roll bar). Front to rear interconnected suspensions are possible, but very unusual (not present in AC?);
7. there may be aerodynamic devices, like wings, that may significantly affect the downforce. These are ultimately present in AC.
The first two assumptions ultimately disregard the elastic compliances (here deformations) of the chassis and of the suspension linkages, respectively, while
the third assumption leaves room for vehicle models with compliant steering systems. This description corresponds to what is portrayed by our simulator
(ACC does have chassis flex instead).
A vehicle basic scheme is shown in Fig., which also serves the purpose of defining some fundamental geometrical parameters:
1. the vehicle longitudinal axis x, and hence the vehicle heading direction i;
2. the height h from the road plane of the center of gravity G of the whole vehicle (often called CGH);
3. the longitudinal distances a1 and a2 of G from the front and rear axles, respectively;
4. the lateral position b of G from the longitudinal axis x;
5. the wheelbase l = a1 + a2;
6. the front and rear tracks t1 and t2 (suspensions.ini);
7. the geometry of the linkages of the front and rear suspensions;
8. the position of the steering axis for each wheel.

Fig. - Vehicle basic scheme and body-fixed reference system. Here b≈0 so it is not indicated.

310
All these distances are positive, except possibly b, which is usually very small (since the vehicle is for the most part symmetrical) and hence typically set
equal to zero, like in Fig.

It is useful to define the body-fixed reference system S = (x, y, z; G), with unit vectors 45 (i, j, k). It has origin in the center of mass G and axes fixed
relative to the vehicle. The horizontal x-axis marks the forward direction, while the y-axis indicates the lateral direction. The z-axis is vertical, that is
perpendicular to the road, with positive direction upward.

To be more precise, in Assetto Corsa for any car there are actually two reference systems:
1. One, 𝐊𝐊1 , is for vehicle dynamics (inertia, masses, aero, tires), and follows the common (x, y, z) convention. O1 is located at G (vehicle centre of gravity).
2. The other, 𝐊𝐊 2𝑖𝑖 , is for per-wheel vehicle component positioning (i.e., suspensions) and is Z-forward Y-up, while the x-axis direction depends on the corner considered.
O2𝑖𝑖 can be attached to the WHEEL_# dummy (pag.) or to the center of the axle, depending on the suspension type chosen.
The symbol 𝑖𝑖 stands for the wheel numbering convention in AC: 0 is wheel LF, 1 is wheel RF, 2 is wheel LR and 3 is wheel RR (Fig.).

O21
x21

x20
O20
O23

x23

x22

O22

Fig. – Visual representation of the system 𝐊𝐊 2𝑖𝑖 . (add the other y-z axes)

Very early in the physics creation process it becomes pretty obvious that in order to work correctly with the 𝐊𝐊1 reference system, the CG must be located
properly. This implies getting right the weight distribution and CG height first. It shall become a first order priority. You will have to take a look the configuration
files explained at par. , specifically car.ini and suspensions.ini for that, where more details will be given in this regard.
𝐊𝐊 2𝑖𝑖 has a peculiarity: when working on suspensions linkages, any changes to the geometry happen on both sides of the car. For example, altering the
coordinate along x20 of a joint will modify the respective coordinate along x21 of the same quantity 46. So while you don’t have to worry about making twice
the work, you are not allowed to obtain special configurations where right corners are different than the left corners (aside from what you can achieve with
setups).
It must be remarked that whenever, during the vehicle motion, there are suspension deflections, several of these geometrical parameters may undergo small
changes. Therefore, it is common practice to take their reference value under the so-called static conditions, which means with the vehicle moving straight
on a flat road at constant speed, or, equivalently if there are no wings, when the vehicle is motionless on a horizontal plane. That’s what is called the design
height of the suspension.
Accordingly, the study of the performance and handling of vehicles is greatly simplified under the hypothesis of small suspension deflections, much like
assuming very stiff springs (which is often the case for race cars). Yet, suspensions cannot be completely disregarded, at least not in vehicles with four or
more wheels. This aspect will be thoroughly discussed.
The vehicle shown in Fig. has a swing arm rear suspension and a double wishbone front suspension. Perhaps, about the worst and one of the best kind of
independent suspensions. They were selected to help explaining some concepts, and should not be considered as an example of a good vehicle design.

(wip) 11.1.5 - VEHICLE MODEL FOR HANDLING AND PERFORMANCE

45
Unit vectors are
46
Keep in mind that with respect to 𝐊𝐊1 , these are opposite directions. Galilean relativity is implied here.

311
11.2 - THE ASSETTO CORSA PHYSICS ENGINE
Due to AC’s modular nature, the physics engine can be attached and detached from the graphics, so it could be (relatively) easily replaced by the devs if
necessary, given the fact that they possess the source code.
We do not have this privilege, but can reverse engineer the 64-bit architecture acs.exe in the main install folder and discover what is officially called the
“Kunos Simulazioni Physics Engine” (Fig.), and divide it in two parts, due to their recognizability: a base physics solver and several additional physics
formulas. Let’s explain both for a while.

Fig. – Directly from the code in execution. Apparently Kunos doesn’t have much fantasy with their internal names. You can also see some lines for the CPU multithreading.

11.2.1 - THE PHYSICS SOLVER

First of all, what is a physics solver?
It is what truly powers the simulation. It usually consists of a platform that does all the calculation work, generating the container 2D/3D environment (the
world), creating all the objects (entities) of the virtual space, their kinematic parameters and their properties, the latter of which we can subdivide in two
categories, defined by physical quantities:
• Intensive, such as velocity, mass density (ρ), specific volume (v), energy density, specific internal energy (u), pressure (p), temperature (T), hardness;
• Extensive, where we find size, mass (m), volume (V), internal energy (U), spring stiffness (k), heat capacity (Cp), entropy (S), enthalpy (H) and more.
An intensive property does not depend on the size nor the amount of material in the system. It is not necessarily homogeneously distributed in space and
can vary from place to place in a body of matter and radiation. By contrast, an extensive property is a physical quantity whose value is proportional to the
size of the system it describes, or to the quantity of matter in it. For example, the mass of a body is an extensive quantity as it depends on the amount of
substance the object is made of.
These properties are widely used in real-world applications.
The fundamental quantities in kinematics are the position, speed, acceleration and time, which is very often used as independent variable, as a function of
which the other quantities are expressed.
A very simplified and visual idea of a physics solver would be the default scene of a game editor (e.g. Unreal Engine, Unity, etc.), where you have the
freedom to create objects and specify how they should behave (Fig.).

Fig. – An empty level with a simple box in Unreal Engine 4.

The physics solver of Assetto Corsa is ODE (Open Dynamics Engine, Fig.), which is “a free, high performance, industrial quality library for simulating
articulated rigid body dynamics” (R. L. Smith, 2001). It is integrated with a C++ API.

312
 Fig. – The official ODE logo.

This physics engine was written by Russell L. Smith in C/C++. Its two main components are a rigid body dynamics simulation engine and a collision
detection engine. It is free software licensed both under the BSD license and the LGPL. The official website is www.ode.org.

The project was started in 2001 and has already been used in many applications and games, such as Assetto Corsa, BloodRayne 2, Call of Juarez,
S.T.A.L.K.E.R., Titan Quest, World of Goo, X-Moto and OpenSimulator.

By default this solver defines a rigid body’s position, orientation, mass, forces 47, adding joints, constraints and the aforementioned collision system.

ODE is good for simulating articulated rigid body structures. An articulated structure is created when rigid bodies of various shapes are connected
together with joints of various kinds. Examples are ground vehicles (where the wheels are connected to the chassis), legged creatures (where the legs
are connected to the body), or stacks of objects.

The engine is designed to be used in interactive or real-time simulation. It is particularly good for simulating moving objects in changeable virtual
reality environments. This is because it is fast, robust and stable, and the user has complete freedom to change the structure of the system even while
the simulation is running. It uses a highly stable integrator, so that the simulation errors should not grow out of control. The physical meaning of this is
that the simulated system should not "explode" for no reason. Speed and stability are emphasized over physical accuracy.

ODE has hard contacts. This means that a special non-penetration constraint is used whenever two bodies collide. The alternative, used in many
other simulators, is to use virtual springs to represent contacts, which is difficult to do right and extremely error-prone. (R. L. Smith, 2006)

It is also not tied to any particular graphics package although it includes a basic one called drawstuff. It supports several geometries: box, sphere, capsule
(cylinder capped with hemispheres), triangle mesh (which AC uses for car colliders and physical roads), cylinder and heightmap.

A typical ODE simulation, from beginning to end, will proceed like this:

1. Create a dynamics world.

2. Create bodies in the dynamics world.
3. Set the state (position etc) of all bodies.
4. Create joints in the dynamics world.
5. Attach the joints to the bodies.
6. Set the parameters of all joints.
7. Create a collision world and collision geometry objects, as necessary.
8. Create a joint group to hold the contact joints.
9. Loop:
1. Apply forces to the bodies as necessary.
2. Adjust the joint parameters as necessary.
3. Call collision detection.
4. Create a contact joint for every collision point, and put it in the contact joint group.
5. Take a simulation step.
6. Remove all joints in the contact joint group.
10. Destroy the dynamics and collision worlds.

11.2.2 - THE PHYSICS FORMULAS

The formulas are really the nucleus of Kunos’s work. Using the ODE solver as a physics platform, several systems can be implemented. We do not entirely
know all the equations, but many times the developers explained them, and said that a lot come almost directly from vehicle dynamics theory. Thus, it is
possible to understand which calculations are being done.

For example, collision detections for tires can be approached in 2 ways.

1. Brute force triangle-triangle approach. Here you get every single triangle from object1 and test for a collision with every single triangle in object2. Of course there are
ways to simplify this test but it's easy to see the drawbacks. For a wheel for example, using a 3D object will require a very highly tassellated (many triangles) shape to
approach the smootness of a wheel. More triangles=more calculations=slower.
2. Basic shape approach. Where you assume that your object is tightly inscribed into a geometrical shape such as, sphere, cylinder, box and so on. A car's tire for example
could be represented with a very good approximation by a cylinder. So rather then testing every triangle agains every triangle you can test the "logical" cylinder against
every triangle in the track. Triangle to "shape" collision function are a big research argouments and it's not difficult to find code on the internet to show how to do it. That's
why I suggested to look for a "torus to triangle" routine.
In netKar Pro Kunos used a raycast plus a torque around the tire "Z" (forward) axis proportional to the camber angle. Pacejika suggests this in his book
giving some parameters. Of course the torque around the Z is also proportional the the tire width.

47
Forces are mass times acceleration (F=ma), following Newton’s second law of motion, and they determine the existence of torques.

313
11.2.3 - PHYSICS RATE
In a computational environment time is relative. To tell time computers use clocks (come on?), and the clocks use a quartz crystal oscillator that creates a
stable, periodic electromagnetic signal or vibration. But many types of oscillators exist, and computers are special ones, because they do not only tell the
time, they do many other things in the meanwhile. This means a machine’s “perception” of time is in intervals, called ticks, not in a continuum like us
humans. As a consequence, all the calculations happen “from time to time”, in short repetitive bursts with huge amounts of data. Everything is designed to
be very fast, and in a simulation, quick enough to complete everything before any frame is drawn on screen.

If you played vintage games from the early years (1980s-1990s), you will know that the framerate and physics of many titles depended on the speed of the
core processor unit (CPU). These are called CPU-speed sensitive games. Few examples are Alien Legacy (1994), Unreal (1998) and Grand Prix Legends
(1998). Thus, your game could run too fast and start glitching if your machine was more powerful than what the software was designed for. Many
videogames were becoming unplayable as technology evolved at an exponential rate, and software developers weren’t prepared. It was a true compatibility
issue.

To solve the problem, often back then machines had a software or hardware switch, the famous turbo button, to slow down the CPU clock (Fig.). The logic
was counter-intuitive but it worked. There are cases where the speed was increased instead, but they are quite unusual.

Fig. – You even had the CPU frequency display back then. It was almost mandatory at the time. Notice that they’re Megahertz (106), not Gigahertz (109)!

This problem luckily was solved; nowadays each game has its own calculation frequencies, not directly linked to the CPU speed, and works identically 48 on
every machine that is powerful enough to run it.

So Assetto Corsa has its own rates too. Its physics work at a whopping 333Hz (=3ms). That is the clock frequency (tick) of the engine 49.

Very stiff F1 cars have ride frequencies that can't simulate smoothly at that frequency, so professional simulators usually obtain measurable changes by
bumping the physics frequency up to twice as much (>600Hz / ~1.5ms, and even more, up to 800Hz / 1.25ms), but that requires a lot more
performance from the CPU. Double the update rate and you've doubled CPU time dedicated to physics, and this quickly becomes expensive. For 99.9% of
cars this is not a concern, and increasing the frequency wouldn’t be worth and noticeable for normal users, so a 3ms rate is fine. Also, with lower rates,
physics are more likely to miss something that would cause a problem.

If you’re interested, you can calculate how much track length the physics skip between every tick with the following kinematic equation (units in square
brackets):

𝑑𝑑𝑑𝑑 [𝑚𝑚] = 𝑣𝑣[𝑚𝑚/𝑠𝑠] ∙ 𝑑𝑑𝑑𝑑[𝑠𝑠] [1.0]

48
Almost identically. Even music CDs are not flawlessly reproduced on different machines. Error corrections and sampling rates exist for these very reasons. See the Nyquist frequency.
49
It shall be mentioned that this is not the FFB (Force Feedback) frequency, which is different.

314
A ms is a millisecond, so 3ms = 0.003 seconds; input this number in [1.0] as dt.

To convert the speed from [km/h] to [m/s] (metres per second) you can use the formula below, then input the result into [1.0]:
𝑣𝑣[𝑘𝑘𝑘𝑘/ℎ]
𝑣𝑣[𝑚𝑚/𝑠𝑠] = [1.1]
3.6

So, for example, if your car is travelling on a straight at 50 km/h, the physics are active every ~0.042m, so every 4.2 centimetres of track. This length
will increase the faster you’re driving and this can have an impact for example when taking a curb at different speeds: the physics ticks won’t cover the entire
bump, but only specific points, in our example every 4.2cm. You can calculate what this number will become going faster. Another example is in Fig. 6.1.

Fig. 6.1 - A visual representation of the physics’ clock while driving. Physics are active during each tick, corresponding to a point on the track, depending on the car speed. (. instead ,)

We can make a little comparison between the physics rate in AC vs other known sims/games:

1998 Grand Prix Legends - 144 Hz

2000 F1 2000 - 50 Hz [from Blackhole Motorsports article]
2001 F1 2001 - 200 Hz [from Blackhole Motorsports article]
2002-'08 Live for Speed - 100 Hz (collision detection) / 2000 Hz (vehicle dynamics) [posted by Scawen on lfsforum]
2005 rFactor - 400 Hz
2005 Forza Motorsport - 180 Hz
2006 Test Drive Unlimited - 100 Hz (collision detection) / 1000 Hz (vehicle dynamics)
2006 NetKar Pro - 333 Hz [posted by Kunos on RSC]
2007 Forza Motorsport 2 - 360 Hz [from wikipedia article]
2008 rFactor Pro - 800 Hz [from official website]
2008 iRacing - 360 Hz [from AutoSimSport]
2009 Forza Motorsport 3 - 360 Hz [from gamespot article]
2012 rFactor 2 - 400 Hz [posted on forum.studio-397.com]
2014 Assetto Corsa - 333 Hz [posted by Kunos on assettocorsa.net]
2015 Automobilista - 720 Hz [from game-automobilista.com]
2015 BeamNG - 2000 Hz [from beamng.gmbh]
2017 Project CARS 2 - 600 Hz [posted by Ian Bell on forum.projectcarsgame.com]
2018 iRacing - 360 Hz / 720 Hz for force calculation [from article on iRacing.com]
2018 Assetto Corsa Competizione - 400Hz [posted by Kunos on assettocorsa.it]

A higher or a lower phy clock doesn’t mean that the physics are directly better or worse in a proportional way, as they are handled by a complex mathematical
model in the first place, and that has a lot more influence in making the difference, especially between sims and games. The tick has a minor impact (at least
for normal/average people), but understanding how it works is important.

Actually, the tick becomes relevant whenever you play in online multiplayer. The number of the server’s ping is the time interval between any call and response
between the server and the client of the session. A ping of 60ms for example is far slower than the physics rate, and programmers have to consider these
aspects when designing their software. That’s the reason why online sessions are often full of glitches. The server and the clients must be synced to operate
correctly.
315
For the development of Assetto Corsa, Stefano Casillo used two computer clients in his studio at Vallelunga, ad a server in Singapore which gave him around
200ms of latency, which is realistic for testing.
(if possible going deeper into Assetto Corsa’s infamous multiplayer glitches).
AC always runs physics at 3ms per tick no matter what FPS you get, to make sure it behaves the same for any player, it only slows down graphics related to
the CPU usage if you have a low framerate; it is valid in offline sessions too. You will notice this if your system has got poor hardware specs. I encountered
it quite often back in the day. You’ll find yourself driving in a seemingly slow-motion state, even if the car is speeding at more than 100 km/h, as reported by
the HUD and the various tachometers. The speed of the graphics will stutter, increase or decrease depending on how heavy is the scene rendered. There is
no way a vehicle can be driven safely in said state. You can particularly notice the effect if you switch the camera to look backwards, where the car is hidden.
You’ll have an immediate FPS boost. The optimizations brought by the CSP mod mitigated a lot the problem, which is encountered more often in vanilla.
Obviously in replays physics are not calculated.

11.2.4 – RESOURCE UTILIZATION

100% occupancy generally happens on the main core of the CPU, which has to run the non-multithreaded parts of AC, so FMOD (the sound engine),
DirectX, etc. If you have a multicore CPU, this doesn't put much of a load on it because it can move around which core is calculating things, but it depends
on single thread performance.
As a general principle, multithreading can only work effectively on things that don't depend on each other. For example if you're simulating 2 cars in
different parts of the racetrack, neither has to know where the other car is to calculate tire temperatures, G forces, etc. So large numbers of AI just spread
across a multicore CPU. On the other hand, collisions need to be completely synchronized so every other calculation waits while it figures out which cars are
running into each other.
You can alter the number of CPU threads dedicated to physics and how they’re managed in the assetto_corsa.ini config, under the
%root%\assettocorsa\system\cfg folder. You can change these parameters:
[THREADING]
USE_TIMER_PROCESS=0 ; -1= Automatic, no timer process for CPU with more than 2 cores, timer process for dual cores. 0=Always off. 1=Always on.
SET_THREAD_AFFINITY_MASK=0 ; 0= Windows scheduler will decide where to run the threads. 1= Main thread assigned to Core0, physics thread to Core1

[PHYSICS_THREADING]
THREADS=-1 ; -1 = automatic, 0 = disabled, 1...n = number of threads dedicated to physics

It’s worth noting that some CSP settings deal with multithreading.

11.2.5 – LOW-SPEED PHYSICS (LSPHYS)

There is no speed sensitivity in AC's physics besides the low-speed physics, a different set of physics which kick in automatically when you go slower than
3 Km/h.
It’s normal that the LSPHYS are a bit wonky. Getting things accurate when going super slow is another story. When you become really slow, a lot of physics
calculations become super stretched and unstable, when standing still you even have things divided by zero.
Vanilla basically stops the simulation for tires at speeds under 3 Km/h to avoid the 'jitters' that used to happen in earlier versions when sitting in the pits.
This won’t affect the suspensions.
There is some kind of “dampening” of the cars under the aforementioned speed, in order to and avoid errors.
You can find the parameter that manages the LSPHYS in the assetto_corsa.ini script, and it consists of the following lines:
[LOW_SPEED_FF] ; Low speed Force Feedback (LSPHYS)
SPEED_KMH=3 ; LSPHYS activate at speeds lower than this value [km/h]
MIN_VALUE=0.01 ; The FF multiplier for 0kmh.

The game will crash if you take off low speed physics.

11.2.6 – ENGINE STALL & CLUTCH

There is no engine stall simulation in vanilla AC, therefore when you come to a stop an artificial hold is applied, like an “auto handbrake”, and the engine
RPM drops to zero, but it won't stall.
This has nothing to do with low-speed physics.
In order to start the car moving again, you just push the throttle, there is no need to put it into neutral in order to avoid the engine stall because there is
none, the engine RPM just cuts off until you hit the throttle again. Driving out purely on idle is impossible, but as long as you give it any throttle (even
0.001%), the lock, bound to pedal input and not to torque, will be gone and idle will pull the car away. So there is no problem launching without any
wheelspin. You can't launch a car with just clutch even with 500NM at idle.

This "movement lock" is a simple solution to more complex problem. You see, some tracks have start grids and pit lanes on inclines, so during races you'd
need to make sure everybody uses handbrakes, then you’d have to create more rules governing movement before start (how much can you roll from your
spot before semaphore lights go out etc). AI would need more code for that too.
Also because the game has to run on LSPHYS below 3km/h, you'd have to make sure these physics are better, with correct static rolling resistance (would
have to be a new variables made for all cars).
And after all the work, it would have to be automated anyways (so like what we have it right now, with the auto brake) for people with gamepads or mouse
steering. Then people on public servers (or even in career) would complain about crashing the car before starting the race, and automatic mode would be
made default and after some time everybody would forget that it can be disabled.
A bit sad but it just wasn't worth the hassle for AC devs.

316
What about CSP 64 bit physics? WIP

11.2.7 - FAQ: CAR DATA AND PHYSICS

QUESTION [1]: Where can I find the X_data_file that I need? There isn't the data folder in the mod’s folder, there's only an encrypted data.acd file instead.
ANSWER [1]: There are two methods to obtain the data files, both of them involve the decryption (unpacking) of the data.acd archive. Be aware that you
should not unpack files of official vehicles made by Kunos. Yes, you can do it, but only to fill knowledge gaps that tutorials or guides won't fill, because
editing copyrighted content is illegal (and if you do it, at least don’t publish it online). That’s part of the reason why this manual of mine exists, so that you
can learn everything you need without committing any crime. Even with mods, remember to treat others' data with respect. Educating yourself is one thing,
but don't abuse it. Someone worked hard to fill up that ACD originally. Not to mention that it may contain very sensitive data. Having a critical spirit and a
modicum of wisdom can make all the difference.

METHOD 1:

1. You can use Content Manager to unpack (decrypt) the data.acd of a specific car.

• Look for these tabs in Content Manager: Content > Cars, then select the car whose data you want to retrieve, then click on the Unpack data button (Fig. 4.1);
• If you can’t find the Unpack data feature, you need to enable Developer mode in CM to activate it: click repeatedly (spam-click) on the version number in the About tab.
Check Fig. 4.2 below.
• This method may not work with cars where the data.acd file has been encrypted with unofficial methods brought by CSP. More about it at par.

2. Look into data folder of the car and you will find the specific data file you want to edit;

3. Open it with Notepad++ or one of the other recommended text editors (pag.) and modify it.

Fig. 4.1 – All the steps you need to follow in order to unpack car data with CM. After you press the Unpack data button, a File Explorer will open with the newly created data folder.

317
Fig. 4.2 – How to enable and disable CM’s Developer mode.

METHOD 2:

1. Use the QuickBMS tool (currently 0.11 release) to unpack (decrypt) the data.acd of a specific car. It doesn’t require CM and CSP, as it is a small
standalone software.

Fig. 4.3 – The QuickBMS tool. The file selection window (File explorer) will open automatically.

The program is available in the extras of this manual, with its extraction and rebuilding scripts (assetto_corsa_acd.bms and assetto_corsa_acd_rebuilder.bms), required
specifically for AC, as this utility can be used to decrypt files from many other games. You can also download it from here: https://aluigi.altervista.org/quickbms.htm (QuickBMS)
and https://zenhax.com/viewtopic.php?t=90 (the specific .acd encryption scripts).

The usage is simple: after extracting the tool’s package in any folder you like,

• Double-click on quickbms.exe;
• Select the script for the type of archive you want to extract/decrypt, in our case assetto_corsa_acd.bms;
• Select the input archive or multiple files, so at this point you will select the data.acd in the mod’s folder.
• Select the output folder where the files will be extracted. This time you will have to create the data folder from File Explorer.
• Watch the progress status of the extraction and the final message.
• If everything went smoothly, you finished.
• If it doesn’t work, try opening the program as Administrator (right click on quickbms.exe > Run as Administrator). Otherwise stick to method 1.

2. Look into data folder of the car and you will find the data file you want to edit;

3. Open it with a text editor and modify it.

With QuickBMS you can also rebuild the data.acd file from a data folder using the assetto_corsa_acd_rebuilder.bms script, following basically the same
steps mentioned above.

If both methods explained here don’t work, most probably the data.acd file has been unofficially encrypted with CSP. See par.

QUESTION [2]: I’m working with the configs in the data folder but nothing changes on the car, even if I made a Lada into a Ferrari with two turbo engines.
ANSWER [2]: Vanilla AC gives the priority to the data.acd file, if present. Move it into another path outside your FIN mod folder, or backup & delete it.
Otherwise, if you use Content Manager, make sure in the Drive tab you have Use unpacked data if exists ticked on. Vadim says thanks.

QUESTION [3]: I want to swap/clone physics files between two cars, is it ok to do such a thing? Or it will break my mods?
ANSWER [3]: It will usually not work well (models not aligned with wheels anymore, dashboard non-functional, potentially crashing the game) so best is to
figure out which files in particular you want and carefully swap those, only one file at a time, testing after each file replacement that the car still loads and
works properly.

You may still need to open some configs and edit a few parameters in the code (for example car.ini is half referred to physics and half to the 3D model,
tyres.ini needs the physical tire radius to match that of the visual wheel, etc.).

Be aware that many lines refer to meshes and/or empties inside the car models, so very often the swap won't work, unless you check also for those.

I get that there are many video tutorials on the topic, but they are made by and dedicated to people who make do, people who make a living from "doing"
and have no time to waste, people who want to get a job done no matter how rough, even rightly so, you can't have perfection. When you see someone
working with physics on Content Manager, it will not be a clean piece of work. But the car will definitely get you from Dover to Calais in a day.

Cloning physics is not an easy thing at all, it's not a direct copy-paste process. Especially with F1 cars, that have a lot more functions and consequently
more lines, more file references (especially .luts, look-up-tables), so generally more things that can go wrong.

In addition, you’re giving to a car the physics from a different vehicle; as a consequence the result will not correspond to reality at all.

Not to mention that putting too much trust into other authors is wrong; you don’t know if anything you’re copying was made with care and good effort. On
the same page, try to ask for permission and give credit as much as possible to the original authors of the physics “donor” car, especially if you intend to
republish it.
318
We can highlight some other issues you may encounter when swapping physics:
Cars with third-party encryption
The data.acd file cannot be unpacked on cars where it has been encrypted with unofficial methods brought by the CSP mod and its derivatives, along with other systems.
Thus you cannot swap the physics, as the single physics files cannot be edited, and swapping the entire .acd file is not feasible, unless the car 3D model is exactly the same
(which is not 99.9% of the times).
Floating or sinking wheels
The car has the wheels that sink in the asphalt or that aren’t touching ground (Fig. ).

Fig. – Top left: RADIUS is too small. Top right: RADIUS is too big. Bottom image: the correct size. Look at the scripts (pag.) to understand what this parameter does.

tyres.ini is the right place to fix this, changing the RADIUS value: you have to make sure the radius of the physical tire matches the radius of the actual 3D model; if the car
has animated suspensions modifying this may override the maximum up/down travel limits though.
Various session crashes due to missing objects
This problem depends on the fact that empties and meshes in the 3D model of the physics donor car are not present in the receiving mod. The scripts that are prone to give
errors of this kind are: analog_instruments.ini, digital_instruments.ini.
Various session crashes due to missing textures
Usually this is due to missing flame textures, under the FIN\texture\flames folder. Missing digital displays tex under the same path may cause issues too.

Vehicle cameras not properly set

If you copy car.ini and cameras.ini from a Formula car and paste them to a stock/road car, the points of view will be located very low above ground. Vice versa the same will
happen but this time the POVs will be too high. There’s a ton of mods out there, especially old and low effort conversions, that suffer from this problem.

Floating car
The car is flying on every track (Fig.). The tire size is correct in the physics files.

319
Fig. – The car stuck mid-air.

Check colliders.ini. The position of the collision boxes may be set too low with respect to the car.
About tires taken from other vehicles
If you clone the tires, I would suggest that weight is a larger factor than just dimensions: for example if you pick tires built for a heavier car and stick them to
a more lightweight vehicle, the grip will be super high, as the tire won’t be operating at the loads designed (with the load sensitivity the coefficient will
reduce with load, so if your peak loads are lower than the car you borrowed the tires from, then it won't really be appropriate without some modification).

QUESTION [4]: What happens with online multiplayer racing if I edit my vehicles? Will they still work there? What is the checksum?
ANSWER [4]: You can edit car 3d models and still use it online, only data.acd should be checksummed, unless the server admin is crazy and put the kn5
files on the server to be checksummed too. If instead you modify the car data, the checksum will fail. There’s a workaround though, that lets you edit the car
data for single player without losing the compatibility of the original files with online vanilla servers. It is the data override you can do with the CSP config
scripts.

The server manager can turn off checksum, while the clients cannot, that's the whole point. For example, if the server doesn’t have track checksums, should
you increase the grips in surfaces.ini and cheat? Well, what’s the point of doing it? I didn’t say anything…

ABOUT CSP: Extended physics are not generated in any way online. It works for single player only. If u want to drive with ExtPhys online, u have to upload
the (in single player mode) created data.acd files to the server for each car. Then u have to provide a download link for the players to these data.acd files.
Easiest way is to create a MOD, which player can activate via JSGME or CM with one click and after that they can join the server without a checksum error.

320
11.3 - HOW TO CREATE DATA FOR YOUR VEHICLE
As a physics creator of simulation vehicles, your goal is to obtain real-world information about the vehicle, referred to as data, interpret it correctly and input
it into the simulation as parameters, in order to produce the intended input-output behaviour.
A simplified model for creating car physics could be as follows: Look for data > Find good data > Calculate parameters from the data > Input into the .ini files
> Test and verify > Back to the beginning.
The simulation in AC is sufficient enough that accurate parameters are able to produce reasonably accurate behaviours. In the case that numbers cannot be
determined with complete certainty, given the fact that the reproducibility 50 conditions are not met (i.e., you often don’t have a car to test), as is the case when
creating most car physics in the context of an amateur hobbyist, educated guesses must be made. 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.
Pro tip: Lesson #1 for learning, testing and troubleshooting is to try wild numbers in both directions (positive or negative) to figure out how something works.

Not every car is equally dealt with when it comes to amount and fidelity of the data present. Ideally one should make a car that they own themselves, have
access to and have acquired detailed data for from road testing and K&C (Kinematics and Compliance) testing, dynamometer and wind tunnel testing.
This is not always a reasonable expectation. If one is willing to accept a somewhat lacking simulation accuracy, one can make a car that has less resources
available to aid in the process. Choosing to do that will place higher stress on having a sound fundamental mechanical understanding and a “common 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 at 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.

11.3.1 - WHERE AND HOW TO LOOK FOR DATA

Useful resources for gathering data are primarily the manufacturer’s own publications, such as workshop manuals, service and user manuals (Fig.).

Fig. – Service and repair manual for the vintage Fiat 500, along with one of the pages dedicated to the suspensions that shows a drawing of the assembly. This book doesn’t come directly
from the manufacturer of the vehicle; nonetheless it contains details you can rely on. OEM manuals do exist too, don’t worry, but the problem is often getting them. Being in contact with
owner clubs of the specific car helps a lot in this case.

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. Homologation documents are probably the highest quality third-party info you can find (Fig.).

50
The ISO 21748:2017 defines reproducibility conditions as “observation conditions where independent test results are obtained with the same method on identical test items in different facilities
with different operators using different equipment”. They are not met since AC does not model real-world behaviors entirely, and recreating identical scenarios when driving is pretty much impossible
(in replays physics are not calculated, but maybe you can configure a predetermined set of inputs and feed it to virtual controller peripherals; an Arduino electronic board could help).
321
Fig. – (left) Italian homologation form of the Fiat Abarth OTS 1000 Coupé. (right) German homologation form of the Audi 100 Coupé S.

Online forums also occasionally have resourceful users who post their own measurements or findings, so don’t ignore them. Car magazines can be trusted
to some extent, but their reliability is limited.
When you’re surfing the web, always bookmark in your browser important pages and websites, and download/save the most important stuff on your PC, as it
might disappear, you never know. Do NOT rely on it being hosted online. Save videos locally if they contain much relevant data or good footage. If the Save
As option is not available when you right-click on the element in the page, disable Javascript or use the Developer tab to inspect and find the link (activates
on Mozilla Firefox with the F12 key), or use other tools specialized for the website you find yourself in (e.g. YouTube video downloaders).
Squeeze like a lemon every forum that has a search function. Take screenshots of conversations, they will definitely come in handy as reminders. And if it
takes too long or the search blocks itself, like on the Discord social platform can happen, download the entire website/chat. At that point it won’t escape from
your hard drive. It is possible with software like HTTrack, DiscordChatExporter or similar. Then you will be able to use your browser’s search function (which
often is a lot faster), and delete things you don’t need, like dumb posts or wasted trash conversations. It’s a lot more productive. Be hungry for information.
E-books and pdfs are some of the best sources of information available, but don’t focus only on them. A lot of good stuff can be found also in articles, studies
and research publications, especially recent ones.
Some good websites to find info are:
• http://www.kolumbus.fi/leif.snellman/gpw5.htm: Grand Prix race regulations from 1895 to 1949. Very useful for pre-war race cars.
• https://www.nhtsa.gov & https://www.regulations.gov/search?filter=nhtsa: the US National Highway Traffic Safety Administration, which publishes inertia data. Download the crash
test reports. They are really detailed.
• https://historicdb.fia.com: the historic database of the FIA (Federation International de l’Automobile) with homologation rules and info for cars from the 1950s to this day.
• https://www.carfolio.com/car-makes: it won’t be the most complete for the single vehicle, but there are a lot of cars, even quite obscure models.
• https://www.automobile-catalog.com/browse.php#gsc.tab=0: there’s so much info you almost ask yourself where they got it. Since 1945. Bah, seems reliable enough.

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 Catalogue) websites, or try to find paper parts catalogues, as they can sometimes give hints for parameters such as shared mechanical parts between
different vehicles (e.g., springs, stabilizers, but also tires, engines, etc.) and occasionally have dimensions, stiffnesses and such reported. Do not ignore video
publications and footage by competent drivers either; on the other hand, try not to listen too much to neophytes who have never driven a car on the racetrack.
Driving normally on the highway does not help much when trying to understand how a car truly behaves.
Moreover, there are standard design choices and solutions used especially in road cars for their reliability, but there can be a large variation between how
cars are designed and how they behave, even within the same manufacturer’s vehicle line-up and especially between manufacturers. This applies to every
aspect of the vehicle: while generally similar trends and logics should be followed, outlier data 51 may be present.
For example, with bigger tire flex the lateral force usually peaks at higher slip angles at increased loads but, with the words of Stefano Casillo from Kunos,
“I've seen some test data showing the opposite trend: lower slips at higher load”.

51
This is a term used in statistics to define, in a set of observations, an abnormal and aberrant value, that is a value clearly distant (numerically) from other available observations. While most of
your data will probably follow a linear, a Gaussian or other types of distributions, you may encounter points that do not follow the trend (e.g., points that don’t satisfy Chauvenet’s criterion for a
Gaussian distribution have to be considered outliners).

322
Thus, you will often encounter a bias, which according to the ISO 21748:2017 is the “difference between the expectation of a test result or measurement
result and a true value”. Since we don’t know what is the true value, which as a concept exists only in a theoretical ideal world, we can only estimate. Indeed,
the same regulation tells you that “the accepted reference value is substituted for the true value”.
A physics creator should refrain from making “opinion based” changes to the physics of cars, especially when good data is present and tread with utmost
care when seemingly going against data. However 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. That’s where some insight from Kunos developers may help you:

Try to find the actual engineers that worked with the car. Possibly have access to the car, be kind enough, give lots of Italian pasta and wine, and they will let you go in
the car and measure all the parts; talk with them, get lap times, and hopefully you will have something important by the end of that process.
Real professional drivers’ feedback is very important. But equally important is to have the experience to understand what they are saying.
Because every driver wants just one thing, to go faster, if he cannot do that it means the car is terrible for him. For example, we were working with James Glickenhaus’
car. Fantastic car, great guys. Great data from the engineers.
Finally we had the car ready, and Giovanardi, a very famous Italian pilot, was driving the car on the Nürburgring; he comes to us and says he would like to try the car on
the simulator for training and so on. He started driving: no problem. This is something really good. We put real drivers on the simulator. If they can get on it and drive the
car naturally without crashing straight out of the pits, this is a huge deal for us. We want them to feel totally at home in the simulator, as they would in their car.
Lap after lap he goes faster and faster, improving as he would in the real car. That already is a very good sign. But the most important thing is once he comes out of the
car from driving for about a half an hour, so he says, “Yeah, okay, that’s enough”. He gets out from the cockpit.
How was it? “Ehh, not so great. I could have gone faster”. I thought we were in a mess now, really scared. “It doesn’t turn well, and then when I accelerate, boots are on
the mat, and then when I brake, I have to be very careful with the down shifting because otherwise the car won’t be stable.” And while he was speaking and literally bringing
hell onto me, I had his race engineer behind me give me thumbs up.
So I asked the race engineer what the hell he meant by the “thumbs up”? I thought the race driver hated the simulation, I was heartbroken after so much hard work to get
it ready for him.
After the driver leaves, the race engineer says to me that we have done an amazing job. It turns out that the racing driver hates the car just as much in real life, and that
the notes he was giving me were the exact same feedback he gives to his race engineer when he gets out of the real car. (Aristotelis Vasilakos, 2016)

The “top guys” usually have years of experience in simulators or engineering, so they know what is possible and what not, in terms of action, and restraint.
For example, studying in the mechanical field, one can consider to use CAD software to get data that is not available out there. Model the parts or get them
online if someone already did it, and then assign a material from a class of steel or aluminum alloys to determine features like the weight of suspension arms,
rims and similar. With software like Solidworks it can be done very easily (Fig.), if you can untangle yourself between the various alloy types.

Fig. – Working on an CAD model of a historic wheel to get its mass in Solidworks. In 1924, wheelmakers used rolled and stamped steel to make steel disc wheels. These wheels were
heavy but easy to produce and repair. But aluminum wheels are older than you may think - very early sports cars used aluminum wheels. The Bugatti Type 35 bore aluminum rims in
1924. Their lighter weight made the wheels turn faster, and aluminum’s ability to dissipate heat made for better braking.

Physics creation is not a short process; there’s a huge amount to learn. In terms of tips, just absorb as much information as possible.

323
11.3.2 - DATA IMPORT AND ORGANIZATION PROCESS
Don’t 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 and
forum posts 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.
Often you will find specifications with numbers only, but many things will be represented with X-Y coordinates (commonly linear or logarithmic) on a plane,
like the engine torque, the power, the aerodynamics of wings, the load/slip curve of a tire, and other curves (Fig. ).

Fig. – The power and torque curves of a VR6 engine, measured on a dynamometer. This is what you find in a typical dyno sheet. For internal combustion engines the power is

These are all very useful, but when surfing the internet most of the times the ones you see are raster images, not vector ones. So how can you grab the values
from the graphs you find?
WebPlotDigitizer comes in handy here. It is a small software that semi-automatically calculates the coordinates of the curves after you pinpoint some of the
units on the main axes and specify the pixels of the line you want to be considered. It’s easy to use and properly formatted LUTs (Look-up-tables, about them
at par. 6.3.2) can be created, after you set which points of the curve shall be “grabbed”.

Let’s see what you can do with this program:

1. Load the image of the graph you want to grab the values from and specify which type of plot it is (Fig. left).

Fig. – (left) A File Explorer window will open after you click on Load Image (1) > Choose file (2). Select the image you want to process. The 2D (X-Y) plot type (3) is the most common.
(right) The graph I chose is another power curve. The selected dot will always appear with a green colour (5). You can also adjust the zoom level.
2. Locate four known points on the axes of the graph (Fig. right). It doesn’t really matter where they are, but if they’re located on opposite ends the result may be more
accurate. You can use the zoom window to adjust the positions with precision. You can click on the points and move them 1 pixel at a time, using the arrow keys.
3. Enter the respective values of the pinpointed units on the plot (Fig.) so that the program can calculate every value.

324
Fig. – The values come directly from the graph’s axes. A rotation correction can be added if the lines are not perfectly straight, if you have a scan from a printed document (like here).
4. Select the Pen tool and highlight the curve you want to be analysed. In my case I want only one of the three curves, but if you want you can assign each one to a different
data set. The width of the pen and of the eraser can be adjusted. For a fast selection, you can use the Box tool, but points on the grid may be included, depending on their
colours. You’ll have to choose which colour will be considered as data on the plot indeed, and as you can see on the right of Fig. , the software already determined the
dominant colors of the image. In my case I will select the darkest one.

Fig. – The Automatic Extraction (7) will be used with any of the tools (Pen, Erase, Box). It will do most of the work, so there’s no need to use the Manual Extraction unless you have to fix
by hand the result calculated by the software (some coordinates may not be considered, dots can be in the wrong places, etc.). The dx and dy parameters (ΔX & ΔY) are basically the
distances (along the X and Y axes; in pixels) between each calculated dot. Don’t lower them too much (use 10<d<30), as AC doesn’t need a ton of coordinates for LUTs. You can
choose a different algorithm too.
5. You can correct little errors made by the program using the Manual Extraction (Fig.).

Fig. – With the Adjust Point and Delete Point tools any created dot can be relocated or removed easily.
6. Here you have the clean, final result after the corrections (Fig.).

325
Fig. – For curves that are quite linear, like this one, it is possible to increase ΔX and ΔY to reduce the number of points and remove some of them, here in the 2500-4000 RPM range.
7. Then how do we get our numbers? Well, pretty simple: click on View Data and you will find all the values that WebPlotDigitizer calculated (Fig.). You can copy these values
to an Excel sheet for your calculations. If you don’t like the default formatting, which by the way is just not right for the AC *.lut files, it is possible to change the number of
digits; we will use a fixed notation and zero decimal digits after the comma. For this kind of graph, hand drawn on a piece of paper, any decimal quantity will basically fall
within the margin of error, so we don’t need those extra digits.
Every value will be correctly approximated, as you can see. The column separator has to be changed too: use | instead of the semicolon. Then click on Copy to Clipboard
and paste it on a text file, or click on Download .CSV to save it as an MS-Excel sheet. There you have it, a LUT (Look Up Table) ready to be used in AC files! Yay!

Fig. – It wasn’t difficult, right?

8. If you still aren’t sure, clicking on the Graph in Plotly button will let you visually check the curve obtained in a dedicated window (Fig.).

Fig. – This is neat, and as you can see WebPlotDigitizer can be very precise. Still, there is some noise, which you can see at various spots, and that should be corrected manually.

326
This specific LUT, being related to power, can be used to create the torque.lut Assetto Corsa data file; you may be tempted keep it as-is, but you may not know
that the values will have to be converted to torque, so what you see in the last picture is not the end. Take this as a lesson: you have to know if the numbers
you get are correct for the job; often (if not always!) creating data is not a copy-paste process. You want to learn some more about it? Keep reading this manual
then!

11.3.3 – DATA CREATION: HOW TO BEGIN

A good starting point for the vehicle data creation is the car.ini script, followed by suspensions.ini and tyres.ini: determine your total mass, unsprung mass,
wheelbase, track, CGH, inertia and tire radius first. Those will determine the general behaviour of the automobile.

Pro tip: the main tricky thing that you'll have to do before anything else is setting up the location of the vehicle CoG (Center of Gravity). You sort of have to do it in order.
1. Set wheelbase in suspensions.ini.
2. Set front weight percent (weight distribution, CG_LOCATION) in suspensions.ini.
3. Set the Y-offset (BASEY) of axles in suspensions.ini (Y = height in this context, it's the distance above or below CoG for that axle at 'design height' which is wherever you
measured it at).
4. Move the 3D model with the help of the graphics offsets in car.ini to match the wheels.
If for some reason you have to change the numbers, you'll have to carry through the steps again. Lots of positional physics references are relative to the CoG, so you need to
set it first.
Even if you forget about this tip, don’t worry, you will encounter it later on, with more details, where you will need it.

You don’t have to focus on finding very specific information, but if you get the chance, input the right numbers from the beginning. We don’t want to do a lot
of trial-and-error later.

Depending on your resources you will need to conduct testing in different ways. At worst, watch videos of the vehicle driving and measure it against yours,
or ask drivers of the real car what they think. This process however varies in accuracy and rarely results in anything very useful being uncovered. Telemetry
analysis is a lot better; it is not terribly practical for most cars, as most of them do not have real-world telemetry available, but if you start learning about
vehicle dynamics, you can get awesome results interpreting the simulated telemetry and looking at possible errors you made.

Having right car weight and its distribution, aerodynamics, engine power, gear ratio, tire grip factor, and an accurate track model (even without accurate
bump data), you can get pretty good correlation to the real-life data. The suspension geometry doesn't have be 100% perfect, but it has to be very close.

Until you start building experience, just find more data and keep gauging its reliability. You should fill gaps in your understanding 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 modelled or might not work as intended or how you
believe they work which will all add up in the end. That’s why you should read this very manual thoroughly, to learn which aspects of real-life does AC
portray.

Ideally you will not know very much about what is right in your car, but more about what is wrong and how. The tires will often ultimately be a bigger source
of error than anything else in your suspensions, drivetrain or aerodynamics. A very good practice is to try getting the intended behaviour 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.

11.3.4 - THE UNIT SYSTEM IN ASSETTO CORSA

When you use numbers in your calculations, you have to know what they represent, otherwise you add up onions and carrots. That’s why units of
measurement exist.

In general AC uses the metric system (SI) for the physics and the scripts. However, to make things a lot easier, in this guide the units will be specified near
almost all the important parameters. As a matter of fact, the following units are the most common:

[m] (meter), [mm] (millimetre), [Kg] (kilogram), [°C] (Celsius), [L] (litres), [psi] (pressure), [deg] (degrees).

Keep in mind that units like [N] (Newton), [J] (Joule), and other kinematic, mechanical and thermodynamic derived SI units are used too.

Width, height, length will be the standard format used by Assetto Corsa dimensions.

11.4 - DATA FILES AND EXAMPLES (with ANALYSIS)

The following paragraphs contain the lists of all the data files; most of the times you will need less, depending on the specific features that differ from car to
car (for example not all of them have electronic devices, active wings and so on).

Keep in mind that without some of these files the car will not load and the game will crash. The remaining configs are required if you want to avoid
behaviours detrimental to the driving experience (including any kind of related bug).

Please note that if you’re using CSP you might encounter errors and crashes anyway!

327
11.4.1 - CONFIGURATION FILES (.ini) (page numberssss)
1. aero.ini p.
2. ai.ini p.
3. ai_tyres.ini p.
4. ambient_shadows.ini p.
5. analog_instruments.ini p.
6. blurred_objects.ini p.
7. brakes.ini (also ctrl_ebb.ini and steer_brake_controller.ini) p.
8. cameras.ini p.
9. car.ini p.
10. colliders.ini p.
11. ctrl_4ws.ini p.
12. damage.ini p.
13. dash_cam.ini p.
14. digital_instruments.ini p.
15. digital_panels.ini p.
16. driver3d.ini p.
17. drivetrain.ini (also final.rto, ratios.rto, ctrl_single_lock.ini and ctrl_awd_center_lock.ini) p.
18. drs.ini p.
19. electronics.ini p.
20. engine.ini (also ctrl_turbo.ini (ctrl_turbo0.ini, ctr_turbo1.ini, etc.) p.
21. ers.ini (also ctrl_ers.ini, ctrl_ers_front.ini) p.
22. escmode.ini p.
23. extra_animations.ini p.
24. flame_presets.ini p.
25. flames.ini p.
26. fuel_cons.ini p.
27. lights.ini p.
28. lods.ini p.
29. mirrors.ini p.
30. proview_nodes.ini p.
31. setup.ini (also ai_default.ini) p.
32. sounds.ini p.
33. suspensions.ini (also suspension_graphics.ini) p.
34. tyres.ini (also ac_tyres.ini) p.
35. wing_animations.ini p.

CSP files?

328
11.4.2 - OTHER FILES
Here we have important stuff. You better learn to use these files, they’re the ones that bring realism and accuracy to the simulation in AC.

LUTs : LOOK UP TABLES

The .lut files you can find in the vehicle data are Look-Up-Tables, hence the extension: you can open them with one of the suggested text editors.
Each line in the LUT maps an input value to an output value; the file itself doesn't say what either of these values means, but every table can be linked to a
specific config file, if its name is written in specific lines of code. With LUTs the physics of a vehicle can be recreated in the most realistic way possible in
AC, so you may be interested in how they work.
These tables should be specific to a car but are more likely to be generic (for example a LUT can recreate a specific behaviour for a tire, and that tire can be
used on many cars).
Every type of LUT you may need will be fully explained in each one of the correlated scripts, under the paragraphs with the title “ABOUT RELATED FILES”.
For now, as a general rule, keep in mind that empty.lut files contain only 0|0 or 0|1 values and are often used as fillers.

DYNAMIC CONTROLLERS
What are controllers?
Controllers are a cascade (or sequence) of lookup tables that combine either by addition or by multiplication, to produce a desired behaviour.
The system looks for the sequence of [CONTROLLER_#], and as soon as the section is not found the sequence ends. So, if for example you have
[CONTROLLER_0] followed by [CONTROLLER_2], [CONTROLLER_2] is not used at all because when the system does not find [CONTROLLER_1] it exits.

The principle behind controllers is that they emulate what real electronic controllers do. They read car data (for example the wing angle, on cars like the Pagani
Huayra, or the KERS working automatically on the Ferrari LaFerrari), and you can write algorithms to generate output values.
Here we have the list of all the vanilla dynamic controller inputs:
• AVG_TRAVEL_REAR
• BRAKE
• CONST
• GAS
• GEAR
• LATG
• LOAD_SPREAD_LF
• LOAD_SPREAD_RF
• LONG
• OVERSTEER_FACTOR
• REAR_SPEED_RATIO
• RPMS
• SLIPANGLE_FRONT_AVG
• SLIPANGLE_FRONT_MAX
• SLIPANGLE_REAR_AVG
• SLIPANGLE_REAR_MAX
• SLIPRATIO_AVG
• SLIPRATIO_MAX
• SPEED_KMH
• STEER
• STEER_DEG
• SUS_TRAVEL_LR
• SUS_TRAVEL_RR
• WHEEL_STEER_DEG

Meanwhile, Custom Shaders Patch adds the following inputs:

• HEADLIGHTS
• CLUTCH
• HANDBRAKE
• HORN
• GEAR_ALT: unlike original GEAR, this one does not go through neutral when shifting
• LIGHT_EXTRA_A
• LIGHT_EXTRA_B
• LIGHT_EXTRA_C
• LIGHT_EXTRA_D
• LIGHT_EXTRA_E (added in 0.1.76)
• LIGHT_EXTRA_F (added in 0.1.76)
• AXLES_DIFFERENCE_RELATIVE: relative difference in angular speed of axles (averaging wheels angular speed)

329
• AXLES_DIFFERENCE_ABSOLUTE: absolute difference
• AXLES_DIFFERENCE_SIGNED: above zero if front axle spins faster than rear one
• FRONT_AXLE_DIFFERENCE_RELATIVE: relative difference in angular speed of front wheels
• FRONT_AXLE_DIFFERENCE_ABSOLUTE: absolute difference
• FRONT_AXLE_DIFFERENCE_SIGNED: above zero if left wheel is faster
• REAR_AXLE_DIFFERENCE_RELATIVE: same, but for rear axle
• REAR_AXLE_DIFFERENCE_ABSOLUTE
• REAR_AXLE_DIFFERENCE_SIGNED
• DAMAGE_ENGINE: from 0 to 1 (added in 0.1.76)
• DAMAGE_GEARBOX

Some files include controllers inside, for example aero.ini has them for the wings. Standalone controllers instead have to be used in the following files:

ctrl_4ws.ini
ctrl_arb_front.ini
ctrl_arb_rear.ini
ctrl_awd2.ini
ctrl_awd_center_lock.ini
ctrl_ebb.ini
ctrl_ers_#.ini
ctrl_ers_front_#.ini
ctrl_single_lock.ini
ctrl_turbo#.ini
ctrl_wastegate*.ini

Whenever you may need them, it will be specified in the next paragraphs. The only exception to this rule is ctrl_4ws.ini, which will have a dedicated section.

330
11.4.3 – EXPLANATION AND ANALYSIS OF EACH .ini SCRIPT
This section of our manual will be pretty long, as we’ll give examples for each configuration file, along with descriptions of what each function and line of
code does. You can copy the text from this document to make your config files, but I suggest you to use the ones included in the archive of the project
(WIP), or to copy them from another vehicle, as the scripts written in this manual are not formatted for proper use.

1. aero.ini
The following code defines and all wing-type objects, including DRS. Wings determine the downforce and drag levels of your car.
[HEADER]
VERSION=3 ; version=3 has YAW_CL_GAIN values that can stall wings depending on yaw angle.

[WING_0] ; SYNTAX: [WING_ID]. Wing identifier. A car can have as many wings as necessary. ID starting from zero.
NAME=BODY_LIFT ; Name of the wing
CHORD=2.0 ; Length of the wing. [unit: meters]
SPAN=1.0 ; Width of the wing. [meters]

% ▲ Along with CHORD, SPAN helps determine the area of the wing. Single unit is used to simplify calculations. Area is in [square meters] (or rather,
it's CHORD * SPAN).

POSITION=0.2,0.1,0.0 ; Position in x,y,z starting from the CoG.

LUT_AOA_CL=wing_body_AOA_CL.lut ; Coefficient of Lift lookup table
LUT_GH_CL= ; Ground height (GH) aero lift multiplier lookup table

% ▲ If set to empty.lut, gives no lift generated from this wing.

CL_GAIN=1 ; Coefficient of Lift multiplier (for easy fine tuning). [dimensionless]

% ▲ CL_GAIN just multiplies whatever the results of the LUTs are. Same thing for CD_GAIN below. If you want an up-force you can use a negative number
here or in the lut. Positive CL_GAIN = downforce, negative CL_GAIN = up-force (lift) in Assetto Corsa. If you set CL_GAIN to 0, you won’t ever get
downforce.

% To get the overall CL, you multiply CL_GAIN with every involved .lut (AOA * GH if present) of the wing.

LUT_AOA_CD=wing_body_AOA_CD.lut ; Coefficient of Drag lookup table

% ▲ If set to empty.lut, gives no drag generated from this wing.

LUT_GH_CD= ; Ground height (GH) aero drag multiplier lookup table

CD_GAIN=1 ; Coefficient of drag multiplier (for easy fine tuning). [dimensionless]

% ▲ If you set CD_GAIN to 0, you won’t ever get drag. Just moving it 10% up or down (=±0.1) will make a considerable difference. Changing downforce (CL)
doesn’t change drag (CD).

ANGLE=0 ; Default starting wing angle which the car loads in game with. For car setup. [degrees]

% ▲ This is the default value used in the car setup. The actual angle is relative to the design heights of the suspension and the velocity the surface is
travelling at vs the rake angle of the car.

ZONE_FRONT_CL=0.0 ; CL=CL/(1.0+ZONE_0_CL*DAMAGE)
ZONE_FRONT_CD=0.0 ; CD=CD*(1.0+ZONE_0_CD*DAMAGE)
ZONE_REAR_CL=0.0 ; CL=CL/(1.0+ZONE_0_CL*DAMAGE)
ZONE_REAR_CD=0.0 ; CD=CD*(1.0+ZONE_0_CD*DAMAGE)
ZONE_LEFT_CL=0 ; CL=CL/(1.0+ZONE_0_CL*DAMAGE)
ZONE_LEFT_CD=0.0 ; CD=CD*(1.0+ZONE_0_CD*DAMAGE)
ZONE_RIGHT_CL=0 ; CL=CL/(1.0+ZONE_0_CL*DAMAGE)
ZONE_RIGHT_CD=0.0 ; CD=CD*(1.0+ZONE_0_CD*DAMAGE)

% ▲ These are coefficients in the formulas for the wing’s CD and CL, and they are related to the damage model. It is a simple way to reduce lift and
increase drag when the car goes through an accident and the aerofoils are damaged. If set to zero they don’t do anything.

YAW_CL_GAIN=-0.0

% ▲ YAW_CL_GAIN doesn't do anything for wings with positive lift on them.

[WING_1]
[WING_2]
[...]

% ▲ A vehicle can have as many wings as necessary.

[FIN_0] ; Vanilla physics have a "fin" wing type that gives sideways lift with yaw (equivalent of AOA).

% ▲ Front and rear fins can yaw at different angles.

NAME=FIN
CHORD=0.8
SPAN=0.4
POSITION=0,0.00,-1.32
LUT_AOA_CL=fin_AOA_CL.lut
LUT_GH_CL=
CL_GAIN=0.5
LUT_AOA_CD=fin_AOA_CD.lut
LUT_GH_CD=
CD_GAIN=0.5 ; For fins CD always comes from where the car is headed, while CL is purely lateral
ANGLE=0 ; The angle of attack is yaw angle (taking into account wind)

% Skipping lines dedicated to damage for the purposes of this book.

YAW_CL_GAIN=0.0

[DYNAMIC_CONTROLLER_0] ; Active aero. Dynamically controls the inclination of a wing, relative to various telemetry factors.
WING=4 ; Wing identifier to activate (wing number on [WING_ID])
COMBINATOR=ADD ; How to behave: COMBINATOR MODE: ADD or MULT
INPUT=BRAKE ; Telemetry channel input. Options: LONG LATG BRAKE0-1 GAS0-1 STEER-1+1 SPEED
LUT=wing_controller_brake.lut ; Input data to wing angle lookup table
FILTER=0.90 ; Movement filter. Controls speed of wing movement from one angle to another.
UP_LIMIT=6 ; Wing angle max limit
DOWN_LIMIT=0 ; Wing angle min limit

[DYNAMIC_CONTROLLER_1]
WING=4
COMBINATOR=MULT
INPUT=SPEED_KMH
LUT=wing_controller_speed.lut
FILTER=0.90
UP_LIMIT=6
DOWN_LIMIT=0

331
LITTLE EXPLANATION
- GH or Ground Height is the distance from the middle of the wing to the ground.
AOA instead is Angle of Attack (α, alpha). It is the pitch angle of the wing relative to its direction of
travel (Fig.), not to be confused with climb angle, which is the angle of pitch relative to the ground.
It can be considered the current angle the wing is moving through the air. The higher α is, the more
lift you will get out of a given wing with two very important caveats.
First, as AOA increases, drag increases, which means fuel efficiency goes down. Second, and more
importantly, there is a max angle at which the wing can generate lift. Angles of Attack greater than
this will cause the wing to “stall”. Note that stall used in the aerodynamic context has nothing to do
with the engines. It refers to the wing. A wing stalls because the air flow over the top portion separates
from the wing surface, causing higher pressure and thus degrading the lift generated by the wing.
- About CD and CL. Lift depends on the density of the air, the square of the velocity, the air's viscosity and compressibility, the surface area over which the
air flows, the shape of the body, and the body's inclination to the flow. In general, the dependence on body shape, inclination, air viscosity, and
compressibility is very complex.
One way to deal with complex dependencies is to characterize the dependence by a single variable. For lift, this variable is called the lift coefficient,
designated CL. This allows us to collect all the effects, simple and complex, into a single equation.
For some simple flow conditions and geometries and low inclinations, aerodynamicists can determine the value of CL mathematically. But, in general, this
parameter is determined experimentally.
Determining the value of the drag coefficient CD is more difficult than determining the lift coefficient because of the multiple sources of drag. The drag
coefficient given above includes form drag, skin friction drag, wave drag, and induced drag components. Drag coefficients are almost always determined
experimentally using a wind tunnel.
In the PHYSICS section there will be a more detailed explanation of the aerodynamic principles for these coefficients, which are dimensionless constants that
work at any speed. You might see "20lb at 100mph" of force in a magazine but any detailed wing analysis uses CL and CD.
- What if you wanted to implement a full aeromap for your vehicle? Sadly in vanilla AC you can’t, but thanks to the Custom Shaders Patch mod you are able
to. See the CSP ADDITIONS section for more details.

- The intended usage of wings is BODY for overall body drag, and FRONT/REAR for separated front/rear lift (centred respectively on front splitter and rear wing).
This allows fine tuning of front-rear aero balance in a manner similar to real cars, as a common way of measuring lift is front/rear axle loads.
- Wings in AC aren't real airfoils, they're just surfaces where aero forces can be applied, so anything about size/shape/angle must be baked into the coefficients
you enter into the lookup tables (LUTs). There's nothing “physical” about them nor do they represent anything “physical”, they’re just a simplified mathematical
model: there isn’t a fluid/airflow simulation in AC, imagine how many calculations/second it would require such a thing. Their NAME (BODY, FRONT, REAR,
SCREEN, DIFFUSER, DRS, etc.) also doesn’t really matter; in addition you can technically name two wings the same (although it is not recommended).

- Every WING has a POSITION. The values are x, y, z in meters from the CoG of the car. Obviously you can calculate this, but the easiest way (at least until
you don't have a very complex aero) is to put your WINGs inside the aero.ini file, go in-game, drive slowly (you need to move the car) and open and check
the WINGS dev app. It shows everything (and aero front % balance) in real time. Of course, everything uses proper physics values and with the help of
wolfram alpha and some Excel work, you can calculate everything before going ingame... honestly though, until you get VERY complex aero situations, the
WINGS dev app is all you need. Works wonders.
- Always locate your wings properly, as their positions set where the forces (lift, drag) apply, relative to the CoG of the car. Examples of correct wing
placement are in Fig.. However, the forces do not actually respond to how the respective wings look like. There are various reasons for this:
• In Assetto Corsa the lift force is always applied directly downwards relative to the car and drag directly against the direction of travel (except for FINs). The angle of the
wing basically influences the resultant of the vector sums of the lift and drag forces.
• Size (CHORD ∙ SPAN) is really for visualization purposes only, as the force can be adjusted to whatever you want. You want to make the area smaller/bigger?
Increase/decrease the force. So really only the center point, specified by the POSITION, really matters. But if it was just 6 single pixel dots on the car it'd be hard to see
the wings. Thus each wing defines how large it is so you can spot which is which. And there is the convenience to make them a 1m by 1m square to simplify calculations.
Each one's POSITION point is where that wing's force on average gets applied to the car. So the body one is at the center of aero pressure for drag, usually. If you're
using CFD they don't necessarily line up with the model's wings because you're going for the same total forces rather than trying to make it match the visual model.
• Moreover, in real life the center of a wing's aerodynamic forces isn't actually the center of the wing (same with a diffuser): it's a bit forward of that (Fig.) and the "wing" in
AC should therefore look offset (unless you design it to account for the different position).

Fig. – (Courtesy NASA Glenn Research Center).

332
Thus, never make the body produce downforce or lift. The way you should simulate the body generating lift is to put in some imaginary wings so to speak at
the positions of the lift. Use the body wing to set up the drag instead.
- FINs in aero.ini apply the side-forces 90 degrees aligned from the wind direction, not the surface. You can make a true side-force with some math and
side-drag application. Putting in a more realistic lateral aerodynamics model has big implications for drifting. It has made it a lot easier and it's kind of funny
how difficult it would be without aero.
As a side note, you should realize how the F1 cars by Kunos don’t have FINs modeled (Fig.), but in the real world the splitters and spoilers are designed to
create lateral forces too. So the aero could have been more accurate, but it isn’t. Once again, the software is capable of doing it, but it wasn’t implemented.
- You can have 20 wings and the weighted average of their positions is where the CoP (Center of Pressure) is. It’s just a Kunos practice to make a body
drag wing + front/rear/diffuser. Actually some of the official cars have more wings, especially F1 cars (Fig.).

Fig.- The wings of the Ferrari F138 by Kunos. As expected, aerodynamics have a huge impact on F1 cars. Do not expect the making of a Formula car mod to be easy.

However you should avoid an excessive number of wings (Fig.). They will be mostly useless, since all the aerodynamic properties of multiple wings can be
“baked” onto a single wing, especially for the car body.

333
Fig. – I knew someone would have thought about doing this. Do not replicate at home. Another bad modding practice. LOOK AT THE WINGS APP!

- If you have a race car, obviously the rear wing and body produce drag, so you have to work with that. But with a streetcar it's only the body. Set the
wing_body_AOA_CD.lut (or whatever you called it for the BODY wing) to 1|1, and then set the CD number for the body to whatever the drag coefficient is.
Everything else for a road car can be on 0, regarding drag.

- Stalling wings at a certain speed is done with the 'active aero' code. It switches from an angle that's preset to stalled behaviour (no lift) to a different angle
that generates lift at a determined car speed mark. You can see the wing move in the aero debug app.

- To get to the actual forces you use the physics equations for drag and lift, which are:
The Drag Equation (link)
The Lift Equation (link)

They’re almost the same equation, so to switch between them you just need to choose the proper coefficient (CD or CL). In the physics literature they are
written like this:
𝐶𝐶𝐶𝐶∙𝐴𝐴∙𝜌𝜌∙𝑣𝑣 2
𝐿𝐿 = (1.0)
2

𝐶𝐶𝐶𝐶∙𝐴𝐴∙𝜌𝜌∙𝑣𝑣 2
𝐷𝐷 = (1.1)
2
% Standard air density (ρ) is 1.225 [kg/m^3]; velocity in m/s will give you force in Newtons [N].

If you have the speed in km/h, you can convert it in m/s with this little formula:
𝑣𝑣 [𝑘𝑘𝑘𝑘/ℎ]
𝑣𝑣 [𝑚𝑚/𝑠𝑠] = (1.2)
3,6

If you have the speed in miles/h, you can convert it in m/s with this other little formula:
𝑣𝑣 [𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚/ℎ]∙1,609344
𝑣𝑣 [𝑚𝑚/𝑠𝑠] = = 𝑣𝑣 [𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚/ℎ] ∙ 0,44704 (1.3)
3,6

So:
A * CL (AREA * Coefficient of lift) in Assetto Corsa is: (CHORD * SPAN) * CL_GAIN * LUT_AOA_CL (#) * LUT_GH_CL (#)
A * CD (AREA * Coefficient of drag) in Assetto Corsa is: (CHORD * SPAN) * CD_GAIN * LUT_AOA_CD (#) * LUT_GH_CD (#)

% ▲ Hashtags (#) indicating a lookup table.

% So drag force at a given velocity is: F = 0.5 * (CHORD * SPAN) * CD_GAIN * LUT_AOA_CD(AOA) * LUT_GH_CD(GH) * air_density * V^2

- Does AC simulate altitude, with different air pressure? Only with Custom Shaders Patch. Without it each track just has a certain fixed air pressure.

- With regards to wings in aero.ini, the controllers are included in the file itself, they’re not separate, unlike some other car features. You can then make
dynamic aero with the [DYNAMIC_CONTROLLER_#] section(s). Keep in mind that the controllers are acting sequentially, one adding the effect to the
previous one. I suggest you put the brake controller as a last one. This way, whatever the wing does during SPEED_KMH or LATG, the BRAKE controller will
add up all the degrees it can whenever the brake pedal is pressed.

- Assetto Corsa features an aero damage model.

- A simple parachute braking system (for example used in drag racing) is possible in AC (Fig.). You can set up some dynamic wings with controllers (tied to
brake pedal input) and animations. The drag force will be there, but the chute won’t respond to the air pressure building up inside, so its movement will be
entirely fictional. But who knows, maybe you can bake a short cloth simulation in the animation with Blender. Still, the sequence cannot be indefinitely long,
so you won’t get anything realistic, just a piece of tissue that extends and retracts itself in the parachute backpack. Can be fun nevertheless.

334
Fig. – (top) Fully deployed parachute, for a drag racing vehicle. (bottom) The opening animation of the chute (the closing one is identical, just reversed) is just a scaling.

ABOUT RELATED FILES

LUTs:
- From the script explained in the previous pages you may have understood that there are two types of aero look-up-tables, one related to the AOA (Angle of
Attack), and one related to GH (ground height).

Thus, the input of an aero LUT can be, depending on the type, either AOA or ground height GH, and the output is a multiplier coefficient, usually CD or CL.
So for each wing to determine its overall drag, you take the area times the ini coefficient times any relevant lut coefficients.

- You can add as many wings you wish, but don't forget to add the corresponding _CD and _CL .lut files for them.

- Here you have some examples of names you can use for your various look-up-tables related to aero:
wing_front_AOA_CL.lut
wing_front_AOA_CD.lut
height_frontwing_CL.lut
height_frontwing_CD.lut
wing_rear_AOA_CL.lut
wing_rear_AOA_CD.lut
wing_diffuser_AOA_CL.lut
height_diffuser_CL.lut
wing_diffuser_AOA_CD.lut
height_diffuser_CD.lut
wing_rearmovable_AOA_CL.lut
wing_rearmovable_AOA_CD.lut
wing_controller_brake.lut
wing_controller_speed.lut

- It is advised to reference empty.lut it in all the empty aero.ini areas.

- Regarding aero.ini, you are not allowed to use inline LUTs (you can’t write the table in the script, unlike for some other config files). But the CSP mod adds
the option to do it.

335
CSP ADDITIONS
- Since Assetto Corsa is quite limited in terms of aero, the mod brings a full aero map implementation, with a 2D lookup table and other features. In the
aero.ini config must be added the following section:
[MAP_0]
NAME = name
MAP_CL_RH = filename.2Dlut ; cl*area versus meters (ride heights at each axle)
MAP_CD_RH = filename.2Dlut ; cd*area versus meters (ride heights at each axle)
MAP_BALANCE_RH = filename.2Dlut ; ratio of front:rear cl*area versus meters (ride heights at each axle)
MAP_YAW_CL = filename.lut ; degrees|multiplier
MAP_YAW_CD = filename.lut ; degrees|multiplier
MAP_YAW_BALANCE = filename.lut ; degrees|addition
MAP_ROLL_CL = filename.lut ; degrees|multiplier
MAP_ROLL_CD = filename.lut ; degrees|multiplier
MAP_ROLL_BALANCE = filename.lut ; degrees|addition
MAP_STEER_CL = filename.lut ; degrees (average at wheels)|multiplier
MAP_STEER_CD = filename.lut ; degrees (average at wheels)|multiplier
MAP_STEER_BALANCE = filename.lut ; degrees (average at wheels)|addition
MAP_SPEED_CL = filename.lut ; kph|multiplier
MAP_SPEED_CD = filename.lut ; kph|multiplier
MAP_SPEED_BALANCE = filename.lut ; kph|addition
FRONT_RH_OFFSET = 0.00 ; meters (static ride height offset; it adds to the ride height input that's sent to the 2D-LUT lookup)
REAR_RH_OFFSET = 0.00 ; same as above
CL_MULT = 1.00
CD_MULT = 1.00
BALANCE_OFFSET = 0.00 ; %/100
INTERPOLATION = LINEAR ; LINEAR, CUBIC
DRAG_OFFSET = 0.00, 0.00 ; meters, meters - left/right, up/down
FRONT_FORCE_DELAY=0.05 ; delay for forces at the front of the car - higher numbers mean less lag
REAR_FORCE_DELAY=0.04 ; delay for forces at the rear of the car - higher numbers mean less lag
DRAG_FORCE_DELAY=0.045 ; delay for drag forces - higher numbers mean less lag

2D LUT example (x-axis is front ride height, y-axis is rear - axis values must ascend as you move right and down):
0.015 0.020 0.025

0.020 1 1 1

0.025 1 1 1

0.030 1 1 1

0.035 1 1 1

0.040 1 1 1

Tab/space-separated for ease of import from spreadsheet software (e.g. MS Excel). It is recommended that you build the table in Excel and copy and paste it
into your 2D LUT file.

There are also a new related tab available in the setup screens, with the option to choose between the different CSP aeromaps you may create within
aero.ini. You can add the following section to setup.ini:
[AEROMAP]
SHOW_CLICKS=0
TAB=AERO
NAME=Aero Configuration ; the setup option's title
LUT=aero_map_setup.lut ; format: display_name|aeromap_index
DEFAULT=0 ; the default index of map (others contained in the LUT will be switched off unless selected in the setup window)
POS_X=0.5
POS_Y=9
HELP=NULL ; vanilla AC options only, for now.

- Added the option to use inline LUTs within the aero.ini script.

- There is a new HEADLIGHTS input for aero controllers. Example:

[DYNAMIC_CONTROLLER_0]
WING=1
COMBINATOR=ADD ; or MULT, same as any other controller
INPUT=HEADLIGHTS
LUT=controller.lut ; 0 is off, 1 is on
FILTER=0.5
UP_LIMIT=90
DOWN_LIMIT=0

CURIOSITIES AND AMENITIES

- Very, very, very old aero.ini files used to have a section called [DATA]:
[HEADER]
VERSION=0.9

[DATA]
REFERENCE_AREA=1.910 ; Frontal area in m^2
CD=0.45 ; Drag coefficient
CL=0.98 ; lift coefficient (positive is downforce, negative is lift)
FRONT_SHARE=0.46 ; percentance of drag on front axis
CDX=1
CDY=1

So if you see this section in any mod (look also at the HEADER), it means that it’s outdated, and the mod itself is way outdated (at least with respect to this
config file).

FAQ
QUESTION [1]: I want to increase downforce on the rear by 25%. How can I do it?
ANSWER [1]: You can just make CL_GAIN=1.25 for the rear wing. Or just calculate 125% of the value already present and just add the difference.

336
Q [2]: Game crashes when I set extended physics (CSP) in my car's aero.ini. I was trying to add a fan element (CSP) and I edited aero.ini like this:
[HEADER]
VERSION=extended-2 ; using extended-2 or extended-1 you can enable extended physics

% ▲ Error: you can set extended physics (CSP) in car.ini only.

[skipping wings and eventual fins]

[FAN_0] ; below are the functions that add physics for a fan to the car (check)
NAME=FAN
MAP_FORCE_RH=FAN_FORCE.2Dlut ; meters (ride heights at each axle) vs. force produced
MAP_BALANCE_RH=FAN_BALANCE.2Dlut ; meters (ride heights at each axle) vs. front balance (%/100)
MAP_SPEED_FORCE=FAN_SPEED_FORCE.lut ; kph|force_multiplier
MAP_SPEED_BALANCE=FAN_SPEED_BALANCE.lut ; kph|balance_offset
FRONT_RH_OFFSET=0.000 ; meters (static ride height offset)
REAR_RH_OFFSET=0.000 ; meters (static ride height offset)
FORCE_MULT=-100.00
BALANCE_OFFSET=0.00 ; %/100
INTERPOLATION=LINEAR ; LINEAR, CUBIC

A [2]: That's because you need to have CSP installed for extended physics, and you activate them with VERSION=extended-1; extended-2 only the in
car.ini HEADER. If you do otherwise, expect crashes.

Q [3]: How can I calculate the front area of the car for a BODY wing in aero.ini when I have very little data?
A [3]: The front area can be determined using and a photograph of the front of the car: overlay the picture with transparent graph paper. Or take measures in
pixels on digital images. If you already made the 3d model things will be way easier and you can even use section planes if you want, but that’s another
story. Here’s an example on how to do it with a photo (especially in case you want to get data for a really old car without schematics). Keep in mind that you
shall separate eventual splitters from the BODY wing (and so from its area). The Caterham below doesn’t have front splitters.

Enclose your car in a grid (Fig. 4.4). Calculate the area of a rectangle which would encompass the front of the vehicle like in Fig. 4.5. In this example we
know from manufacturer data that our car is 1.61m wide and 1.07m high. While working with wings you can estimate some measures if you don’t have
enough specs. Look at the tires for example, if you know their diameter and width you already have a starting point to make some proportions. You can also
try looking at homologation rules for wheels or known visible elements (shock absorbers, suspensions, etc).

Fig. 4.4 – As you can see, a grid has been drawn to Fig. 4.5 – Area of the rectangle that completely covers the Fig. 4.6 - In total there are 600 squares.
enclose the front of this Caterham. You might want to do vehicle ( = length x width). In this case 1.61m x 1.07m ≈
this more precisely, i.e. closer to the car. 1.72m²

Calculate the total no. of squares and the no. of squares not covered by the silhouette (Fig. 4.6). The design of the transparent grid overlay helps. The total
not contained in the silhouette here is 135. This means the race car takes up 465 squares.

By multiplying the proportion of squares covered by the total area, you can find your racing cars actual frontal area, or at least a good approximation:

465/600 = 0.775 –> 77.5%

Typical adjusting values are 80-85% for cars, 70% for motorcycles, and 100% for trucks.
From this you can now calculate your vehicle’s frontal area:

Area = 77.5% * 1.72m² = 1.333m²

Now you can use this area to make a BODY wing and for any aero calculation you want to do with the equations (1.0) and (1.1).

Personally, I think the most time-consuming part of this process is finding a decent image. This is because most images are at an angle to make them look
better! Once you have it though, hopefully you will be able to follow the steps.

Q [4]: Where should I look for the downforce levels of cars?

A [4]: There is this website: http://www.mulsannescorner.com/data.html; it is a good resource, but the prototype/open wheeler downforce levels tend to be
slightly optimistic.

Q [5]: About active aero, is it possible to have a wing that goes from 0 to 20° at 120km/h and then back to 0° when you go lower than 80km/h?
A [5]: Yes, it's possible. Assuming it is wing 1, you can add the following controller for example:
[DYNAMIC_CONTROLLER_0]
WING=1
COMBINATOR=ADD
INPUT=SPEED_KMH
LUT=wing_controller_speed.lut
FILTER=0.90
UP_LIMIT=20

337
DOWN_LIMIT=0

While the respective wing_controller_speed.lut should look like this:

0|0
80|0
120|20

Obviously you'd need to change the wing number to be appropriate for the wings you have.

Q [6]: Can I use a CFD simulation software to calculate the aerodynamics of my car?
A [6]: Yes, you can, but the program must be able to provide useful data. You can try with OpenCFD, it has been used to create the mod of the KRB Audi S1
Silhouette (https://www.racedepartment.com/downloads/krb-audi-s1-silhouette.14447), Fig. .

Fig. – Aero CFD simulation (OpenCFD) for the KRB Audi S1 Silhouette mod by @AccAkut.

338
PHYSICS - AERODYNAMICS
In order to set the various parameters for the aerodynamics of our car, we first need to understand how the physics work in real life. After grasping the basic
concepts of aerodynamic theory, we will be able to ask the right questions when we’ll go in search of the technical data of our car.
Land vehicle aerodynamics concerns the study of the interactions between a vehicle in motion near the ground. As such it uses the conceptual tools of fluid
dynamics, with several specific aspects related to the type of geometries that are used and the velocities involved.

1.0 - Main physical properties of air

Fluid dynamics, and aerodynamics in particular, uses a continuous description of a fluid, which in our case is air. It is a gas whose behaviour is well described
by the perfect gas model. The classic equation of state is
𝑝𝑝𝑝𝑝 = 𝑁𝑁𝑘𝑘𝐵𝐵 𝑇𝑇
Where p is the thermodynamic pressure in Pascal [Pa] (for our purposes just consider atmospheric pressure at ground level ~1atm = 101325 Pa), V is
the volume of gas, T the absolute temperature (measured in Kelvin [K]), N is the number of gas molecules contained in the aforementioned volume and
𝑘𝑘𝐵𝐵 = 1.38 × 10−23 𝐽𝐽/𝐾𝐾 in [Joule/Kelvin] is the Boltzmann constant 52.
Usually the number of molecules is expressed in moles, one mole being an Avogadro number (𝑁𝑁𝐴𝐴 = 6.022 × 1023 ) of particles 53.
This way, introducing the universal gas constant, 𝑅𝑅 = 𝑘𝑘𝐵𝐵 𝑁𝑁𝐴𝐴 = 8.314472 𝐽𝐽𝐽𝐽/𝑚𝑚𝑚𝑚𝑚𝑚, the equation of state is written as
𝑝𝑝𝑝𝑝 = 𝑛𝑛𝑛𝑛𝑛𝑛
Where 𝑛𝑛 = 𝑁𝑁⁄𝑁𝑁𝐴𝐴 is the number of moles.
Air is a mixture of gases composed of different species (i.e., atoms and molecules). We have to account for this. A mole (or molar) fraction is defined as the
ratio of the number of moles of a certain chemical species S normalized to the number of total moles, 𝑋𝑋𝑆𝑆 = 𝑁𝑁𝑆𝑆 /𝑁𝑁. It’s basically the percentage of that
species in the substance 54. The molar mass instead is the ratio between the mass and the amount of substance (measured in moles) of any sample of
compound. You can find the molar masses of single atoms in the periodic table, corresponding to the atomic weight 55 (Fig.).

Fig. – The periodic table. Chemistry is involved in aerodynamics, yes. All subjects are connected. That’s what makes you a better engineer.

You can find that at sea level, dry air (~35°C and without impurities) consists of molecular nitrogen, N2 molar mass 𝑚𝑚𝑁𝑁2 ≅ 2 ∙ 14.006 ≅ 28, present with
the molar fraction 𝑋𝑋𝑁𝑁2 ≅ 0.7808; molecular oxygen O2 with 𝑚𝑚𝑂𝑂2 ≅ 2 ∙ 15.999 ≅ 32, present with 𝑋𝑋𝑂𝑂2 ≅ 0.20947; argon, 𝑚𝑚𝐴𝐴𝐴𝐴 ≅ 39.948 with
𝑋𝑋𝐴𝐴𝐴𝐴 ≅ 0.0934; carbon dioxide CO2, with 𝑚𝑚𝐶𝐶𝐶𝐶2 ≅ 2 ∙ 15.999 + 12.0096 ≅ 44.0076 and 𝑋𝑋𝐶𝐶𝐶𝐶2 ≅ 0.000314, plus traces of other species (0.003%).
Thus, the mass in grams of one mole of air (average molar mass) is the following weighted average:
𝑋𝑋𝑁𝑁2 𝑚𝑚𝑁𝑁2 + 𝑋𝑋𝑂𝑂2 𝑚𝑚𝑂𝑂2 + 𝑋𝑋𝐴𝐴𝐴𝐴 𝑚𝑚𝐴𝐴𝐴𝐴 + 𝑋𝑋𝐶𝐶𝐶𝐶2 𝑚𝑚𝐶𝐶𝐶𝐶2
𝑚𝑚𝑎𝑎 = ≅ 0.7808 ∙ 28 + 0.20947 ∙ 32 + 0.00934 ∙ 39.95 + 0.000314 ∙ 44.0076 ≅ 28.95 𝑔𝑔/𝑚𝑚𝑚𝑚𝑚𝑚
𝑋𝑋𝑁𝑁2 + 𝑋𝑋𝑂𝑂2 + 𝑋𝑋𝐴𝐴𝐴𝐴 + 𝑋𝑋𝐶𝐶𝐶𝐶2

52
Being a constant, you don’t really need to know where it does come from, just take it as granted. If you are curious do a little search on the web.
53 One mole of a certain substance is the quantity of said substance that contains as many elementary entities (atoms, ions, molecules, electrons or other specified entities) as how many atoms are
contained in exactly 12 grams of 126𝐶𝐶 , which is a particular isotope of carbon. Dividing the total mass of one mole of carbon by the mass on one atom, you obtain the number of Avogadro. This is
a convention in chemistry. The mole is one of the fundamental SI measurement units.
54
In fact, if you take a look at the data immediately below, air has around 0.7808=78% of nitrogen, 0.2095=20% of oxygen and 1% of argon.
55
This is due to the fact that compounds from Earth have a typical isotope composition. But we won’t delve any further into the topic.

339
Be aware that usually in chemistry calculations are necessary quite a few decimal numbers, otherwise the results become quite imprecise right away.

The percentage composition of the main constituents (nitrogen, oxygen and rare gases) does not change up to 80-100 km of height in the atmosphere. This
is because there are large-scale turbulences that cause continuous mixing.

The mass of N moles of air is therefore Ma = Nama, so the equation of state can be expressed as

where Ra = R/ma = 287.05J/(KgK) is the air gas constant and the mass is expressed in kg. The equation of state can be rewritten in terms of density 𝜌𝜌 =
𝑀𝑀𝑎𝑎 /𝑉𝑉,

From the equation of state we obtain the density of air. For example at a temperature of 273K (≅0°C) and a pressure of 760mmHg ' 1 atm ' 105 Pa we find
⇢ ' 1.3Kg/m3. Under ambient conditions (temperature of of 273K and atmospheric pressure), the air is far from critical conditions (Tc ' 133K, pc ' 3770
kPa), so it actually behaves like a perfect gas.

2.0 – Reynolds number

The forces created by the airflow around a car depend on several factors: the shape of the car, the relative velocity of the air and the car, and other things
such as protuberances on the car. At low speeds these forces are usually low, but at high speeds they can severely affect the performance of the car.
Stability, tire traction, handling ability are all affected, and of particular importance, fuel economy is also affected. Engine power has to overcome
aerodynamic forces, and this takes fuel.

The overall aerodynamic drag on the car we’re interested in consists of five different types of drag: form, lift, surface friction, interference, and internal flow.
• Form drag depends on the form of the shape of the car: how smoothly air passes over the contour of the body and how it breaks away at the rear.
• Lift drag is the result of pressure differences on the bottom and top of the car that create lift.
• Surface friction drag is a result of the viscosity of the air-in other words, how much friction there is between the various layers of air near the car.
• Interference drag is caused by projections on the car body, and internal drag is caused by air passing through the car.

The amount of drag caused by the various forces varies considerably. Percentage-wise, for an average passenger car we can assume the following drags:
form, 55%, interference, 16%, internal, 12%, surface friction, 10%, lift, 7%.

Streamlines, Airflow over the vehicle and Surface friction drag

A small section of the airflow over a car is referred to as a streamline, and the family of streamlines is called the airflow pattern. This pattern depends on the
car’s shape and its speed through the air. It can be seen in a wind tunnel if an opaque gas such as smoke is used (Fig.).

340
Fig. – Smoke tests for various vehicles, in order from top left to bottom right: wooden 1:5 scale model of Jaguar XJ13, Gumpert Apollo Sport, Ferrari 599 GTB Fiorano, Ferrari 430
Scuderia. Look at how splitters and diffusers push the air up or down. You can see that the smoke becomes turbulent on the rear end of the vehicle.

Streamlines in the vicinity of a car are complex. Over the front they generally follow the contours of the vehicle, but they can split and separate. Of particular
importance is the internal friction, or viscosity, of the air. It was shown in 1744 by Jean LeRond D’Alembert that if the viscosity is zero, no tangential forces
can act on the surface of an object, and no forces would therefore be exchanged between the air and the object: in other words, aerodynamic forces would
not exist. This is known as D’Alembert’s paradox.

Of course, in practice, no fluids have zero viscosity, so aerodynamic forces do exist.

Viscosity creates frictional forces between the layers of air that pass over one another. They give rise to what is called the boundary layer. They layer of air in
contact with the surface of the car tends to stick to it so that it moves along with it. The next layer gets dragged along because of friction, but it is faster as it
isn’t in contact with the wing object, so it moves ahead slightly. The third layer moves even farther ahead, and so on. The gradual “lagging” of the layers
gives rise to a gradient, the boundary layer (Fig.).

Fig. – Due to the surface friction between the airfoil and the layer of air in contact with it, the nearest streamlines are slowed down, to the point that a turbulence is created.

How thick is it? It is usually very thin, like a sheet, and as the speed of the car increases, it gets even thinner. It gets thicker, however, as it approaches the
rear of the car. The frictional force due to the layers of air close to the surface is referred to as surface friction drag, or skin friction drag. It acts in a direction
tangential to the surface.

When the friction between the layers is not high, the layers slide over one another quite easily. In this case we have what is called laminar flow (smooth
flow), which occurs only at relatively low speeds over a car.
The transition from laminar flow to turbulent flow is a huge part of aerodynamics and considerable study has gone into it.

Form Drag
As we saw earlier, form drag depends mainly on the shape of the car. Frictional forces produce pressure differences at right angles to the surface, and if we
add up all these pressures over the area of the car we get the total form drag force on it.

Form drag also depends on the splitting of the streamlines and the wake behind the car. It is important to reduce splitting as much as possible and also to
keep the wake to a minimum. The energy that goes into creating the wake is taken out of the kinetic energy of the vehicle and therefore reduces the car’s
horsepower.

Over the years, designers experimented with various shapes to reduce the turbulence in the rear part of vehicles (Fig.).

341
Fig. - The Special version of Norman-Timbs. Manufactured in the 1940s, the vehicle has an aerodynamic coefficient of less than 0.25.

Fig. - This beauty comes from the house of Ferrari. The 512 S Pininfarina Modulo (year 1970) was all about design and performance.

Bernoulli’s Theorem
One of the most important relations in aerodynamics is referred to as Bernoulli’s theorem. It was formulated in the eighteenth century by Daniel Bernoulli. He
showed that as the velocity of a fluid increases, its pressure decreases. Mathematically, we can state this as
𝜌𝜌𝑣𝑣 2
𝑝𝑝 + 2
= 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐 (1.4)

𝜌𝜌𝑣𝑣 2
Where p= air pressure, ρ= density of air (at 101.325 kPa (abs) and 20 °C (68 °F), air has a density of approximately 1.204 kg/m3), v= velocity, and
2
is the dynamic pressure.
We can see from this that as dynamic pressure, which depends on velocity, increases, air pressure must decrease, and vice versa. This increase in pressure
is the reason an airplane wing produces lift. It is designed so that the velocity of air across the top is greater than across the bottom. If the velocity is greater,
the pressure is less. This means the pressure beneath the wing is greater, and this in turn produces the lift which allows the plane to fly. Imagine a car
spoiler as a plane wing, but reversed. It will give us the downforce we need in order to obtain the grip we want on our wheels.

Drag Force and Drag Coefficient

But how do you go about testing the aerodynamics of a car? Everything, it turns out, hinges on a simple number called the coefficient of drag (Cd or Cx). If
you know this number, you know most of what is to be known about the aerodynamics of the car.

Both the drag force on a car and the coefficient of drag, Cd, can easily be calculated. The drag force is given by

𝜌𝜌𝑣𝑣 2 𝐴𝐴𝑓𝑓 𝐶𝐶𝑑𝑑

𝐹𝐹𝑑𝑑 = 2
(1.5)

342
Where 𝐴𝐴𝑓𝑓 is the frontal area of the car.
If we measure the drag force in a wind tunnel, we can use the same formula (1.5) to calculate Cd:

2𝐹𝐹
𝐶𝐶𝑑𝑑 = 𝜌𝜌𝑣𝑣 2 𝐴𝐴𝑑𝑑 (1.6)
𝑓𝑓

The coefficient of drag is based on the drag of a flat square sheet; in the wind it has a Cd of 1.00. It was assumed early on that this was the maximum, but
later it was shown that other shapes actually produced larger Cd’s. Early cars typically had a Cx of 0.7. Over the years it has gradually decreased until some
of the lowest values today are less than 0.3. As a rough guide we can say that a car has poor aerodynamics if it has a Cd of 0.5 and good aerodynamics if it
is 0.3 or less.
What are the Cx coefficients of actual cars? Manufacturers do occasionally publish them.

In order to predict a vehicle's Cd, manufacturers often simulate wind turbulence with modeling software applications (Fig.) to quickly evaluate changes to a
model design, allowing greater improvements before the physical prototyping stage.

Fig. – An aerodynamic simulation of the airflow for a van (Volvo).

Once the model has been simulated satisfactorily, production mockups are incrementally created and tested in the wind tunnel to collect actual data to
validate the modeling and to zero in on any final improvements.
As it turns out, aerodynamic drag is not the only force acting against the motion of the car. Rolling resistance is also important. In most cases it is much less
than form drag but it does have an effect. It is relatively difficult to calculate. We’ll see how later.

Front area (𝐴𝐴𝑓𝑓 ) of the vehicle

In the formula for aerodynamic force and coefficient of drag, one of the main components is the frontal area of the vehicle 𝐴𝐴𝑓𝑓 . This area should therefore be
kept as small as possible if the drag force and Cd are to be low. This is important when car manufacturers create a new vehicle design.
The frontal area can be determined with various methods, for example using a laser and a photograph. To a first approximation, we can use 80% of the
height times the width, however we’ve already seen a more accurate way to get the area in the FAQ of aero.ini.

Since frontal area and Cd are both of particular importance, it is worthwhile to consider their product, called the figure of merit. The figure of merit gives a
better comparison between cars, because it is possible that a vehicle with a low Cd has a relatively large frontal area, and vice versa. So, only one of the
numbers does not tell the entire story. Their product, however, does.

Graph

Aerodynamic Lift and Downforce

Popular Explanation vs Physical Explanation

We are going to show you that lift is easier to understand if one starts with Newton’s laws rather than the Bernoulli principle.
We will also show you that the popular explanation that most of us were taught is misleading at best and that lift is due to the wing diverting air down. Most
of this diverted air is pulled down from above the wing.

343
The popular description of lift is based on the Bernoulli principle. The primary advantage of this description is that it is easy to understand and has been
taught for many years. Because of its simplicity, it is used in most manuals. The major disadvantage is that it relies on the "principle of equal transit times",
or at least on the assumption that because the air must travel farther over the top of the wing it must go faster. This description focuses on the shape of the
wing and prevents one from understanding such important phenomena as inverted flight, power, ground effect, and the dependence of lift on the angle of
attack of the wing.

Students of physics and aerodynamics are taught that an airplane flies as a result of the Bernoulli principle, which says that if air speeds up the pressure is
lowered (in fact this is not always true; the air flows fast over the airplane’s static port but the altimeter still reads the correct altitude). The argument goes
that a wing has lift because the air goes faster over the top creating a region of low pressure. This explanation usually satisfies the curious and few challenge
the conclusions.
Some may wonder why the air goes faster over the top of the wing and this is where the popular explanation of lift falls apart. In order to explain why the air
goes faster over the top of the wing, many have resorted to the geometric argument that the distance the air must travel is directly related to its speed. The
usual claim is that when the air separates at the leading edge, the part that goes over the top must converge at the trailing edge with the part that goes under
the bottom. This is the so-called "principle of equal transit times".

One might ask if the numbers calculated by the popular description really work. Let’s look at an example. Take the case of a Cessna 172, which is a high-
winged, four-seat airplane. The wings must lift 1045 kg (2300 lb) at its maximum flying weight. The path length for the air over the top of the wing is only
about 1.5% greater than under the wing. Using the popular Description of lift, the wing would develop only about 2% of the needed lift at 104 km/h (65
mph), which is "slow flight" for this airplane. In fact, the calculations say that the minimum speed for this wing to develop sufficient lift is over 640 km/h
(400 mph). If one works the problem the other way and asks what the difference in path length would have to be for the popular Description to account for
lift in slow flight, the answer would be 50%. The thickness of the wing would be almost the same as the chord length.

But who says the separated air must meet at the trailing edge at the same time? Fig. shows the airflow over a wing in a simulated wind tunnel. In the
simulation, smoke is introduced periodically. One can see that the air that goes over the top of the wing gets to the trailing edge considerably before the air
that goes under the wing. In fact, the air is accelerated much faster than would be predicted by equal transit times. Also, on close inspection one sees that
the air going under the wing is slowed down from the "free-stream" velocity of the air. The principle of equal transit times holds only for wings with zero lift.

Fig. –

The popular explanation also implies that inverted flight is impossible. It certainly does not address acrobatic airplanes, with symmetric wings (the top and
bottom surfaces are the same shape), or how a wing adjusts for the great changes in load such as when pulling out of a dive or in a steep turn?
So, why has the popular explanation prevailed for so long? One answer is that the Bernoulli principle is easy to understand. There is nothing wrong with the
Bernoulli principle, or with the statement that the air goes faster over the top of the wing. But, as the above discussion suggests, our understanding is not
complete with this explanation. The problem is that we are missing a vital piece when we apply Bernoulli’s principle. We can calculate the pressures around
the wing if we know the speed of the air over and under the wing, but how do we determine the speed? As we will soon see, the air accelerates over the
wing because the pressure is lower, not the other way around.

Another fundamental shortcoming of the popular explanation is that it ignores the work that is done. Lift requires power (which is work per time). As will be
seen later, an understanding of power is key to the understanding of many of the interesting phenomena of lift.

The physical description on lift

The Physical Description of lift is based primarily on Newton's three laws and a phenomenon called the Coanda effect. It is also a useful tool for making
rough estimates ("back-of-the-envelope calculations") of lift. The Physical Description of lift is also of great use to a pilot who needs an intuitive
understanding of how to fly an airplane.

Newton’s first law states a body at rest will remain at rest, or a body in motion will continue in straight-line motion unless subjected to an external applied
force. That means, if one sees a bend in the flow of air, or if air originally at rest is accelerated into motion, a force is acting on it. Newton’s third law states
that for every action there is an equal and opposite reaction. As an example, an object sitting on a table exerts a force on the table (its weight) and the table
puts an equal and opposite force on the object to hold it up. In order to generate lift a wing must do something to the air. What the wing does to the air is
the action while lift is the reaction.

Let’s compare two figures used to show streamlines over a wing. In Fig. the air comes straight at the wing, bends around it, and then leaves straight behind
the wing.

344
Fig. - Common depiction of airflow over a wing. This wing has no lift.

We have all seen similar pictures, even in flight manuals. But, the air leaves the wing exactly as it appeared ahead of the wing. There is no net action on the
air so there can be no lift!

Fig. shows the streamlines, as they should be drawn.

Fig. - True airflow over a wing with lift, showing upwash and downwash.

The air passes over the wing and is bent down. Newton’s first law says that them must be a force on the air to bend it down (the action). Newton’s third law
says that there must be an equal and opposite force (up) on the wing (the reaction). To generate lift a wing must divert lots of air down.

The lift of a wing is equal to the change in momentum of the air it is diverting down. Momentum is the product of mass and velocity (mv). The most
common form of Newton’s second law is F= ma, or force equal mass times acceleration.
The law in this form gives the force necessary to accelerate an object of a certain mass. An alternate form of Newton’s second law can be written: The lift of a
wing is proportional to the amount of air diverted down times the vertical velocity of that air. It is that simple. For more lift the wing can either divert more air
(mass) or increase its vertical velocity. This vertical velocity behind the wing is the vertical component of the "downwash". Figure 4 shows how the
downwash appears to the pilot (or in a wind tunnel).

Fig. - How downwash appears to a pilot and to an observer on the ground.

The figure also shows how the downwash appears to an observer on the ground watching the wing go by. To the pilot the air is coming off the wing at
roughly the angle of attack and at about the speed of the airplane. To the observer on the ground, if he or she could see the air, it would be coming off the
wing almost vertically at a relatively slow speed. The greater the angle of attack of the wing the greater the vertical velocity of the air. Likewise, for a given
angle of attack, the greater the speed of the wing the greater the vertical velocity of the air. Both the increase in the speed and the increase of the angle of
attack increase the length of the vertical velocity arrow. It is this vertical velocity that gives the wing lift.

As stated, an observer on the ground would see the air going almost straight down behind the plane. This can be demonstrated by observing the tight
column of air behind a propeller, a household fan, or under the rotors of a helicopter; all of which are rotating wings. If the air were coming off the blades at
an angle the air would produce a cone rather than a tight column. The wing develops lift by transferring momentum to the air. For straight and level flight
this momentum eventually strikes the earth in. If an airplane were to fly over a very large scale, the scale would weigh the airplane.

Let us do a back-of-the-envelope calculation to see how much air a wing might divert. Take for example a Cessna 172 that weighs about 2300 lb (1045 kg).
Traveling at a speed of 140 mph (220 km/h), and assuming an effective angle of attack of 5 degrees, we get a vertical velocity for the air of about 11.5 mph
(18 km/h) right at the wing. If we assume that the average vertical velocity of the air diverted is half that value we calculate from Newton's second law that
the amount of air diverted is on the order of 5 ton/s. Thus, a Cessna 172 at cruise is diverting about five times its own weight in air per second to produce
lift. Think how much air is diverted by a 250-ton Boeing 777 on takeoff.
Diverting so much air down is a strong argument against lift being just a surface effect (that is only a small amount of air around the wing accounts for the
lift), as implied by the popular explanation. In fact, in order to divert 5 ton/sec the wing of the Cessna 172 must accelerate all of the air within 18 feet (7.3 m)
above the wing. One should remember that the density of air at sea level is about 2 lb per cubic yard (about 1kg per cubic meter). Figure 5 illustrates the
effect of the air being diverted down from a wing. A huge hole is punched through the fog by the downwash from the airplane that has just flown over it.

So how does a thin wing divert so much air? When the air is bent around the top of the wing, it pulls on the air above it accelerating that air downward.
Otherwise there would be voids in the air above the wing. Air is pulled from above.
This pulling causes the pressure to become lower above the wing. It is the acceleration of the air above the wing in the downward direction that gives lift.
(Why the wing bends the air with enough force to generate lift will be discussed in the next section.)
As seen in figure 3, a complication in the picture of a wing is the effect of "upwash" at the leading edge of the wing. As the wing moves along, air is not only
diverted down at the rear of the wing, but air is pulled up at the leading edge. This upwash actually contributes to negative lift and more air must be diverted
down to compensate for it. This will be discussed later when we consider ground effect.

345
Normally, one looks at the air flowing over the wing in the frame of reference of the wing. In other words, to the pilot the air is moving and the wing is
standing still. We have already stated that an observer on the ground would see the air coming off the wing almost vertically. But what is the air doing below
the wing? Figure 6 shows an instantaneous snapshot of how air molecules are moving as a wing passes by. Remember in this figure the air is initially at rest
and it is the wing moving. Arrow "1" will become arrow "2" and so on. Ahead of the leading edge, air is moving up (upwash).
At the trailing edge, air is diverted down (downwash). Over the top the air is accelerated towards the trailing edge. Underneath, the air is accelerated forward
slightly.

Fig. - Direction of air movement around a wing as seen by an observer on the ground.

So, why does the air follow this pattern? First, we have to bear in mind that air is considered an incompressible fluid for low-speed flight. That means that it
cannot change its volume and that there is a resistance to the formation of voids.
Now the air has been accelerated over the top of the wing by of the reduction in pressure. This draws air from in front of the wing and expels if back and
down behind the wing. This air must be compensated for, so the air shifts around the wing to fill in. This is similar to the circulation of the water around a
canoe paddle. This circulation around the wing is no more the driving force for the lift on the wing than is the circulation in the water drives the paddle.
Though, it is true that if one is able to determine the circulation around a wing the lift of the wing can be calculated. Lift and circulation are proportional to
each other.
One observation that can be made from figure 6 is that the top surface of the wing does much more to move the air than the bottom. So the top is the more
critical surface. Thus, airplanes can carry external stores, such as drop tanks, under the wings but not on top where they would interfere with lift. That is also
why wing struts under the wing are common but struts on the top of the wing have been historically rare. A strut, or any obstruction, on the top of the wing
would interfere with the lift.

Coanda Effect
A natural question is "how does the wing divert the air down?" When a moving fluid, such as air or water, comes into contact with a curved surface it will try
to follow that surface. To demonstrate this effect, hold a water glass horizontally under a faucet such that a small stream of water just touches the side of the
glass. Instead of flowing straight down, the presence of the glass causes the water to wrap around the glass as is shown in Fig.. This tendency of fluids to
follow a curved surface is known as the Coanda effect. From Newton’s first law we know that for the fluid to bend there must be a force acting on it. From
Newton’s third law we know that the fluid must put an equal and opposite force on the glass.

Fig. - Coanda effect.

So why should a fluid follow a curved surface? The answer is viscosity; the resistance to flow which also gives the air a kind of "stickiness". Viscosity in air
is very small but it is enough for the air molecules to want to stick to the surface. At the surface the relative velocity between the surface and the nearest air
molecules is exactly zero. (That is why one cannot hose the dust off of a car.) Just above the surface the fluid has some small velocity. The farther one goes
from the surface the faster the fluid is moving until the external velocity is reached. Because the fluid near the surface has a change in velocity, the fluid flow
is bent towards the surface by shear forces. Unless the bend is too tight, the fluid will follow the surface. This volume of air around the wing that appears to
be partially stuck to the wing is called the "boundary layer" and is less than one inch (2.5 cm) thick, even for a large wing.
Look again at Figure 3. The magnitude of the forces on the air (and on the wing) are proportional to the "tightness" of the bend. The tighter the air bends the
greater the force on it. One thing to notice in the figure is that most of the lift is on the forward part of the wing. In fact, half of the total lift on a wing is
typically produced in the first 1/4 of the chord length.

Lift as a function of angle of attack

There are many types of wing: conventional, symmetric, conventional in inverted flight, the early biplane wings that looked like warped boards, and even the
proverbial "barn door". In all cases, the wing is forcing the air down, or more accurately pulling air down from above. (Though the early wings did have a
significant contribution from the bottom.) What each of these wings has in common is an angle of attack with respect to the oncoming air. It is the angle of
attack that is the primary parameter in determining lift.

346
To better understand the role of the angle of attack it is useful to introduce an "effective" angle of attack, defined such that the angle of the wing to the
oncoming air that gives zero lift is defined to be zero degrees. If one then changes the angle of attack both up and down one finds that the lift is proportional
to the angle. Figure 8 shows the lift of a typical wing as a function of the effective angle of attack. A similar lift versus angle of attack relationship is found for
all wings, independent of their design. This is true for the wing of a 747, an inverted wing, or your hand out the car window. The inverted wing can be
explained by its angle of attack, despite the apparent contradiction with the popular explanation of lift. A pilot adjusts the angle of attack to adjust the lift for
the speed and load. The role of the angle of attack is more important than the details of the wings shape in understanding lift. The shape comes into play in
the understanding of stall characteristics and drag at high speed.

Fig. - Lift versus the effective angle of attack.

Typically, the lift begins to decrease at a "critical angle" of attack of about 15 degrees. The forces necessary to bend the air to such a steep angle are greater
than the viscosity of the air will support, and the air begins to separate from the wing. This separation of the airflow from the top of the wing is a stall.

Lift is a serious thing particularly in racing cars. It has a serious effect on the control and handling of the car.
Lift occurs because the airflow over the top of a car is faster than across the bottom. This occurs to some degree in all cars. As the speed increases, the
pressure decreases, according to Bernoulli’s theorem. The top of the car therefore has a lower pressure than the bottom, and the result is a lifting force.
Comparing a car to an airplane wing, we see the similarity.
The lift force is given by

Where A is the area of the underside of the car and Cl is the coefficient of lift.

Fig. – Group B racing Jaguar sketches. On the right the sketch shows the rear diffuser area of the car: the concept is that the entire car is an inverted wing profile that
accelerates the airflow and creates low pressure beneath the car, in accordance with the Bernoulli principle, that effectively "sucks" the car towards the road.

wip

Which cars have better aerodynamic designs, square or smooth ones?

There is so much more to aerodynamics than something being just smooth or boxy.
A design will benefit from smooth curving surfaces that lower the Cd, but it doesn't necessarily mean the car will end up being aerodynamically efficient.
The overall purpose of the design is what determines how much drag is wanted or needed.

To illustrate this point, in the following examples (Fig.), the vehicle on the left has a higher Cx than the one on the right.

347
Fig. - The Ferrari F50 has a Cd of 0.372, while the Tatra 77A has a Cd of 0.212.

Fig. – In general Formula 1 cars have a Cd between 0.7-1.1. Pickups, like this beautiful Chevrolet Apache C-10, have a Cd between 0.35-0.45. This coefficient is so high in
F1 cars because they need far more tire grip, improving both acceleration and cornering. The aerodynamic drag is used to create lift efficiently.

So how does the design of the car make it more aerodynamic?

There used to be a word in common use in the 1930s, 40s and 50s called “streamlining”. Nobody uses it now, but it essentially meant changing the shape
of a body so that its resistance to air flowing over it becomes as little as possible (Fig.). They really went overboard then, and even “streamlined” teacups
and kettles were marketed, because it was a buzzword.

Fig. – (left) The difference from a “standard” and a streamlined car (1930s ca.). (right) Main features of a streamlined car.

Streamlining is a way to design a shape that generates as little turbulence as possible, with the purpose of generating less drag. You can see some indicative
examples in Fig. below.

348
Fig. - These figures would correspond to objects at about 140 mph in air. The percentage of drag would vary at different speeds and at very low speeds there would not be much
difference. At higher speeds laminar flow and turbulence come into play with different effects than in these illustrations, which are just indicative. Wind resistance (the drag in air flow)
increases up to the speed of approximately 140 mph, and up to this speed a rough surface gives less drag than a smooth polished surface. This is due to the turbulence at the surface
acting like tiny ball bearings to allow the air layers to pass over more smoothly. At approx. 140 mph the drag drops off as the flow becomes laminar and turbulence creates more drag.
Laminar flow continues as speed and drag increase. (FIND BETTER PIC)

Streamlining would seem to be important, after all, we want the car to move more easily through the air (less drag = faster), but the most dominant reason
behind the large difference in the appearance of the more recently designed multiwinged race car is the focus on using its body and wings to create aerodynamic
downforce. This raises the question of why aerodynamic downforce is needed.
When wings generate lift, they also create drag, which is the force that resists the motion. The drag is usually much smaller than the lift, and it can be
reduced by streamlining the vehicle (having a smooth external surface). Of course, any improvement in a vehicle’s drag leads to potential improvements in
fuel economy, which is why drag is quite important to the passenger car industry.
But the shape of the airfoil is not the entire problem: the condition of the surface affects the movement of the particles that collide with it. As seen in Fig.,
having a mirror finish doesn’t mean less drag. When a particular type of roughness is present on a surface it can also create a skin-friction-drag reduction.
Skin-friction drag is perhaps the most essential manifestation of the dissipative nature of turbulence and accounts for the total drag in the case of planar
walls (as in a zero-incidence flat plate boundary layer, Fig.). Several techniques are available to reduce friction drag below the level typical of a smooth solid
wall; they can be categorized into active (requiring extra energy) and passive ones. The former typically provide larger savings but imply extra complexity
and cost, so that the ideal technique for friction reduction remains a passive one, often embodied in surface patterns performing better than the planar flat
geometry.
Dimples are small concavities imprinted on a flat surface, known to affect heat transfer and also flow separation and aerodynamic drag on bluff bodies when
acting as a standard roughness.
The use of dimples on the surface of bluff bodies is well known (e.g., in golf ball manufacturing, they have been an accepted practice since the 1930s), and
their ability to influence the turbulent boundary layer and the separation on the body is rather well understood; the same concept is also being considered in
sports-car racing and other competitive sports (Fig.).

349
Fig. – (top) Dimples on the very end of the rear spoiler of a race car. (bottom) Bugatti Dimple Airscoop, an active dimple aero device fitted on the 2020 Bugatti Bolide.

It has been proven that when the air flows along the surface of the aerofoil with dimple, there is an acceleration of the flow at the dimple surface and the
boundary layer changes from laminar to turbulent. This transition results in delayed flow separation which reduces the drag. The presence of a dimple therefore
increases the stall angle of the aircraft. This, if incorporated would be extremely beneficial in making an aircraft more maneuverable and increase the aircraft’s
fuel economy. The position and dimensions of the dimple affect the drag and lift characteristics. The total aerodynamic efficiency increases due to the reduced
drag. However, experimental studies have to be performed. It is also necessary to determine the feasibility of generation of dimples on aircraft wings. The
concept of presence of dimples on aircraft wings to reduce drag cannot be applied to all aerofoil profiles. (Rajasai, Tej, Srinath, 2015)

Another study confirms that:

The velocity renderings and the pressure variations observed [in the CFD FLUENT simulations] are in synchronisation with the experimental results. The
dimple parameters were chosen based on the theoretical study of the flow around the body and the past results which led to a 0.3 % reduction in drag value.
But there exists even greater scope for optimisation of the dimple geometry and its positioning over the body surfaces which can lead to a massive reduction
in the drag coefficient. (Grover et al., 2017)

However, no optimization information of dimple sizing is given in literature.

This principle was apparently already employed a long time ago, knowingly or unknowingly: the streamlined Alfa Romeo 40-60 HP Aerodinamica (Fig.)
adopted skin-dimpling to improve its aerodynamic performance and reach a 139 km/h top speed.

350
Fig. - The 1914 Alfa Romeo 40-60 HP Aerodinamica (1970 replica). All this shows how the Bugatti Dimple Airscoop is not really anything new and everything has already been done
before, as always. They are just active dimples. Those Italians knew it all along.

(wip) XD

351
2. ai.ini
This file manages the behaviour of the single-player AI opponents for each car. You don’t need to mess a lot with this config, as you can easily copy it from
another car with a working AI and just change the shifting behaviour in [GEARS]. Nevertheless, always test it in multiple races to verify that everything is
working properly.
[HEADER]
VERSION=3 ; version of the AI behaviour. VERSION=4 introduced differences in the shifting functions below.

[GEARS]
UP=5700 ; Upshipt gear at value RPM (also used for automatic gearbox assist); rpm AI shifts up at.
DOWN=3800 ; Downshift gear at value RPM (also used for automatic gearbox assist); rpm AI shifts down at.

% ▲ for [HEADER] VERSION=4, Kunos changed the downshift behaviour to be a percentage of revs rather than a particular RPM, so it needs to be DOWN=60 (or
70 or 80 or w/e) rather than =5500 or =3800; you can always switch back to version 3

SLIP_THRESHOLD=0.5 ; Slip ratio permitted for AI driving - how well AI rev matches
GAS_CUTOFF_TIME=0.1 ; Gearchange time needed for AI control - how long ai lifts throttle on upshifts

[PEDALS]
GASGAIN=4.0 ; how the AI pushes the throttle pedal vs. in other cars (since they have different engine maps, torque curves, etc)
BRAKE_HINT=0.8 ; how the AI pushes the brake pedal in this car (0.9 = 90% of the recorded line's suggested braking)

% ▲ This parameter regulates the time and space to brake the car, so if the parameter is in 1, for example, the car brakes the fastest possible, but if
the parameter goes down, then the time to stop the car is higher.

TRAIL_HINT=0.2 ; trail braking, same thing

[STEER]
STEER_GAIN=1.5 ; how hard the AI needs to turn the wheel to make corners (depends on ideal slip ratios, the way the car handles
oversteer/understeer, etc.)

[LOOKAHEAD]
BASE=20 ; how far in front of the car the AI looks at the recorded line to know what to do
GAS_BRAKE_LOOKAHEAD=3 ; not sure if this is added to the base. Tells the AI how far it needs to be ready to brake/throttle.
SPEED_GAIN=0.2 ; how much ai increases the distance according to speed (needs to look farther ahead to be ready for corners at higher
speeds)

[DRAG]
SLIP_RATIO_LIMIT=10 ; the AI won't brake or throttle to a higher slip ratio than this; this is for drag mode

[ULTRA_GRIP] ; Changing this value doesn’t affect the AI anymore since VERSION=3
VALUE=1.2 ; how much lateral grip the AI is simulated within braking zones. This helps AIs brake closer to the limit

% ▲ AI cars have a 20% (1.2 * 100 = 120%) tire grip overhead vs the player and some form of (artificial) stability control. They don't try to use the
extra grip normally though. The extra is there so the AI's weird and twitchy inputs don't make them spin. That’s why it’s overhead, they don’t use more
than 100% unless they have to, up to that 20% extra. The value is hardcoded to 1.2.

[PHYSICS_HINTS]
AERO_HINT=0.75 ; how much grip the car gains from aero with speed, so the AI can calculate high speed cornering speeds more accurately
without having to know everything about its aero loads.

[TYRES]
HINT=1.00 ; how much grip the ai will use

LITTLE EXPLANATION:
- AIs in Assetto Corsa don’t make any difference between the real player and another virtual opponent. So, learn how to flow with them.
- Tracks don't use ai.ini. Only cars do. And yes, it's still used. Tracks use ai_hints.ini to influence the AIs, on top of the behaviour already set by the config
file of the single vehicle (ai.ini).
- If you are planning to have a long race, start with a long qualification session and let the AI run and figure out what the real fuel consumption is. Otherwise
they won’t be calculated.
- Not all of these values are being used anymore, famously ULTRA_GRIP is now a hardcoded value, and the line in ai.ini will be ignored.
- To change some parameters of the script live, during a race session, you can use the Kunos AI app. Go to ccxxx for more info about it.
- The TRAIL_HINT works together with the BRAKE_HINT.
- The more the car is complex, the more is the difference between human and artificial intelligence.
- The AC logs are very helpful when trying to understand the behaviour of the opponents because they contain the AI's strategy decisions.

CSP ADDITIONS
CSP brings the New AI Behaviour. It introduces these features (more may be added later on):
• Cool down lap in offline races, for you to gradually get back to pits;
• In track day mode, creates seemingly endless traffic (brought to online servers too);
• Allows to drive wrong way in practice or track day.
• Now AIs (only with some cars) can use wet tyres when raining, and can drive quite well in wet conditions too with the new updates. The ai.ini doesn't manage this feature
though.

FAQ
QUESTION [1]: Have you ever had issues with cars just sitting on the grid after race start?
ANSWER [1]: If it's a track specific problem it means the grid spots are too close together. If it's the car then generally they’re transmission issues. Check
the FINAL gear ratio in drivetrain.ini. It can be also related to the new ai behaviour in CSP, try disabling that as well.
Switch to the AI cars during a replay session and check if they rev up but fail to switch to first gear. If that is the case, it's the ai.ini ‘s fault. You have to
manually adjust the UP and DOWN shifting RPM values. Lower the UP value to something below the engine limiter. The AI only shifts up when it reaches that
value and it can't if set too high.

352
CURIOSITIES AND AMENITIES
- Often the AI doesn't steer into me and they're utter cowards.
They heavily brake on the exit of corners while you're slotting back behind them after they've overtaken you (almost coming to a stop), brake when there's a
car in front instead of overtaking, etc.
I have to say the AI in some cases is not too retarded. It steers into you if you're not careful, but very often they try to brake or avoid you in order to avoid a
collision. So basically their pit-maneuver is mostly your fault, not following the ideal line. If you're getting constantly spun out by the AI then you might want
to either have a look at your settings or your driving style, you can't be too aggressive with the AI, much like real people you need to leave space for them.
Always stay close to the apex if you want to avoid these situations.
- It is a fact that in many situations the AI fails to account of the "space shrink" when speed decreases (ie. if there's space for 2 cars at 200 Km/h there might
be no space for the same 2 cars at 80 Km/h). Add the actual player to this and the situation gets even more difficult to analyse... the users complaining about
AI hitting them and then posting videos of themselves moving around the track as if nobody was there are innumerable in the almost 10 years AC has been
around.
- A fast driver can be frustrated by the AIs, because once you pass them on the outside of a corner, they sort of “give up”. The reason why they abandon the
overtake fight is that they know you are on the outside. Now, as humans, we can do a very complex reasoning:
“if I am on the inside of a corner, I have a better line compared to the guy on the outside and eventually I can get wider and go faster at the exit”.
The AI doesn’t know that. They think they have to take the entire corner on the inside. So they actually brake more. It’s annoying and immersion breaking, as
you immediately know what they’re going to do.
At the same time, “this sense of the AI not fighting is essential for people that are not really that good at driving, so even if you brake in stupid positions, the
virtual opponents need to be able to avoid you” (Stefano Casillo, 2015).
On a real track, if you hit the brakes at the wrong points, you would be taken aside and told that you’re a danger to others and yourself.
- The code for overtaking doesn’t really work for cars that are the same. They actually use more time that they gain doing that manoeuvre. But it works in
situations where you have a vehicle that is faster than another, for example two different classes of GT cars, so they don’t get stuck behind slower types.
- AIs don’t use the exact same physics as players, so the speed an AI can leave a corner is not identical to the player’s one. Very often you can't run the same
line as them since they're using 120% as much grip (to compensate for the jankyness of their trajectory) and you can win because their route is not very
optimal.
- In AC the artificial intelligence is very good when it’s about managing cars with lots of power, because it’s good at putting power down. With cars where you
have to keep the momentum and the flow, be very gentle on the pedals, generally speaking it is not as capable.
- The aggression slider is there to let AIs make moves that risk hitting the player if the player doesn't avoid it. So if you're in a class where "rubbing is
racing" like BTCC, you can move it above 0%. It is the biggest thing you can tweak to get decent AI races, as it impacts how close the cars will get to you
and to each other, which is why at times they will brake in strange ways if they enter a turn with a car in front of them, even if it's another AI car.
Too low on aggression and they brake early causing you to rear end them. Too high on aggression and they won't slow down when you brake ahead of
them and just slam into you. I notice that with low aggression, they never want to pass me even when I leave an opening. Too high aggression makes the AI
pretty much ignore you and just run you off the road even if you have the line. Now I don't mind this because it keeps me on my toes. Then you have to take
different mods into account. And in this paragraph I won't even go into how the track, AI lines, AI Hints, etc. factor into all of this. I'll simply close by saying
that of all racing sims, I still have more fun against the AI with AC than with any other.
- The AIs have always tyre blankets ON, even when they're disabled player-side.
- I've been looking for answers to the question "can AIs drift?".
Of course the answer is NO, at least with standard tires. There are ways that I've seen to render the opponents looser, by manipulating the ai.ini and tyres.ini
files to get slip and counter-steer with low-grip compounds.
You can edit the tires to obtain more slip angle for longitudinal and lateral forces, allowing for a slip raise in ai.ini, and using a different tire pressure
combination, low at the front and high at the rear. Try increasing the FRICTION_LIMIT_ANGLE of your tires (see tyres.ini, pag.) to something unrealistic
like 60 degrees 56. The maximum you can go to is <90°, after that the lateral slip angle becomes “longitudinal” and it ceases to make sense from a physical
point of view.
There aren't other settings to make this happen, unless you change the values to force it to happen, with trial and error.
- In early versions of AC, the AIs did not use the ABS assist, since they were faster without it. Nowadays? (do they use stability control?)
- The AI in Assetto Corsa is probably the best you can get without going to what is called a “generative” AI, a system that learns from its experience. Stefano
Casillo stated (2015) that he did experiment a little with this type of algorithm (which he calls the “expert” system) at the beginning of AC development. The
idea is that the AI has a history: in a single turn, it can divide the tracking in different sections and every time it passes one of them, analyses what happened
and can tell whether the driving is good or not, to self-adjust and generate values similar to the ones portrayed by ai.ini automatically.
The problems with this are (were, at time of AC development):
• The time needed to train to a good degree the AI of each car on each track.
• Every time you change any part of the algorithm, including the vehicle or road physics, all your data becomes invalid, as all the AI assumptions for any part of the track
become wrong. You’ll have to re-train from scratch every car.

- On the leaderboard you can see which tires the virtual opponents are using (Fig.).

56
A normal value would be around 10°.

353
3. ai_tyres.ini
You can find this config in the Ferrari 458 GT2, Ferrari 599XX EVO, BMW M3 GT2, Lotus Evora GX, Mercedes-Benz C9 LM and a lot of other Kunos official
cars. This script helps AIs with picking tires for the qualification session, comparing to the track’s length. It is not for AI pit strategy, as AIs do not change
tires when pitting.
[SS]
MAX_KM=20 ; maybe more info about this value

[S]
MAX_KM=80

[M]
MAX_KM=150

[H]
MAX_KM=300

4. ambient_shadows.ini
This .ini sets the dimension of the ambient shadows of your car. In Chapter 1 you can find info about them.
[SETTINGS]
WIDTH=1.0 ; width of the car’s ambient shadows
LENGTH=2.8 ; length of the car’s ambient shadows

354
5. analog_instruments.ini
This config file sets all the parameters related to the analogue car instruments on the cockpit: basically all the tachometers, gauges, needles and indicators.
Not all the lines of this file are required, depending on the vehicle, but here all the sections will be written down and explained. You can add or remove them
to your liking. We can say that this script is really modular from this point of view.
For all the headers below you can use the same lines of the first [RPM_INDICATOR] section (even though probably you don’t need them all, for example a
LUT is not always necessary). The common ones will be skipped. Eventual additional or differently-functioning lines will be present and explained.
[RPM_INDICATOR] ; The engine tachometer.
OBJECT_NAME=ARROW_RPM ; Name of the object (NULL/dummy) that represents the arrow.

% ▲ The corresponding NULL must be present in the vehicle model, otherwise the session will crash.

ZERO=-20.000 ; The starting position of the arrow. [deg]

% ▲ It is best to export the car model with the arrow object at 0° so you don't need to play with this number and just leave it at 0.

MIN_VALUE=0 ; Minimum threshold value. [RPM]

% ▲ For example if you set this to 10, the instrument should not show anything below 10 (input value).

STEP=0.5 ; Arrow movement angle/engine RPM ratio.

% ▲ Pretty simple, if you want that 1° represents 1 RPM you leave this value at 1, if you want 10 RPM to be 1° then it should be 0.1, etc. For clockwise
movement, it has to be a positive value, for counter clockwise, it has to be negative.

OBJECT_NAME_MAX= ; Name of the telltale object for the main arrow.

LUT=(0=0|1000=10|2000=26|3000=42|4000=71|5000=102|6000=132|7000=163|8000=194|9000=224|10000=254)

% ▲ Look-up-table, left side is value (RPM), right side is degrees of movement. Good for asymmetric tachometer gauges.

[SPEED_INDICATOR] ; The speedometer.

OBJECT_NAME=ARROW_SPEED
STEP=1.398333 ; Arrow movement angle/vehicle speed ratio.

% ▲ If you want that 1° represents 1 speed unit (1 km/h or 1 mph) you leave this value at 1, if you want 10 km/h to be 1° then it should be 0.1, etc. For
clockwise movement, it has to be a positive value, for counter clockwise, it has to be negative.

% ▲ The speed indicator can also use an external LUT file instead of the internal one.

[FUEL_INDICATOR] ; The fuel needle.

OBJECT_NAME=ARROW_FUEL
STEP=1.307692 ; Arrow movement angle/litres of fuel ratio.

% ▲ If you want that 1° represents 1 litre of fuel you leave this value at 1, if you want 10 litres to be 1° then it should be 0.1, etc. For clockwise
movement, it has to be a positive value, for counter clockwise, it has to be negative.

LUT=(0=0|20=30|40=60)

% ▲ Look-up-table, left side is amount of fuel in litres, right side is degrees of movement. Good for asymmetric fuel gauge.

[TURBO_INDICATOR] ; The turbo needle. If more than one, SYNTAX: [TURBO_INDICATOR_ID], ID starting from zero.
OBJECT_NAME=ARROW_TURBO
USE_BAR=0 ; Changes gauge pressure units. Instead of [psi], use [BAR] (=1 for true, =0 for false).

[LIMITER_INDICATOR] ; Engine RPM limiter.

[same as above]

% ▲ The RPM limiter is hard coded, and if the 3D object is named ARROW_LIMITER, this code is not needed. The RPM limiter arrow should be an identical
copy of RPM arrow, with the dummy at same place and same orientation, in order to function properly.

[WATER_TEMP] ; The water temperature needle.

OBJECT_NAME=ARROW_WATER_TEMP
ZERO=0
STEP=-0.49
MIN_VALUE=0
LUT=(1=0.02|75=-36.500|150=-73.500)

% ▲ Look-up-table, left side is temperature in Celsius [°C], right side is degrees of movement. Good for asymmetric water temperature gauges.

[FUEL_WARNING_0]
OBJECT_NAME=FUEL_WARNING_0
FUEL_SWITCH=3

[PLACE_HOLDER_0] ; Generic placeholder gauge. SYNTAX: [PLACE_HOLDER_ID], ID starting from zero.

OBJECT_NAME=ARROW_OIL_TEMP

[PLACE_HOLDER_1]
OBJECT_NAME=ARROW_OILPRESSURE

LITTLE EXPLANATION
- Vanilla AC supports these types of instruments by default:

• Tachometer (RPM)
• Telltale tachometer
• Speedometer (km/h or miles/h)
• Fuel level indicator
• Turbocharger pressure manometer (psi or bar)
• Water temperature

Other instruments are called placeholders in the analog_instruments.ini script, as there are no existing inputs to make them work. CSP brings more options
from this point of view.

- LUTs are not mandatory in order for analog_instruments.ini to work, but when they are used inside said script, the STEP and MIN_VALUE lines of the
specific section are ignored. They can be in-line, but if you have many values it is recommended to specify a separate file.

- The [LIMITER_INDICATOR] section is for the telltale tachometer. It is a tachometer that has a second (usually red) arrow that shows the highest
amount of revs reached (Fig.).

355
Fig. - This one is a Smiths Chronometric tachometer, model number and vintage so far unknown. It is installed in an MGA Twin Cam car along with all of the other standard Jaeger
instruments. Chronometric instruments were always cable driven. It was also common to rotate the instrument in the dash to position the intended red line straight up at top of the dial
face where it is easy to see out of corner of your eye without a direct glance.

It was often used in competition cars. The needle could be set somewhere in the vicinity of the intended red line for the engine. If this engine speed was
exceeded the white tach needle would push the red needle higher, and the red needle would stay there giving indication of the highest engine speed.

RELATED FILES
LUTs:
analog_speed_curve.lut
This is a separate look-up-table table for the speedometer, but it is rarely used. It comes in handy when it’s difficult to obtain a precise reading based on the
ZERO and STEP values alone.

You input the filename in the LUT field of the [SPEED_INDICATOR] section. The file itself looks like a typical LUT, nothing more and nothing less:
0|0
100|45
200|90

On the left side is speed in [km/h], on the right side is the angle of movement of the needle in degrees; regarding STEP and MIN_VALUE, they are
ignored when this LUT is used.

To set up this table properly, the best method is to check in your 3D editor of choice the various angles that the needle generates with respect to the zero
position 57. First, note on a piece of paper the angle of the minimum value which shall be registered (usually corresponding to the zero), see Fig.

Fig. - The angle of the minimum value is -29.3° (rotation along the y-axis). The minus depends on the reference system adopted by your editor; in this example, Blender.

57
I am assuming that you have set up your ARROW_# dummies correctly (see pag.).

356
Second, write down also all the angles of the other positions which you want to include (Fig.). I will proceed with steps of ten units here: one can use less,
or more, depending on how accurate you want the needle to be. But do not cover every single notch, it’s not worth it.

Fig. – Several notches later… the entire range is covered.

At the end it is necessary to subtract the degrees of the needle at the “zero” position from all the angles you note down. In the example I had these values:

0 km/h – 29.3°, 10 km/h – 37°, 20 km/h - 44.4°, 30 km/h - 59.6°, 40 km/h – 75°, 50 km/h – 89.8°, 60 km/h – 105° and so on till 200 km/h, so I have to
remove 29.3° from all the angles (zero included). The final result is the following analog_speed_curve.lut:
0|0
10|7.7
20|15.1
30|30.3
40|45.7
50|60.5
60|75.7

…plus the other values that I won’t list here for matters of length. It’s a tedious process, but the instrument will be very precise.

CSP ADDITIONS
- The mod brings an entirely new set of instruments to the simulator, all set from the ext_config.ini file (pag.). Unlike vanilla, the system is completely
flexible and allows a needle to visualize almost any kind of information, being linked to a new INPUTs system, very similar to what dynamic controllers use.
You can look at p. for a complete list. In any case, regarding analog dials, summarized below are the most important instruments added:

• Clock
• Battery voltage
• Oil pressure
• Oil temperature
• Ambient (air) temperature

(more details in the future)

- Working analog and digital trip odometers are a feature available with CSP.

FAQ
QUESTION [1]: Having a HUD visible on screen I've noticed that the speedometer is around 50 km/h out at high speed. So while 150+ km/h are displayed
on the HUD, the instrument in the cockpit is showing around 200 km/h. How do I set up the analog_instruments.ini to make it more accurate?
ANSWER [1]: Change the STEP line under [SPEED_INDICATOR] until the needle moves correctly. It should be in degrees/unit, so degree/rpm and
degree/kph.

QUESTION [2]: No matter how much I try, the needle won’t measure right; it is correct on certain numbers while on others it is not, and the STEP parameter
doesn’t fix the problem entirely.
ANSWER [2]: When the needle is not precise on the whole measurement range, a LUT can be employed. Let’s make an example; if you read the RELATED
FILES paragraph, you will know that typically the look-up-table for the speedometer is called analog_speed_curve.lut. Obviously the name can be changed
to your liking, but it’s important to realize that different instruments can adopt the same principle. Just add a LUT line in the respective section and configure
it properly (the input values will always be the units measured by the instrument, the outputs will be the angle travelled by the needle).

357
6. blurred_objects.ini
The visuals of wheels spinning at high speed are artificially recreated swapping the fully detailed rim meshes (RIM_LF) with other ones less detailed, that
have a lower polygon count and blurred textures (RIM_BLUR_LF); the switch happens depending on different car speeds.
The following script controls at what velocities of the car an object will appear or disappear.
[OBJECT_0] ; Object identifier; SYNTAX: [OBJECT_ID].
WHEEL_INDEX=0 ; Indexes of the wheels as defined below.

% ▲ AVAILABLE WHEEL INDEXES:

0 = LEFT FRONT
1 = RIGHT FRONT
2 = LEFT REAR
3 = RIGHT REAR

NAME=RIM_LF ; Name of the mesh/object, or of the parent NULL/dummy (look at null hierarchy).
MIN_SPEED=0 ; Minimum speed the object is visible at. [Km/h]
MAX_SPEED=40 ; Maximum speed the object is visible at. [Km/h]

[OBJECT_1]
WHEEL_INDEX=0
NAME=RIM_BLUR_LF
MIN_SPEED=30
MAX_SPEED=10000

% ▲ You’ll never be able to go this fast, so this value is high to keep the blurred rims active at “normal” speeds. If you add more of them, you’ll have
to lower this number for the meshes that should be visible at rotational regimes between your RIM and the RIM_BLUR with the most blurred texture.

[OBJECT_2]
WHEEL_INDEX=1
NAME=RIM_RF
MIN_SPEED=0
MAX_SPEED=40

[OBJECT_3]
WHEEL_INDEX=1
NAME=RIM_BLUR_RF
MIN_SPEED=30
MAX_SPEED=10000

[OBJECT_4]
WHEEL_INDEX=2
NAME=RIM_LR
MIN_SPEED=0
MAX_SPEED=40

[OBJECT_5]
WHEEL_INDEX=2
NAME=RIM_BLUR_LR
MIN_SPEED=30
MAX_SPEED=10000

[OBJECT_6]
WHEEL_INDEX=3
NAME=RIM_RR
MIN_SPEED=0
MAX_SPEED=40

[OBJECT_7]
WHEEL_INDEX=3
NAME=RIM_BLUR_RR
MIN_SPEED=30
MAX_SPEED=10000

LITTLE EXPLANATION
- You can use more than one RIM_BLUR mesh per wheel, so you’ll have smoother transitions, for example with 2 or 3 objects. There’s a lot of space for
implementations. There should be no limit in the number of objects you can put here, so have fun! Be careful with the speeds at which each model transitions
into another, those give you some span for the smoothest result, and keep in mind that the script is just for cosmetic purpose, it doesn’t affect physics.
- You can even enter the names of objects completely different from rims, in order to make them appear/disappear whenever you like. This is what I call
moddability!
- Here is an example of what a blurred rim is made of: a basic mesh with a texture (Fig.).

Fig. – (left) The original wire-spoked rim and the blurred rim mesh with texture applied (no transparency displayed here). Notice how the hub cap was not included in this example. (right)
The car of this example is an open wheeler, thus it is necessary to create four meshes: two for either side, and one of each side with normals flipped in order to make the rows of spokes
visible from both sides of the wheel (this is due to backface culling).

Typically for a blurred rim mesh is necessary to make a simple hollow cone, for special designs and for wheels with hub caps however it may be necessary
to create a more complex geometry; in the example of Fig. the cap was not included due to personal choices (I manage the cap with a different blurred object).

358
The textures can be made very simply by rendering the rim with a light shone directly in front of it, with a transparent background (Fig.). Save the render as
RGBA image to preserve the alpha channel (transparency).

Fig. – Render the rim with Cycles if you use Blender. It doesn’t really matter how bright is the light, as the diffuse can be adjusted in ksEditor later. What’s important is the angle, that
must be perpendicular to the rim circumference plane. Notice how only half of the wires are present, and a huge chunk of the center hub is hidden; that’s because of the technique to
avoid backface culling for open wheelers. You don’t want to double the amount of wires you see in the final result.

Then you take the render, modify it with an image editor like Photoshop make the texture semi-transparent (reduce opacity to 70-80% on the Layers tab) and
add a Spin Blur effect to the rim. That will do the trick.
If you want something more advanced, you can enable the Motion Blur in the Blender Render settings and create a fast rotation animation: the frames will
already portray a blurred wheel. It should be more accurate than the Spin Blur, as you can tune with the timeline how many rotations per second you want the
rim to make, so you can calculate and set the correct switch speed within blurred_objects.ini (thus obtaining optically based effects). It will be much more
accurate, as within Photoshop you can specify any Spin Blur rotation angle without any criteria, while this takes advantage of the Cycles render engine.
Alternatively, you can mix both techniques, like I did in Fig..

Fig. – The first texture on the left was made with Blender’s motion blur and chroma key; the second and third texture are the result of the Spin Blur in Photoshop.

For the shading, in ksEditor you can use the ksPerPixelAlpha shader or another shader with transparency capability; within the SDK editor it’s important to set
the BlendMode parameter to eAlphaBlend, otherwise you will have some trouble with eAlphaTest selected by default.

359
CURIOSITIES AND AMENITIES
There are a couple theories about rim blur:
The first one suggests to avoid it. The main arguments in favour of this philosophy are the following:
1. Blur exists because in old games the frame rate was too low to have the wheels appear rolling smoothly, or even calculating the mesh rotation was too much for the
hardware. Ten years ago a nicely detailed wheel could be modelled, but having to compute all those polygons moving together was too expensive in terms of resources.
2. Screenshots aren’t rendered in real-time and any amount of post-processing can be applied. Rim blur saves sometimes a lot of polygons, especially when activated over
high poly wheels, but it doesn’t improve the graphics, as you are looking through a virtual camera, so the 'walking' or ‘stepping’ effect you see is exactly what you would
see in a real replay. Then it is more like another LOD (info about LODs) that lessens the strain on our device, so you can ignore it completely if your rims are simple.
3. It's added complexity, adding it means you need to make sure that blurred_objects.ini is correct, make sure all the materials/textures/shaders are set right and then edit the
textures in Photoshop with radial blur. Deleting everything to do with them takes 1-2 minutes, making sure everything works with them, probably about 5-10 minutes.
Removing rim blur means 4 less objects. If you want to paint rims, adopting blur objects you would need to paint both the RIM and the blur or make a new blur texture
which implies mapping the rim. In vanilla AC the rim blur also keeps being visible if you're in photo mode and set shutter speed to zero, making the car look still but with
blurred rims.
4. Often the transition between blurred/non-blurred state is jarring even at a distance in replays. This is of course subjective and related to specific cars.
The second one suggests to make it. This is why:
1. If Kunos added it, follow their standard. Keep things as simple as possible including everything. It may seem a paradox, but if you do things right from the beginning, other
people won’t have to edit your mod afterwards to fix its missing or incorrect parts, so you should worry about it, especially if you don’t want your creations to be modified.
You will notice how well-made mods are often those with the smallest number of edited versions made by people unrelated to the original author.
2. When you do have high poly rims, very performance expensive, you must create a nice lower poly rim and use blurred_objects.ini to define when to switch it in.
3. Nowadays we get so much performance from the hardware that choosing between adding blur or not based on this aspect is just a waste of time, unless you consider
players with less powerful machines. Not everyone can afford high-end PCs.
4. You may want to see the blur during the race because you like the effect, which is realistic from the point of view of the human eye, not from the cameras’ perspective.
After all, if a user doesn’t like it, he can always disable it, changing the values in blurred_objects.ini (if the data is/can be unpacked).
5. Rim blur can help with the immersion and reduce eye strain and motion sickness (especially when considering PP filters, but that is another story).
6. Even if you enable Nice Screenshots and the Photo Mode app in the CSP mod settings, the rims will be blurred correctly only in screenshots, look at the example of Fig.
4.7. Photo mode is accumulative, so it renders frames across a small window of time based on shutter speed, and averages the result. However if you don’t add the vanilla
RIM_BLUR to your car mod, you won’t have the effect during the race or replays.
My conclusion? Do create a good rim blur, especially if you have high-poly wheels. Keep in mind that in cockpit view you’ll never see it again, but you can
at least flex you made it and be satisfied of the result when looking at the vehicle from exterior cameras. The first theory is just an excuse for lazy people. It
takes very little effort to create simple geometries and textures. See the examples of the previous page.

Fig. 4.7 – The result with 1/125 set as shutter speed in the Photo Mode app during replay. You can definitely see the rims have been blurred, even if this car mod has no RIM_BLUR
models (note that the speed is 105 kmh).

360
7. brakes.ini
Without this short config file, your car won’t brake at all (or the game will crash). You can also define the brake disk glow behaviour here.
[HEADER]
VERSION=1 ;

% ▲ VERSION=2 enables temperatures for brakes (with cphys? undocumented)

[DATA]
MAX_TORQUE=1400 ; Maximum brake torque. [Nm]

% ▲ 100% brake pedal input will give you this torque value. This is the resistance made by the brakes on the axle. So it's not really like a real brake
pedal.

FRONT_SHARE=0.66 ; Percentage of brake torque at front axis.

% ▲ This is the default value for the brake bias. It’s the one you can find in setup screens, if the bias adjustment is available.

HANDBRAKE_TORQUE=1000 ; Handbrake torque (at the rear wheels); 0= no handbrake. [Nm]

COCKPIT_ADJUSTABLE=1 ; 0= no bias control from cockpit, 1= bias control from cockpit.
ADJUST_STEP=0.5 ; Step for bias adjustment from the cockpit (how much each click/button push changes the bias).

[DISCS_GRAPHICS] ; Lines for the brake disc glow at high temperatures.

% ▲ The brake disk glow works only if you applied the ksBrakeDisc shader to your disc meshes (this implies also the textures for disc glow). See par.

DISC_LF=g_Disk_LF ; Specifies the left front disc mesh that will glow.
DISC_RF=g_Disk_RF ; “ “ right front disc mesh “ “ “ .
DISC_LR=g_Disk_LR ; “ “ left rear disc mesh “ “ “ .
DISC_RR=g_Disk_RR ; “ “ right rear disc mesh “ “ “ .
FRONT_MAX_GLOW=60.0 ; Max emission value the front brakes will have at full heat.
REAR_MAX_GLOW=24.0 ; Max emission value the rear brakes “ “ “ “ “ .
LAG_HOT=0.995 ; Amount of filtering interpolation lag used while making the brakes brighten.

% ▲ Refers to the difference in time between when the disc is normal and when it reaches glowing temperature while braking.

LAG_COOL=0.98 ; Amount of filtering interpolation lag used while spinning up the turbo

% ▲ Refers to the difference in time between when the disc is glowing and when it goes back to normal after releasing the brakes.

LITTLE EXPLANATION
- The temperature behaviour of brakes in vanilla is quite lacking.

ABOUT RELATED FILES

Controllers:
ctrl_ebb.ini
This script allows the controllers to change the brake bias.
[CONTROLLER_0]
INPUT=BRAKE
COMBINATOR=ADD
LUT=prop_valve_r32_brembo.lut
FILTER=0.98
UP_LIMIT=1
DOWN_LIMIT=0.0

FROM ALFA ROMEO GIULIA

[CONTROLLER_0]
INPUT=LOAD_SPREAD_LF ; OVERSTEER_FACTOR REAR_SPEED_RATIO SLIPANGLE_FRONT_AVERAGE SLIPANGLE_FRONT_MAX SLIPANGLE_REAR_AVERAGE SLIPANGLE_REAR_MAX
COMBINATOR=ADD
LUT=(|0.3=0.67|0.4=0.66|0.5=0.65|0.6=0.66|0.7=0.67|)
FILTER=0.01
UP_LIMIT=1
DOWN_LIMIT=0.0

[CONTROLLER_1]
INPUT=SLIPANGLE_REAR_MAX ; OVERSTEER_FACTOR REAR_SPEED_RATIO SLIPANGLE_FRONT_AVERAGE SLIPANGLE_FRONT_MAX SLIPANGLE_REAR_AVERAGE SLIPANGLE_REAR_MAX
COMBINATOR=MULT
LUT=(|0=1|3.0=1|8.7=1.05|)
FILTER=0.95
UP_LIMIT=1.2
DOWN_LIMIT=0.0

[CONTROLLER_2]
INPUT=BRAKE ; OVERSTEER_FACTOR REAR_SPEED_RATIO SLIPANGLE_FRONT_AVERAGE SLIPANGLE_FRONT_MAX SLIPANGLE_REAR_AVERAGE SLIPANGLE_REAR_MAX
COMBINATOR=MULT
LUT=(|0=1|0.1=1.09|1=0.967|)
FILTER=0.95
UP_LIMIT=1.2
DOWN_LIMIT=0.0

steer_brake_controller.ini
This config is used on some Kunos McLaren roadcars only. The script can apply braking to one wheel and is an override for EDL (Electronic Differential
Lock).
It applies rear brake on one side. It’s similar to the F1 fiddle brake but with a controller instead of a manually operated pedal. It is a form of torque vectoring.
The McLaren P1 uses it in real life.
Don't feature it if you plan to use it as an LSD (Limited-slip Differential). Also, this functionality is broken, as it applies braking only to the RR wheel, on both
left and right turns; apparently it’s never applied on LR.
[CONTROLLER_0]
INPUT=STEER_DEG
COMBINATOR=ADD
FILTER=0
UP_LIMIT=1
DOWN_LIMIT=-1
LUT=(-170=-1|-20=0|20=0|170=1)

361
[CONTROLLER_1]
INPUT=SPEED_KMH
COMBINATOR=MULT
FILTER=0
UP_LIMIT=1
DOWN_LIMIT=-1
LUT=(100=0.1|150=0.2|200=0.5)

[CONTROLLER_2]
INPUT=CONST
COMBINATOR=MULT
FILTER=0
UP_LIMIT=100
DOWN_LIMIT=-100
CONST_VALUE=100

CSP ADDITIONS
Custom Shaders Patch adds a new thermal model for brakes, with an object based brake-torque system which requires more configuration and
supplementary lines of code in brakes.ini.

CURIOSITIES AND AMENITIES

Of the dozens of technologies banned by F1’s governing body through the years, McLaren’s rear brake pedal stands out as one of the most unjust.
It was banned early in 1998 as McLaren made a stunningly dominant start to the year. Following a protest by Ferrari the system, that had previously been declared legal, was
outlawed.

Foot operated clutches have been a thing of the past in Formula 1 for many years, so a
drivers footwell typically only features an accelerator and brake. But in the footwell of
Hakkinen’s McLaren F1 car was three pedals; the ‘steer-brake’, the normal brake pedal and
the throttle. The steer-brake pedal was quite stiff and the driver would have to press quite
hard on it to use it. This way, pilots wouldn’t have to worry about tapping it and spinning
out.
The steer-brake pedal operated one rear brake on one side of the car. The side of the car
that it operated changed depending on the race and was decided on a track basis. The
main deciding factor was long high-speed corners in which drivers would normally
experience a high amount of understeer. So if McLaren were set to race on a circuit with a
few tricky righthand turns, the engineers would set up the cars to have the brake-steer
pedal to operate the rear right brake.

“As you applied the brake mid-corner it would brake one of the rear wheels, and as you
didn’t want to slow the car down, you’d open the throttle to compensate.”
“So it was a combination of pressing on two pedals at the same time. In doing that you’re
putting more torque through the outside rear wheel and less through the inside, and that Fig. h - The three pedals–from left to right, fiddle-brake, regular brake, and
puts a yaw moment on the car to steer the car around the corner.” accelerator–of the #8 West McLaren Mercedes MP4/12 F1 car

Not only did the innovation help correct understeer, but it also improved cornering
aerodynamics as the front wheels would be straighter and drivers didn’t have to carry as much front wing on corner entry, making the car more stable.

The pedal allowed the drivers to operate either of the rear brakes independently of the others. This gave them two additional means of controlling the car and improving the
performance – by reducing either understeer or wheelspin depending on which wheel was braked and when.

McLaren continued with the system in 1998 by which time they had leapt from front-of-midfielders to runaway championship leaders. Now their immediate rivals – chiefly
Ferrari – protested the rear brake pedal on the grounds that it was primarily a steering system.
Although the system had previously been passed fit to race by Charlie Whiting the stewards at the Brazilian Grand Prix – the second round of 1998 – ruled against the rear
brake pedal. It was unsavoury to see a perfectly valid system banned on such a dubious technicality when it had been declared legal on other previous occasions. But it was
not the first nor the last time that it happened. It did not stop McLaren from running away with the Brazilian Grand Prix – or from winning both championships that year.

FAQ
QUESTION [1]: Which parameter of which file should I open and modify to increase the braking of a car?
ANSWER [1]: You can increase the MAX_TORQUE in brakes.ini But the braking force is still limited to tire friction. So if you increase it too much you will start
losing grip very easily when braking.

Q [2]: I'm trying to mess with some car values to add ABS to a car that does not originally have ABS. Does anyone know how I can do that? I looked in
brakes.ini but don't really see anything related to ABS.
A [2]: ABS is not under brakes.ini, it’s managed in electronics.ini.

PHYSICS (for brakes.ini)

sdgasghsd

362
8. cameras.ini
This config sets the positions of cameras for the extra views that are activated pressing the F6 key. Imagine each camera represented by a heading
vector. You can easily modify the values in-game using the camera app. More info about it in chapter 6. About the origin of the axis
[CAMERA_0]
POSITION=0,0.92819,-0.34668
FORWARD=0,-0.38871,0.92129
UP=0,0.92135,0.38872
FOV=60 ; Field of View (FOV) of the camera.
EXPOSURE=41
EXTERNAL_SOUND=1 ; select between 0 (off) and 1 (on) to choose between internal and external sound

[CAMERA_1]
POSITION=0.53088,0.51102,-0.065308
FORWARD=0.021429,-0.34203,0.93945
UP=0.0039044,0.93968,0.34203
FOV=60
EXPOSURE=36
EXTERNAL_SOUND=1

[CAMERA_2]
POSITION=-0.2511,0.7385,-0.18799
FORWARD=0.21679,-0.39312,0.89357
UP=0.075636,0.91935,0.38611
FOV=60
EXPOSURE=31
EXTERNAL_SOUND=1

[CAMERA_3]
POSITION=-0.011475,0.68746,0.28223
FORWARD=0.00081515,-0.06956,0.99758
UP=-0.0010552,0.99758,0.06956
FOV=60
EXPOSURE=47
EXTERNAL_SOUND=1

[CAMERA_4]
POSITION=0.51489,0.62795,0.36731
FORWARD=-0.78566,-0.042336,-0.61722
UP=-0.078064,0.99647,0.031015
FOV=70
EXPOSURE=46
EXTERNAL_SOUND=1

[CAMERA_5]
POSITION=0,1.0151,-0.53455
FORWARD=0,-0.36649,-0.9299
UP=0,0.92998,-0.36715
FOV=60
EXPOSURE=26
EXTERNAL_SOUND=1

You can see the standard point of view (official reference positions) for each camera in Fig.. You don’t need to follow an exact order, because the player can
cycle very easily between them. Just be faithful to the standard in the AC content made by Kunos.

Fig. – Here you can see the most important points of view (in no particular order): 1. Top left, the perspective recreates the typical view from F1 footages, when you see the
head of the pilot. In stock cars this camera is located on the roof, slightly looking at the hood. 2. Top right, the wheel view. You can adjust it however you like, just keep the
road ahead widely visible on screen. I have fun trying to drive in this position. Plus on open wheelers it’s nice to see the suspension move. 3. Bottom left, the cockpit cam.
This is aimed at the interior of the car, slightly tilted towards the steering wheel on single-seaters. On two-seater cars, you can place it exactly between the seats, framing the
whole dashboard and the steering wheel. 4. Bottom right, you have the hood cam. It’s very simple to understand.

363
Fig. – These cameras are less important, but let’s take a look at them: 1. On the left you have the pilot’s cam. On single-seaters, it’s located outside the vehicle. On two-
seaters, it’s placed on the dash, looking at the driver and the steering wheel. 2. On the right you have a rear camera. With open-wheelers it’s on the rear wheels, which one
depends on where the exhaust is, to be able to see the flames and bits of suspensions. On stock cars (sedans, coupés, etc.), you shall put it on the trunk of the vehicle,
slightly showing the rear end of the car.

364
9. car.ini
This is a crucial config for the vehicle, because it is general-purpose: it regulates the fundamental parameters for physics and specifies the game UI info.
You can also change the positions of the main vehicle cameras (the ones activated with the F1 key), under the [GRAPHICS] section.
[HEADER]
VERSION=2 ; SYNTAX: [VERSION=1; 2]. Version of the car that AC loads.

% ▲ It does not represent the development version of the car, but how the AC engine will deal with its physics instead. Acceptable inputs are 1 or 2,
with VERSION=1 as the old (first) AC car.ini; VERSION=2 is preferred and recommended, as it introduces various features, for example it adds SHORT_NAME.

[INFO]
SCREEN_NAME=Formula Example 2022 ; Name of the car in UIs, on info apps and to identify it on servers.

% ▲ Upper and lowercase characters may be used alongside numbers; special characters may be limited.

SHORT_NAME=FE 22 ; Abbreviated label used to the name the car in the race session leaderboards. Available if VERSION=2.

[BASIC]
GRAPHICS_OFFSET=0,-0.370,-0.208646 ; 3D axis correction (x,y,z) to move the visual body polygon model in relation to the wheels. [meters]

% ▲ The body is referenced to the center of gravity, or “CG” of the car. This value must be adjusted every time a change to the CG is made.

GRAPHICS_PITCH_ROTATION=0.0 ; Changes the pitch of the visual vehicle body. Values >0 bring the front closer to the ground. [deg]
TOTALMASS=1075 ; Total mass of vehicle with driver, but WITHOUT FUEL. Other types of fluids must be included. [kg]

% ▲ The weight of the driver has to be considered equal to 75 kilograms, no more and no less.

INERTIA=1.0,0.8,2.80 ; Dimensions of a box with same moments of inertia (x,y,z) of the vehicle sprung mass. [m]

% ▲ A solver to solve for sprung inertia from total car inertia is available in the attachments of the manual. Typical values are smaller than the
physical constraints of the vehicle.

[EXPLICIT_INERTIA] ; Optional section, introduced with AC 1.15.

INERTIA=1300,1400,500 ; Enables direct input of inertia values and overrides the box inertia parameter.

[GRAPHICS]
DRIVEREYES=0.484284,0.81469,0.165061 ; 3d axis placement (x,y,z) of driver eyes (POV). [m]
ONBOARD_EXPOSURE=28 ; Onboard camera exposure for HDR.
OUTBOARD_EXPOSURE=31 ; Outboard camera exposure for HDR.
ON_BOARD_PITCH_ANGLE=-9.583473 ; Onboard driver eyes pitch angle relative to the horizon. [deg]
MIRROR_POSITION=0.0,0.6,0.5 ; Position used for the rendered mirror views.
VIRTUAL_MIRROR_ENABLED=0 ; Sets the virtual mirror to permanently enabled (=1) or disabled (=0). check
SHAKE_MUL=2 ; Camera onboard G forces multiplier
USE_ANIMATED_SUSPENSIONS=0 ; Use animated suspensions (1) or not (0). Animated suspensions will not be updated in real time from
setup changes.
FUEL_LIGHT_MIN_LITERS=12 ; Minimum fuel load to activate the Fuel indicator icon

% ▼ With the next few parameters you can set the positions of the main vehicle cameras.

BUMPER_CAMERA_POS=0.010,-0.239,0.910 ; Bumper camera position. [m]

BUMPER_CAMERA_PITCH=-2.990 ; Bumper camera pitch angle. [deg]
BONNET_CAMERA_PITCH=-14.998 ; Bonnet camera pitch angle. [deg]
BONNET_CAMERA_POS=0.000,0.940,-0.330 ; Bonnet camera position. [m]
CHASE_CAMERA_PITCH=0 ; Chase camera pitch angle. [deg]

[CONTROLS]
FFMULT=4.444 ; Force Feedback power multiplier.

% ▲ Controls the car-specific gain for the Force Feedback, 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=1.000 ; Variable steer assist, speed relative.

% ▲ It’s a gamma function for load-based effects of FFB. It does NOT determine power steering or anything similar. Values other than 1.0 should generally
be avoided. The default setting is 1.0, or linear.

% Think of it like a gamma curve for steering force. Lower values amplify low forces (I think at 0 it just means constant force steering). Only deviate
from a value of 1 if you know your steering system isn’t linear.

STEER_LOCK=440 ; Real car's steer lock from center to right. [deg]

% ▲ Controls the in-cockpit steering wheel rotation of the car physics. It must be input in as the real-world value. It’s not required that it matches
the user’s simulation peripheral wheel maximum rotation. The input is from center to one side, so divide the total range by 2 to solve for STEER_LOCK.

STEER_RATIO=12.0 ; Effective steering ratio of the vehicle, used in solving the roadwheel’s steering angle.

% ▲ The real-world rack’s value should be entered if unsure.

LINEAR_STEER_ROD_RATIO=0.0038 ; Because of AC complex suspension geometry, you need to calculate manually this value.

% ▲ This line is used to calculate the roadwheel’s steering angle. Change the sign of the value (from positive to negative or vice versa) 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. See the LITTLE EXPLANATION section for more details on how to determine this parameter.

[FUEL]
CONSUMPTION=0.025 ; Fuel consumption in litres per second, expressed as a function of (rpm*gas*CONSUMPTION)/1000. [L/s]

% ▲ If you don’t have data, you can estimate the fuel consumption. Good sources are the race leaderboards. Read the LITTLE EXPLANATION and FAQ sections
for more info.

FUEL=50 ; The amount of fuel the car loads in game with at the beginning of every session. [L]
MAX_FUEL=100 ; Fuel tank capacity. [L]

[FUEL_EXT] ; Vanilla section.

KG_PER_LITER=0.87 ; Option for different fuel density, introduced with AC 1.14. [kg/dm^3]

[FUELTANK]
POSITION=0,0.12,-1.72 ; Position of fuel mass (tank) from CoG (Center of Gravity). [m]

[RIDE]
PICKUP_FRONT_HEIGHT=0.00 ; Height of the front ride height pickup point. [m]
PICKUP_REAR_HEIGHT=0.00 ; Height of the rear ride height pickup point; same as the front. [m]

% ▲ These lines act as reference point for the ride height values shown inside the setup screens. They are also used for the ride height rules. They’re
referenced from CG. They do NOT control anything related to the physics.

The values are positive upwards, and set the height at which the ride height is measured for the rule compliance. Measured from the centre of gravity at
that end of the car. So the height above the ground would be RADIUS + BASEY + PICKUP_FRONT_HEIGHT.

[RULES] ; Setup height rules.

MIN_HEIGHT=0.010 ; Minimum front/rear allowed setup ride height, determined by the lines under [RIDE]. [m]

% ▲ If your setup of the car goes under the minimum height, the Drive button will be disabled after a short 5-second check. You can also set this to 0.0
for no ruling.

365
% Including the MIN_HEIGHT line in your script is not recommended due to some issues with the ground plane calculation.

[PIT_STOP] ; Pit stop timing parameters.

TYRE_CHANGE_TIME_SEC=2 ; Time spent to change all tires. [s]
FUEL_LITER_TIME_SEC=0.05 ; Time spent to pour/pump 1 litre of fuel in the fuel tank. [s]
BODY_REPAIR_TIME_SEC=1 ; Time spent to repair 10% of the body damage. [s]
ENGINE_REPAIR_TIME_SEC=1 ; Time spent to repair 10% of the engine damage. [s]
SUSP_REPAIR_TIME_SEC=1 ; Time spent to repair 10% of the suspension damage. [s]

LITTLE EXPLANATION
- car.ini shall be the first config you work on. It’s the fundamental one, so you better start from it.

- Since you may be at the beginning and that is a delicate phase, we will write this here so you can’t forget. Don’t use the graphical offsets in
suspensions.ini, set those to 0. Use the offset in car.ini which moves the 3D model relative to the centre of gravity. If the suspensions aren’t located
correctly, it most likely means you placed the SUSP dummies the wrong way.

- The moments of inertia (MOI) of a car influence its cornering behaviour, depending on the engine's position. Not only that. They affect the oscillation of the
entire vehicle, thus the suspension system, and the aerodynamics as a consequence. The bigger is the moment of inertia of a body, the more “resistance” it
will put to any change of direction. We could say that it will require more energy to make it move or rotate and to make it stop. So we can state that everything
regarding the handling is deeply rooted in these physical quantities, which can truly make the difference AT THE FOUNDATION.
How are the MOIs represented in AC then?
CoG and inertia are modeled correctly in AC. The CG position is actually fixed at the 0,0,0 coordinates of the car, you move everything else relative to that.
More info about it can be found in the suspensions.ini config file explanations.
The inertia instead is not calculated by taking the weight and position of every single car part. The actual values are calculated for the sprung masses (i.e., the
whole car body, without the wheels and other suspended parts located at the hubs, often called unsprung masses altogether), based on the dimensions a
solid box of uniform density 58. The dimensions of that box are the (x, y, z) components which you input in the INERTIA line.
The sprung mass is calculated by AC from the TOTALMASS line, subtracting the hub (unsprung) masses specified in suspensions.ini. Unsprung masses
generate their own inertia separately.
Pro tip: with the STRUT suspension type in suspensions.ini, the calculations for unsprung masses are handled differently by AC, you should keep that in mind.

When AC pairing the INERTIA with the sprung mass (body), the result is a massive driveable virtual brick, not a car as we're used to know. It is similar to
the model in Fig..

Fig. – An elegant Alfa Romeo design prototype car along with a box portraying the sprung mass inertia. The respective centres of gravity are displayed (SOLIDWORKS).

There is no problem as far as we drive 1-ton bricks around. But how can we describe the inertia of cars and not the physical behaviour of a solid block?
You would need to acquire MOI measurements of the real car, calculate the sprung mass component, then solve for the box that fits the values you get. AC
calculates the MOI from the dimensions of that box, so they need to be representative (the dimensions of the vehicle are not).
Commonly the apparatus used to capture such information is called VIMM, which stands for Vehicle Inertia Measurement Machine. It consists of a
spherically mounted platform where the vehicle is mounted onto, actuated by three hydraulic cylinders (Fig.).

58
In the modding community often called “inertia box” without much afterthought. This can result in misinterpretations, as also the total vehicle inertia can be rendered with an inertia box, taking in
account both sprung and unsprung masses. The latter being a standard practice in vehicle literature, research and testing facilities, always make clear if the MOIs in question are sprung or total.

366
Fig. – MOI and CG measurements for a Tesla Model 3 and a BMW i3.

Within a specific test procedure which includes stationary and dynamic measurements (Fig.), it can be determined the position and height of the center of
gravity, as well as the principal mass moments of inertia for pitch, roll and yaw motion.

Fig. – Dynamic tests are performed by continuously rotating the entire vehicle of a certain number of degrees on the bench. The rotation is periodic, clockwise and anticlockwise, that’s
why the graphs are sine waves.

There's a small set of cars with actual inertia measurements but it's only done by pretty large organizations since the measurement rig is a million-dollar item,
and of those, NHTSA (US National Highway Traffic Safety Administration) is about the only one posting them in public journals.
Even the best AC modders do rarely (if ever) have the occasion to find real values.
But if you don’t have data, you need to guess close enough then correlate from telemetry. Kunos developers stated:
“The calculations inside AC are made in a way that if you put the rough dimensions of the car in the INERTIA line, you can get pretty good behaviour”. (Aristotelis Vasilakos,
2015)
I have to say that this tip should be taken with a grain of salt. You definitely must NOT input in the car dimensions, but anything you will add, subtract or
entirely replace will be based on how much accuracy you want to get.
Starting with coarse approximations, automobiles with the engine further away from the center of the overall sprung mass will have a bigger inertia box, due
to a higher MOI. Mid- and rear-engine cars should have the third value smaller than the car's length.
A “decent” approximation is done with values that are 80% of the vehicle size. That’s just how big real inertia measurements suggest the box should be.
With the amount of variance between regular cars you're not going to be more than around 10-20% wrong.
Kunos advices a box longer than the car for automobiles with the engine at the front/rear or a similar weight distribution, and a box smaller than the car for
vehicles with the engine in the middle. Then, in-game open the CAR PHYSICS dev app and check the "DINDEX" value. This is a perfect help to better
understand how to setup the car in terms of inertia.
There are so many factors that go into figuring out what uniform density box would fit the car, that getting an accurate estimate is almost impossible, due to
cars obviously not being a box, different parts having different density and consequently weight, for example chassis, engine, transmission and fuel tank being
far heavier than the body, as well as the roof being much lighter than the lower panels, especially in race cars.

367
The aforementioned method is just for guessing: it is not the best solution, unless you have telemetry data to make appropriate comparisons; in reality there
is no limitation on how AC works with inertia, it behaves correctly as long as you enter the numbers for only sprung mass correctly. Thus, if you're more
advanced, you can have other options:
1. Calculate all the inertias for every single part of the car with whatever program or method you want to use. Typically it can be done very easily if you have a full 3D model
in an industrial CAD software. Get the values, convert them to the dimensions of a box with the MOI formulas 59 and input them into the INERTIA line.
2. Measure the MOI by yourself on a rig. If you manage to, create a 3D box with the same inertias with the MOI formulas, and input its dimensions in the INERTIA field.
3. Adopt one of the standard estimation methods based on the total vehicle inertia. Look at the PHYSICS section (pag.) for more details.
Inertia is something you either have data for or you don't. If you don't, it is fine to continue using the estimates; it's usually fairly close anyway...it is the
standard option when working with the config files, because inertia measurements are rather rare, and the databases are few.
The official Assetto Corsa cars by Kunos shouldn't be the gold standard to follow for the values... inertia is nowhere near close enough, and it gets worse
the more compact the car is internally. Some of the KS racing cars have up to 90% error per axis in their sprung MOI. That is, their MOI is 90% higher than
the correct value.
For an example of inertia that's far too high, the Kunos Toyota TS040's inertia box is 30% too large on the x-axis (41 cm), 72% too large on the y-axis (44
cm), and 19% too large on the z-axis (72 cm). Imagine this, compared to a car that had less engineering knowledge and far lower budget put into it. For the
BMW M4 indeed, the values input by the devs are totally identical to the real vehicle’s dimensions. And that’s wrong.
- Usually low-quality drift car mods tweak the inertia parameters to make the vehicles a joke to drift, and that’s completely unrealistic; you see, when you
have an inertia box the size of a truck it’s pretty easy to predict the behaviour of the car and counter-steer accordingly.
On average drift car mod packs are not accurate in terms of physics. 5-6 meters of inertia box are pretty common on these mods.
- Technically if you owned the vehicle and had a lot of time you could build yourself a ramp with wood (Fig.) and place scales on the corners of the car to
measure the weight distribution and calculate the CG height.

Fig. – Example of a wooden ramp for vehicle repairs, along with the respective schematic diagram. Everything is held together with threaded connections.

You measure the difference in corner weights and do some maths; it’s the only method of measuring CG that you can do at home.

59
You can do it with the spreadsheet in the attachments of this manual.

368
- Keep in mind that fuel affects inertia by being a mass placed at the location of the fuel tank set in car.ini. I don't know offhand if it has a specific
dimensional inertia box as well, I'd guess no. Even a point mass that's rigidly fixed to the body affects its overall inertia so it's just implicitly added that way.

- If you work in an engine analysis lab and you know how many litres does your vehicle burn per second (instant fuel consumption), you can use the
following formula to obtain a CONSUMPTION value:
1000 ∙ 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐
𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 =
𝑅𝑅𝑅𝑅𝑅𝑅 ∙ 𝑔𝑔𝑔𝑔𝑔𝑔
Where 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 is how many litres per second the car burns (aka the fuel consumption), RPM is the rotational regime of the engine and gas is the throttle input
in percent (so in the formula for example 10% is 0.1 and 90% is 0.9).

This will not be very useful if compared to the data you typically find published for vehicles. While in a race on track it can be somewhat important, time is
often irrelevant when talking about commuters that need to go from point A to point B efficiently and economically. Usually when the salesman compares
automobiles in salons, we find more practical to know about relationships of fuel per fixed distance (litres per 100 km), or distance per fixed fuel units, the
famous km/litre, or miles per gallon ratios (reminder that AC adopts SI units, so any conversion is on you).
If you have this type of data available, there is only one method to set up fuel consumption in our simulator, and that is by recreating, or at least estimating
the test conditions of the data you have, then see how much fuel is burned by the car with the in-game apps, and calculate the real fuel consumption in
conjunction with CONSUMPTION values that you’ll have to tune by hand to get the desired 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 .
For example, considering the EPA (United States Environmental Protection Agency) highway cycle tests, you’ll have to drive your car in-game for the length
of the real fuel consumption test (10~20km) at the speed it was done (70~100 km/h) and see how much fuel the car uses, then apply the following
formulas:
𝐹𝐹𝑛𝑛 ∙ 𝑙𝑙𝑐𝑐𝑐𝑐𝑐𝑐 1 𝑅𝑅𝑅𝑅𝑅𝑅 ∙ 𝑔𝑔𝑔𝑔𝑔𝑔
𝐹𝐹𝑛𝑛 ∶ 𝐿𝐿𝑛𝑛 = 𝑥𝑥 ∶ 𝑙𝑙𝑐𝑐𝑐𝑐𝑐𝑐 ⇒ 𝑥𝑥 = ⇒ 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 = 𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 ∙ 𝑥𝑥 ∙ ∙ ∙ 𝐵𝐵
𝐿𝐿𝑛𝑛 𝑓𝑓𝑏𝑏 1000
You have a proportion, where 𝐹𝐹𝑛𝑛 is the nominal fuel burned by the nominal distance 𝐿𝐿𝑛𝑛 , equal to 100km (litres per 100 km); 𝑙𝑙𝑐𝑐𝑐𝑐𝑐𝑐 is the length of the real fuel
cons test (usually 10km), or your estimate of that distance. The unknown 𝑥𝑥 is to be multiplied by CONSUMPTION and 𝑓𝑓𝑏𝑏 (the fuel burned in-game) to know
what is the actual 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 of the vehicle simulated. 𝐵𝐵 is the turbo boost (if separated from the engine data, otherwise ignore it).
Pro tip: in AC boost simply multiplies fuel consumption. If your car has got a turbo fitted but you have data for the NA engine only, since B must be present in the equation
you need to know what boost the turbo creates at the reference RPM/gas (throttle %). In case the engine specs take in account boost already, this is not necessary.

Example: consider a car with a NA engine that consumes 6.4 litres (𝐹𝐹𝑛𝑛 ) per 100km (𝐿𝐿𝑛𝑛 ). It revs to 6400 RPM. Drive it for 20 km at steady state (without
changing the throttle input) on a very long flat, straight track (see test tracks) and watch how much fuel it uses, then multiply your template CONSUMPTION
0 𝑖𝑖
value by 𝑥𝑥 = 6.4⁄(100⁄20) when calculating 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 . Once you obtain a preliminary 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 , adjust the CONSUMPTION, until your definitive 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 will
correspond to the real-world data .60

There's no other effective way to calculate your fuel cons, unless it's a race car in a series with regulated fuel flow (e.g., F1 or LMP1), in that case refer to
QUESTION [3] of the FAQ.
Alternatively look at pag. for an engineering evaluation of fuel consumption.
- None of what AC's fuel consumption does is realistic in terms of efficiency.
- About the optional KG_PER_LITER line: it allows to specify the fuel density. By default AC uses the 0.75 kg/dm3 density of a 95 octane gasoline.
You can use the table below as a reference guide 61 for the values you can choose. Notice the temperature: fluids typically grow in volume as T increases,
but compared to gases, the effect is negligible. Any difference between leaded and unleaded fuel can be ignored too.
Fuel Density (T=15°C) [kg/dm3] Otherwise, if your car is some kind of prototype running on Vodka or apple cider (???),
Diesel 1D (*) 0.875 there is a pretty simple method to calculate the density ρ. You fill a jerrycan with 1 litre of
Diesel 2D (*) 0.849 fuel and measure its weight 62, then apply the following formula:
Diesel 4D (*) 0.959
𝑚𝑚𝑓𝑓 𝑚𝑚𝑚𝑚𝑚𝑚𝑚𝑚 [𝑘𝑘𝑘𝑘]
EN 590 Diesel (**) 0.82-0.845 𝜌𝜌 =
𝑉𝑉
=
𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣𝑣 ([𝐿𝐿] = [𝑑𝑑𝑑𝑑3 ])
⇒ 𝑉𝑉 = 1 ⇔ 𝜌𝜌 = 𝑚𝑚 (666)
Fuel Oil 0.75-0.94
Gas Oil 0.825-0.90
Where mf is the net mass of fluid in kilograms.
Gasoline (generic) 0.71-0.78
Unleaded gasoline 95 RON (***) 0.720-0.775 This means that the weight measured in kilograms of 1L of fuel is directly its density.
Aviation gasoline (avgas) 0.720
Heavy fuel oil 0.80-1.01 If you want to make the fuel weight nothing, set KG_PER_LITER=0, or a very low
Kerosene 0.775-0.84 fraction (0.0001). Useful for electric vehicles. Else, if the line is not present, AC will keep
Natural gas 0.0007-0.0009 the default.
Propane 0.0017
- About STEER_RATIO: the steering ratio is the number of degrees turned at the steering wheel divided by the number of degrees the front wheels are
deflected:

60 𝑖𝑖
The i symbol in 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 represents the indefinite number of adjustments you’ll have to do.
61
All data from https://www.engineeringtoolbox.com/fuels-densities-specific-volumes-d_166.html, except where indicated. RON is a standard for fuel octane. (*) Diesel fuels are in USA broken up into 3
different classes: 1D, 2D and 4D. The difference between these classes depends on viscosity and boiling point ranges. 4D fuels tend to be used in low-speed engines. 2D fuels are used in warmer
weather. 1D is preferred for cold weather as it has a lower viscosity. (**) The EN 590 is an European diesel standard from 2005. (***) Courtesy of Türkiye Petrol Rafinerileri A.Ş.
62
What we are interested in is the net weight of the fluid, not its container, so use a scale with a tare zero function, or weigh the jerrycan first (especially if it is made of metal) and calculate the
difference when the fuel is inside.

369
 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 𝑤𝑤ℎ𝑒𝑒𝑒𝑒𝑒𝑒 𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎 [°]
𝑆𝑆𝑟𝑟 =
𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓 𝑤𝑤ℎ𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒′ 𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎 [°]
So for example, if the steering wheel is turned 30° and the front wheels only turn 1°, that gives a Sr of 30:1. For most modern cars, it is between 12:1 and
20:1. This, coupled with the maximum angle of deflection of the wheels gives the lock-to-lock turns for the steering wheel. For example, if a car has a
steering ratio of 18:1 and the front wheels have a maximum deflection of 25°, then at 25°, the steering wheel has turned 25°x18, which is 450°. That's only
to one side, so the entire steering goes from -25° to plus 25° giving a lock-to-lock angle at the steering wheel of 900°, or 2.5 turns (900° / 360).
Since we’re on topic, here’s how to set up the steering ratio/steer lock for your vehicle in AC:
1. Create your suspension geometry and just copy the values for steering from the formula_k car.ini template.
2. Set your STEER_RATIO= value from real-world data.
3. Enter AC with developer apps enabled, launch a session and open the Suspensions dev app.
4. Turn your steering wheel at 90 degrees (left or right doesn't matter).
5. Check on the aforementioned app the steering ratio line (STR, see pag.). That is your current steering ratio.
6. Modify the LINEAR_STEER_ROD_RATIO value (with small changes, like 0.00005 at a time), until the in-game STR and car.ini’s STEER_RATIO values are similar. This
implies restarting the session various times (until you’re satisfied), as the car must be reloaded.

Variable steering ratios?

- Frame rigidity: Assetto Corsa does simulate the frame/chassis/uni-body as a single rigid entity, but it doesn’t acknowledge that it flexes.

CSP ADDITIONS
- The mod adds the following values to car.ini, that must be present if you want to use any features of Custom Shaders Patch’s extended car physics for
your vehicle. It allows to make sure everybody is racing in the same conditions.
[HEADER] ; Vanilla header.
VERSION=extended-1 ; Version of the car that AC loads. Inputs: 1, 2, extended-1, extended-2

% ▲ With CSP, extended-1 or extended-2 values may be used instead of the vanilla ones (1, 2) and are necessary to enable extended physics features (rain
physics… etc.), from now on referred to as “cphys”. Recommended input is extended-2 if your car is RWD or AWD. extended- can be considered a prefix.

The idea is that vanilla AC would crash if it encountered these VERSION values, because it can’t parse them as integers. CSP on the other hand catches
them, stops AC from crashing and marks the car being loaded to use extended physics on it.
- Also, since release 1.74, a car can be locked to adopt a specific CSP version with the following lines:
[HEADER] ; Vanilla header.
VERSION=extendedV1 ; The param can still have 1 or 2 at the end to reflect vanilla values. Inputs: extendedV1, extendedV2

[_EXTENSION]
REQUIRED_VERSION=2142 ; Internal development code number of the CSP release.

% ▲ This example is using the 1.79 CSP release code as an example.

The code number above can be found easily in Content Manager > Settings > Custom Shaders Patch > About & Updates > Shaders Patch version ID (Fig. ).

Fig. – The Shaders Patch version ID is what you’re interested into.

Otherwise, if you don’t have CM, you can look in the mod’s files, specifically data_manifest.ini, under %root%\assettocorsa\extension\config, that has the
following section:
[VERSION]
; hidden
SHADERS_PATCH=0.1.80-preview115
SHADERS_PATCH_BUILD=2260

CURIOSITIES AND AMENITIES

- Originally one of the Kunos developers’ ideas for the PICKUP_FRONT_HEIGHT and PICKUP_REAR_HEIGHT values was that sparks would spawn when
this plane touched ground. Sadly this feature was not implemented, but CSP brought it to AC (probably with other methods).
There's a sparks.ini file in the install folder (with many parameters). So it's obvious that the engine can do it, in some way.
And yeah, the sparks you see in the vanilla launcher intro and in the launch trailer (Fig.) is just a video effect. Stefano Casillo said on Twitter:
“Added in video post-production. We have sparks in AC but they've been broken for ages, don’t know if I'll be able to fix in time.”

370
Fig. – Case closed. Actually no, because the Tech Preview DID HAVE sparks.
He also said that it was about car-to-car contact that they left them out, because it wouldn’t look right:
“At the beginning of the AI development in the Early Access, especially on grid starts like in Monza, they were hitting each other all the time, so it was this ridiculous
situation when you had sparks everythere” (Stefano Casillo, 2015)
The code was improved, however the feature never made it to the final game. Another problem was the additional replay data required. But with vfx in the
trailer it’s cheating! Kunoooooooos...

- The 1.15 version of AC added some optional physics parameters for modders. Of those, one was the [EXPLICIT_INERTIA] section, originally
recommended for use with real life inertia data, where the MOI of the vehicle could be input directly.
This is how it looked like:
[EXPLICIT_INERTIA] ; Required header.
INERTIA=1300,1400,500 ; This code enables direct input of inertia values and overrides the box inertia parameter.

Sadly this feature never worked: the code is still present, but I personally tested in 1.16.4 and even in the old 1.15; the inertia of the car goes to zero and
some errors happen. However it’s the proof that from the point of view of real-world values, AC does not have any limitations.

FAQ
QUESTION [1]: Is there a deadzone in the AC’s steering system?
ANSWER [1]: Unless you’re talking about controller settings, there's no deadzone in the AC physics... just raise the steering ratio and you'll get slower steering.

Q [2]: How can I change the ride height of my car?

A [2]: This question begs for more clarification: which height do you want to change, visual or physical? Changing the visual height is a black magic trick, as
the only thing that moves is the car model and everything attached to it, with the offsets inside car.ini. Modifying the physical height instead is what the
mechanic would do to obtain a higher or a lower suspension: you change the ROD_LENGTH in suspensions.ini.

Q [3]: How can I estimate the vehicle’s fuel consumption in a crazy way? I’m desperate.
A [3]: I have a method that should be quite good. It’s not the best, nor the correct way (since AC’s fuel consumption is instant, not average), but it kind of
works if you want to make a very rough estimate (it can be quite good actually). It requires you to know: the length of a race your vehicle took part in, how
much time it took to complete it, the race homologation regulations, and the capacity of the fuel tank (as counterproof).

Now we’ll understand how to proceed with an example. Let’s consider a pre-war vehicle, like the Alfa Romeo P2. There isn’t much data available for this car,
let alone the fuel cons, but we know for sure that it took part in a race on the 9 June 1924 on the Cremona Circuit (Fig.), which is 320km long, and it took 2
hours and 2 minutes.

Fig. – This table comes from Wikipedia, the free encyclopedia.

We know that our fuel tank is 145 L of capacity. This is what we take for granted. We can then take a look at the race regulations per year; the closest I
managed to find with fuel consumption specs is for the 1913 Grand Prix and it consists of 20 litres per 100 km (Fig.).

371
Fig. – From this website: http://www.kolumbus.fi/leif.snellman/gpw5.htm. Very nice info.

Now we know: 320 km of track divided by 100 km gives you 3,2. Multiply it by 20 litres and you get 64 L of gasoline. This is totally possible, because the
car tank is bigger. That’s why knowing its capacity is useful, to compare our result. We can also use longer races and think about the refuelling methods
practiced back in the day.
Anyway, on that infamous day the race took 2 hours and 2 minutes, so let’s convert this amount in seconds:
2ℎ 2′ = 122′ = 122′ ∙ 60′′ = 7320𝑠𝑠
So on average the fuel consumption per second is:
𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 𝑓𝑓𝑓𝑓𝑓𝑓𝑓𝑓 𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏𝑏 [𝐿𝐿] 64
= = 0,00874 [𝐿𝐿/𝑠𝑠]
𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 [𝑠𝑠] 7320

Now we will put this number in the CONSUMPTION formula as 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 :

1000 ∙ 𝐹𝐹𝑐𝑐𝑐𝑐𝑐𝑐 1000 ∙ 0,00874
𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶 = = = 0,00273
𝑅𝑅𝑅𝑅𝑅𝑅 ∙ 𝑔𝑔𝑔𝑔𝑔𝑔 4000 ∙ 0,8

where I estimated the RPM to be at 4000 and the gas at 0,8 on average during the race. gas is once again to be considered a percentage of throttle input,
where 1=100%, so 0,8=80%. I believe the driver was quite aggressive and heavy on the pedal. Probably more, probably less, who knows.
The Alfa P2 could rev up to 5500 RPM, and I don’t think it has had been pushed to the maximum on the Cremona circuit. This is my reasoning.
Even if the race regulations in 1924 would have had been limited to 10 litres per 100 km, or 30 litres per 100 km, we would get a range between 0,0014
and 0,0041, so you already have a tight enough margin of error.

The value we obtained is quite plausible, especially if compared to other mods of vehicles of the same period. We can use it as our CONSUMPTION inside
car.ini. You can always decide for an optimistic or pessimistic estimate if you don’t like it, and personally that’s what I will do.
The difficult part is finding the correct homologation rules for the race you consider, and considering the right RPM and gas values. But with some
experience this process can be much more accurate than using random numbers. Happy now?

372
PHYSICS (for car.ini)
Since car.ini involves some general concepts around car dynamics, we will try to explain how things work the best way possible.
Let’s start with the things that you should absolutely get right first.

1.0 - Centre of gravity (CoG)

1.1 - What is a centre of gravity?

It is a point, near or within a body, through which its weight can be assumed to act when considering forces on the body and its motion under gravity. This
coincides with the center of mass in a uniform gravitational field.
In physics, the center of mass of a distribution of mass in space (sometimes referred to as the balance point) is the unique point where the weighted relative
position of the distributed mass sums to zero. This is the point to which a force may be applied to cause a linear acceleration without an angular acceleration.
Calculations in mechanics are often simplified when formulated with respect to the center of mass. It is a hypothetical point where the entire mass of an object
may be assumed to be concentrated to visualise its motion. In other words, the center of mass is the particle equivalent of a given object for application of
Newton's laws of motion.

In the case of a single rigid body, the center of mass is fixed in relation to the body, and if the body has uniform density, it will be located at the centroid. The
center of mass may be located outside the physical body, as is sometimes the case for hollow or open-shaped objects, such as a horseshoe. In the case of a
distribution of separate bodies, such as the planets of the Solar System, the center of mass may not correspond to the position of any individual member of
the system.

The center of mass is a useful reference point for calculations in mechanics that involve masses distributed in space, such as the linear and angular momentum
of planetary bodies and rigid body dynamics. The center of mass frame is an inertial frame in which the center of mass of a system is at rest with respect to
the origin of the coordinate system.

1.2 - Vehicle CoG and handling properties

The following are important variables in vehicle engineering:

• The vehicle centre of gravity V
• The body (sprung-mass) centre of gravity Bo
• The axle (unsprung mass) centres of gravity 𝑈𝑈𝑓𝑓 or 𝑈𝑈𝑟𝑟 .

The distance of the centres of gravity V and Bo from the front or rear axle and their height above ground are crucial for:
• Braking and acceleration capacity;
• Calculating the climbing ability (not required for AC);
• Designing brake systems and four-wheel drives;
• Designing body centre of gravity and aspects of vibration stability;
• Driving stability investigations;
• Determining mass moment of inertia (the most important part).

Low centres of gravity are always desirable, as they are associated with fewer driving dynamic problems and increased vehicle performance during cornering
and braking, but in practice the design options are relatively restricted.
The position of a vehicle centre of gravity V and the body centre of gravity Bo is highly dependent on the load; when people get into the vehicle or luggage
is loaded in the boot or onto the roof, the centre of gravity changes vis-à-vis the empty condition, both in the longitudinal direction (x-axis) and upwards (z-
direction). The body lowers when it is loaded, i.e. its centre of gravity Bo drops.
The centre of gravity of the people and, in particular, that of the luggage carried on the roof, is higher than that of the body so the end result is usually a
higher overall centre of gravity V (distance ℎ𝑉𝑉 , Fig.XXAN).

Fig. XXAN- Designation of the paths for determining the centres of gravity V of the overall vehicle and Bo of the body. The centres of gravity 𝑈𝑈𝑓𝑓 and 𝑈𝑈𝑟𝑟 of the front and rear axles can
be regarded as being in the centres of the wheels.

373
1.3 - Calculating the vehicle centre of gravity

Calculating the position of the centre of gravity is likely to be possible only with great difficulty and considerable effort. If the vehicle and all its individual
components are shown on a computer in the form of a digital model including body surfaces and properties (digital surfaced model), modern CAD/CAE/CAM
tools make it possible to calculate the position of the centres of gravity of the components and the whole vehicle.
It is much simpler to determine the position experimentally by weighing.

1.4 - Centre of gravity distance to front and rear axle

Fig.XXAN contains the paths and angles necessary for calculating the centres of gravity and Fig. 3.3 the position of the coordinate system. When the vehicle
is weighed, it must be standing on a completely horizontal plane and with each axle on a weighbridge. So as not to distort the weighbridge, it must be
possible to turn the wheels freely. The weighed front axle load 𝑚𝑚𝑉𝑉,𝑓𝑓 and the rear axle load 𝑚𝑚𝑉𝑉,𝑟𝑟 give the total weight 𝑚𝑚𝑉𝑉,𝑡𝑡 of the vehicle in kilograms:
𝑚𝑚𝑉𝑉,𝑡𝑡 [𝑘𝑘𝑘𝑘] = 𝑚𝑚𝑉𝑉,𝑓𝑓 [𝑘𝑘𝑘𝑘] + 𝑚𝑚𝑉𝑉,𝑟𝑟 [𝑘𝑘𝑘𝑘]
The balance of moments around 𝑚𝑚𝑉𝑉,𝑓𝑓 or 𝑚𝑚𝑉𝑉,𝑟𝑟 , in conjunction with the wheelbase 𝑙𝑙 in the longitudinal direction, gives the centre of gravity distances 𝑙𝑙𝑓𝑓 to
the front and 𝑙𝑙𝑟𝑟 to the rear axle:
𝑚𝑚𝑉𝑉,𝑟𝑟 𝑚𝑚𝑉𝑉,𝑓𝑓
𝑙𝑙𝑓𝑓 = 𝑙𝑙 ; 𝑙𝑙𝑟𝑟 = 𝑙𝑙 → 𝑙𝑙𝑓𝑓 = 𝑙𝑙 − 𝑙𝑙𝑟𝑟
𝑚𝑚𝑉𝑉,𝑡𝑡 𝑚𝑚𝑉𝑉,𝑡𝑡
If the lateral distance of the centre of gravity (y-direction) from the vehicle centre-line is required the wheel loads must be weighed to be able to calculate
first of all the lateral offset of the centres of the front and rear axles from the centre-line via similar equations made up from the rear view, and then similarly
for the vehicle centre of gravity from the top view (see Equations).

1.5 - Centre of gravity height

To calculate hV, first the front and then the rear axle must be lifted as high as possible (by the amount h) with an elevating mechanism (autohoist, jack,
crane), with the other axle standing in the centre of a weighbridge (Fig.). The following would need to be ensured:
• The vehicle must be prevented from falling off by inserting wedges from the outside on the axle to be raised. The brake must be released and the gearbox must be in neutral.
It must be possible to turn the wheels on the platform easily; the platform would otherwise distort and the result be imprecise.
• The wheels are held still on the centre of the platform, the vehicle forward movement must be even when the vehicle is raised, in order to prevent wrong measured values
as a result of different force application positions on the horizontal surface.
• If the change in axle load during lifting is measured by means of a crane over a load cell, it is possible to ensure that the direction of lifting is completely vertical.
• The vehicle should be in the on-road condition, i.e. full tank, tools, spare wheel, etc. (as per the curb weight, see).
• Both axles must be prevented from compressing or rebounding before the vehicle is raised. The locking device must be of an adjustable variety so that the amount by
which the body sinks when there are two or four people and luggage in the vehicle can be taken into consideration.
• To eliminate tyre springing during the measurement, it is recommended that the tyre pressure on both axles be increased to 3.0 to 3.5 bar.
Mathematical observation of the measurement is as follows (Fig.):

Fig. 6.2 - Vehicle on a weighbridge with forces and paths for deriving the equation for vehicle centre of gravity height hV included.

374
2.0 - Mass moments of inertia
From the theory of mechanics it is known that when a body is accelerated in a straight line the inertia Fc is given by
Fc = m ax = mass * acceleration (N)
In comparison to this, in the case of accelerated rotational movement, the acceleration moment is influenced by the rotation mass J.
The rotation mass – equivalent to the mass moment of inertia J (kg m2) and also known as second degree mass moment – is a measure of inertia on
rotating bodies. In vehicles, three important rotational movements occur in the various vehicle conditions, to which the variables of the mass moments of
inertia J are related.
• The vehicle moment of inertia JZ,V around the vertical axis (z-axis, Fig.) is required for driving stability studies or even for reconstructing road traffic accidents.
• The body moment of inertia JX,Bo around the vehicle’s longitudinal axis (xaxis) is essential for generally studying body movement (roll behaviour) during fast lane
changes in the driving direction.
• The body moment of inertia JY,Bo around the transverse axis (y-axis) is the determining variable for calculating pitch vibration behaviour.

In addition to this, in general, the inertia moments of power units (engine–gearbox unit) and individual rotationally symmetrical elements, such as steering
wheels, tyred wheels, etc. are of importance.
The position of its centre of gravity and the variables of the moment of inertia are usually determined with the basic design of a vehicle (drive, wheelbase,
dimensions and weight).
In addition to the type of drive, the vehicle’s moment of inertia JZ,V around the vertical axis is the determining factor for its cornering performance.
Manoeuvrability increases as the inertia moment decreases, whereas driving stability when the vehicle is moving in a straight line and on S bends decreases
by the same amount. JZ,V comprises the mass mV,T of the vehicle as a whole and the radius of gyration iZ,V squared:
JZ,V = mV,t i 2Z,V (kg m2)
The magnitude of the radius of gyration iZ,V depends on the length, width and weight distribution of the body, the length and weight of aggregate units
(engine, gear box, differential) and the position and weight of the occupants and the luggage. Series tests with saloons have shown that the radius of
gyration is mainly a function of the load status and only varies within narrow limits from vehicle to vehicle. Fig. shows the average values. Only the
vehicle weight mV,t in the occupancy or load condition to be investigated is necessary for determining the approximate moment of inertia JZ,V (see).

2.2 - Moment of inertia estimation techniques

The moments of inertia, in yaw, pitch, and roll, as well as the center of gravity height are necessary to successfully model the 3D dynamic behaviour of
vehicles. A number of vehicle parameter estimation techniques have been developed and are currently in use in North America and Europe.
Many parameters have been measured by NHTSA and others. The estimation techniques are compared to the available measured values, and
recommendations are made for best estimating the parameters when measured values are not available.
Modeling the 3D dynamic behavior of a vehicle requires a minimum of the vehicle geometry, the center of gravity height and the triaxial moments of inertia.
Because moments of inertia are difficult (but most important, expensive) to measure for a given vehicle, there is a need for estimation techniques that use
easily obtained vehicle measurements.
More complex models like Assetto Corsa require data concerning the sprung and unsprung vehicle masses. For now here will be discussed the whole
vehicle moments of inertia relative to the total vehicle centroidal axes, and the height of the whole vehicle center of gravity.
Theory:
In simple linear Newtonian mechanics, the mass of a vehicle is assumed to be concentrated at the center of gravity location. This assumption may be
appropriate for the simplest dynamic models, pure central collisions, or for very coarse estimation purposes. When the vehicles are involved in rotations, as
is the most common case, then the simple models are inadequate, and the distribution of the vehicle’s mass about the centroid must be considered.
The resistance of an object to rotation is a function of the mass of said object, and the location of the mass with respect to the center of rotation, and is
known as its moment of inertia, 𝐼𝐼.
An idealized motor vehicle can be considered a solid homogeneous slab as shown in Fig. (left).

Fig. – (left) The vehicle as a solid homogeneous slab or prism. (right) The vehicle with concentrated masses.

375
The moments of inertia about the three axes of the slab would be:
1 1 1
𝐼𝐼𝑥𝑥𝑥𝑥 = 𝑚𝑚(𝑊𝑊 2 + ℎ2 ) ; 𝐼𝐼𝑦𝑦𝑦𝑦 = 𝑚𝑚(𝐿𝐿2 + ℎ2 ) ; 𝐼𝐼𝑧𝑧𝑧𝑧 = 𝑚𝑚(𝐿𝐿2 + 𝑊𝑊 2 )
12 12 12
Regarding vehicles, this is termed the prism method. The yaw moment of inertia for a solid slab is a function of the length and width as well as mass, not
mass alone.
A motor vehicle is not a solid homogeneous slab. It has concentrated masses at the engine, transmission, suspension, etc., as shown in Fig. right
The moment of inertia for any object can be calculated, if enough is known about these distributed masses. However, the MOI of a motor vehicle is more
practically measured by testing, as already mentioned previously (see).
To explain a purely theoretical method, a simplified top view of a vehicle is shown in Fig.

Fig. – Top view of a vehicle being tested for the yaw moment of inertia.

The vehicle is allowed to pivot at its center of gravity, on a massless undamped frictionless frame. The fore/aft mass distribution is 50/50. Yaw inertia is
measured thanks to springs with constant k. The moments sum as follows:
2𝑘𝑘𝑎𝑎2
� 𝑀𝑀 = 𝐼𝐼𝐼𝐼 ; −2(𝑘𝑘𝑘𝑘𝑘𝑘)𝑎𝑎 = 𝐼𝐼𝜃𝜃̈ ; 𝜃𝜃̈ + � � 𝜃𝜃 = 0
𝐼𝐼
Where 𝜃𝜃̈ is the second derivative of the angle, so the angular velocity 𝜔𝜔. The period (the time for a single oscillation) of this oscillating structure is:

𝐼𝐼
𝜏𝜏 = 2𝜋𝜋�
2𝑘𝑘𝑎𝑎2
In this idealized example, one measures the period, the geometry, and the spring constants, and the moment of inertia is readily determined:
1
𝐼𝐼 = 2𝑘𝑘𝑎𝑎2 𝜏𝜏 2
4𝜋𝜋 2
The actual measurement of the inertial properties of vehicles is far more complex than presented here.
Estimation techniques
A number of methods have been proposed to estimate the moments of inertia, and in some cases the height of the center of gravity. These are listed here in
chronological order.
- Grime (1969) proposed the prism method described previously.
- Burg (1982) tested against the measured values of 56 European vehicles and found that the best correlation for the yaw moment for his sample was:
𝐼𝐼𝑧𝑧𝑧𝑧 = 0.1269𝑚𝑚𝑚𝑚𝑚𝑚
- Reide: Researchers at General Motors (1984) tested a number of passenger vehicles “sold commercially somewhere in the world”. No truck or bus types
were included. Body styles ranged from 2-passenger sports cars to station wagons, masses from 575 to 1761 kg, and wheelbases from 2025 to 2953 mm.
Nine were front engine-rear drive, six front engine-front drive, and two were rear engine-rear drive, for a total of 17 cars. They were tested in curb condition,
no passengers and full gas tank. The best fit for the whole vehicle MOIs, relative to the total vehicle centroidal axes, were:
𝐼𝐼𝑥𝑥𝑥𝑥 = 0.37𝑚𝑚 − 86.4, 𝑅𝑅2 = 0.893 ; 𝐼𝐼𝑦𝑦𝑦𝑦 = 2.56𝑚𝑚 − 1103, 𝑅𝑅2 = 0.919 ; 𝐼𝐼𝑧𝑧𝑧𝑧 = 2.86𝑚𝑚 − 1315, 𝑅𝑅2 = 0.920
Where m is the total vehicle mass and R is the average radius of the mass distribution, evaluated to obtain the equations given.
No techniques for estimation of center of gravity heights were given.
- Allen (1987) et al. proposed a method for the roll moment, as a variant of the prism method:
1
𝐼𝐼𝑥𝑥𝑥𝑥 = 𝑚𝑚(𝑊𝑊 2 + ℎ2 )
12
Where this time ℎ2 = 𝛼𝛼1 ℎ1 2 + 𝛼𝛼2 ℎ2 2 , and 𝛼𝛼1 + 𝛼𝛼2 = 1.
The values 𝛼𝛼1 and 𝛼𝛼2 shown in Fig. are weighting coefficients which consider the proportions of the vehicle at various heights.

376
Fig. – The vehicle with averaged height.

Allen suggests that this method of determining the roll moment is accurate to within 20%. The center of gravity height is given as:
ℎ𝑐𝑐𝑐𝑐 = 0.38ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 ± 5%
Allen has offered no recommendations for the pitch moment.
- Garrott: The most complete listing of measured was published by Garrott in 1988. In addition to the values measured, the authors presented a number of
historic “rules of thumb” (in this manual indicated as ROT) and proposed a set of revised rules (all units have been converted to metric) which are listed in
tab. below. tav is the average of front and rear track of the car.
Passenger cars Light trucks Garrott also fitted curves through the measurement data, and presented the MOI
ℎ𝑐𝑐𝑐𝑐 = 540.8 ± 38.1 𝑚𝑚𝑚𝑚 ℎ𝑐𝑐𝑐𝑐 = 678.4 ± 101.6 𝑚𝑚𝑚𝑚 parameters for passenger cars and light trucks as a function of vehicle mass
ℎ𝑐𝑐𝑐𝑐 = 0.395ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 ± 2.6% ℎ𝑐𝑐𝑐𝑐 = 0.387ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 ± 3.5% (herein indicated as f(m)).
𝑚𝑚 ∙ 𝑡𝑡𝑎𝑎𝑎𝑎 ℎ𝑟𝑟 𝑚𝑚 ∙ 𝑡𝑡𝑎𝑎𝑎𝑎 ℎ𝑟𝑟 Passenger cars:
𝐼𝐼𝑥𝑥𝑥𝑥 = (0.73 ± 0.13) 𝐼𝐼𝑥𝑥𝑥𝑥 = (0.67 ± 0.16)
4 4 𝐼𝐼𝑥𝑥𝑥𝑥 = 0.538𝑚𝑚 − 203, 𝑅𝑅2 = 0.80
𝐼𝐼𝑦𝑦𝑦𝑦 = (1.07 ± 0.17)𝑚𝑚𝑚𝑚𝑚𝑚 𝐼𝐼𝑦𝑦𝑦𝑦 = (1.04 ± 0.22)𝑚𝑚𝑚𝑚𝑚𝑚 𝐼𝐼𝑦𝑦𝑦𝑦 = 2.96𝑚𝑚 − 1558, 𝑅𝑅2 = 0.89
𝐼𝐼𝑦𝑦𝑦𝑦 = (1.03 ± 0.08)𝐼𝐼𝑦𝑦𝑦𝑦 𝐼𝐼𝑦𝑦𝑦𝑦 = (1.00 ± 0.1)𝐼𝐼𝑦𝑦𝑦𝑦
𝐼𝐼𝑧𝑧𝑧𝑧 = 3.08𝑚𝑚 − 1635, 𝑅𝑅2 = 0.88
Light trucks:
𝐼𝐼𝑥𝑥𝑥𝑥 = 0.66𝑚𝑚 − 319, 𝑅𝑅 2 = 0.70 ; 𝐼𝐼𝑦𝑦𝑦𝑦 = 3.35𝑚𝑚 − 2247, 𝑅𝑅2 = 0.70 ; 𝐼𝐼𝑧𝑧𝑧𝑧 = 3.08𝑚𝑚 − 1821, 𝑅𝑅2 = 0.73

- Curzon: Later researchers developed the work of Garrott further. Curzon and colleagues (1991) measured the inertial properties of sport utility vehicles,
pickup trucks, and vans, and developed MOI estimations applicable to most light trucks.
They found the prism method was the best estimate for the yaw moment for sport utility vehicles, using the track width instead of the vehicle width.
1
𝐼𝐼𝑧𝑧𝑧𝑧 = 𝑚𝑚(𝐿𝐿2 + 𝑡𝑡 2 )
12
For the yaw of pickup trucks, the rule of thumb was best: 𝐼𝐼𝑧𝑧𝑧𝑧 = 𝑚𝑚𝑚𝑚𝑚𝑚
Regarding vans, they recommend either the prism method as for sport utility vehicles, or Garrott’s value for light trucks: 𝐼𝐼𝑧𝑧𝑧𝑧 = 3.08𝑚𝑚 − 1821
The roll moment was best approximated by a sum of prisms, similar to the method first proposed by Allen, that account for the varying cross sections of the
vehicles (Fig.).

Fig. – Prism models for pickup trucks, sport utility vehicles and vans.

The recommended relationship for the roll moment for sport utility vehicles is as follows:
1 𝐿𝐿𝑟𝑟 ℎ𝑟𝑟 2 1 𝐿𝐿𝑟𝑟
𝐼𝐼𝑥𝑥𝑥𝑥 = 𝑚𝑚 � + 𝑊𝑊 2 � + 𝑚𝑚 �1 − � (ℎ𝑤𝑤 − ℎ𝑎𝑎 )2
12 𝐿𝐿 12 𝐿𝐿
Like the earlier work by Allen, the roof length is required to use this technique.
For the roll moments of vans, Curzon recommends either the method above for sport utility vehicles, or Garrott’s value for light trucks: 𝐼𝐼𝑧𝑧𝑧𝑧 = 0.66𝑚𝑚 − 319.
Curzon offered no recommendations for the pitch moment or the CG height.
- Noon: Noon (1994) has proposed three methods to estimate the yaw moment. They have been conveniently called Noon-1, Noon-2, and Noon-3.

377
The first one has the moment being a function of the mass and the overall length:
𝑚𝑚𝐿𝐿2
𝐼𝐼𝑧𝑧𝑧𝑧 =
12
The second has the moment being a function of the mass and the wheelbase alone, assuming the masses are concentrated at half the wheelbase from the
geometric center:
𝑚𝑚𝑙𝑙 2
𝐼𝐼𝑧𝑧𝑧𝑧 =
4
Noon’s third method, Noon-3, considering the engine to be the most significant concentrated mass affecting the application of the prism method, accounts
for the effect of the engine mass with a combination of methods one and two:
𝑚𝑚𝐿𝐿2 𝑙𝑙 2
𝐼𝐼𝑧𝑧𝑧𝑧 = 2(1 − 𝑥𝑥) + (2𝑥𝑥 − 1)𝑚𝑚
12 4
where 𝑥𝑥 is the fraction of vehicle mass borne by the front axle.
This third method assumes that the difference between the weights on the axles is due to a point mass at the heavier axle, and that the centroid is at the
geometric center. Although contradictory, these assumptions are justified for an estimation technique.
Noon offered no recommendations for the pitch or roll moments or the CG height.
- Bixel: Bixel (1996) measured the parameters for 104 passenger cars, 84 multi-purpose vehicles, 82 pickup trucks, and 43 vans.
They found the roll moment for all vehicles The pitch moment for passenger cars: The yaw moment for all vehicles can be
can be estimated as: estimated as:
𝑚𝑚�ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 + ℎ𝑐𝑐𝑐𝑐 �𝐿𝐿 𝑚𝑚𝑚𝑚𝑚𝑚
𝑚𝑚�ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 + ℎ𝑐𝑐𝑐𝑐 �𝑡𝑡 𝐼𝐼𝑦𝑦𝑦𝑦 = 𝐼𝐼𝑧𝑧𝑧𝑧 =
𝐾𝐾 𝐾𝐾
𝐼𝐼𝑥𝑥𝑥𝑥 =
𝐾𝐾 The pitch moment of multi-purpose vehicles,
pickup trucks and vans:
𝑚𝑚�ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 + ℎ𝑐𝑐𝑐𝑐 �𝑙𝑙
𝐼𝐼𝑦𝑦𝑦𝑦 =
𝐾𝐾
Where K is an approximation constant determined for each class of vehicle.
The Bixel K factors are summarized in tab. Bixel notes that these approximation constants must evolve with evolving vehicle design.
Vehicle class Pitch Roll Yaw All the methods proposed by Bixel except yaw use the CG height, a quantity that is not generally
Passenger cars 5.2901 7.9846 2.1942 available on published databases. However, we explained at p. how to determine hcg practically.
Sport Utility, l<2.41 m 4.2193 9.4212 2.2048
Sport Utility, l>2.41 m 3.4510 9.4212 2.2048
The vehicle property estimations obtained with the Bixel method are only appropriate for vehicles
Pickups 3.3783 9.4738 2.1858 that were manufactured since 1980.
Vans 3.4734 7.8854 2.2168
All the estimation techniques mentioned previously are compared in tab. below.

Method 𝐼𝐼𝑥𝑥𝑥𝑥 𝐼𝐼𝑦𝑦𝑦𝑦 𝐼𝐼𝑧𝑧𝑧𝑧 ℎ𝑐𝑐𝑐𝑐 The equations providing the smallest range of standard deviation error (68% confidence limit) are given in the
tables of p.. Note that these equations have been multiplied through by their individual correction factors.
Prism x x x
Burg x x x If the information required to use a recommended equation is not available, another equation from the
methods discussed before may be used with its correction factor taken from the tables at p.. The user must
Reide x x x
then be aware of the slightly greater error being introduced.
Allen x
Garrott x x x x When adjusted, it was found that Garrott's revised rules of thumb provided identical results to the original rules
Curzon x x of thumb. This was expected as Garrott's revised rules are the result of multiplying the original rules by a
Noon x constant. Allen's adjusted equation for center of gravity height also provided identical results to those of the
Bixel x x x rules of thumb for the same reason.
The inertia estimation methods proposed by Garrott and Reide had greater deviations than the other methods. Both the Reide and Garrott methods consider
the moments of inertia to be linearly related to the vehicle mass and do not consider the vehicle geometry.
The only available body of MOI data for European vehicles has been given in the Burg study. No guidance can be offered for those European vehicles not
included in the NHTSA data used for this comparison.
At this point you may say: we only talked about total vehicle inertia estimation, but AC works with the sprung mass inertia. Very well, in the attachments of
this manual there is a solver (come on maaaaan wheeeere) that will allow you to convert the total MOI to the sprung one, once the first is estimated or
measured.
Be aware that the total inertia estimation doesn’t take in account the fuel mass. That’s totally fine, because in AC it is added as a point mass after the internal
calculations with sprung MOIs. Keep that in mind when checking telemetry data.

- If there is a known concentrated mass in a vehicle, due to occupant positioning or cargo loading, remote from the radius of gyration, then the moments
can be summed using the parallel axis theorem:
𝐼𝐼 ′ = 𝐼𝐼 + 𝑚𝑚𝑟𝑟 2

378
 The correction factors are simply to be multiplied by the results you obtain from the original formulas of the different methods, paying attention to the vehicle type. That will give you results correct to the 68% degree of confidence,
which is the same of the Best Adjusted Equations.

The Best Adjusted Equations already have the correction factors applied to them, that is exactly the point of them being adjusted.

The [ROT] and [f(m)] indicators for the Garrott factors refer to the Rules Of Thumb first, and to the formulas function of mass (hence the math symbol f(m)). You can find all of them in the explanations of the previous pages.

The spreadsheet in the attachments of the manual was tested with BMW M3 E30, Jeep CJ-5 and is working properly.

Advice for sports cars (prototypes/open wheelers/hypercars): they centralize the mass as much as they're allowed, so roll is quite lower than the estimate for passenger cars.

I will clean some more the table, putting the methods in the same order for each vehicle type.

379
10. colliders.ini
This small script lets you create additional colliders for the bottom of the car, which handle the collisions with the asphalt and kerbs, because the 3D collider
mesh (more info at Chapter) doesn’t really want to hit the ground in some scenarios, plus running the entire 60 poly object against the ground is too
demanding in terms of computational resources, so at the bottom of the car there are some flat planes.
[COLLIDER_0] ; SYNTAX: [COLLIDER_ID], starting from zero. A car can have as many colliders as necessary.
CENTRE=0 ,-0.23 ,-0.2 ; Where the center of the collision box will be placed. 0,0,0 XYZ reference is the CoG

% ▲ The position depends on how annoying you want it to be; if it exactly matches the mesh your car might have trouble driving over curbs, especially
with F1 cars. If you want to do a fine tuning of the collisions with the ground, make the .kn5 collider smaller than the car, so the panels have some
"give" and handle the underbody with colliders.ini.

SIZE=0.8 ,0.1 ,3 ; The size of the collision box in XYZ [meters]

GROUND_ENABLE=1 ; This value enables the ground collider. 0= disabled, 1= enabled.

[COLLIDER_1]
CENTRE=0 ,-0.16 ,0.40
SIZE=1.4 ,0.15 ,1.5
GROUND_ENABLE=1

[COLLIDER_2]
[COLLIDER_3]
[...]

% ▲ A car can have as many ground colliders as necessary.

LITTLE EXPLANATION
- In Fig. we have some examples of collider models straight from the official content.

Fig. – Images obtained via CM showrooms. (top) The Ferrari 312T by Kunos has got three colliders (the red boxes) in addition to the collider.kn5 (the rainbow-coloured mesh).
(bottom) The Ferrari F138 by Kunos has got six colliders in the config file. The 3D collider has been hidden for clarity purposes. COLLIDER_4, which isn’t at ground level, it is at the
pilot’s head level instead. That’s for the roll hoop, a safety feature of F1 cars. The config isn’t limited only to ground level objects. Even a driver halo’s collider may be added.

Here we have a mod example instead (Fig.).

380
Fig. – You can clearly see how colliders have been used for the front splitter and for the underside of the vehicle.

- It is advisable to use just one collider that goes the front tyres to the rear tyres (Fig.), but to be honest, there aren’t other specific rules about where you
have to place them, so the limit is just your creativity. The cost is always the computational performance.

Fig. – Often a single collider will completely fulfill your needs. It can also be easier to manage.

- Keep the 3D collider.kn5 as you made it (following the rules) for the vehicle body, and change the values in colliders.ini for the floor of the car. Parametric
ground colliders are not a replacement for the 3D collider mesh: both systems are required!

- The reference point of the values is the car’s CoG (center of gravity) as determined in the data files. Changing the model won’t alter the position of the
ground colliders.

381
11. ctrl_4ws.ini
This is a dedicated controller file. You can use it for both active and passive 4 Wheel Steering. Nissan GT-R R34, Mada RX-7, Porsche 918, Carrera S and
GT3 RS have different versions of this stuff.
[CONTROLLER_0]
INPUT=LATG ; OVERSTEER_FACTOR REAR_SPEED_RATIO SLIPANGLE_FRONT_AVERAGE SLIPANGLE_FRONT_MAX SLIPANGLE_REAR_AVERAGE SLIPANGLE_REAR_MAX RPMS STEER_DEG
WHEEL_STEER_DEG LATG
COMBINATOR=ADD
LUT=(|-0.55=-0.0008|-0.3=0.0005|-0.1=0.0|0=0|0.1=0.0|0.3=-0.0005|0.55=0.0008|)
FILTER=0.99
UP_LIMIT=100
DOWN_LIMIT=-100

LITTLE EXPLANATION
- ctrl_4ws.ini can be used to simulate rear axle steering. It’s one of those features that has popped up a few times over the years but was usually ahead of its
time. Or at least ahead of the complexity required and the engineering cost to make it reliable. But that hasn’t stopped automakers from trying it. Over and
over and over.

Honda was one of the first to bring rear-steer to the market in the late ’80s. The four-wheel steering system was followed Nissan’s HICAS system but both
didn’t stick around. GM had Quadrasteer, which was offered on full-size trucks and 2500 series Suburbans in the mid-2000s. Porsche’s 928 had a passive
rear axle that could increase rear toe-in when braking, but that’s not exactly the same.

There are a few different effects from steering the rear wheels. Increased stability, improved maneuverability, a decreased turning radius. Oh, and more
steering parts to wear out and then fail. Especially if the manufacturer decides that it’s not going to keep offering the feature.

- Turn the rear wheels the opposite way as the front wheels and the car pivots around the center axis. The rear wheels don’t turn much, less than 15 degrees
in most cases and just 3-5 in others. It makes the wheelbase feel shorter. The Cadillac CT6, which is a very large car, trims its turning radius by a full three
feet with active rear steering.

Turn those back wheels at speed, though, and things get more interesting. Ever try and crank the wheel in reverse when you’re moving quickly? So at speed,
the rear wheels turn in the same direction as the front. That lets the vehicle almost crab walk over into the next lane. Instead of turning, you’re making a
diagonal movement. The effect is like making the wheelbase longer. Like turning a bus instead of a sports car. It’s a smoother movement, so the car feels
more stable as you make a lane change. If you’re towing, like in the pickups, the trailer gently follows. It actually reduces sway and makes it easier to control.

So how does it work? Basically, there is a small steering rack fitted to the rear axle. Since the wheels don’t turn very far, it can be much more compact than
what you’d find on the front wheels. From that there are tie rods that link to the rear hubs, and those rear hubs can pivot. It’s like a tiny version of the front
suspension layout, mounted in the back.

There’s no steering column leading to the back wheels either. The call to steering is done by computer. A sensor on the steering column measures what
you’re trying to do. It tells the computer, which also knows how quickly you’re moving. From there, the computer decides to either turn the rear wheels with
the fronts or the opposite. The speeds where the direction changes depend on the manufacturer and the type of vehicle. On a 911, for example, the switch
happens somewhere around 50 mph. Cadillac’s system changes the speed depending on which dynamic mode the vehicles is in.

Audi’s system works a bit differently. Instead of the smaller rear steering rack, each rear wheel has a small electric actuator. These take advantage of Audi’s
48-volt system. A moving link from the actuator to the hub toes each wheel in or out to steer the rear of the car. It’s the same basic idea, though. It moves
the rear wheels and either makes the vehicle turn tighter or change lanes more smoothly.

On heavy trucks and buses rear steering axles are VERY common nowadays.

382
11. damage.ini
The script that manages the VISUAL and/or MECHANICAL damage of your car. This has very little theoretic relation with physics, given that you can set at
which speed and acceleration a vehicle part gets visual and/or mechanical damage.
Be aware that this is not realistic at all, because there is not a simulation of deformations and damage. Everything is user-defined, so damage is more of an
artistic expression. With some reasoning and logic though you can make something quite good out of this. Look at the official cars for example.
[SCRATCHES]
MIN_SPEED=0 ; [km/h]
MAX_SPEED=20 ; [kmh]

[DAMAGE]
INITIAL_LEVEL=20

[DAMAGE_GLASS_FRONT]
MIN_SPEED=20 ; Minimum vehicle speed for the glass damage to appear (usually on the windscreen). [km/h]
FULL_SPEED=80 ; MAXIMUM DAMAGE SPEED

[DAMAGE_GLASS_REAR]
MIN_SPEED=20 ; MINIMUM DAMAGE SPEED
FULL_SPEED=80 ; MAXIMUM DAMAGE SPEED

[DAMAGE_GLASS_LEFT]
MIN_SPEED=20 ; MINIMUM DAMAGE SPEED
FULL_SPEED=80 ; MAXIMUM DAMAGE SPEED

[DAMAGE_GLASS_RIGHT]
MIN_SPEED=20 ; MINIMUM DAMAGE SPEED
FULL_SPEED=80 ; MAXIMUM DAMAGE SPEED

[DAMAGE_GLASS_CENTER]
MIN_SPEED=20 ; MINIMUM DAMAGE SPEED
FULL_SPEED=80 ; MAXIMUM DAMAGE SPEED

[OSCILLATIONS]
ENABLED=1

[VISUAL_OBJECT_0]
NAME=MOTORHOOD ; NAME OF THE NODE
STATIC_ROTATION_AXIS=-1,0,1 ; STATIC ROTATION AXE
STATIC_ROTATION_ANGLE=2.86 ; STATIC ROTATION ANGLE
MULT_G=0.1 ; EFFECT OF THE G FORCES ON THE OSCILLATION
DAMAGE_ZONE=FRONT ; ZONE IDENTIFIER
MIN_SPEED=0 ; MINIMUM DAMAGE SPEED
FULL_SPEED=20 ; MAXIMUM DAMAGE SPEED
OSCILLATION_AXIS=-1,0,0 ; OSCILLATION AXE
OSCILLATION_MIN_ANGLE=0 ; MINIMUM ANGLE OF OSCILLATION - never less than 0 and never more than 5
OSCILLATION_MAX_ANGLE=5 ; MAXIMUM ANGLE OF OSCILLATION - never less than 0 and never more than 5
ALLOWED_G=0,1,1 ; SET WHICH G AXIS HAVE EFFECT ON DAMAGE ANIMATION and how much (0 is off, 1 is 100%)

[VISUAL_OBJECT_1]
NAME=FRONT_BUMPER ; NAME OF THE NODE
STATIC_ROTATION_AXIS=-1,0,0.5 ; STATIC ROTATION AXE
STATIC_ROTATION_ANGLE=5.76 ; STATIC ROTATION ANGLE
MULT_G=0.1 ; EFFECT OF THE G FORCES ON THE OSCILLATION
DAMAGE_ZONE=FRONT ; ZONE IDENTIFIER
MIN_SPEED=0 ; MINIMUM DAMAGE SPEED
FULL_SPEED=20 ; MAXIMUM DAMAGE SPEED
OSCILLATION_AXIS=-1,0,0 ; OSCILLATION AXE
OSCILLATION_MIN_ANGLE=0 ; MINIMUM ANGLE OF OSCILLATION - never less than 0 and never more than 5
OSCILLATION_MAX_ANGLE=4 ; MAXIMUM ANGLE OF OSCILLATION - never less than 0 and never more than 5
ALLOWED_G=0,1,1 ; SET WHICH G AXIS HAVE EFFECT ON DAMAGE ANIMATION and how much (0 is off, 1 is 100%)

[VISUAL_OBJECT_2]
NAME=REAR_BUMPER ; NAME OF THE NODE
STATIC_ROTATION_AXIS=1,0,0 ; STATIC ROTATION AXE
STATIC_ROTATION_ANGLE=5.76 ; STATIC ROTATION ANGLE
MULT_G=0.01 ; EFFECT OF THE G FORCES ON THE OSCILLATION
DAMAGE_ZONE=REAR ; ZONE IDENTIFIER
MIN_SPEED=0 ; MINIMUM DAMAGE SPEED
FULL_SPEED=20 ; MAXIMUM DAMAGE SPEED
OSCILLATION_AXIS=1,0,0 ; OSCILLATION AXE
OSCILLATION_MIN_ANGLE=0 ; MINIMUM ANGLE OF OSCILLATION - never less than 0 and never more than 5
OSCILLATION_MAX_ANGLE=5 ; MAXIMUM ANGLE OF OSCILLATION - never less than 0 and never more than 5
ALLOWED_G=0,1,0 ; SET WHICH G AXIS HAVE EFFECT ON DAMAGE ANIMATION and how much (0 is off, 1 is 100%)

LITTLE EXPLANATION
- The debug of damage zones can be done in ksEditor. (material)

- You can make things like the exhaust (or rear mirror) “jiggle” through damage.ini. Try something similar to what you find below - the important bits are
MIN_ and FULL_SPEED, as setting them both to -1 means the “damage” is on all the time:
[VISUAL_OBJECT_0]
NAME=Exhaust1
STATIC_ROTATION_ANGLE=0
MIN_SPEED=-1 ; three the most important values
FULL_SPEED=-1
ALLOWED_G=0,0,0
OSCILLATION_AXIS=0,-1,1 ; change this to choose axis
OSCILLATION_MAX_ANGLE=1 ; and this to change amplitude

Another example of a swinging object can be a keychain on the dash, like the Lancia Fulvia 1.6 HF mod has (Fig.).

383
Fig. – The swinging keychain of the Lancia Fulvia mod.

This is the code for that exact purpose:

[VISUAL_OBJECT_1]
NAME=keychain
STATIC_ROTATION_AXIS=0,0,0
STATIC_ROTATION_ANGLE=0
MULT_G=0.00001
DAMAGE_ZONE=FRONT
MIN_SPEED=-1
FULL_SPEED=-1
OSCILLATION_AXIS=-1,0,0
OSCILLATION_MIN_ANGLE=0
OSCILLATION_MAX_ANGLE=40
ALLOWED_G=-1,0,0

Be aware that it encounters a limitation of the AC engine, so it only swings to one side,
and quite slowly (may be adjusted with MULT_G).

To clarify some more, you don’t need a NULL for damageable wobbly parts, it’s just for
convenience. You can use the origin of the object’s mesh like in the keychain example
above.

Fig. shows how the origin was placed in the right spot for the keychain to oscillate
around the ring correctly.

Fig. – As you can see the origin is in the center of the ring.

CURIOSITIES AND AMENITIES

- Why a good simulator with a physically based damage model doesn’t exist out there?
The problem is not the manufacturers who don’t want to see their cars damaged, that one is mainly a Gran Turismo philosophy (which to me makes no
sense, as they could simply add an option to enable or disable damage). So much fuss over gasoline-sucking pieces of iron. But then ask Kazunori
Yamauchi, that’s more artistic direction than anything else.

The real trouble is the amount of calculations required to make a good damage model. Following the principle of realism, you don't want to simulate
sponges like in BeamNg, which reminds me a lot of Algodoo, a little program to play with physics.
You’d need to account for the strain resistance of the materials, the chassis deformation during the impact, the destruction of mechanical parts. All of this
requires a ton of research, data and computational power. Also, from the point of view of the graphic engine you would have to implement bones for your
meshes to let them interact with the physics. Just simulating the deformation of a small bolt or bracket can take up to several minutes with an engineering
software like Solidworks, designed to give you only the end result (Fig.), not an interactive environment.

384
Fig. – Just look at how many triangles you need to get an accurate result.

Imagine doing this in real-time. Not only that. Even if we had the CPU and GPU compute power needed, a complete damage model includes energy absorbing
zones made by the manufacturers with crash test results, so patented data, authorizations, etc. are required. If back in the day Kunos had added a sketchy
dynamic damage model, so not very realistic, people would've complained, so devs kept it as it was in the first place, basically textures. Maybe some day CSP
(or Kunos themselves?) will bring detachable meshes for cars and more complex particle effects (like bolts and small springs on the road), so at least you will
see some "shattering shards" on the track; that will be the compromise. Hood deformation effects are already there.
Not to mention the fact that once the car is destroyed, the race ends. Imagine the chaos in multiplayer. Realism kills fun here, and those who can enjoy
wrecking cars and seeing them burn are only a niche (luckily). I know I would have fun with crash tests, but that’s beyond the purpose of a racing simulator,
and in that case BeamNG is better.
I personally believe it’s good to not have an accurate damage model. It’s a sign of respect towards all the pilots who lost their life or had various accidents
during the many years of motorsport (Fig.).

Fig. – (Maybe too harsh. Replace image?)

385
12. dash_cam.ini
This config file is pretty simple, as it only sets the parameters for the position of dash cam of your vehicle. This camera is the one you can use to drive with
your hardware wheel in front of the screen, hiding the virtual one and the driver 3d model. It’s usually the second interior view activated when cycling
between the cameras with the F1 key on your keyboard.
[DASH_CAM]
POS=-0.00324544,1.05167,-0.958184 ; (x,y,z) x-/rightt; z+/forward
EXP=28 ; Exposure level.

13. digital_instruments.ini

If it wasn’t already obvious, this script controls the digital instrumentation of your vehicle: displays, timers, etc. You can also set the parameters for eventual
LEDs on the steering wheel (the ones that light up for RPMs near redline, often present on GT or GT3 sport cars).
Always delete the contents of this file at the beginning of a new project, because it always causes crashes, as often it looks for dummies or objects that are
likely not present on your model. (instead of a single script, let’s put example modules)
[FUEL_WARNING_0]
OBJECT_NAME=fuel_indicator_off
FUEL_SWITCH=8

[WATER_TEMP_0]
PREFIX=WATER_TAG_
START_TEMP=40
END_TEMP=110
LED_COUNT=12

[ITEM_0]
PARENT=DISPLAY_SPEED ; Name of the NULL, following the standard for digital instruments.
TYPE=SPEED ; Function of the instrument.

% ▲ List of all kinds of TYPE values; some are very useful for GT3 cars:

SPEED
RPM
CLOCK
AMBIENT_TEMP
GEAR
FUEL
FUEL_CONS
LAPTIME
PERF
RPM_GRAPH
TC_LEVEL
WATER_TEMP
PLACE_HOLDER

POSITION=0,-0.0075,0 ; Position relative to the parent object.

SIZE=0.013 ; Font size in meters.
COLOR=255,255,255 ; Color of the font in RGB (red, green, blue) format (it can also be R,G,B,A where A is the Alpha).
INTENSITY=2 ; Intensity of illumination.
FONT=e92_big ; Font of the display (for custom fonts).
VERSION=2 ; This is needed for the latest vanilla features (not documented); leave at 2.
ALIGN=CENTER ; Alignment of the text. Can be LEFT, CENTER, RIGHT.
UNITS=KMH ; Line for the SPEED unit displayed; input can be KMH [Km/h], MPH [miles/h] or SYSTEM (from AC options)

[ITEM_1]
PARENT=DISPLAY_RPM
TYPE=RPM
POSITION=0,-0.0075,0
SIZE=0.013
COLOR=255,255,255
INTENSITY=2
FONT=e92_big
VERSION=2
ALIGN=CENTER

% ▼ We can have a lot of instruments, so below we’ll keep only the differences between them and the lines of code that have the same functions will be
skipped. There are no missing lines compared to [ITEM_1].

[ITEM_2]
PARENT=DISPLAY_CLOCK
TYPE=CLOCK
[skipping lines similar to ITEM_1]

[ITEM_3]
PARENT=DISPLAY_TEMP
TYPE=AMBIENT_TEMP
[skipping lines similar to ITEM_1]

[ITEM_4]
PARENT=DISPLAY_TEMP
TYPE=PLACE_HOLDER
TEXT=@ ; Placeholder text for the temperature display.
[skipping lines similar to ITEM_1]

[ITEM_5]
PARENT=DISPLAY_DATA
TYPE=GEAR
N_TIME=0.3 ; Transition time between one gear number/letter and another. [s]

% ▲ Puts a delay on Neutral so it doesn't jump back to N between gears. Useful for modern cars where the gear change is shown seamlessly.

[skipping lines similar to ITEM_1]

[ITEM_6]
[ITEM_7]
[...] ; A vehicle can have as many [ITEMS] as necessary.

[KERS_INPUT_SERIE_0]
PREFIX=TAG_EMISSION_
START_INDEX=0
END_INDEX=15

[KERS_RECHARGE_SERIE_0] ; harvest series function

386
PREFIX=TAG_CHARGE_
START_INDEX=0
END_INDEX=13
NORM_MAX=0.001192

[SPEED_SERIE_0] ; series script for digital speed bars

PREFIX=TAG_SPEED_
START_SPEED=0
END_SPEED=350
LED_COUNT=35

[POWER_918_0] ; Porsche 918 Spyder-style full power usage series function

PREFIX=TAG_RPM_
START_TORQUE=0
END_TORQUE=980
LED_COUNT=44
FILTER=0.85

[LED_0]
OBJECT_NAME=LED_0
RPM_SWITCH=7400
EMISSIVE=0,40,0
DIFFUSE=0.1
BLINK_SWITCH=7400
BLINK_HZ=0

[LED_1]
OBJECT_NAME=LED_1
RPM_SWITCH=7600
EMISSIVE=0,40,0
DIFFUSE=0.1
BLINK_SWITCH=7600
BLINK_HZ=0

[LED_2]
OBJECT_NAME=LED_2
RPM_SWITCH=7800
EMISSIVE=0,40,0
DIFFUSE=0.1
BLINK_SWITCH=7800
BLINK_HZ=0

[LED_3]
[LED_4]
[...] ; A vehicle can have as many [LEDs] as necessary.

[FUEL_0]
OBJECT_NAME=FUEL_TAG_0
FUEL_SWITCH=1

[FUEL_1]
OBJECT_NAME=FUEL_TAG_1
FUEL_SWITCH=12

[FUEL_2]
OBJECT_NAME=FUEL_TAG_2
FUEL_SWITCH=24

[FUEL_3]
OBJECT_NAME=FUEL_TAG_3
FUEL_SWITCH=36

[FUEL_4]
OBJECT_NAME=FUEL_TAG_4
FUEL_SWITCH=48

[FUEL_5]
OBJECT_NAME=FUEL_TAG_5
FUEL_SWITCH=60

[FUEL_6]
OBJECT_NAME=FUEL_TAG_6
FUEL_SWITCH=70

[FUEL_7]
OBJECT_NAME=FUEL_TAG_7
FUEL_SWITCH=80

[FUEL_8]
OBJECT_NAME=FUEL_TAG_8
FUEL_SWITCH=90

[FUEL_9]
OBJECT_NAME=FUEL_TAG_9
FUEL_SWITCH=100

387
14. digital_panels.ini

This is the script you’ll have to create when working with digital panels.

Position
Use the following script to activate the function:
[FULLPOSITION_SERIES_0]
PREFIX=textName_ ; prefix of texture names located in your_car_folder/texture/display_panel.
POSITION=
PARENT=DUMMY ; parent dummy name.
START=0 ; postfix start.
END=9 ; postfix end.
DIGIT=1 ; set 1 for second digit, 10 for first digit.
WIDTH=30
HEIGHT=40
COLOR=255,255,255,255
INTENSITY=2

Push-to-Pass
Use the following script to activate the function:
[PUSH2PASS_SERIES_0]
PARENT=PANEL_P2P ; name of parent dummy.
POSITION=0.0615,-0.068,0
WIDTH=0.124
HEIGHT=0.137
TRIGGER=0
PREFIX=num_ ; prefix of texture names.
COLOR=255,255,255,255
INTENSITY=40.0
START=0 ; name postfix to start from
END=9 ; name postfix to end at
DIGIT=1 ; (=1 for second digit, =10 for first digit)
BLINK_HZ=5 ; blink rate when activated (=0 for no flashing)

Push-to-Pass status led

[PUSH2PASS_LED_0]
OBJECT_NAME=LED_P2P
EMISSIVE=0,0,800
DIFFUSE=0.35
INVERTED=0 ; for inverse function
BLINK_HZ=0 ; if higher than 0, it blinks

LITTLE EXPLANATION

- The digital panels’ colour is defined in digital_panels.ini.

- Known limitation: in replays, the P2P (Push-to-Pass) and displayed position status is not communicated, which is why the panels will show incorrect or
placeholder values.

388
15. driver3d.ini

This script manages the behaviour and the animations of the virtual driver model inside the car.
[MODEL]
NAME=driver_skidlid ; This value determines which driver model will be used (there are different models available).
POSITION=0,0,0 ; Position of the driver.

[STEER_ANIMATION]
NAME=steer.ksanim ; Determines which animation clip to use for the steering wheel.

% ▲ The default name is steer.ksanim and it makes the clip immediately recognizable, as widely used. It is recommended to use the same name for your
steer animation when exporting.

LOCK=360 ; Rotational limit of the steering animation. [degrees]

% ▲ It's just a value calibrated to match the driver animation, unrelated to physical steering lock. Changing it can only break the driver visuals. You
put here the steering lock of the driver animation file. If the animation does only 1 turn, you put here 360, if it does more turns you put 720 and so
on.

% ▲ If you want the animation to be correct, you have to make 100 frames for each direction of the steering wheel: frame 0 is 360 degrees left of center
frame 100, and frame 200 is 360 degrees right of frame 100. The full animation is actually a rotation of 720° from side to side.

[SHIFT_ANIMATION] ; Lines that manage the driver animations.

BLEND_TIME=100 ; Time needed to move the driver’s hand from the steer position to the first frame. [milliseconds]
POSITIVE_TIME=250 ; Time needed to move the hand from the first frame to the gear lever (forward anim.). [ms]
STATIC_TIME=102 ; Interval where the hand is still on the gear lever (Wait Time between forward & reverse anim.). [ms]
NEGATIVE_TIME=250 ; Time needed to move the hand from the gear lever back to the first frame (reverse anim.). [ms]
PRELOAD_RPM=5600 ; When the car’s engine reaches this regime the forward anim. is automatically played. [RPM]

% ▲ Preload time: plays the first half of the animation, actually shifting plays the second half, then it reverses through the whole thing (ping-pong
animation, for more info see par.)

INVERT_SHIFTING_HANDS=1 ; Set to =1 if the driver shifts with the left hand. =0 if he shifts with the left hand.

[HIDE_OBJECT_0] ; Change the ID number to add more objects to hide; SYNTAX: [HIDE_OBJECT_ID]; ID starting from zero.
NAME=helmet_sub1 ; Hides the specified mesh of the driver model when in cockpit view. In this case the helmet is hidden.

[HIDE_OBJECT_1]
NAME=DRIVER:GEO_Driver_FACE ; Another example: here the driver’s head is hidden.

% ▲ Note: The driver meshes may have different names if you use a custom driver model.

[HEAD_MOVEMENT] ; Parameters for the movement of the virtual driver’s head when subject to accelerations.
FILTER=0.150000 ; 0=no movement, do not use. Low values=high filter, high values=low filter

% ▲ Amount of filtering applied to the g acceleration values.

MAX_G=1.500000 ; Max G level allowed. G above this value will be clamped. [m/s^2]

% ▲ Maximum acceleration appliable to the driver’s head for the calculation of its movement. 1G = 9.81 m/s^2.

ROLL_MAX_DEG=-8 ; Head roll vs lateral G acceleration. Maximum rotation at the MAX_G lateral acceleration value. [deg]

% ▲ Maximum roll angle for the movement of the driver’s head.

PITCH_MAX_DEG=-7 ; Same as above (ROLL_MAX_DEG) but for head pitch vs longitudinal G (braking). [deg]
YAW_MAX_DEG=12 ; Same as above (ROLL_MAX_DEG and PITCH_MAX_DEG) for head yaw vs lateral G. [deg]

% ▲ The visual representation of the three angles is in Fig..

Fig. – For a better understanding of which angle is which, here you have all of them.

LITTLE EXPLANATION
- Here we have an alternative description of the parameters for the shifting animation:
[SHIFT_ANIMATION]
BLEND_TIME=140 ; Time it takes the driver's hand to reach from the wheel towards the shifter.
POSITIVE_TIME=400 ; Time it takes to grab the shifter and change into gear
STATIC_TIME=120 ; How long the driver keeps their hand on the shifter
NEGATIVE_TIME=400 ; Time it takes the driver's hand to let go of the shifter and start heading back towards the wheel
PRELOAD_RPM=7400 ; The driver will reach for the shifter after the engine has exceeded this specified engine RPM, or
take their hand off the shifter if you fall below this specified RPM.

Tweaking these parameters can really help achieve the realistic look of manual shifts.

FAQ
QUESTION [1]: What happens if I don’t include driver3d.ini in the data of my vehicle?
ANSWER: acs.exe crashes and you get this error (Fig.).

389
Fig. – Why did you ask?
QUESTION [2]: I want the shifting animation to be triggered by pressing my Fanatec clutch pedal, instead of the animation being tied to each car's high RPM
value.
ANSWER: It is not possible. The shift animation is triggered on gear change and there's no way for the game to predict it. The PRELOAD_RPM line is the only
thing controlling it.
If you don’t want to see the preload animation, set PRELOAD_RPM to some higher number. I would set it above the engine rev limit to turn the preloading
completely off, so that the driver will move his hand on the gear lever only when shifting happens.
At least AC has shifting animations, half of the other sims don't.

QUESTION [3]: Can I make and use my own driver model?

ANSWER: Yes, of course, but you will have to include it in your mod’s files for people to be able to use it. A vehicle with a custom-made driver model won’t
work if the model specified in the [MODEL] section of driver3d.ini does not exist in the AC files, specifically in this path: %root%\assettocorsa\content\driver

QUESTION [4]: Can I make vehicles with a hidden driver?

ANSWER: It is possible, probably with the [HIDE_OBJECT_ID] lines, but I suggest doing so only for really exotic vehicles (Fig.). If yours is a real-world
car, include it. People can always hide it if they don’t like it. It’s better to have more alternatives than less, right?

Fig. - Is this a joke? Most likely yes, and the only thing that remains visible is the head.

390
16. drivetrain.ini
This is the file that manages the parameters for the transmission and differential. It can have a huge influence on the car’s performance, top speed and
acceleration.
[HEADER]
VERSION=3 ; 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=RWD ; Traction type of the vehicle. Acceptable values are RWD, FWD, AWD, AWD2.

[GEARS]
COUNT=4 ; Number of forward gears. Maximum amount is 10.

% ▲ After gear 8, the numbers won’t work anymore: gear 9 and 10 will be displayed as eLinear and eBezier by AC. After the 10th gear, the vehicle won’t
upshift, even if there are 11th or 12th or more gear ratios.

GEAR_R=-2.840 ; Gear ratio for the reverse with any possible overdrive, but without final gear. Input example: -3.382
GEAR_1=2.880 ; Forward gears ratios. must be equal to number of gears defined on COUNT
GEAR_2=1.91
GEAR_3=1.27
GEAR_4=1.00

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

FINAL=3.27 ; Final gear ratio.

[DIFFERENTIAL]

% ▲▼ The rules for the differential are always required by AC to load, but not used (means still present) if the car has the AWD or AWD2 traction types.

POWER=0.012 ; differential lock under power. 1.0=100% lock - 0 0% lock

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

COAST=0.012 ; differential lock under coasting. 1.0=100% lock 0=0% lock

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

% ▲▲ A value of 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. For open diffs it would be beneficial to increase lock
from 0.00 to 0.01 - 0.03 or so, to account for the internal friction of the system binding wheels together.

PRELOAD=12 ; Differential preload torque setting. [Nm]

% ▲ The preload is the minimum torque that is necessary to make the differential spin (due to internal friction). It can be measured via a torque wrench
if you remove the differential from the vehicle (Fig.).

Fig. –

Otherwise you can estimate it.

By the way is it

[GEARBOX]
CHANGE_UP_TIME=169 ; Mechanical upshift time. [ms]
CHANGE_DN_TIME=240 ; Mechanical downshift time. [ms]
AUTO_CUTOFF_TIME=170 ; Auto cutoff time for upshifts, set to 0 to disable. [ms]
SUPPORTS_SHIFTER=1 ; 1=Car supports shifter, 0=car supports only paddles
VALID_SHIFT_RPM_WINDOW=1200 ; range window additional to the precise rev matching rpm that permits gear engage.
CONTROLS_WINDOW_GAIN=0.6 ; multiplier for gas,brake,clutch pedals that permits gear engage on different rev matching rpm. the
lower the more difficult.
INERTIA=0.02 ; Gearbox inertia. By default value goes to 0.02 if not set. [kg*m^2]

[CLUTCH]
MAX_TORQUE=300

[AUTOCLUTCH]
UPSHIFT_PROFILE=NONE ; Name of the autoclutch profile for upshifts. NONE to disable autoclutch on shift up
DOWNSHIFT_PROFILE=DOWNSHIFT_PROFILE ; Same as above for downshifts
USE_ON_CHANGES=0 ; Use the autoclutch on gear shifts even when autoclutch is set to off. Values: 1, 0.

391
% ▲ Needed for cars with semiautomatic gearboxes.

MIN_RPM=900 ; Minimum rpm for autoclutch engadgement

MAX_RPM=4000 ; Maximum rpm for autoclutch engadgement
FORCED_ON=0 ; If set =1 disables manual clutch.

[UPSHIFT_PROFILE]
POINT_0=50 ; Time to reach fully depress clutch
POINT_1=110 ; Time to start releasing clutch
POINT_2=150 ; Time to reach fully released clutch

[DOWNSHIFT_PROFILE]
POINT_0=20 ; Time to reach fully depress clutch
POINT_1=320 ; Time to start releasing clutch
POINT_2=800 ; Time to reach fully released clutch

[AUTOBLIP]
ELECTRONIC=0 ; If =1 then it is a feature of the car and cannot be disabled
POINT_0=50 ; Time to reach full level
POINT_1=200 ; Time to start releasing gas
POINT_2=220 ; Time to reach 0 gas
LEVEL=0.95 ; Gas level to be reached

[DAMAGE]
RPM_WINDOW_K=100

[AUTO_SHIFTER]
UP=5000
DOWN=3800
SLIP_THRESHOLD=0.99 ; Slip ratio needed to shift up regardless of rpm.
GAS_CUTOFF_TIME=0.170

[DOWNSHIFT_PROTECTION] ; Automatic protection to prevent engine damage when downshifting too early or at high vehicle speed.
ACTIVE=1
DEBUG=0 ; Adds a line in the log for every missed downshift.
OVERREV=200 ; How many RPM over the limiter the car is allowed to go.
LOCK_N=0 ; Lock neutral (prevent it from engaging) unless the car is stationary.

[AWD]

% ▲▼ If you set the traction TYPE under [TRACTION] to AWD, the lines below must be present. [AWD] codes are required by AC even if you set [TRACTION] to
AWD2, but they are not used. Keep in mind that the rules under [DIFFERENTIAL] must always be included, whichever the traction type is.

FRONT_SHARE=50 ; AWD front mechanical split in full percentage values. For example 50% = 50. [0 - 100]

% ▲ Think of it as if the torque coming from the engine. You get out of the engine 100Nm. You set FRONT_SHARE=40. That means that 40Nm will go to the
front wheels and 60Nm to the rear wheels.

FRONT_DIFF_POWER=0.002 ; same as “POWER” but for AWD type.

FRONT_DIFF_COAST=0.002 ; same as “COAST” but for AWD type.
FRONT_DIFF_PRELOAD=2 ; same as “PRELOAD” but for AWD type.
CENTRE_DIFF_POWER=0.002 ; same as “POWER” but for AWD type.
CENTRE_DIFF_COAST=0.002 ; same as “COAST” but for AWD type.
CENTRE_DIFF_PRELOAD=2 ; same as “PRELOAD” but for AWD type.
REAR_DIFF_POWER=0.002 ; same as “POWER” but for AWD type.
REAR_DIFF_COAST=0.002 ; same as “COAST” but for AWD type.
REAR_DIFF_PRELOAD=2 ; same as “PRELOAD” but for AWD type.

% ▲ Like for [DIFFERENTIAL], here setting ~_DIFF_POWER and ~_DIFF_COAST to a value of 1.0 for any of the differentials is a special case in AC that
removes the diff and makes it a spool.

[AWD2]
FRONT_DIFF_POWER=0.002 ; same as “POWER” but for AWD2 type.
FRONT_DIFF_COAST=0.002 ; same as “COAST” but for AWD2 type.
FRONT_DIFF_PRELOAD=2 ; same as “PRELOAD” but for AWD2 type.
CENTRE_RAMP_TORQUE=76.0 ; Ramp-up torque for Viscous center differential, per rad/s of differential speed between front and
rear axle. [Nm]
CENTRE_MAX_TORQUE=800.0 ; Maximum torque for Viscous center differential, at the wheels after gearing. [Nm]

% ▲ AWD2 has a viscous coupling based on wheel speed difference. And it can‘t provide preload.

% One may set “CENTRE_RAMP_TORQUE” and “CENTRE_MAX_TORQUE” to the same value when using ctrl_awd2.ini AWD2 center diff controller to control the “maximum
lock” of the center differential. Bear in mind that lower gears will offer a lower effective maximum lock % than higher gears due to greater amount of
torque available, which will result in center differential slip. Typical values are approximated to be 500 - 1500Nm~.

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

REAR_DIFF_POWER=0.002 ; same as “POWER” but for AWD2 type.

REAR_DIFF_COAST=0.002 ; same as “COAST” but for AWD2 type.
REAR_DIFF_PRELOAD=2 ; same as “PRELOAD” but for AWD2 type.

% ▲ Like for [DIFFERENTIAL] and for [AWD], here setting ~_DIFF_POWER and ~_DIFF_COAST to a value of 1.0 for any of the differentials is a special case in
AC that removes the diff and makes it a spool.

ABOUT RELATED FILES

Gear ratio files (.rto):
They are used for cars with multiple gear ratio options. The setup.ini will refer to them.

final.rto
The value you use in drivetrain.ini for the final gear ratio (FINAL) has to exist in final.rto.

ratios.rto
This file is only for in-game setup selection, normally you just need to write them into drivetrain.ini as ratios.

Controllers:
ctrl_single_lock.ini
This script controls the preload torque for a rear active differential on a RWD drivetrain (and front diff on FWD?? not sure).
Power and coast settings from drivetrain.ini are discarded (ignored) when the controller is used.
When ctrl_single_lock.ini is found in the vehicle data, the diff is set to have 0% power, coast and preload, and the controller is evaluated every step to
produce a lock value in Nm. Think of it as a dynamic preload.
392
[CONTROLLER_0]
INPUT=GEAR ; OVERSTEER_FACTOR REAR_SPEED_RATIO SLIPANGLE_FRONT_AVERAGE SLIPANGLE_FRONT_MAX SLIPANGLE_REAR_AVERAGE SLIPANGLE_REAR_MAX
COMBINATOR=ADD
LUT=gear_start.lut
FILTER=0.99
UP_LIMIT=10000
DOWN_LIMIT=0.0

[CONTROLLER_1]
INPUT=OVERSTEER_FACTOR
COMBINATOR=MULT
LUT=understeer_factor_vs_lock.lut
FILTER=0.98
UP_LIMIT=10000
DOWN_LIMIT=0.0

[CONTROLLER_2]
INPUT=GEAR
COMBINATOR=MULT
LUT=difflock_gear_mult.lut
FILTER=0.9
UP_LIMIT=10000
DOWN_LIMIT=0.0

[CONTROLLER_3]
INPUT=BRAKE
COMBINATOR=MULT
LUT=difflock_brake_mult.lut
FILTER=0.9
UP_LIMIT=10000
DOWN_LIMIT=0.0

The UNDERSTEER FACTOR

It's a large calculus equation that combines a large number of variables to determine the handling balance of the car.
The way it is calculated in AC is basically the slip angle of the front of the car minus the slip angle of the rear of the car. It gives you a positive number when
the car is oversteering, and a negative number when it is understeering. (Casillo 2015)

ctrl_awd_center_lock.ini
This file controls the centre differential preload torque, in [Nm] for the AWD drivetrain type.
Power and coast values in drivetrain.ini are ignored when the controller is used.
ctrl_awd2.ini
Obviously drivetrain TYPE must be AWD2 for this controller to work. Output is CENTRE_MAX_TORQUE, but the controller only sets the maximum value at any
moment. The actual value is still fundamentally controlled by CENTRE_RAMP_TORQUE.
And you can't actively control front and rear differentials. That’s the same reason why [AWD2] has no lines in setup.ini, while [AWD] has them.

LITTLE EXPLANATION
- Power/coast values are 0-100 in setup.ini but 0-1 in drivetrain.ini. Always remember this!
Example: setup.ini 50 = drivetrain.ini 0.5
Go figure out why; such are the mysteries of this simulator.
- If you don't understand what the fractions values under [GEARS] mean, those are the gear ratios. In the mechanical literature the gears for transmissions
and drivetrains are often referred to with the tooth counts on the actual gears, like 14/37 or 12:45 (Fig.); the ratio itself is the number of teeth on the input
gear (or cog), divided by the number of teeth on the output gear. Be careful when identifying them. The fractions are also used as descriptive labels, and the
real number that is also used by AC is the calculation of those, which you can put in the drivetrain.ini, final.rto and gears.rto files.
Example: 12/37 is 3.08

393
Fig. – (left) Main internal components of a transmission. (right) Various gears belonging to a Volkswagen Transporter T3. The ratio is clearly written on the box: 0,785 (28:22).

The same principle applies to the ratio of the differential, where for the cheapest and simplest types you just have two main spinning parts (Fig.).

Fig. – (left) Spool type differential assembly. (right) Ring and pinion gear.

- With all-wheel drive cars, the FRONT_SHARE value is important because not all permanent AWD cars are 50/50 front/rear (F/R).

- The original [AWD] code isn’t really appropriate for modern cars, it’s more for things like the Audi Quattro, with open center diff, symmetrical torque split; it
is portrayed by a mechanical 3-Lsd AWD like some Audis use.

- [AWD2] is just a better way to simulate AWD for cars that have asymmetrical torque split. It is portrayed by an RWD with clutch to the front and the
controllers determine how much torque the clutch provides (limited to 50% of total). [AWD2] caps out at 50% front. It basically starts with 100% torque on
the rear and can transfer up to 50% to the front.

- The main difference between [AWD] and [AWD2] is that [AWD] has a differential at the center, while [AWD2] has a clutch (a viscous center coupling).

- Always check whether the car mods you download from online websites do have AWD even if the real cars they represent shouldn’t. Some mod creators
add some little “fancy” traction (let’s say four wheel drive instead of two) to the cars to make them driveable, usually given the overall low quality of the
physics. This is technically cheating, but it’s likely to be so subtle that goes unnoticed to the untrained eye.

- Relationship between engine torque and wheel torque. As depicted in

the image above, the engine is the source of torque. The gearbox is
connected to the engine through the clutch (on manual transmissions)
or torque converter (on automatic transmissions).

In this case the engine torque Te is equal to the clutch/torque

converter torque Tc.
𝑇𝑇𝑐𝑐 = 𝑇𝑇𝑒𝑒 (2.2)
Furthermore, the engine torque is transmitted through the gearbox, where is multiplied with the gear ratio of the engaged gear ix and outputs the gearbox
torque Tg.
𝑇𝑇𝑔𝑔=𝑖𝑖𝑥𝑥 ∙ 𝑇𝑇𝑒𝑒 (2.3)
394
The propeller shaft is transmitting the torque to the rear axle, where is multiplied
with the final drive gear ratio i0. This gives the torque at the differential Td.
𝑇𝑇𝑑𝑑 = 𝑖𝑖0 ∙ 𝑇𝑇𝑔𝑔 (2.4)
If the vehicle is driven on a straight line, the torque at the differential is equally
split between the left wheel Tlw and the right wheel Trw.

𝑇𝑇𝑙𝑙𝑙𝑙 = 𝑇𝑇𝑟𝑟𝑟𝑟 =
𝑇𝑇𝑑𝑑
2
(2.5)

The sum of the left and right wheel torque gives the torque at the differential.
Replacing (2.2) in (2.3) in (2.4) gives the mathematical
expression of the wheel torque function of the engine torque, for a given gearbox
ratio ix and a final drive ratio i0.

(2.6)
𝑖𝑖𝑥𝑥 𝑖𝑖0 𝑇𝑇𝑒𝑒
𝑇𝑇𝑤𝑤 =
2

If we consider nw as the number of driving wheels, then the wheel torque

formula will have the general form of:

(2.7)
𝑖𝑖𝑥𝑥 𝑖𝑖0 𝑇𝑇𝑒𝑒
𝑇𝑇𝑤𝑤 =
𝑛𝑛𝑤𝑤

If the vehicle is rear wheel drive (RWD) or front wheel drive (FWD) then nw = 2, if the vehicle is four-wheel drive (4WD) or all-wheel drive (AWD) the nw =
4. If the vehicle is a motorcycle (who knows???) then nw = 1.
wip

- In the AC SDK there is the ksGearRatioEditor app (Fig.). This simple tool creates cogs for gear ratios. It is a solver, meaning that it generates possible
solutions.

Fig. – The ksGearRatioEditor solver with some examples. This OS has the comma as decimal character, pay attention to that.

Here's what to do, start with the RatioToGear tab. Insert a ratio you have, for example 3.65. Input the minimum and maximum cogs "available" and fill in the
acceptable error. The tool will generate all the possible options.

In the second tab GearToRatio, you can create similar results but for all the gears you might need instead of going through every single one, saving time.

Note: the tool has a problem with the decimal symbols (mark or comma). If your OS has the comma (,) as decimal character, use that. If you can, go to the
International settings of your operating system and change the decimal character to point. Do not mix commas with points! Use either one or the other,
depending on the standard present on your PC.
Pro tip: keep in mind that, based on the input parameters, there may not be always a solution, especially for very small Ratios, low Error parameters, or for very narrow Min-
Max ranges. For example, if Ratio = 0.05, Min = 7, Max = 70, Error = 0.05, there is only one solution. If you reduce the Error margin to 0.04 there are no solutions.
If you need for instance 3.751:1, it is hardly that you'll get exactly that with no error, so you give it a 1% chance to recalculate, then you'll get a lot of combinations, you
reduce that error margin, until 2-5 results are left, and you choose the one that is most accurate.

395
- About top fuel Dragsters: in AC there is not really any way of simulating a 6-plate clutch system with an automatic 6 speed gearbox.

CSP ADDITIONS
- Since CSP release 0.1.76 it’s possible to get additional clutch damage from high torque when shifting. New options are set in drivetrain.ini, next to the
vanilla damage option:
[DAMAGE] ; Vanilla section.
TORQUE_THRESHOLD= ; uses torque produced by the engine
TORQUE_DAMAGE_K= ; intensity multiplier, similar to existing DAMAGE_K
ENGINE_TORQUE_THRESHOLD= ; uses total drivetrain torque
ENGINE_TORQUE_DAMAGE_K=
CLUTCH_TORQUE_THRESHOLD= ; uses clutch torque
CLUTCH_TORQUE_DAMAGE_K=

The lines are simply added to the already existing [DAMAGE] section.

FAQ
QUESTION [1]: How would you model a torsen differential in AC?
ANSWER [1]: The answer is you don't. AC's diffs just don't work that way (they transfer a percent of input, instead of a percent of the other output, which
only models ramp style LSDs). Probably the closest you can get is setting it to the percent you want to go to the slower axle (eg. in a 5:1, it can be up to
85%). If you use that in combination with traction control you'll get the expected behaviour (of a car with torsen + TC) but if TC is off, there'll be too much
torque put on the wheel with traction.

17. drs.ini

Gyrtsd
[HEADER]
VERSION=2

[WING_3]
MODE=ANGLE

% ▲ ANGLE=uses the ANGLE value and not EFFECT, this angle will override any controller in the wing. EFFECT=Uses only the EFFECT value as a multiplier.

EFFECT=0.1 ; When in EFFECT mode, with DRS on the wing angle will be the current wing angle*EFFECT
ANGLE=10 ; When in ANGLE mode, this value will be set in the wing when DRS is on.

[DRS_ZONES]
IGNORE_ZONES=1 ; Boolean operator. Sets wether or not the DRS zones on the track shall be ignored. Inputs: 0, 1.

[DEACTIVATION]
LIMIT_G=0.5 ;

396
18. electronics.ini
This config file manages the behaviour of the various real-life electronic devices of the vehicle in our simulation: ABS (Anti-lock Braking System), TCS
(Traction Control System) and EDL (Electronic Differential Lock).
[ABS]
SLIP_RATIO_LIMIT=0.10 ; Slipratio limit before ABS engages.
CURVE=abs.lut ; Slipratio lookup table with different slipratio limits, in order to define ABS levels if present.

% ▲ Leave the value completely blank if you wish for a single level given by the SLIP_RATIO_LIMIT line above.

PRESENT=0 ; =1 if ABS is present on the car, =0 if not present.

% ▲ ABS always works if ABS assist is activated from the realism menu UI.

ACTIVE=0 ; =1 the car starts with ABS on (if present), =0 the car starts with ABS off (even if present).

% ▲ You can toggle this value on and off in-game with Ctrl+A.

RATE_HZ=100 ; ABS pulse frequency. It's better to insert the actual ABS pumps refresh rate, than the ECU and
sensors frequency

[TRACTION_CONTROL]
SLIP_RATIO_LIMIT=0.12 ; Slipratio limit before TC engages
CURVE=traction_control.lut ; Slipratio lookup table with different slipratio limits, in order to define TC levels if present.

% ▲ Leave the value completely blank if you wish for a single level given by the SLIP_RATIO_LIMIT line above. ctrl+T to toggle

PRESENT=0 ; 1 if present in car, 0 if not present (TC always work if TC assist is activated from realism menu UI)
ACTIVE=0 ; 1 will make the car start with TC active (if present), 0 will make the car start with TC inactive
(even if present). ctrl+T to toggle
RATE_HZ=100 ; TC pulse frequency. It's better to insert the actual TC pumps refresh rate, than the ECU and sensors
frequency
MIN_SPEED_KMH=40 ; Traction control is set automatically OFF under the min speed value in km/h even if selected as
assist by the user.

[EDL]
PRESENT=0 ; 1 if present in car, 0 if not present (TC always work if TC assist is activated from realism menu UI)
ACTIVE=0 ; 1 will make the car start with TC active (if present), 0 will make the car start with TC inactive
(even if present).
MAX_SPIN_POWER=0.8 ; Brake torque ramp on power. 0=no difference , 1=fast wheel twice the speed of slow wheel
MAX_SPIN_COAST=0.4 ; Brake torque ramp on coast. 0=no difference , 1=fast wheel twice the speed of slow wheel
BRAKE_TORQUE_POWER=50 ; Brake torque to apply to the fastest spinning wheel, on power
BRAKE_TORQUE_COAST=400 ; Brake torque to apply to the fastest spinning wheel, on coast
DEAD_ZONE_POWER=0.2 ; Dead zone for brake torque ramp on power
DEAD_ZONE_COAST=0.0 ; Dead zone for brake torque ramp on coast

LITTLE EXPLANATION
(is this a CSP feature?)
-How to make 4 channel ABS with electronics.ini:
[ABS_V2]
SLIP_RATIO_LIMIT=0.12
CURVE=
PRESENT=1
ACTIVE=1
RATE_HZ=250
CHANNELS=4

ABOUT RELATED FILES

LUTS
traction_control.lut
Example:
0|0.08
1|0.09
2|0.10
3|0.11
4|0.12
5|0.13
6|0.14
7|0.15
8|0.16

abs_control.lut
Example:
0|0.10
1|0.11
2|0.12
3|0.13
4|0.14
5|0.15
6|0.16
7|0.18

FAQ
QUESTION [1]: I have a car which is missing both ABS and TCS (Traction Control System). Now, I don't care about TCS, but I'd like to add the ABS. Do I
have to simply swap the electronics.ini file from a "donor" car?
ANSWER [1]: We’ll make it short: Yes, but if you want to keep ABS only, delete the TCS/EDL sections. At the same time don’t share Frankenstein mods, and
if you do, at least specify which features your customized version has or doesn’t have in the README.txt (see par.8.). Think as if you’re the end user. For
example, how would you feel when you found out that your beloved Audi Quattro mod is only 2WD? You’d feel disappointed, right? Let’s avoid bad
practices.

397
CUSTOM SHADERS PATCH – CSP ADDITIONS
Extended Physics has these lines in electronics.ini
[SPEED_LIMITER]
SPEED_KMH = 159, 161 ; min, max
RATE_HZ = 20

PHYSICS (for electronics.ini)

The ABS: Anti-lock Braking System

Braking stability

If both wheels of an axle lock (if ABS is not fitted), i.e. if they slide on the road, there is not just reduced friction in the longitudinal direction (Fig.), but also
lower friction in the lateral direction. If the rear axle locks, as shown in Fig., lateral forces FY,W,f will occur at the rolling wheels of the front axle, which will
intensify the problem, even in the case of a minor yawing effect, i.e. the condition is unstable.

KL

398
19. engine.ini
You can add parameters for the engine (or motor, whatever you call it) of your vehicle in this config file. Pretty useful, especially if you want to add turbos to
take off and land on the Moon.
[HEADER]
VERSION=1 ; VERSION controls the version of the script that AC will load. It does NOT represent the development
version of the car. Acceptable input is 1.

POWER_CURVE=torque.lut ; Defines the look-up table file (LUT) loaded for the torque curve.
COAST_CURVE=FROM_COAST_REF ; Controls the coast torque method.

% ▲ Defines 3 different options (coast reference, coast values for mathematical curve, coast curve file). Recommended input is FROM_COAST_REF.

[ENGINE_DATA]
ALTITUDE_SENSITIVITY=0.1 ; Sensitivity to altitude of the engine. Default value is 0.1. Deprecated, see CSP additions section.
INERTIA=0.165 ; Moment of inertia of the engine. A typical value is between 0.100 - 0.150. [kg*m^2]
MINIMUM=850 ; Engine idle rotations per minute. [rpm], [gg./min], [U/min], [tr/min], [об/мин]
LIMITER=6500 ; Engine rev limiter. Set to 0 = no limiter. [rpm]
LIMITER_HZ=20 ; Frequency of power cut when hitting LIMITER. [Hz]

% ▲ The maximum frequency that can be input is 333 Hz, due to Assetto Corsa’s physics engine clock (info at p.). Above that value the limiter won’t work.

DEFAULT_TURBO_ADJUSTMENT=0.8 ; Default turbo pressure amount if one or more turbos are cockpit adjustable. 0.5 = 50% boost.

[COAST_REF]
RPM=7000 ; Reference RPM for coasting torque.
TORQUE=50 ; Engine coasting torque (engine braking torque) value at rev number reference. [Nm]

% ▲ I've seen counter torque on some videos of dyno runs, you just have to watch carefully when they end a run and are coasting, to get some data. Plot
your own graph and input it into coast.lut. (works?)
% engine.ini has compression braking torque.

NON_LINEARITY=0 ; Coast engine brake from ZERO to TORQUE value at rpm with linear (0) to fully exponential (1)

[COAST_DATA] ; COAST0, COAST1 and COAST are unused legacy lines which must be included to load engine.ini properly.
COAST0=0
COAST1=0
COAST=0.0000015

[COAST_CURVE] ; Section which must be included to load engine.ini properly. Unknown if functional.
FILENAME=coast.lut ; Defines the LUT loaded for the coasting torque curve.

% ▲ Unknown if functional. Input may be invalid without an existing file; commonly coast.lut is used.

[THROTTLE_RESPONSE] ; Variable throttle response as a function of RPM.

RPM_REFERENCE=6000 ; Lowest engine RPM where “LUT” curve starts being in effect.
LUT=throttle_max.lut ; Filename of the second of the two possible LUT curves used by the throttle map (vanilla).

[TURBO_0] ; SYNTAX: [TURBO_ID]. Turbo identifier. ID starting from zero.

LAG_UP=0.995 ; Amount of filtering interpolation lag used while spinning up the turbo
LAG_DN=0.99 ; Amount of filtering interpolation lag for the turbo when spooling down the turbine.

% ▲ Turbo lag parameters define how responsive the turbocompressor is to the engine regime.

MAX_BOOST=1.40 ; Maximum theoretical boost pressure generated.

% ▲ This value is never exceeded; multiply the torque like T=T*(1.0 + boost), so a boost of 2 will give you 3 times the torque at a given rpm.

WASTEGATE=1.38 ; Max level of boost before the wastegate starts working. 0= no wastegate

% ▲ Controls the maximum allowed boost pressure. It is not the real-world wastegate spring pressure or anything similar, but a practical max pressure.

DISPLAY_MAX_BOOST=1.40 ; Boost pressure considered to be maximum by display apps.

REFERENCE_RPM=2300 ; The theoretical engine rev the turbo reaches MAX_BOOST at, with full throttle and no lag. [rpm]
GAMMA=2.5 ; Gamma function used for the turbo pressure build-up when applying throttle.

% ▲ Controls turbo spool speed, related to REFERENCE_RPM above. Lower gamma = more boost build-up at lower throttle amounts. Typical values are 1.5 -
5.0. This value has nothing to do with the torque equation.

COCKPIT_ADJUSTABLE=0 ; If the turbo boost is adjustable in-cockpit with number digits on keyboard; 0= off and 1= on.

[TURBO_1]
[TURBO_2]
[...]

% ▲ A vehicle can have as many turbos as necessary.

[BOV]
PRESSURE_THRESHOLD=0.5 ; the pressure on the air intake that the valve can take before opening, the pressure on the intake
depends on throttle, this is mostly used for fmod audio (is this deprecated?)

[DAMAGE]
TURBO_BOOST_THRESHOLD=1.2 ; Level of TOTAL boost before the engine starts taking damage.
TURBO_DAMAGE_K=5 ; Amount of damage per second when over TURBO_BOOST_THRESHOLD. Depends on (boost - threshold).
RPM_THRESHOLD=6700 ; RPM before the engine starts to take damage.
RPM_DAMAGE_K=1 ; Amount of damage per second when over RPM_TRESHOLD. Depends on (rpm-threshold).

LITTLE EXPLANATION
- Assetto Corsa is not an engine simulator: the way you get reasonable power curves is by typing reasonable torque curves into the engine look-up-table
based on real data.
- The torque LUT file referenced in the POWER_CURVE line defines with X-Y coordinates (specifically, input | output values) the torque curve of our car. Its
units are revolutions per minute [RPM] and torque at the wheels after drivetrain loss in [Nm].
Pro tip: the file is misnamed in the official vehicles, as it is always called power.lut; it should have been named torque.lut, but that is what we got from Kunos. And unfortunately,
modders kept copy-pasting the file from the templates without changing its name, which is actually defined within engine.ini (in the POWER_CURVE line). Let’s try to avoid
this trend that creates only misunderstandings and do things properly.

- Torque forms part of the basic specification of an engine: its power output is expressed as its torque multiplied by its rotational speed. Internal-combustion
engines produce useful torque only over a limited range of rotational speeds. The varying torque output can be measured over that range with a dynamometer,
which shows it as a torque curve.
Torque is often expressed in [Nm] (Newton * meter) or [kgm] (kilogram * meter); 1 kgm is equal to 9,81 Nm. Be aware that AC works with [Nm].

399
- Often the car you’ll be working on will have torque graphs available (Fig.). The ideal situation is having the graph of the torque at the wheels.

Fig. – A power and torque dynamometer graph. Notice how these are not SI units.

Sometimes though, due to manufacturer choices, or based on the data you will be able to find, you may only have a graph with the engine power ([bhp] or
[W]), or the power at the wheels ([hp] or [W]), like the one in Fig., thus you need to convert power into torque.
Now, in Fig. you can see a graph showing the power AT THE WHEELS expressed in horsepower [HP] on the Y axis, depending on the engine speed in [RPM]
(on the X axis). This is important: always pay attention to the units!

Fig. – These are actually three curves because each is for a different engine (Alfa Romeo). Let’s focus on one curve only. Notice how this is the power at the wheels (metric horsepower);
it means that once we calculate the torque curve from it we do not need to account for transmission losses due to friction: they are already included in the measurement.

If you have only the engine power as reference, not only you’ll need to convert it to engine torque, but you’ll have to calculate also the transmission loss to
obtain the graph of the torque at the wheels (which Assetto Corsa uses). We’ll see how later.
So how can we obtain the torque curve (at the wheels in this case) knowing the respective power graph? Physics give us this general formula:
𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 = 𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 ∙ 2𝜋𝜋 ∙ 𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 (1.6)
Which can also be written like this:
𝑃𝑃 = 𝜏𝜏 ∙ 2𝜋𝜋 ∙ 𝜔𝜔 (1.7)
where τ is torque and P is power. We can modify it a little, to obtain the torque of our rotating system from its power:

400
 𝑃𝑃
𝜏𝜏 = (1.8)
2𝜋𝜋∙𝜔𝜔

Now, it is important to input our data with the correct units, so here is the final torque equation we’re going to use the equation:
60∙𝑃𝑃[𝑊𝑊] 30∙𝑃𝑃[𝑊𝑊]
𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 [𝑁𝑁𝑁𝑁] = 2𝜋𝜋∙ 𝜔𝜔[𝑅𝑅𝑅𝑅𝑅𝑅] = 𝜋𝜋∙ 𝜔𝜔[𝑅𝑅𝑅𝑅𝑅𝑅] (1.9)

Where [Nm] is the measure of torque and [W] (Watts, equal to energy per second, or Joule/second [J/s]) is the measure of power; the factor 60 depends on
the rotational speed ω, which is expressed in radiant/second [rad/s], while RPM uses 1 minute as time unit, so 1 RPM = 1 rotation per minute = 1
rotation/60 seconds; the number 60 of this little ratio has just moved to the numerator of the formula, thanks to math’s operations.
Now we can look again at the graph, to immediately find out that power here is not in Watts like in (1.9), but in horse power [Hp]. We like the metric
system, which AC uses, so we won’t change (1.9), instead we’ll convert any type of HP 63, imperial (mechanical) or metric, to Watts.
With the following formulas you can convert respectively imperial and metric Hp in Watts, which you will then input into (1.9):
𝑊𝑊 = 𝐻𝐻𝐻𝐻(𝐼𝐼) ∙ 745,699 (2.0)
𝑊𝑊 = 𝐻𝐻𝐻𝐻(𝑀𝑀) ∙ 735,5 (2.1)
We keep talking about different units and at this point you may be wondering why. You’ll encounter many types of power graphs, so to understand them we
need to distinguish power at the wheels from the engine power previously mentioned, which are similar concepts often confused.
In simpler words, what’s the difference between HP (power at the wheels) and BHP (engine power)?
Horsepower or Indicated power (HP), is simply the engine’s power, measured at the front/rear axle or at the wheels (Fig.). This is the power the whole vehicle
delivers when we drive.
Brake horsepower (BHP) is a measurement of the engine’s power taken at the flywheel or crankshaft without the engine losing power due to drivetrain and
gearbox resistance. This means that the bhp of an engine will always be higher than the hp. If you had to put it in a simple formula it would be something
like this:
𝑃𝑃𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒 (𝑏𝑏ℎ𝑝𝑝) = 𝑃𝑃𝑤𝑤ℎ𝑒𝑒𝑒𝑒𝑒𝑒𝑒𝑒 (ℎ𝑝𝑝) + 𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿 (𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑)
After an engine model has been selected for a specific vehicle, it is tested to check how much power it delivers and how it performs (stress tests). The power
delivered by engine alone is calculated by a device called dynamometer. In the setup, special brakes or loads are applied along with sensors to the crankshaft
end to measure the torque at a certain RPM; look at Fig.right for example.
While performing the tests, torque and RPM are thus known in the above equations and so we can calculate power.
Since the power delivered by engine is calculated by applying brakes during testing, it is popularly called as brake horsepower.

Fig. – Simple visualization of how power at the engine and at the wheels are distinguished. Whenever you see them you have to immediately recall this image.

In Europe, the DIN 70020 standard tests the engine fitted with all ancillaries and exhaust system as used in the car. The older American standard by Society
of Automotive Engineers/SAE International, prior to 1972, (SAE gross horsepower, referred to as bhp) used an engine without alternator, water pump, and
other auxiliary components such as power steering pump, muffled exhaust system, etc., so the figures were higher than the European ones for the same
engine. The newer American standard (referred to as SAE Certified Power) tests an engine with all the auxiliary components. In the early 2000s SAE tightened
its horsepower rules to eliminate the opportunity for engine manufacturers to manipulate factors affecting performance such as how much oil was in the
crankcase, engine control system calibration, and whether an engine was tested with high octane fuel. In many cases, such can add up to a change in
horsepower ratings.
So there are various factors you need to recall when you search for an engine/vehicle power/torque graphs. As long as you want a car mod to be realistic.

63
The same conversion formulas (2.0) and (2.1) can be used for metric/imperial bhp. As far as the measurement unit goes, typically 1 hp = 1 bhp.

401
Fig. – How HP is measured (on the left) vs how BHP is measured (on the right).

Pro tip: the power graph you can see in Content Manager (with the red colour, see Fig. below) is the engine BHP calculated FROM the torque curve at the wheels, so that curve
won't necessarily match dyno graphs.

Fig. – Do not use Content Manager’s graphs as a reference point, they may be confusing (and especially wrong).

If you have the power curve (HP) of your vehicle, you can convert it directly to torque using in order (2.0) or (2.1) and (1.9), then input the values in torque.lut.
If you have the BHP curve of the engine instead, you’ll need to convert power to torque like before, but then you have to account for the loss due to mechanical
friction of the transmission to obtain the torque at the wheels; it depends mostly on the efficiency of the powertrain, and unless you have very specific data,
you can only estimate it. We’re also going to assume that there is no slip in the clutch or torque converter, the engine being mechanically linked to the wheels.
To convert actual engine power to wheel power, subtract 10-15% for road cars, 15-19% for race cars 64, and as much as 20-22% for vintage cars. But be wary
on manufacturer estimates for the transmissions, as they can be lower/higher than in reality.
Different gears do not have an impact on the torque curve (torque.lut), since the ratios are already accounted for in the drivetrain.ini config file. The only factor
that changes the torque in the LUT, as already mentioned, is the friction given by the transmission. In reality, torque differences can also exist given the fact
that you’re using different gear pairs, each with their own friction, weight and moment of inertia, but those are insignificant and can be ignored.
- Until now, we worked with imperial measurement units, [hp] and [bhp], but if you have dynamometer graphs with SI units, the distinction between engines
and wheels may be difficult, as you will work directly with watts [W] as power unit, whether the measurement was at the crankshaft or at the wheels (Fig.).

Fig. – As you can see, this engine power graph has SI units. If the sheets you find are almost blank, with no title or caption, good luck determining whether it is engine or wheel power.

64
Higher percentage of compensation? Yes, racing drivetrains are less efficient but more robust.

402
- As a side note, be careful with reading data at the ends of in the dyno graph; see Fig. , the massive jump in torque from 1500 to 2000 is very unusual
(read: likely incorrect) and could perhaps be caused by the throttle not being depressed fully within that interval.

Fig. - In this case, the given range is 1200~6500 RPM.

- Engine torque is also tied to throttle pedal input: at 0% pedal input AC ignores the throttle LUT and applies 0 torque. This is due to the artificial damping of
the cars when stopped (see pag.).
- If you want an estimation of engine inertia you should find flywheel weight and diameter and maybe clutch housing weight & diameter, since it’s linked to
the flywheel. Everything that rotates has an inertia, but those parts will be the greater component because they have both a considerable weight and gyration
radius.
- The RPM_TRESHOLD value sets the redline. It refers to the maximum engine speed at which an internal combustion engine or traction motor and its
components are designed to operate without causing damage to the components themselves or other parts of the engine. The redline of an engine depends
on various factors such as stroke, mass of the components, displacement, composition of components, and balance of components.
The word is also used as a verb, meaning to ride or drive an automotive vehicle above the redline. The actual term redline comes from the red bars that are
displayed on tachometers in cars starting at the rpm that denotes the redline for the specific engine (Fig.).

Fig. - Tachometers with redlines above 6000 RPM. From left to right: Porsche, Jaeger, Ferrari (Veglia).

Operating an engine in this area is known as redlining. Straying into and trespassing this area usually does not mean instant engine failure, but may increase
the chances of damaging the engine.

- Adding turbo compressors:

Turbos work by taking energy from the exhaust with an exhaust impeller and then transferring it to build pressure into the intake pipes with an impeller on
the intake side. This extra air increases the amount of power that your vehicle can produce.
But since it is quite a big area to build pressure into the intake pipes, it takes a little time to give you the power output you’re looking for. This lag time is
called turbo lag.
The only way to have a correct turbo curve, is to start with a turbo engine dynamometer sheet, and match that run (converting to torque) in torque.lut. You’d
think another way is to find the curve for a naturally aspirated engine (NA) and add whatever turbo you like, because reverse engineering the turbo curve with
just a dyno graph is not very fun; it’s easier but wrong: turbo works with pressure and influences torque. The two things have to be separated: the pressure is
a curve that you can either approximate (with the basic lines under the [TURBO] section) or plot into a separate LUT, while the torque generated is “baked”

403
into the engine torque. If you don't have the real-world pressure curve, just estimate it. If you have it, match it with the respective LUT in the controllers, then
adjust torque.lut according to the dyno graph.
Keep in mind that in AC, turbos are multipliers for the engine torque, because the formula is, at any given RPM:
𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇𝑇 = (1 + 𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵) ∙ 𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝𝑝. 𝑙𝑙𝑙𝑙𝑙𝑙
Where Boost depends on MAX_BOOST, WASTEGATE, REFERENCE_RPM and GAMMA. Being a multiplier, Boost has no dimension. This formula
shows that when boost pressure is =1.0, torque is =2.0.
GAMMA is the turbo pressure sensitivity on the gas pedal. It makes the turbo boost build with more or less accelerator pedal input. An old laggy turbo will
need a high value so that you will have to press the gas pedal to the max to start building boost. Vice versa for a modern small inertia turbo.
The maximum generated boost at a given rpm is governed by the following relationship:
GAMMA
𝑡𝑡ℎ𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 ∙ 𝑅𝑅𝑅𝑅𝑅𝑅
𝐵𝐵𝑚𝑚𝑚𝑚𝑚𝑚 = MAX_BOOST ∙ min �1, � � �
REFERENCE_RPM

So if you've got a 3100 rpm reference, if you are at 100% throttle 3100 rpm or 50% throttle 6200 rpm, you get full boost.
The minimum does seem to be present regardless of wastegate setting.
Pro tip: use the Car physics app to troubleshoot in-game boost pressure. See p. for more details.

In addition, AC’s turbo model is not really meaningful for free-revving, it only makes sense if torque is being applied to the tires.
% ▼ Turbo LAG_UP refers to the difference in time between when you press the accelerator and when the turbo kicks and starts delivering extra air to your
engine.
% ▼ Turbo LAG_DN refers to the difference in time between when the turbo is at full pressure and when the turbo reaches zero pressure while spinning down
(spool down time).
1.0 values for both LAG_UP and LAG_DN 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_DN and LAG_UP control how quickly the turbo boost spins up or down, using the formula (LAG_UP * previous boost + (1-LAG_UP) * next boost) every
frame. it uses LAG_UP if the max boost curve is higher than the current amount, LAG_DN if it's lower. Turbo lag has nothing to do with boost, it’s the
delay in pressure building. It has nothing to with the torque calculation.

You can set up a turbo so that it's only adjustable in setup, without the number 1-10 hotkeys, by setting COCKPIT_ADJUSTABLE=0 and adding turbo
entries in setup.ini.

- Adding superchargers:
A supercharger uses almost the same principles of a turbo; the difference is where the
energy to make it work comes from.
You see, while a turbo uses the pressure of the exhaust gases to spin its turbine, the
supercharger is belt-driven from the engine crankshaft, so it takes power directly from it.
As a consequence of this, superchargers just change the torque curve.
They deliver a decent power at lower RPMs, and have no spool time (lag), meaning you
enjoy the effects straight away (there’s a bit of lag actually, the spinning motion is not 1:1
exactly tied to throttle, but you can ignore it, especially if you don’t have a precise measure).

In AC you’re supposed to bake them into torque.lut, as Kunos did for example with the Lotus
Elise SC. If you have a supercharged vehicle dyno sheet just type the values into torque.lut. The turbo functions in engine.ini add turbo lag and wastegate
valves which superchargers do not have, although they have blowoff valves which change the off-throttle behaviour a bit, but there's not really anything to
do about that in AC.

If you want boost gauges to work on the dashboard of the car though, you can add a small “fictional” turbo, basically with zero boost (0.001bar for example)
and no lag, just for aesthetic purpose.

The problem of sound:

If you want to add more immersion thanks to your supercharger, bake its sound into the engine samples; otherwise tie the sound to the turbo Event of your
soundbank and add the “fictional” turbo in engine.ini, this way it should sound more realistic.

- The engine LIMITER:

Most modern cars have computer systems that prevent the engine from straying too far into the redline by cutting fuel flow through the fuel injectors/fuel rail
(in a direct-injected engine)/carburettor or by disabling the ignition system until the engine drops to a safer operating speed. This device is known as a rev-
limiter and is usually set to an RPM value at redline or a few hundred RPM above.
Most Electronic Control Units (ECUs) of automatic transmission cars will upshift before the engine hits the redline even with maximum acceleration (The
ECU in a sports car's automatic transmission will allow the engine to go nearer the redline or hit the redline before upshifting). If manual override is used,
the engine may go past redline for a brief amount of time before the ECU will cut power to pull it back or auto-upshift. When the car is in top gear and the
engine is in redline (due to high speed), the ECU will cut fuel to the engine, forcing it to decelerate until the engine begins operating below the redline at
which point it will release fuel back to the engine, allowing it to operate once again.

However, even with these electronic protection systems, a car is not prevented from redlining through inadvertent gear engagement. If a driver accidentally
selects a lower gear when trying to shift up or selects a lower gear than intended while shifting down (as in a motorbike sequential manual transmission), the
engine will be forced to rapidly rev-up to match the speed of the drivetrain. If this happens while the engine is at high RPMs, it may dramatically exceed the
redline. For example, if the operator is driving close to redline in 3rd gear and attempts to shift to 4th gear but unintentionally puts the car in 2nd by mistake,

404
the transmission will be spinning much faster than the engine, and when the clutch is released the engine's rpm will increase rapidly. It will lead to a rough
and very noticeable engine braking, and likely engine damage. This can actually happen in AC.

The limiter is well before you theoretically lose all torque, and in real life the engine will explode before that point anyway.

- What’s the relationship between throttle percentage (%) and output torque at any given rpm? In AC, it is calculated by default taking directly the values
inside torque.lut with a linear interpolation between them; however, you can change the relationship between accelerator pedal and engine (aka the shape of
the throttle curve) with throttle.lut.
About the [THROTTLE_RESPONSE] section: it’s a vanilla feature present since AC 1.15, dedicated to modders, that’s why it is not seen very often in
mods and official content. It is used for changing how the engine reacts to the gas pedal input, like modern ECUs with a different curve for starting from idle,
for low RPM, for high RPM, etc. The so-called Sport and Eco modes work by altering how the throttle works too.

But since in AC throttle is just a power percentage input, it is a simplified system. As already mentioned in the script descriptions, only a maximum of two
look-up-tables can be used: throttle.lut is the first, which you can directly put in the data files without referencing it in engine.ini; the second one, which you
can call however you like, must be referenced in the LUT line. The CSP mod changes this.

“Why are two tables available?” you may ask. You see, they are combined together to create different throttle response maps. throttle.lut will be used as base
curve from 0 RPM and above, while whichever second LUT you specify will be used from when the engine reaches the RPM_REFERENCE and below, with
a linear interpolation between the two LUTs until that value (Fig.).

For clarity purposes, let’s consider 6000 RPM our reference, thus let’s call a second table throttle_6000.lut. I recommend to follow a similar practice when
you will work with your files, distinguish them with the rev number to have an easier time, especially when making complex curves.

Fig. – Clarification of how LUTs are interpolated: the transition between the values is smooth, and at the extremes are found the exact values of the configured maps.

If say throttle.lut is 50|30, and the second map is 50|50, before the REFERENCE_RPM the throttle would be in between them, so 40% output. And of
course after it would be fully onto 50%.

You can check the log.txt file to see if the system is working - it will record if it is loading the .lut files. When you start the race session it also prints out a
whole 2d chart, beginning with "THROTTLE RESPONSE TABLE", showing a table of RPM vs gas values (every 1000 RPM, and that may be confusing).
Refer to p. for AC debug logs.
Pro tip: It shall be noted that throttle.lut may also be used alone, without the [THROTTLE_RESPONSE] section, to configure a simple throttle curve.
More importantly, you should be aware that if you’re playing AC with mouse or keyboard the throttle will always be at 100% whenever you click or press the gas button. So it
is more difficult to test properly the throttle response without a pedal controller, but you can still determine accurately the numbers in the LUTs via engine map curves (if you
can find them).

- If you really have time to waste or you’re just interested, you can try using the Lotus Engine Simulation software (Fig.), which you can find here for free:
https://www.lotusengineering.com/engineering-software.

Fig. – (top) A quick test I made with a four-cylinder engine. Not quite like Simulink, maybe more similar to Working Model 2D. There are panels with a ton of options, and animations.

I have yet to become familiar with this program, however it’s old-school and quite nice. Seems promising. It has also a data-checking wizard that lets you
know of eventual errors.

ABOUT RELATED FILES

Controllers:
405
ctrl_turbo0.ini
This config manages turbo controllers. It can be renamed based on how many turbos you have
[CONTROLLER_0]
INPUT=RPMS
COMBINATOR=ADD
LUT=(|0=0.525|7200=0.525|8500=0.47|)
FILTER=0.99
UP_LIMIT=10000
DOWN_LIMIT=0.0
ctrl_wastegate0.ini

LUTs:
torque.lut
This is the torque curve of our vehicle. The numbers on left are RPM, those ones on right are torque in [Nm] at the wheels, including any drivetrain losses.
Oh, and I should note, these values are before any turbos. The torque used in power.ini is effectively from a vehicle with N/A (Natural Aspirated) engine.
Turbines are to be added later.
Example: engine_example.lut
0|70
500|70
1000|70
1500|70
2000|113
2500|118
3000|128
3500|129
4000|114
4500|112
5000|110
5500|103
6000|100
6500|91

Pro tip: remember that in official vehicles and most mods this LUT is mistakenly called power.lut.

throttle.lut
This is the base throttle response curve. The numbers on the left are throttle % input, on the right you have torque % output. Example:
0|0
10|30
20|50
30|60
40|70
50|75
60|80
70|85
80|90
90|95
100|100

It works basically as a multiplier for the torque from torque.lut. Also, you do not need to specify all the percentages, since the values are interpolated, as
usual with LUTs. So do not put hundreds of values, it is not necessary.

It is the only LUT that doesn't need a reference in the config files. Why? Because it is already hardcoded in AC, see Fig.

Fig. – An extract, straight from the code of acs.exe. As you can see “throttle.lut” is already referenced.

If you want to use an additional throttle map for the [THROTTLE_RESPONSE] section of engine.ini, the file is identical, but it must be referenced.

COAST CURVE EXAMPLE

0: 6.818182
500: 2.272727
1000: -2.272727
1500: -6.818182
2000: -11.363636
2500: -15.909090
3000: -20.454544
3500: -25.000000
4000: -29.545454
4500: -34.090908
5000: -38.636364
5500: -43.181816
6000: -47.727272
6500: -52.272724
7000: -56.818180
7500: -61.363636
8000: -65.909088
8500: -70.454544
9000: -75.000000

(since COAST LUTS aren’t likely working in AC with all its bugs aaaaaah TUT, you can try using KERS, that one at least should work)

CSP ADDITIONS

406
- The ALTITUDE_SENSITIVITY of engine.ini is part of a function sadly not implemented well in vanilla AC; it won't affect turbos/engine as it should. It
does work, but at the same time it doesn’t; anything that's altitude sensitive does have code to handle it, it's just never told it's not 0 in vanilla. In fact, you
can't even set the track altitude, each map just has a certain fixed air pressure.
The principle behind altitude sensitivity is that going very high above the sea level, the air pressure reduces, along with its density, thus the engine has less
combustion agent to burn the fuel, and struggles more and more the higher you go, to the point that’s even difficult to breathe for humans and you need
oxygen 65. This is a phenomenon well known to mountaineers and climbers.
However, altitude effects have been implemented for a while for cars using extended physics brought by CSP. When you enable extended physics, the patch
will change the Assetto Corsa internal air density, which affects aero (already happens in vanilla) and engines (already happens in vanilla but it’s a bit better
with CSP), according to altitude. It is not used for cars without extended physics since it would cause online compatibility issues (read “cheating”).
To enable altitude sensitivity effects, it is necessary that the track has a new [ALTITUDE] section added to surfaces.ini (see pag.).
The elevation change alters the power of the engine. NA engines are pretty much proportional to air density, so the code just portrays that.
The ALTITUDE_SENSITIVITY line was not recycled by the mod because very often people put in totally random values for it, so many car mods would
have been totally broken (engine too sensitive if the line had a value of, say, 10).
Pro tip: there is a problem with electric cars: in real life electric motors are not affected by elevation change, so if you adopt extended physics you should add a small turbo to
compensate for the power loss at high altitudes. The better option however would be to avoid using extended physics.

- The patch adds new options for turbos, only available with extended physics: LUTs for the gas pedal and spin delay.

The following is an example of the vanilla section we learned previously, with the new lines (EXT_GAS_CURVE and EXT_SPIN_DELAY):
[TURBO_0]
LAG_DN=0.985
LAG_UP=0.9965
MAX_BOOST=1.0
WASTEGATE=0.58
DISPLAY_MAX_BOOST=0.58
REFERENCE_RPM=2500
GAMMA=4
COCKPIT_ADJUSTABLE=0
EXT_GAS_CURVE=(|0=0|0.3=0|1=1|)
EXT_SPIN_DELAY=0.2

In AC the gas pedal is used as a multiplier for turbo activation. With EXT_GAS_CURVE (which could also be a file name instead of inline LUTs), you can
remap that multiplier value, for example, stopping turbo from activating until pedal is pressed to at least 30% of its range. A somewhat similar effect could be
achieved in vanilla with the ctrl_turbo#.ini controller using INPUT=GAS, but a LUT allows to alter the value before gamma is applied. The default value (in
case you wanted to recreate the vanilla physics) is EXT_GAS_CURVE=(|0=0|1=1|).

As for EXT_SPIN_DELAY, it adds some sort of negative turbo pressure, extending the boost range. Engine would act as naturally aspirated (NA) until
turbo would spin beyond zero point. With EXT_SPIN_DELAY=1, if original turbo boost would equal 0.5, after altering, it’ll drop to 0, and would climb
from there. With EXT_SPIN_DELAY=0.5, it would be 0.33 (not very clear). Default value (again, for vanilla-style physics) is EXT_SPIN_DELAY=0.

- The usage of throttle response maps is changed, with more than two LUTs now available. This is done by adding a [MAP] section in engine.ini:
[MAP]
DEFAULT=0 ; Default map index.
MAP_0=engine_map0.lut ; File reference for the CSP throttle LUT (it is NOT like throttle.lut) in the car data.

% ▲▼ The number after MAP_ is the throttle map’s index. This is important for later, when working with setup.ini.

MAP_1=engine_map1.lut
MAP_2=engine_map2.lut
[...]

% ▲ A vehicle can have as many throttle maps as necessary.

The tables themselves here do not correspond to what you find in vanilla (throttle.lut): the values are still multiplying torque.lut, but they are RPM at the
input and torque multiplier (percentage in decimal number, so 1.1=110%) at the output, like this:
0|1
250|1.01
500|1.02
750|1.03
1000|1.04
1250|1.05
1500|1.06
1750|1.07
2000|1.08
2250|1.09
2500|1.1
2750|1.11
3000|1.12

It’s a much simpler approach compared to the vanilla [THROTTLE_RESPONSE] section. If you want to have a throttle map that leaves the original engine
power untouched, put ones at the outputs.

In Fig. you have a demonstration of what it is possible to achieve.

65
Hopefully this doesn’t happen when you drive in a simulator!

407
Fig. – How different ECU modes can be recreated thanks to CSP.

The engine throttle maps implemented with the mod can be managed from the setup screens too, editing setup.ini. Example:
[ENGINE_MAPS]
SHOW_CLICKS=0 ; The function is the vanilla one from the setup.ini script.
TAB=GENERIC ; The chosen tab for the engine map selection (in AC setup screens).
NAME=Engine Map ; Name of the engine maps group (you can use it as the name of the car’s ECU).
LUT=engine_map_setup.lut ; A look-up-table that specifies which are the single engine maps in the group.

% ▲ The format of the LUT is: name|index. It can also use the traditional system of indexing, just make sure your indexes don't go out of bounds of your
MAP_# entries. Example:

Standard|0
Tuned|1
Eco|2

POS_X=0.5 ; The function is the same as the vanilla one. Again, look at the setup.ini script.
POS_Y=3 ; Same as the line above.
HELP=NULL ; Same as the line above.

You can also associate a key binding to change them while driving (CTRL+E is the default binding).
Pro tip: I would advice to remove any vanilla throttle LUT if you choose the CSP method, it is not clear if they are overridden or they act on top of each other.

- This is important when working on physics: for mouse and keyboard users, CSP 1.70 introduced a new method of applying throttle: Forced throttle. See p.
of PART 1: AC USER MANUAL for more details.

FAQ
QUESTION [1]: There are no values that control the horsepower in engine.ini, only the torque.lut. I don't know how to modify it.
ANSWER [1]: You can’t define the power of an engine throughout all of its possible rotational regimes (RPM) with only one maximum value, you need
what’s called a “power curve”. If you want to modify it for an existing vehicle, you open the torque.lut Look-Up-Table with any text editor. But modifying any
number without any correlation between them will be an unrealistic mess.
Q [2]: I want to make a fully electric powertrain for a car but I'm having trouble understanding how electric motors work in AC.
A [2]: There’s not much to it. You can simulate electric motors with peak torque at 0 rpm, and adopt one drivetrain gear.

408
ENGINE PHYSICS
- To calculate fuel consumption, what one could try is the cylinder volume times revolutions per minute. Indeed, this gives the volume per minute of air-fuel
mix entering each cylinder of the engine. The point is that the air-fuel mix is not all fuel, and operates at varying pressure. Also, not all of it is burned in one
stroke. So no conclusion here.
In real life a motor’s fuel consumption is measured through experiments and recorded as a function of speed (RPM) and load (torque). It is called BSFC
(Brake-Specific Fuel Consumption), the rate of fuel flow mass rate [kg/s] divided by the effective output power produced [W]:
𝑚𝑚̇𝑓𝑓
𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵 = [𝑘𝑘𝑘𝑘/𝐽𝐽]
𝑃𝑃𝑒𝑒
Engine power is the product between engine speed and torque. Therefore, we can express the BSFC function of engine speed and torque:
𝑚𝑚̇𝑓𝑓
𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵 = [𝑘𝑘𝑘𝑘/𝐽𝐽] (yyyy)
𝜔𝜔𝑒𝑒 ∙𝑇𝑇𝑒𝑒

where 𝑇𝑇𝑒𝑒 is the effective (brake) engine torque 66 in [Nm] and 𝜔𝜔𝑒𝑒 is the engine speed in [rad/s].
Usually, the fuel mass flow rate is measured in [g/s], the engine power in [kW], which gives the brake specific fuel consumption in [g/kW·h]. Just multiply
the BSFC you get by 3600.

Engine torque can also be defined function of the mean effective pressure (MEP) of the engine.
𝑛𝑛𝑐𝑐 ∙𝑉𝑉𝑑𝑑 ∙𝑝𝑝𝑚𝑚𝑚𝑚
𝑇𝑇𝑒𝑒 = (cdnv)
2𝜋𝜋𝑛𝑛𝑟𝑟

where 𝑛𝑛𝑐𝑐 is the number of cylinders, 𝑉𝑉𝑑𝑑 is the cylinder displacement 67 [m3], 𝑝𝑝𝑚𝑚𝑚𝑚 is the mean effective pressure [Pa], 𝑛𝑛𝑟𝑟 is the number of crankshaft
rotations for a complete engine cycle (for 4-stroke engine 𝑛𝑛𝑟𝑟 = 2).
The MEP can be regarded as an average pressure in the cylinder for a complete engine cycle. By definition, mean effective pressure is the ratio between the
work and displacement:
𝑝𝑝𝑚𝑚𝑚𝑚 = 𝑊𝑊/𝑉𝑉𝑑𝑑
where W is the work performed in a complete engine cycle [J]. From equation () we can write the expression of the engine work as:
𝑊𝑊 = 𝑝𝑝𝑚𝑚𝑚𝑚 · 𝑉𝑉𝑑𝑑
There is also a direct relationship between the power of the engine and the work produced:
𝑊𝑊 = (𝑛𝑛𝑟𝑟 · 𝑃𝑃)/𝑛𝑛𝑒𝑒
where P is engine power [W], 𝑛𝑛𝑒𝑒 is the engine speed in [rps], aka rotations per second =RPM/60.
By making equation () equal to (), we get the expression of the mean effective pressure function of power and engine speed:
𝑝𝑝𝑚𝑚𝑚𝑚 = (𝑛𝑛𝑟𝑟 𝑃𝑃)/(𝑛𝑛𝑒𝑒 𝑉𝑉𝑑𝑑 )
Power can be written once again, as in (), as the product between torque and speed, so we get the expression of MEP, function of engine torque:

𝑃𝑃 = 𝜔𝜔𝑇𝑇 = 2𝜋𝜋𝑛𝑛𝑒𝑒 · 𝑇𝑇 ⇒ 𝑝𝑝𝑚𝑚𝑚𝑚 = (2𝜋𝜋𝑛𝑛𝑟𝑟 · 𝑇𝑇)/𝑉𝑉𝑑𝑑

As you can see, from expression (), the mean effective pressure is not influenced by the engine speed. Also, since the torque is divided by the engine
capacity, the mean effective pressure parameter can be used to compare internal combustion engines of different displacements.
For an engine with multiple cylinders we have to take into account the total volumetric capacity. We only have to multiply the volume of one cylinder with the
number of cylinders 𝑛𝑛𝑐𝑐 . The expression of mean effective pressure becomes:
𝑝𝑝𝑚𝑚𝑚𝑚 = (2𝜋𝜋𝑛𝑛𝑟𝑟 · 𝑇𝑇)/(𝑛𝑛𝑐𝑐 · 𝑉𝑉𝑉𝑉)
Mean effective pressure is used for initial engine design calculations, with engine torque and MEP as inputs, the engine designer can calculate what is the
required engine volumetric capacity. Remember that mean effective pressure is only a parameter to measure engine performance and does not reflect the
actual pressures inside an individual combustion chamber.
Be aware that there are different types of mean effective pressure:
• indicated mean effective pressure (IMEP) calculated with indicated power (work). This parameter does not take into account the efficiency of the engine.
• brake mean effective pressure (BMEP) calculated from the dynamometer power (torque). This is the actual output of the internal combustion engine, at
the crankshaft. BMEP takes into account the engine efficiency.
• friction mean effective pressure (FMEP) indicative of the mean effective pressure of the engine lost through friction and it’s the difference between
indicated mean effective pressure and brake mean effective pressure. FMEP = IMEP – BMEP
Now, replacing (cdnv) in (yyyy), we can write the formula of the brake specific fuel consumption function of the mean effective pressure of the engine:
2𝜋𝜋𝑛𝑛𝑟𝑟 𝑚𝑚̇𝑓𝑓
𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵 = ∙ 3600 [𝑔𝑔/𝑘𝑘𝑘𝑘ℎ]
𝑛𝑛𝑐𝑐 𝑉𝑉𝑑𝑑 𝑝𝑝𝑚𝑚𝑚𝑚 𝜔𝜔𝑒𝑒

66
Brake engine torque is the torque measured at the crankshaft. Read p. and look at Fig. for clarification.
67
For one cylinder, the displaced volume is the product between the stroke of the piston and the area of the cylinder circumference.

409
The lower the brake specific fuel consumption, the more efficient the engine is. For spark ignition (gasoline engine) the BSFC is around 250 g/kWh and for
compression ignition (diesel) around 200 g/kWh.

BSFC plots are like topographic maps: small round shapes inside larger round shapes, with each shape having a constant BSFC value (isoline). And the
axes of the plot are speed and load.

Fig. – This graph adopts BMEP as you can see. The lowest BSFC is represented by an “island”, usually at medium engine speeds and high torque (load), close to peak full load torque.

Suppose that we’re looking for optimum fuel consumption. Then we need that plot, and we need to look at the smallest isoline inside all the other shapes.
Note that it is associated with a unique (x, y) combination.

In the end, is all this worth the effort? Probably not, at least for AC. Maybe the next title? At least you learned something.

410
20. ers.ini
This script allows the configuration of the ERS (Energy Recovery System) of your vehicle. It finds most of its applications on moder Formula cars and
prototypes. Hybrid commuters can make use of some features too.
[HEADER]
VERSION=1

[KINETIC] ; MGU-K configuration.

CHARGE_K=0.00014 ; Charge as function of brake torque (include engine) and rotation speed.
TORQUE_CURVE=kers_torque.lut ; File reference for the torque curve LUT in Nm/RPM.
COAST_CURVE=kers_torque_coast.lut ; Coast Torque curve Nm/RPM.
DISCHARGE_TIME=87000 ; Time to discharge the MGU-K or KERS, when used to deliver torque. [ms]
HAS_BUTTON_OVERRIDE=1 ; Boolean.
MAX_KJ_PER_LAP=10000000 ; Maximum energy discharge allowed per lap, given by race regulations. [kJ]
DEFAULT_CONTROLLER=0 ; Values: 0= 1=
BRAKE_REAR_CORRECTION=30 ; Torque removed from rear axle as function of kinetic recovery. [Nm]

[HEAT] ; MGU-H configuration.

CHARGE_K=0.002 ; Charge as function of turbo boost percentage.
TORQUE_PERC=10 ; % of torque the Heat is able to generate from the kinetic motor.

[COCKPIT_CONTROLS] ; Specify if the controls below should be available for cockpit operation.
RECOVERY=0 ; Boolean logic operator: 0=False, 1=True.
DELIVERY_PROFILE=1 ; “ “ “
MGU_H_MODE=0 ; “ “ “

LITTLE EXPLANATION
- First of all, what is an ERS system?
The power unit used in Formula 1 cars is hybrid; partly the “classic” combustion engine which we’re used to know, partly the ERS. The latter has been used
in some form or another since 2009.
All ERS are the same in terms of their basic concept: they allow the car to save energy that would otherwise be wasted, and use it when necessary. However,
with time the designs have changed a bit since.
The first ERS introduced to F1 was KERS (Kinetic Energy Recovery System), very well known to the public. It used either a flywheel or an electricity
generator with a battery to store the car's kinetic energy that would have otherwise been lost during braking, and supplemented the engine's power when
needed.
These days, Formula 1 cars are equipped with a different assembly, which essentially consists of four parts:
• Two electric motors, MGU-K (Motor Generator Unit – Kinetic) and MGU-H (Motor Generator Unit – Heat);
• An ECU (Electronic Control Unit) and an energy storage unit, consisting of a battery pack.

The motors are the heart of the contraption:

The MGU-K is connected to the crankshaft before the clutch, which exchanges mechanical power with the rear wheels. Under acceleration, it can deliver up
to 120 kW (about 160hp) with a maximum torque of 200Nm, with a spin limit of 50'000 rpm.
The regulations impose a limit of deliverable energy per revolution of 4MJ (as of 2020, check newer). The delivery of electric power is set through maps that
distribute electric power according to the gear used and speed.
When braking, on the other hand, the unit acts as a generator and derives electrical energy by dissipating mechanical energy from the crankshaft. It actually
takes energy from the rear wheels and converts it into electrical energy. The regulations again impose a limit on absorbable energy per lap of 2MJ.
The intensity of motor braking can be set from the pitbox and affects braking stability.
The MGU-H system consists of a control unit and an electric motor keyed directly to the axis of the engine turbine. This system limits the rotational speed of
the turbine by generating electricity that can be stored in batteries or can be used instantaneously by the MGU-K. When active, the MGU-K adds about an
extra 161 horsepower to the car's total power output. Its rotational speed is limited to 125'000rpm, and the regulations do not impose power generation
limits. The drivers can only use the MGU-K for a short amount of time each lap, however.
The MGU-H also functions as an engine by rotating the turbocharger even during deceleration. This system allows for nearly zero turbo lag, a problem that
plagued turbochargers in the 1980s.
Finally, we have the energy storage unit, which is made of batteries. The capacity of the batteries is 4MJ, and the ECU regulates energy delivery and
absorption.

- There is the possibility to change ctrl_ers mode with a button.

ABOUT RELATED FILES

LUTs:
Controllers:
ctrl_ers.ini
[HEADER]
NAME=Charging

[CONTROLLER_0]
COMBINATOR=ADD ; COMBINATOR MODE: ADD or MULT
INPUT=GAS ; Telemetry channel input.

% ▲ List of telemetry channel inputs (put at the beginning of controllers?) SLIPRATIO_MAX SLIPRATIO_AVG LONG LATG BRAKE0-1 GAS0-1 STEER-1+1 SPEEDKMH GEAR

LUT=ers0_gas.lut ; input data to kers delivery lookup table

FILTER=0.96 ; filter for eliminating spikes in variations and control variation speed
UP_LIMIT=1 ; kers delivery max limit
DOWN_LIMIT=-1 ; kers delivery min limit (can be negative)

[CONTROLLER_1]

411
COMBINATOR=ADD ; COMBINATOR MODE: ADD or MULT
INPUT=BRAKE ; telemetry channel input.
LUT=ers0_brake.lut ; input data to kers delivery lookup table
FILTER=0.96 ; filter for eliminating spikes in variations and control variation speed
UP_LIMIT=1 ; kers delivery max limit
DOWN_LIMIT=-1 ; kers delivery min limit (can be negative)

[CONTROLLER_2]
COMBINATOR=MULT ; COMBINATOR MODE: ADD or MULT
INPUT=SPEED_KMH ; telemetry channel input.
LUT=ers0_speed.lut ; input data to kers delivery lookup table
FILTER=0.96 ; filter for eliminating spikes in variations and control variation speed
UP_LIMIT=1 ; kers delivery max limit
DOWN_LIMIT=-1

[CONTROLLER_3]
COMBINATOR=MULT ; COMBINATOR MODE: ADD or MULT
INPUT=GEAR ; telemetry channel input.
LUT=ers0_gear.lut ; input data to kers delivery lookup table
FILTER=0.96 ; filter for eliminating spikes in variations and control variation speed
UP_LIMIT=1 ; kers delivery max limit
DOWN_LIMIT=0 ; kers delivery min limit (can be negative)

412
21. escmode.ini
This config sets the parameters for the camera that orbits 360° around the vehicle at the beginning and at the end of every session (in the setup/leaderboard
menu in pits or on the starting line) when you press F5 before driving. After you start driving, this camera movement is disabled and AC switches to the last
camera used in the previous sessions.
[SETTINGS]
POSITION=0,1.4,3 ; Position of the camera, referenced from the vehicle’s origin / CoG (center of gravity) in xyz. [m]
FOV=45 ; Field of View (FOV) angle of the camera. [deg]

LITTLE EXPLANATION
- At the beginning and end of every vanilla race session this camera enables automatically, whether you’re still on the track or you’re in pits (Fig.). The only
difference is that it stays still, looking at the vehicle side.

Fig. – REPLACE IMAGE

- If you press F7 you can enable the free camera, thus deactivating it temporarily, but doing this in the post-race screen is not very useful to look around
since the view is covered by the AC lap times GUI (Fig.).

Fig. – The camera in the vanilla session end screen is managed by escmode.ini.

413
22. extra_animations.ini
Additional animations can be configured with this script. Rotating objects can also be controlled here. This is the right place to add a simple spinning
movement to a fan. Bear in mind that everything is just visual, any moving or rotating object will not have any impact on the physics, independently from its
shape.
[ANIMATION_0]
FILE=extra_boot.ksanim
MIN=0
MAX=100

[ANIMATION_1]
FILE=extra_hood.ksanim
MIN=0
MAX=100

[ROTATING_OBJECT_0]
NAME=FAN ; Name of the dummy that rotates.
RPM=100 ; Rotational speed of the NULL. [rpm], [gg./min], [U/min], [tr/min], [об/мин]

% ▲ As there is no blurred texture, unlike for blurred rims, after a certain speed the rotation actually starts looking slower due to framerate, so keep
this value around 100.

AXIS=1,0,0 ; Axis of the rotation movement.

LITTLE EXPLANATION
- Properly set animations can be used in the vanilla Showrooms to open the trunk or the hood of the vehicle using numpad 4 and 5; this won’t be possible
during a race session. CM showrooms integrate the animations by activating them via checkboxes. Look at the Porsche 917/30 Spyder for an example of the
implementation of this feature.

Fig. –

414
23. flame_presets.ini
The lines of code below manage mainly the backfire animation and the colour of the flames of your vehicle. There are also other parameters. Flame types
It is suggested to read the explanation of the flames.ini for a better understanding of how flames work in AC. The two scripts are complementary when using
the latest version of the flame behaviour (v2).
[HEADER]
SIZE_MULT=1 ; Size multiplier of the total flame animation.

[PRESET_START_0] ; Starting backfire animation.

TRIGGER=0 ; Animation's frame trigger index.
OFFSET=0.0,0.0,0.02 ; Position of the flame texture.
SIZE=0.05 ; Size of the texture.
TYPE=0 ; 0 = F type texture (f2.dds), 1 = X type (x0.dds), 2 = L type (l3.dds)
RGB=200,150,150,0.5 ; RGB colour multipliers for the flame texture (Red, Green, Blue) + intensity value.

[PRESET_START_1]
TRIGGER=1
OFFSET=0.0,0.0,0.1
SIZE=0.1
TYPE=1
RGB=200,120,155,0.07

[PRESET_START_2]
TRIGGER=2
OFFSET=0.0,0.0,0.08
SIZE=0.07
TYPE=0
RGB=200,120,155,0.08

[PRESET_END_0] ; Ending backfire animation: TRIGGER is inverse because textures start already visible.
TRIGGER=4
OFFSET=0.0,0.0,0.02
SIZE=0.06
TYPE=1
RGB=90,190,150,0.1

[PRESET_END_1]
TRIGGER=2
OFFSET=0.0,0.0,0.06
SIZE=0.04
TYPE=1
RGB=120,120,55,0.07

[PRESET_END_2]
TRIGGER=0
OFFSET=0.0,0.0,0.1
SIZE=0.04
TYPE=2
RGB=120,50,55,0.05

[PRESET_LOOP_0] ; Looping animation (start always included).

TRIGGER=0
OFFSET=0.0,-0.01,0.18
SIZE=0.13
TYPE=1
RGB=150,50,28,0.1

[PRESET_LOOP_1]
TRIGGER=1
OFFSET=0.0,-0.04,0.26
SIZE=0.13
TYPE=1
RGB=100,50,28,0.06

[PRESET_LOOP_2]
TRIGGER=2
OFFSET=0.0,-0.06,0.35
SIZE=0.15
TYPE=2
RGB=100,50,28,0.05

[PRESET_FLASH_0] ; Flash animation : TRIGGER is inverse because textures start already visible.
TRIGGER=2
OFFSET=0.0,0.0,0.00
SIZE=0.04
TYPE=0
RGB=255,90,0,0.01

[PRESET_FLASH_1]
TRIGGER=1
OFFSET=0.0,0.0,0.03
SIZE=0.04
TYPE=0
RGB=255,90,0,0.006

[PRESET_FLASH_2]
TRIGGER=0
OFFSET=0.0,0.0,0.06
SIZE=0.06
TYPE=1
RGB=255,90,10,0.01

LITTLE EXPLANATION
- The full animation of backfire flames is made by the flame_presets.ini file. There are three stages in this anim:
• START
• LOOP
• END

Each one of these stages is made of one or more "frames": each frame has a trigger, color and type for the flame.
The TYPE is the texture group: every texture cycles in its own group.
-Two versions of flames exist in AC: v1 and v2. v1 is older.

415
If flame_presets.ini does not exist in your mod files (inside data.acd or the data folder), then the old flames (v1) will be used. v2 flames are enabled only if
this file is present.
-It is recommended to use v2 flames.
Keep in mind that with v2 the flame textures need to be .dds files.
-When using v1 the animation events are triggered by gas only if in normal mode (in a standard game session); they don’t work with the AC debug console
(see p.). Instead of setting the command with the console you can adjust every stage of the animation using the EDIT_STATE line of flames.ini to switch
stage.

CURIOSITIES AND AMENITIES

-So, in the real world, what defines the color of the flame?
The burning substance, the temperature, the 𝑂𝑂2 (oxygen) content... lots of things.

24. flames.ini
This config manages the flames for backfires. Leave it empty if your car doesn’t backfire. Keep in mind that what actually triggers the backfires’ sound is in
the parameters of the sounds.ini config.
It is suggested to read the explanation of the flames_presets.ini for a better understanding of how flames work in AC. The two scripts are complementary
when using the latest version of the flame behaviour (v2).
[HEADER]
EDIT_MODE=0 ; Deprecated in v2: use "set observeFlames 1" on the console.
INTENSITY=60.0 ; Deprecated in v2
EDIT_BIG=1 ; Useless (stated by Kunos)
EDIT_STATE=0 ; Debug: 0=no visible flame, 1=1st stage (start), 2=2nd stage (loop), 3=3rd stage (end), 4=flash flame
BURN_FUEL_MULT=10 ; Flame's lifetime: lower number = shorter lifetime.
FLASH_THRESHOLD=6 ; Threshold for the main flame. Value between 0 and 10. With the value=11 there are no main flames.

% ▲ The main flames appear only if the current gas/rpm/other stuff total is > of this threshold, if between 0 and 10. The main flame is the biggest
flame, with the prefix “x” on the textures in the flames folder.

% ▼ A car can have as many flames as required/needed. Make a car burning in flames.

[FLAME_0] ; Flame identifier. SYNTAX: [LOD_ID], ID starting from zero.

POSITION=0.830,0.22,-0.49 ; Position of the flame vector (x,y,z), related to the vehicle model origin. [meters]
DIRECTION=1,0,-1 ; Direction of the flame vector.
VSIZE_START=0.15 ; Deprecated in v2
VSIZE_END=0.10 ; Deprecated in v2
LSIZE=0.24 ; Deprecated in v2
IS_LEFT=1 ; Is the flame on the left or the right side of the car? 1=left side, 0=right side
SIZE_MULT=1 ;
GROUP=0 ; Group index of the flame (big exhausts need more flames to fill them).

[FLAME_1] ; Additional flames have the same lines of code as [FLAME_0].

POSITION=0.830,0.22,-0.49
DIRECTION=1,0,-1
VSIZE_START=0.15
VSIZE_END=0.10
LSIZE=0.24
IS_LEFT=1
SIZE_MULT=1
GROUP=0

[FLAME_2] ; A car can have as many flames as required.

[FLAME_3]
[FLAME_4]
[...]

LITTLE EXPLANATION
In order for the flames to work, their textures must be present in a dedicated subfolder called flames inside the texture folder of your FIN mod folder (about
it on pag.). There are flames textures of common use in AC, so you can copy them from another car and they will work; each official car usually doesn’t have
all of them: only some, or none, depending on the type of backfires it makes (or doesn’t make = no tex.). You can find all of them in the extra contents of
this manual.

The following are all the common flames textures you must use; they can be divided in different categories, based on their functions and letter prefix:
FLASH (hence the f prefix): TAIL (hence the l prefix; that’s an L): MAIN (every prefix except f and l):
• f2.dds • l3.dds • x0.dds
• f3.dds • l4.dds • x1.dds
• f4.dds • l6.dds • x5.dds
• f#.dds (additional numbers) • l#.dds (additional numbers) • x7.dds
• x8.dds
• x#.dds (additional numbers)
At least one texture from each of these three categories (FLASH, TAIL, MAIN) must be present to make the car work, unless flames.ini is empty or
flames_presets.ini does not exist. (must verify) Then I could have only three files inside the texture\flames folder.

òòèèòùòùàòD
• 1.png
• 2.png
• 7.png
• 8.png
You can also create and use your own own textures. Just drop them in the aforementioned path (your_car_mod\texture\flames) and use the correct prefix
and file format (.dds for v2 flames & ). [still need more info, may be wrong]

416
CSP ADDITIONS
The New flames brought by CSP ignore vanilla params.

FAQ
QUESTION [1]: I have all the parameters for the flames but they don’t appear in game. What can I do?
ANSWER [1]: Check if you added the flames textures to the texture folder inside the main archive of your mod. Otherwise check the sounds.ini lines dedicated to backfires.

Q [2]: Is there an easy way to adjust the flames positions after adding them to the script? I copied them from another car.
A [2]: Yes, there is. But first and foremost, after copy-pasting the lines of code for each flame in your flames.ini, always check that the numbers in the POSITION have
simple coordinates like 0,0,-1 or 0,1,0 or similar. This way you’ll always know where to look for your flames. Look at Fig. for a clearer explanation of this.
There are actually two methods to adjust the flames positions. They’re quite easy, and each has its pros and cons. Both of them require the car to be working in AC to some
extent, as you will have to look at the result of your edits in a game session.

METHOD 1: Using the AC console

This is the best method in my opinion, because it is very straightforward and almost everything happens in-game, so there’s no way you can get things wrong if you’re adjusting
them live, looking directly at the final result. It is also the first method that ever existed.
It involves the AC console, which you can find an explanation of at par. 6.1. Using the command set observeFlames 1 you can display any change in the flames config
live, during any practice or race session. You adjust the positions to your liking and you’re done. There’s almost nothing done by the machine, you’re the only one who’s
changing the damn numbers on the config file with the text editor. If you pay attention at what you’re doing, there’s a lower chance of errors happening.
This method is also useful when working with flame behaviour and flames_presets.ini, as you can directly give the car some gas and see how it responds.
The only problem of this procedure is that you may need a couple minutes to understand the XYZ directions, but after that your brain will adjust automatically and everything
should be fine. With small changes to the coordinates you will be able to obtain the position you like.
Estimated time to completion: 20’-30’ or more (with zero knowledge), 10’-15’ (after reading, with trial and error), 5’ (nerd)
Pros: Once done it’s done; few tools, low effort. Relax.
Cons: Getting used to orienting with coordinates can take some time.

METHOD 2: Using Content Manager showrooms

Few years ago, when CM didn’t exist, I would have told you to use the console, but now apparently you can do almost everything with this powerful tool. That’s not true and we
know it, otherwise this manual wouldn’t exist. But enough talk. With this method you will use the CM showrooms, which you can see in Fig..
You have to activate the Flames checkbox in the Physics section of the Car tab of the CM showroom GUI. That will make appear a red vector representing the flame position
and direction (Fig.).

Fig. – You can use simple coordinates if you don’t or have difficulty to see the vector in the 3D viewport. Then adjust the POSITION and DIRECTION values to your liking.

Opening the text editor and adjusting the position by hand (Fig.) is possible, but you can also hit the letter T on your keyboard to enable the built-in Edit mode. This way you
can move the vector along the axes or rotate it with some drag and click of the mouse. Then you can save the result (Fig.).

417
Fig. – All in all it’s pretty easy, but be careful.

The main problem of this method is that you can’t look at the final result. You can only edit the position and direction on screen. When working with flame_presets.ini and
flame behaviour, this procedure is not useful at all, so I suggest using method 1 if you want to do that.
Estimated time to completion: 10’-15’ or more (with zero knowledge), 5’ (after reading, with trial and error), 2’ (nerd)
Pros: Moving things with the mouse is easy. Your cat is happy.
Cons: You can’t do everything with it, and some mod tools are required.

418
25. fuel_cons.ini
This file is used by the AI to calculate the amount of fuel before the start of the race session, based on the vehicle’s fuel consumption. Without the
fuel_cons.ini the amount they have at the race start is pretty much random. They will still pit normally when their tank is empty though.
This config can be created with the AI developer app if it's missing, but you need to unpack data.acd or create a data folder if you want AC to be able to
write/edit this config with the app. Official vanilla cars do have this file by default of course.
[FUEL_EVAL]
KM_PER_LITER=1.324720 ; Average fuel consumption of the vehicle for AI opponents. [Km/L]

% ▲ How many kilometres the vehicle can travel in average with 1 litre of fuel.

LITTLE EXPLANATION
- [FUEL_EVAL] is a consumption estimate for km/L that will skew the AI pit strategy/starting fuel, so if you make it too high they can end up doing stuff like
having to pit on the last laps to refuel.

CURIOSITIES AND AMENITIES:

- It's kinda hit or miss with the ai in my experience. It is better if you start off in weekend mode, as they don't actually build a pit stop plan in quick race
mode so they end up retiring. Having a practice and/or qualification session before the race forces them to calculate fuel. Now then once they've done that
it's up to race length. The ai won't pit in a 20-lap race if their tank is filled enough for it, while the longer the race the higher the probability of them pitting.
Last but not least always check the AI's tire compound before the race (with the Race Fuel Monitor app) and use the same.
- We know that modded AC has become a jewel at handling, variety and eye candy, but it's still trapped in often very disappointing AI racing conditions. The
AI driving itself is actually nice, you just need to find the perfect skill/aggressiveness range for each car, but their pit strategies (or lack of) make the race too
linear specially if Formula racing is your thing.
While there's no definite clean/realistic solution to it, a workaround I've been doing with some degree of success (and a great degree of fun) is this:
Unpack the car data. I'd recommend backing up the car you're going to tamper with.
Then, simply go to car.ini and find the [FUEL] line. You'll see the lines corresponding to the default FUEL and the MAX_FUEL the car can take.
Now, start a race with the desired car being controlled by AI, and open the Race Fuel Monitor app. After a few laps, you'll see how much Fuel per lap (FxL)
they are spending.
What now? Imagine you are planning on a 53-lap race on a particular track, and the AI is burning 1.80 litres per lap. 53 * 1.80 = 95.4 is how much fuel
they'd need to complete the race in a full tank, and if the car tank holds more than that, very often the AI decides on not stopping at all, so only on absurdly
long races (For a Formula perspective that is) we'd see them pitting.
After some experimentation, I've found out that if you change the MAX_FUEL to somewhere between this non-stop race value (95.4) and its half (47.7), so
say, 70 litres, the AI is forced to choose a stopping strategy. Change the MAX_FUEL in car.ini however you like, and then repack the data (or leave the data
folder and delete the data.acd file).
And what's really nice about it is that they won't all choose the same strategy (again, open Race Fuel Monitor at the beginning of the race to see what they've
decided on), sometimes you'll see one-stoppers (with early or late pitting!) and even a few two-stoppers. Then you'll race with the AI over and under cutting
both you and each other, and you can at least play around a bit with pit strategy.
To enhance this effect, the Weekend mode is best, because in it the AI will use the practice session to establish how much fuel they are burning, and I see
way more variety than when they just estimate mathematically in the Race mode. I also think that forcing them to use soft tyres makes the race more varied.
Ideally, they would choose different tyres in race but that's not possible unless you clone the car and choose multiple defaults. This is achieved with Content
Manager and the method of Fake Cars (Fig.).

Fig. – In the About section of CM you can find the explanation of the method of Fake Cars, which you can use to tweak the AI behaviour. The underlying procedure, even if automatic,
is quite tricky and relatively heavy on the system, but can potentially achieve good results.

419
26. lights.ini
If your car has got headlights, you’ll definitely want to see them work! This *.ini file manages all the lights of your vehicle, bulbs, blinkers, LEDs, gauges,
buttons, cockpit instruments illumination, and more.
Don’t forget to detach the objects (meshes of the bulbs, reflectors, etc.) and link them to their respective dummies if they are located on moving objects (e.g.
on the steering wheel or on retractable lights).
[HEADER]
VERSION=3 ; Script version. Keep this value =3 to support latest functions

% ▼ Modern Formula cars can add to [HEADER] the following four lines for a rear ERS status flash light:

FLASHING_BLINK_TIME=0.15 ; Flash blink time length for pit light and flasher. [s]
FLASHING_REPEAT=8 ; Blink repeat for pit light and flasher
KERS_BLINKING=1 ; Add this line to enable KERS blinking (optional)
NO_LIGHT_SWITCH=1 ; Add this line to block lights from activating with the headlight key (optional)

% ▼ Add only these two lines to the [HEADER] if you want to enable the flash function for headlights and pitlane lights:

FLASHING_BLINK_TIME=0.15
FLASHING_REPEAT=8

[BRAKE_0] ; Brake light identifier. SYNTAX: [BRAKE_ID], ID starting from zero.

% ▼ Different functions and colours can be assigned to different meshes.

NAME=EXT_LIGHT_BRAKE_1 ; Name of the mesh to light up.

COLOR=450,30,0 ; RGB emissive value (RED, GREEN, BLUE) assigned when you press the brake pedal.

% ▲ The mesh is lit using HDR and there is no maximum limit of intensity. The values for the COLOR parameter are in RGB 0 to 1 range, so a value of 1
means the maximum value of the RGB scale (256). The values can go over 1 if more intensity is needed. As an example, a value of 240 is given to the
[LIGHT_0] section, in order to produce a strong glow.

% ▲ For a glowing brake light the recommended value for R (red) is between 150 and 850. For day racing lights, recommended values are between 40 and 100,
while for high beams, recommend values range from 250 to 800.

OFF_COLOR=0,0,0 ; RGB emissive value for position light when brakes are off; mandatory for BRAKE items in VERSION=3

% ▲ The line OFF_COLOR is the emissive value of the rear position light for cars where the same mesh is lit up when you turn the lights on and when you
brake.

[LIGHT_0] ; Light identifier. SYNTAX: [LIGHT_ID], ID starting from zero. For headlights and general purpose.
NAME=EXT_HEADLIGHT ; Name of the mesh to light up.
COLOR=240,240,240 ; RGB emissive value when the front light is on.
OFF_COLOR=25,25,25 ; Add this RGB emissive value for a day racing light (optional)
INTENSITY=1 ; add description

[LIGHT_1]
NAME=EXT_Emissive_Light_Endurance_1
COLOR=180,0,0
PITLINE=1 ; Add this value for pit lights: 1 means it flashes in pitlane.
KERS=1 ; ERS status flash light: 1 means it flashes when KERS harvest is active
SPECIAL=1 ; Add this value if pit light should not be turned on with light switch\key, switching it on only in
pits

[LIGHT_2]
NAME=EXT_Emissive_Flash_0
COLOR=3,10,0
FLASH=1 ; Add this value if the light is also a flasher; 1 means will flash when flash key is pressed

[LIGHT_GAUGE_0]

% ▲ The dashboard headlight indicator lights and the dashboard lighting are also controlled by lights.ini. The dashboard objects and any other objects
that light up in the interior must be detached and named according to the following convention: [LIGHT_GAUGE_ID] and [LIGHT_INTERIOR_ID]

NAME=clocks
COLOR=0.2,0.2,0.1

LITTLE EXPLANATION
- There are few limitations on light behaviour with lihts.ini:
• Pit light and flasher functions do not work on BRAKE items.
• When the OFF_COLOR line is present in a LIGHT item, blinking occurs between the two values.

CURIOSITIES AND AMENITIES

- The Audi R18 e-tron quattro 2014 has in its data several lights.ini scripts that have been discarded during development: lights_blue.ini, lights_red_blue.ini
and lights_white.ini. This is serious dedication, as they weren’t originally supposed to be found (due to official .acd encryption).

420
27. lods.ini
This script manages the transitions between the LODs (of the exteriors?) of the vehicle.
Little reminder: LODs are a set of simplified models that change in relation of the camera distance. This process is necessary in order to optimize the
framerate in the game. The LOD switching can be controlled via the following script, located in ~root/AssettoCorsa/content/cars/your_car_name/data.
Verify that the distance of LOD “out” value matches the “in” value of the next LOD, otherwise your car will disappear before the switch.
Be aware that you can create more than four LODs, as explained in chapter, but it’s neither mandatory nor necessary.

- LODs don’t have specific naming rules, neither in the folder nor in the lods.ini script, but distinguishing them with letters is super useful to make things
easier. You don’t need to replicate the examples shown in chapter 1, however you should use one of the following naming standards, being equivalent:
~_a.kn5; ~_A.kn5; ~_lod_a.kn5; ~_lod_A.kn5; ~_LOD_a.kn5; ~_LOD_A.kn5; ~a.kn5; ~A.kn5.
[COCKPIT_HR]
DISTANCE_SWITCH=6 ; Indicates the distance (in meters) when the cockpit_HR changes to the cockpit_LR (if present)

[DRIVER_HR]
DISTANCE_SWITCH=750 ; just wow. I keep finding new lines. I imagine [DRIVER_HR] require a DRIVER_HR dummy in the scene.

[LOD_0] ; LOD identifier. SYNTAX: [LOD_ID], ID starting from zero.

% ▲ First LOD (the most detailed one). Corresponds to LOD A.

FILE=abarth500.kn5
IN=0 ; The distance at which Lod A appears visible.
OUT=15 ; Indicates the distance (in meters) at which lod A exchanges with lod B (if present)

[LOD_1] ; Second LOD. Corresponds to LOD B

FILE=abarth500_B.kn5
IN=15 ; For a correct behaviour, must be equal to the OUT value of previous Lod.
OUT=45 ; Indicates the distance (in meters) at which lod B exchanges with lod C (if present)

[LOD_2] ; Third LOD. Corresponds to LOD C

FILE=abarth500_C.kn5
IN=45 ; For a correct behaviour, must be equal to the OUT value of previous Lod.
OUT=200 ; Indicates the distance (in meters) at which lod C exchanges with lod D (if present)

[LOD_3] ; Fourth LOD. Corresponds to LOD D

FILE=abarth500_D.kn5
IN=200 ; For a correct behaviour, must be equal to the OUT value of previous Lod.
OUT=1500 ; Indicates the distance (in meters) at which lod D disappears from visual.

% ▼ Other LODs (not required, optional) added in this example. They follow the same syntax and use similar lines of code as the ones above. Adequate
FILE, IN and OUT values must be used in order to work properly. Vanilla content does not have more than the first four LODs (A, B, C, D).

[LOD_4]
[LOD_5]
[...]

28. mirrors.ini

This script manages mirrors. How?

[MIRROR_0] ; Mirror identifier. SYNTAX: [MIRROR_ID], ID starting from zero.
NAME=g_Door_L_SUB4 ; Name of the mesh that should act as a mirror.

[MIRROR_1]
NAME=g_Door_R_SUB2

[MIRROR_2]
NAME=GEO_Cockpit_SUB17

[MIRROR_3]
[MIRROR_4]
[...] ; A vehicle can have as many [MIRROR] as necessary.

421
29. proview_nodes.ini
This .ini is for Assetto Corsa Pro (feature available in vanilla AC as well, but meant for AC Pro).
It’s a view mode that can turn off / hide any object of the car which is being rendered. It’s the perspective you have in the stands with F1 cars, where there is
a car body in real life, so only the wheels are drawn on the screen (Fig.).

Fig. – Kunos software (a modified version of AC obviously), being used in the Evotek simulators.

Keep in mind that this works only for the two first person cameras in the cockpit, so you’ll see the car from outside views (Fig.). The script itself is basically
the tree of the hierarchy of all the objects (so meshes and NULLs) in the vehicle’s model.

Fig. – As you can see, the car is still visible in the exterior views.

422
To show only tyres (or only whatever you want) in a car:
1. Open with a text editor the options.ini file in your Assetto Corsa install folder: %root%\assettocorsa\system\cfg
2. This is the part of the script inside we care about:
[OPTIONS]
AUTOFLIP_RECOVERY=1
PROVIEW_MODE=0
RENDER_SPLINE=0
DISABLE_SHOW_MODE=0
IGNORE_RESULT_TELEPORT=0

3. Change PROVIEW_MODE=0 to PROVIEW_MODE=1. This enables the view mode, so every part of the car will be hidden. Note that you will have to change this back to
zero when you’ll desire to use the standard onboard view again.
4. Open proview_nodes.ini in the data folder of the car you want to modify (look at the FAQ of par. if you have data.acd) and edit the value of every element you want to see
when driving. Default is 0 (not visible). Change it to 1 and make it visible.
This script is also very useful if you want to reverse engineer mods, especially if you can’t or don’t want to unpack (decrypt) the models. The list is pretty
much identical to the Outliner in Blender and the Scene Explorer in 3DsMax.
The following example of proview_nodes.ini comes from the Ferrari 458 GT2 by Kunos. It is divided in two columns to save some space (and paper). The
colours refer to the NULLs of Chapter 2.
[NODES] ____LED_RPM_0=0
WHEEL_LF=0 ____LED_RPM_1=0
____RIM_BLUR_LF=0 ____LED_RPM_2=0
________polymsh_detached131=0 ____LED_RPM_3=0
____RIM_LF=0 ____LED_RPM_4=0
________Cerchione_Anteriore=0 ____LED_RPM_5=0
____TYRE_LF=0 ____LED_RPM_6=0
________g_Tyre_RF001=0 ____LED_RPM_7=0
WHEEL_RF=0 ____LED_RPM_8=0
____RIM_BLUR_RF=0 ____LED_RPM_9=0
________polymsh_detached133=0 ____LED_FUEL=0
____RIM_RF=0 ____GEO_cockpit_HR=0
________Cerchione_Anteriore1=0 ________Extra_Mirror=0
____TYRE_RF=0 COCKPIT_LR=0
________g_Tyre_RF4=0 ____STEER_LR=0
WHEEL_LR=0 ________GEO_Steer_LR=0
____RIM_BLUR_LR=0 ____GEO_cockpit_LR=0
________polymsh_detached132=0 DOOR_R=0
____RIM_LR=0 ____GEO_Door_R=0
________polymsh_detached129=0 ____DAMAGE_GLASS_RIGHT_2=0
____TYRE_LR=0 ________polymsh_extracted13=0
________g_Tyre_RF2=0 DOOR_L=0
WHEEL_RR=0 ____GEO_Door_L=0
____RIM_BLUR_RR=0 ____DAMAGE_GLASS_LEFT_2=0
________polymsh_detached134=0 ________polymsh_extracted14=0
____RIM_RR=0 WIPER=0
________polymsh_detached130=0 ____polymsh9=0
____TYRE_RR=0 ____WIPER1=0
________g_Tyre_RF3=0 ________polymsh_detached=0
SUSP_LF=0 DAMAGE_GLASS_RIGHT_1=0
____GEO_HUB1=0 ____polymsh_detached120=0
SUSP_RF=0 DAMAGE_GLASS_CENTER_2=0
____GEO_HUB=0 ____polymsh_detached119=0
SUSP_LR=0 DAMAGE_GLASS_REAR_1=0
____GEO_HUB2=0 ____polymsh_extracted9=0
SUSP_RR=0 DAMAGE_GLASS_LEFT_1=0
____GEO_HUB3=0 ____polymsh_detached121=0
DISC_LF=0 DAMAGE_GLASS_CENTER_1=0
____GEO_DISC_LF=0 ____polymsh_extracted11=0
DISC_RF=0 DAMAGE_GLASS_FRONT_1=0
____GEO_DISC_RF=0 ____polymsh_extracted12=0
DISC_LR=0 WING=0
____GEO_DISC_LR=0 ____GEO_RearWing=0
DISC_RR=0 GEO_BODY_Trasp=0
____GEO_DISC_RR=0 FRONT_LIGHTS=0
COCKPIT_HR=0 ____FRONT_LIGHT_2=0
____STEER_HR=0 ____FRONT_LIGHT_1=0
________GEO_STEER=0 ____FRONT_LIGHT_3=0
____________LED_0=0 REAR_LIGHTS=0
____________LED_1=0 ____REAR_LIGHT_REAR=0
____________LED_2=0 ____REAR_LIGHT_BRAKE=0
____________LED_3=0 ____REAR_LIGHT_BRAKE_CENTRAL=0
____________LED_4=0 FRONT_BUMPER=0
____________LED_5=0 ____GEO_FRONTBUMPER=0
____________LED_6=0 REAR_BUMPER=0
____________LED_7=0 ____GEO_REARBUMPER=0
____CINTURE_ON=0 ____LIGHT_RAIN=0
____CINTURE_OFF=0 MOTORHOOD=0
____DOOR_R1=0 ____GEO_Motorhood=0
________GEO_Door_R1=0 EXHAUST1=0
____DOOR_L1=0 EXHAUST2=0
________GEO_Door_L1=0 Mtore=0
____GEO_Vetro_interno=0 GEO_Body=0
____SHIFT=0 FLYCAM_L_0=0
________SHIFT2=0 FLYCAM_L_1=0
____________polymsh_detached1=0 FLYCAM_L_2=0
________polymsh_detached135=0 FLYCAM_L_3=0
____SHIFT1=0 FLYCAM_L_4=0
________polymsh_detached5=0 FLYCAM_L_5=0
____SHIFT3=0 FLYCAM_R_0=0
________SHIFT4=0 FLYCAM_R_1=0
____________polymsh_detached4=0 FLYCAM_R_2=0
________polymsh_detached2=0 FLYCAM_R_3=0
____DISPLAY_DATA=0 FLYCAM_R_4=0
____LED_LIGHTS=0

423
30. setup.ini
This configuration file lets you determine the values that can be changed in the setup GUIs right at the beginning of every session. It is one of the longest in
terms of text lines.
To avoid repetition and confusion, the example script below has been edited: some repeated lines are missing, and some sections have been reordered. For
reference, take a look at the setup.ini file of the official Ferrari SF70H by Kunos, or other Formula cars, which are the most complete in terms of features.
[DISPLAY_METHOD]
SHOW_CLICKS=1

[GEARS] ; Defines what kind of gearset can be used in setup.

USE_GEARSET=0 ; =0 gives access to various gears sliders. =1 Gives you prefixed compilations of gearboxes.

/////////////////////////////////////////////////////
;AERO
/////////////////////////////////////////////////////

[WING_1]
SHOW_CLICKS=0 ; 0 shows actual value. 1 Shows number of clicks needed depending step. 2 shows clicks starting from 0
TAB=AERO ; Tab to visualise.

% ▲ Keep consistent with default tabs otherwise ac will crash because of locales files errors.

NAME=Front left ; Name of setup component

MIN=0 ; Minimum permitted value, for wings is the angle. [deg] (this unit only for wings)
MAX=30 ; Maximum permitted value, for wings is the angle. [deg] (this unit only for wings)
STEP=1 ; Sets the amount changed by each click in setup screens; if it's 10 then you go +10 or -10 per click.
POS_X=0 ; Position of the selector on the X axis. Values: 0=left, 0.5=middle, 1=right.

% ▲ Where the text shows up on the setup screen, in the X coordinates.

POS_Y=1 ; Position of the selector on the Y axis. Values from 0 to 8.

% ▲ Where the text shows up on the setup screen, in the Y coordinates.

% ▲+▲▲ The following picture (Fig.) shows the coordinates in the setup tabs.

HELP=HELP_FRONT_WING ; Tool tip help to show on title mouseover.

% ▲ Reference for AC to decide which of the quick tips should be displayed in the setup menu. The quick tips are predefined and the following:

hfigkjghklfghlhjolminònm

PITSTOP=2.5

% ▼ The lines similar or identical to [WING_1] will be skipped. There are no lines missing apart from those.

[WING_2]
NAME=Front right

[WING_3]
NAME=Rear wing
HELP=HELP_REAR_WING

/////////////////////////////////////////////////////
;TYRES
/////////////////////////////////////////////////////

[PRESSURE_LF]
SHOW_CLICKS=0
TAB=TYRES
NAME=Pressure LF
MIN=6 ; Minimum permitted value, for tires is the pressure. [bar] (this unit only for tires)
MAX=28 ; Minimum permitted value, for tires is the pressure. [bar] (this unit only for tires)
STEP=1 ; Sets the amount changed by each lick in setup screens; if it's 10 then you go +10 or -10 per click.
POS_X=0
POS_Y=2
HELP=HELP_LF_PRESSURE

% ▼ The lines similar or identical to [PRESSURE_LF] will be skipped. There are no lines missing apart from those.

[PRESSURE_RF]
NAME=Pressure RF
HELP=HELP_RF_PRESSURE

[PRESSURE_LR]
NAME=Pressure LR
HELP=HELP_LR_PRESSURE

[PRESSURE_RR]
NAME=Pressure RR
HELP=HELP_RR_PRESSURE

/////////////////////////////////////////////////////
;SUSPENSION
/////////////////////////////////////////////////////

[SPRING_RATE_HF]
SHOW_CLICKS=2
TAB=SUSPENSIONS
NAME=Wheel rate HF
MIN=80
MAX=180
STEP=10 ; Sets the amount changed by each click in setup screens; if it's 10 then you go +10 or -10 per click.
POS_X=0.5
POS_Y=3
HELP=HELP_HF_WHEELRATE

% ▼ The lines similar or identical to [SPRING_RATE_HF] will be skipped. There are no lines missing apart from those.

[SPRING_RATE_HR]
NAME=Wheel rate HR
HELP=HELP_HF_WHEELRATE

[SPRING_RATE_LF]
NAME=Wheel rate LF
HELP=HELP_LF_WHEELRATE

% ▼ The lines similar or identical to [SPRING_RATE_LF] will be skipped. There are no lines missing apart from those.

[SPRING_RATE_RF]
NAME=Wheel rate RF

424
HELP=HELP_RF_WHEELRATE

[SPRING_RATE_LR]
NAME=Wheel rate LR
HELP=HELP_LR_WHEELRATE

[SPRING_RATE_RR]
NAME=Wheel rate RR
HELP=HELP_RR_WHEELRATE

[ROD_LENGTH_LF]
SHOW_CLICKS=0
TAB=SUSPENSIONS
NAME=Height LF
MIN=100
MAX=500
STEP=10
POS_X=0
POS_Y=2
HELP=HELP_LF_RODLENGTH

% ▼ The lines similar or identical to [ROD_LENGTH_LF] will be skipped. There are no lines missing apart from those.

[ROD_LENGTH_RF]
NAME=Height RF
HELP=HELP_RF_RODLENGTH

[ROD_LENGTH_LR]
NAME=Height LR
HELP=HELP_LR_RODLENGTH

[ROD_LENGTH_RR]
NAME=Height RR
HELP=HELP_RR_RODLENGTH

[ARB_FRONT]
SHOW_CLICKS=2
TAB=SUSPENSIONS
NAME=ARB Front
MIN=30000
MAX=100000
STEP=2000
POS_X=0.5
POS_Y=0
HELP=HELP_FRONT_ARB

% ▼ The lines similar or identical to [ARB_FRONT] will be skipped. There are no lines missing apart from those.

[ARB_REAR]
NAME=ARB Rear
HELP=HELP_REAR_ARB

/////////////////////////////////////////////////////
;SUSPENSION ADVANCED
/////////////////////////////////////////////////////

[BUMP_STOP_RATE_LF]
SHOW_CLICKS=0
TAB=SUSPENSION ADV.
NAME=Packer rate
MIN=150
MAX=250
STEP=5
POS_X=0
POS_Y=0
HELP=HELP_LF_BUMP_STOP_RATE

% ▼ The lines similar or identical to [BUMP_STOP_RATE_LF] will be skipped. There are no lines missing apart from those.

[BUMP_STOP_RATE_RF]
HELP=HELP_RF_BUMP_STOP_RATE

[BUMP_STOP_RATE_LR]
HELP=HELP_LR_BUMP_STOP_RATE

[BUMP_STOP_RATE_RR]
HELP=HELP_RR_BUMP_STOP_RATE

[PACKER_RANGE_LF]
SHOW_CLICKS=0
TAB=SUSPENSION ADV.
NAME=Travel range
MIN=20
MAX=80
STEP=1
POS_X=0
POS_Y=1
HELP=HELP_LF_TRAVEL_RANGE

% ▼ The lines similar or identical to [PACKER_RANGE_LF] will be skipped. There are no lines missing apart from those.

[PACKER_RANGE_RF]
HELP=HELP_RF_TRAVEL_RANGE

[PACKER_RANGE_LR]
HELP=HELP_LR_TRAVEL_RANGE

[PACKER_RANGE_RR]
HELP=HELP_RR_TRAVEL_RANGE

/////////////////////////////////////////////////////
;ALIGNMENT
/////////////////////////////////////////////////////

[CAMBER_LF]
SHOW_CLICKS=0
TAB=ALIGNMENT
NAME=CAMBER_LF
MIN=-3.6 ; degrees
MAX=1
STEP=1
POS_X=0
POS_Y=0
HELP=HELP_LF_CAMBER

% ▼ The lines similar or identical to [CAMBER_LF] will be skipped. There are no lines missing apart from those.

425
[CAMBER_RF]
NAME=CAMBER_RF
HELP=HELP_RF_CAMBER

[CAMBER_LR]
NAME=CAMBER_LR
HELP=HELP_LR_CAMBER

[CAMBER_RR]
NAME=CAMBER_RR
HELP=HELP_RR_CAMBER

[TOE_OUT_LF]
SHOW_CLICKS=2
TAB=ALIGNMENT
NAME=Toe LF
MIN=0
MAX=100
STEP=1
POS_X=0
POS_Y=1
HELP=HELP_LF_TOE

% ▼ The lines similar or identical to [TOE_OUT_LF] will be skipped. There are no lines missing apart from those.

[TOE_OUT_RF]
NAME=Toe RF
HELP=HELP_RF_TOE

[TOE_OUT_LR]
NAME=Toe LR
HELP=HELP_LR_TOE

[TOE_OUT_RR]
NAME=Toe RR
HELP=HELP_RR_TOE

/////////////////////////////////////////////////////
;DAMPERS LF ; Left Front wheel dampers.
/////////////////////////////////////////////////////

[DAMP_BUMP_LF]
SHOW_CLICKS=2
TAB=DAMPERS
NAME=Bump
MIN=1000
MAX=5560
STEP=190
POS_X=0
POS_Y=0
HELP=HELP_LF_DAMPER_BUMP

% ▼ The lines similar or identical to [DAMP_BUMP_LF] will be skipped. There are no lines missing apart from those.

[DAMP_FAST_BUMP_LF]
NAME=FST Bump
HELP=HELP_LF_DAMPER_FBUMP

[DAMP_REBOUND_LF]
NAME=Rebound
HELP=HELP_LF_DAMPER_REBOUND

[DAMP_FAST_REBOUND_LF]
NAME=FST Rebound
HELP=HELP_LF_DAMPER_FREBOUND

% ▼ For all other damper types, the lines similar or identical to every section of the DAMPERS LF above will be skipped. There are no lines missing apart
from those.

/////////////////////////////////////////////////////
;DAMPERS RF ; Right Front wheel dampers.
/////////////////////////////////////////////////////

[DAMP_BUMP_RF]
HELP=HELP_RF_DAMPER_BUMP

[DAMP_FAST_BUMP_RF]
HELP=HELP_RF_DAMPER_FBUMP

[DAMP_REBOUND_RF]
HELP=HELP_RF_DAMPER_REBOUND

[DAMP_FAST_REBOUND_RF]
HELP=HELP_RF_DAMPER_FREBOUND

/////////////////////////////////////////////////////
;DAMPERS LR ; Left Rear wheel dampers.
/////////////////////////////////////////////////////

[DAMP_BUMP_LR]
HELP=HELP_LR_DAMPER_BUMP

[DAMP_FAST_BUMP_LR]
HELP=HELP_LR_DAMPER_FBUMP

[DAMP_REBOUND_LR]
HELP=HELP_LR_DAMPER_REBOUND

[DAMP_FAST_REBOUND_LR]
HELP=HELP_LR_DAMPER_FREBOUND

/////////////////////////////////////////////////////
;DAMPERS RR ; Right Rear wheel dampers.
/////////////////////////////////////////////////////

[DAMP_BUMP_RR]
HELP=HELP_RR_DAMPER_BUMP

[DAMP_FAST_BUMP_RR]
HELP=HELP_RR_DAMPER_FBUMP

[DAMP_REBOUND_RR]
HELP=HELP_RR_DAMPER_REBOUND

[DAMP_FAST_REBOUND_RR]
HELP=HELP_RR_DAMPER_FREBOUND

/////////////////////////////////////////////////////

426
;DAMPERS HF ; Heave Front dampers.
/////////////////////////////////////////////////////

[DAMP_BUMP_HF]
TAB=HEAVE DAMPERS
HELP=HELP_HF_DAMPER_BUMP

[DAMP_FAST_BUMP_HF]
TAB=HEAVE DAMPERS
HELP=HELP_HF_DAMPER_FBUMP

[DAMP_REBOUND_HF]
TAB=HEAVE DAMPERS
HELP=HELP_LF_DAMPER_REBOUND

[DAMP_FAST_REBOUND_HF]
TAB=HEAVE DAMPERS
HELP=HELP_HF_DAMPER_REBOUND

/////////////////////////////////////////////////////
;DAMPERS HR ; Heave Rear dampers
/////////////////////////////////////////////////////

[DAMP_BUMP_HR]
TAB=HEAVE DAMPERS
HELP=HELP_HF_DAMPER_BUMP

[DAMP_FAST_BUMP_HR]
TAB=HEAVE DAMPERS
HELP=HELP_HF_DAMPER_FBUMP

[DAMP_REBOUND_HR]
TAB=HEAVE DAMPERS
HELP=HELP_LF_DAMPER_REBOUND

[DAMP_FAST_REBOUND_HR]
TAB=HEAVE DAMPERS
HELP=HELP_HF_DAMPER_REBOUND

/////////////////////////////////////////////////////
;DRIVETRAIN
/////////////////////////////////////////////////////

% ▲▼ If you’re using the AWD traction type in drivetrain.ini, the lines under [AWD_FRONT_TORQUE_DISTRIBUTION], [FRONT_DIFF_POWER], [FRONT_DIFF_COAST],
[FRONT_DIFF_PRELOAD], [CENTER_DIFF_POWER], [CENTER_DIFF_COAST], [CENTER_DIFF_PRELOAD], [REAR_DIFF_POWER], [REAR_DIFF_COAST] and [REAR_DIFF_PRELOAD] can be
added under the ;DRIVETRAIN setup tab.

% For the AWD2 traction type, the code does not allow any regulations, so you won’t have to add the lines below to setup.ini. Basically you can’t edit an
AWD2 setup.

[AWD_FRONT_TORQUE_DISTRIBUTION]
SHOW_CLICKS=0
TAB=DRIVETRAIN
NAME=Front Distribution
MIN=0
MAX=100

% ▲ Front Torque Distribution is wrong coded and you have to put value between 0 and 1, not 0 to 100.

STEP=1
POS_X=0.5
POS_Y=-0.5
HELP=

[FRONT_DIFF_POWER]
SHOW_CLICKS=0
TAB=DRIVETRAIN
NAME=Front Power
MIN=0
MAX=100
STEP=5
POS_X=0
POS_Y=1.5
HELP=HELP_DIFF_POWER

[FRONT_DIFF_COAST]
SHOW_CLICKS=0
TAB=DRIVETRAIN
NAME=Front Coast
MIN=0
MAX=100
STEP=5
POS_X=1
POS_Y=1.5
HELP=HELP_DIFF_COAST

[FRONT_DIFF_PRELOAD]
SHOW_CLICKS=0
TAB=DRIVETRAIN
NAME=Front preload
MIN=0
MAX=100
STEP=5
POS_X=0.5
POS_Y=2.5
HELP=HELP_DIFF_PRELOAD

% ▼ The lines similar or identical to [FRONT_DIFF_POWER], [FRONT_DIFF_COAST] and [FRONT_DIFF_PRELOAD] will be skipped. There are no lines missing apart
from those.

[CENTER_DIFF_POWER]
NAME=Center Power
POS_X=0
POS_Y=4.5

[CENTER_DIFF_COAST]
NAME=Center Coast
POS_X=1
POS_Y=4.5

[CENTER_DIFF_PRELOAD]
NAME=Center preload
POS_X=0.5
POS_Y=5.5

[REAR_DIFF_POWER]
NAME=Rear Power
POS_X=0

427
POS_Y=7.5

[REAR_DIFF_COAST]
NAME=Rear Coast
POS_X=1
POS_Y=7.5

[REAR_DIFF_PRELOAD]
NAME=Rear preload
POS_X=0.5
POS_Y=8.5

/////////////////////////////////////////////////////
;GEARS
/////////////////////////////////////////////////////

[FINAL_GEAR_RATIO]
RATIOS = final.rto
NAME = Final Gear Ratio
POS_X = 0.5
POS_Y = 2.5
HELP = HELP_REAR_GEAR

/////////////////////////////////////////////////////
;GENERIC
/////////////////////////////////////////////////////

[FUEL]
SHOW_CLICKS=0
TAB=GENERIC
NAME=Fuel
MIN=5
MAX=133
STEP=1
POS_X=0.5
POS_Y=0
HELP=HELP_FUEL

[FRONT_BIAS]
SHOW_CLICKS=0
TAB=GENERIC
NAME=Brake Bias
MIN=52
MAX=68
STEP=1
POS_X=0.5
POS_Y=1
HELP=HELP_BRAKE_BIAS

[BRAKE_POWER_MULT]
SHOW_CLICKS=0
TAB=GENERIC
NAME=Brake power
MIN=80
MAX=100
STEP=1
POS_X=0.5
POS_Y=2
HELP=HELP_BRAKE_POWER_MULT

LITTLE EXPLANATION
- If a parameter in your setup.ini does not have the correct range, it will overrule the other data files and limit the default value(s) of the physics.
For example, if your default camber on your front wheel is -3° (given from suspensions.ini) but your setup.ini range is from -2 to -1, then the default camber
in-game won't exceed -2°.
Another case: if setup.ini says that springs have a 200˙000-300˙000 N/m range, while suspensions.ini has a value of 50,000 N/m, then AC will use
200˙000-300˙000 N/m.
Basically if you have a range of adjustment in the setup script, the real-time simulated value will always fall within it, no matter if it’s a larger or thinner interval.
So always double check and verify that your setup.ini has the correct range of values to fit the default physics values.
When creating a new vehicle, the best option is to clear out setup.ini of everything but camber, toe, fuel and tires. Tweak the car via the other data files, and
fill in this config file as the last step after everything else is done.
It is also possible to create a premade setup file that you paste every time when you’re working with your mods, with really wide ranges, that way you're not
being constrained by anything, but can still make very quick changes early on.
- In general, with few exceptions, you can add anything from the data files to setup.ini. (needs more research)

ABOUT RELATED FILES

ai_default.ini
This is an extra config file that can be created by copying the setup.ini of the specific car inside the following path:
C:\Users\Your_User_Name\Documents\Assetto Corsa\setups\your_car_name\specific_track_name.
It allows you to force virtual opponents (AIs) to use a predefined setup for the races. The file is looked up by AC for offline sessions only.
You can also create it inside the GUI of a race session, by saving a new setup as “AI_default”. If it already exists (normally it shouldn’t), just overwrite it.
This functionality however is limited to aerodynamics, suspensions (e.g. ride height) and gear ratios, and there are some bugs. For some reason the AIs
disregard the eventual gear ratios (if you have multiple gearsets). Moreover, as already explained for ai.ini, virtual opponents pick their own tire compounds
and fuel, and sadly this file has no influence on that.
Also, it is track-specific, as you might have guessed from the folder path. This way the function is sadly not useful to adjust the AI for a specific race condition,
pit stop strategies, etc.
The following is an example of use case for this script:
Speedways can be geared and winged for over 400 kph whilst Short ovals can be below 300 kph.

428
This large difference means the use of ai_default.ini as a saved setup is unavoidable, however the AI won't use the gear ratios from that file and also lose the
ability to change the final gear ratio to an appropriate one.
In setup.ini toggle USE_GEARSET=1. Design a generic gearset or more, that the player can use; design a fine grained choice of Final Drive ratios for the
player to use.
In drivetrain.ini use 9 really close ratios and a final drive ratio, ensure these do not share any value with any ratio available to the player.
The AI won't use the player's gearset, as none of the values match, so defaults to the values in drivetrain.ini. On track it now has more gears to work with,
hopefully allowing it to run at any speed.
In the example above the AI would only use 9th gear at say Michigan but would only ever get into 5th or 6th at Milwaukee.
Works 'perfectly' in the above example or in Karts with only one gear.
Problems:
-The gears used may not reflect real gear ratios.
-Nine gears in the setup GUI is displayed somewhat messed up (more than six doesn't seem to fit).

429
31. sounds.ini
For technical reasons and easier management, some sound events (par. 7.) get external interaction with this script, which lets you adjust the volume of
certain sounds of your car, and configures also some backfire params. One of the most important parameters here is the POSITION of the engine. It must
correspond to the actual vehicle configuration, so that the sound source is placed correctly on the car by the audio engine.
[SKIDS] ; Section dedicated to tire skid/squeal sound.

% ▲ The whole [SKID] section is deprecated and is not needed anymore.

ENTRY_POINT=0.45 ; Related to the tyre load. Values [0 – 1.0]

% ▲ Lowering the value will make the skid sound audible even with a minimum tyre load.

MIX_VOLUME=0.7 ; Global sample volume of tire squeal sound. Values [0 – 1.0]

PITCH_BASE=0.42 ; Deprecated
PITCH_GAIN=0.13 ; Deprecated

[WIND] ; Section dedicated to wind sound

SPEED_GAIN_0=0 ; Volume increase for every kmh
SPEED_GAIN_1=0.000045 ; Volume increase for squared kmh
VOLUME_GAIN=0.9 ; Maximum volume reached by the wind (DO NOT EXCEEED 1.0)
PITCH_REFERENCE=50 ; Reference speed for speed variation. [Km/h]
PITCH_GAIN=0.3 ; Pitching gain for speed variation

[TYRE_ROLLING]
SPEED_GAIN_0=0.0025
SPEED_GAIN_1=0.0
VOLUME_GAIN=0.88
PITCH_REFERENCE=50
PITCH_GAIN=0.25

[BACKFIRE] ; Section dedicated to backfire parameters. Influences when backfires happen, not only the sound.
MAXGAS=0.4 ; Backfires are not played if input gas is > maxgas. Values [0 – 1.0]
MINRPM=9000 ; Minimum rotational regime of the engine at which backfires happen. [RPM]
MAXRPM=15000 ; Maximum rotational regime of the engine at which backfires happen. [RPM]

% ▲▲ MINRPM and MAXRPM represent the engine RPM range within which the backfires are audible.

TRIGGERGAS=0.8 ; Trigger point for backfires, related to throttle input. Values [0 – 1.0]
VOLUME_IN=1.0
VOLUME_OUT=1.0
VOLUME_SCALE_OUT=8

[BODY_WORK]
MIN=0.4
GAIN=1

[GEAR_EXT]
DISTANCE_SCALE=9

[ENGINE] ; Section dedicated to the engine sound emitter position.

% ▲▼ Optional. If this section is not present, the engine sound emitter is on the CoG of the vehicle. It is recommended to add these lines in your script
and input a correct value.

POSITION=rear ; Position of the engine sound relative to the car’s configuration. Available options: front, rear.

CURIOSITIES AND AMENITIES

You may find obsolete sections in the sound configs of old mods or official cars by Kunos. An example is in the Nissan Skyline GTR R34 V-Spec, because
there is this part:
[TURBO]
WAV=turbo.wav ; The presence of this line indicates that this is an obsolete section. It can be deleted/ignored.
REF_PITCH=1.2
PITCH_GAIN=0.2
VOLUME=0
MIN_VOLUME=0
MAX_VOLUME_AT=3
DISTANCE_SCALE=2.0
VELOCITY_GAIN=0.0

% ▲ As a consequence, the entire [TURBO] section can be deleted/ignored as obsolete.

[TURBO_BOW]
WAV=turbo.wav ; The presence of this line indicates that this is an obsolete section. It can be deleted/ignored.
FULL_GAS_LIMIT=2.5
ZERO_GAS_LIMIT=0.7
REF_PITCH=1.2
PITCH_GAIN=0.2
VOLUME=0
MIN_VOLUME=0
MAX_VOLUME_AT=3
DISTANCE_SCALE=2.0

% ▲ As a consequence, the entire [TURBO_BOW] section can be deleted/ignored as obsolete.

Whenever there are filenames in sounds.ini, it means that the sections come from a period in time located before AC adopted the FMOD audio engine, and
thus employed directly the audio samples. Those lines of code can be deleted. Another relic of the development past of our simulator.

430
32. suspensions.ini
This config sets most of the parameters for the sprung and unsprung masses, such as the placement of the suspension linkages, the stiffness of springs and
dampers, the graphical offsets (you can set spacers for the wheels) and more. In this example Double Wishbone suspensions will be used, while other
possible designs will be explained in the continuation.
[HEADER]
VERSION=4 ; Version of the suspensions code that the physics engine will load.

% ▲ Each version introduces new and more accurate features. Input is a number, from 1 to 4, with 1 being the oldest and 4 including the latest features.

% ▲ VERSION=2 adds the progressive wheelrate and other parameters. =3 and =4 add features too and are required for the live axle. Again, the recommended
input is 4, use it to avoid confusion.

[BASIC]
WHEELBASE=2.6441 ; Longitudinal distance between the front and rear axle (how far apart they are). [m]
CG_LOCATION=0.585 ; Distribution of the sprung mass over the wheels. Input is percent, for example 50% = 0.50.

% ▲ This value is NOT the total car CG. The total CG is calculated from the fuel tank position and weight (described in the values under [FUEL] and
[FUELTANK] in car.ini) and the ride height.

% For a basic drawing of what the WHEELBASE and CG_LOCATION values do, look at Fig. in the LITTLE EXPLANATION section.

[ARB] ; Anti-Roll-Bar. (explanation)

FRONT=100 ; Stiffness of the front ARB, measured at the wheel. [N/m]
REAR=100 ; Stiffness of the rear ARB, measured at the wheel. [N/m]

[FRONT]
TYPE=DWB ; The suspension type used. Inputs are DWB, STRUT, ML.
BASEY=0.014 ; The height that is 0 for all suspension components. [m]
RIM_OFFSET=0 ; Wheel offset. [m]

% ▲ Effectively, it adds the amount to the X coordinates of the suspension linkages, on each side of the car.
Take care to adjust TRACK in suspensions.ini after adjusting RIM_OFFSET if the intention is to “change wheels”. As in, to know how much you should
increase your track, divide RIM_OFFSET by 2.
Not required, but it simplifies suspension creation, as you can use one set of coordinates with multiple wheels.

TRACK=1.335 ; Track width (from 3D placement of the pivot of the 3d model of a wheel). [m]

% ▲ Lateral dimension between the left and right tire contact patch, when the camber angle is 0 degrees and the suspension is at design height.
% When you go measure track on your car, you measure from center of tire, to center of tire.

ROD_LENGTH=0.055 ; Push rod length in meters. Positive raises ride height, Negative lowers ride height. [m]

% ▲ This is an offset value. Before using it, set properly the car's weight, the springrates, and some other stuff, and then adjust ROD_LENGTH so the car
sits at the right height. If the actual suspension attachment points aren't where you want them, that's what BASEY or the car.ini visual offset is for.

HUB_MASS=54 ; Portion of the unsprung mass for one corner. Includes the wheel and tire weight. [Kg]

% ▲ With the AXLE suspension type, the unsprung mass is 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.
You can check the unsprung masses in the Car Engineer App.

% 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.

% ▼ Coordinates of the suspension attaching points:

STRUT_CAR=0.12, 0.3, -0.0

STRUT_TYRE=0.1,-0.10,0.0
WBCAR_BOTTOM_FRONT=0.35,-0.09,0.32
WBCAR_BOTTOM_REAR=0.35,-0.1,-0.37
WBTYRE_BOTTOM=0.1,-0.10,0.0
WBCAR_STEER=0.667,-0.175,-0.16
WBTYRE_STEER=0.135,-0.175,-0.11
TOE_OUT=0.0000
; Bottom front car side wishbone attach point.
; Bottom rear car side wishbone attach point.
; Bottom tyre side wishbone attach point.
; Steering rod car side attach point.
; Steering rod tyre side attach point.
; Setup toe angle, expressed as the length of the steering arm. [m]

% ▲ It is the lateral displacement of the tie rod. Currently not functional for TYPE=AXLE.

STATIC_CAMBER=2.35 ; Wheel static camber angle for setup. The actual camber is relative to suspension geometry and
movement. check values in game. [deg]

% ▲ Keep in mind that camber adjustment will not move TYRE suspension points, it simply pivots the wheel. Currently not functional for AXLE.

SPRING_RATE=32000 ; Wheelrate of a single corner spring on that axle; the value is shared for left and right. [N/m]

% ▲ This is the wheel rate stiffness. Do not use the spring value. This parameter has to be calculated.

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=1 ; Progressive WHEELRATE. Can and commonly should be paired with SPRING_RATE. [N/m/m].

% ▲ For progressive springs, you should also have a linear springrate component.

BUMP_STOP_RATE=580 ; WHEELRATE of the PACKER_RANGE and BUMPSTOP_UP/DN. [N/m]

% ▲ Bear in mind that STRUT and AXLE suspensions currently have a hardcoded ~500000 N/m rate for the BUMPSTOP entries.

BUMPSTOP_UP=0.13112 ; Vertical movement of the wheel, until impacting the bump rubber. [m]
BUMPSTOP_DN=0.0526 ; Wheel travel, until impacting the internal bump stopper of the damper, which resists droop. [m]
PACKER_RANGE=0.162 ; Position of the packer along the suspension travel. [m]

% ▲ Gap to bumpstop from the ROD_LENGTH point of the suspension. The formula is susp travel + 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.

Total travel minus packer range equals packer thickness.

100mm - 80mm = 20mm.

So if you have 100mm of total travel and want a 20mm packer, then you set PACKER_RANGE=0.080 and the rest 20mm of the travel will be the packer. If you
have no packer, you set PACKER_RANGE as the total travel, and there will be no packer.

(old description) Total suspension movement range, before hitting packers

But actually, what are packers?

such as a plastic packer for racecars, or rubber bumpstop for roadcars

DAMP_BUMP=26800 ; Wheel damping rate for bump travel when the wheel is travelling slower than the
DAMP_FAST_BUMPTHRESHOLD value. [N/m/s]

431
DAMP_FAST_BUMP=1 ; Wheel damping rate for bump travel when the wheel is travelling faster than the
DAMP_FAST_BUMPTHRESHOLD value. [N/m/s]

DAMP_FAST_BUMPTHRESHOLD=1 ; Transition point, or “knee” for the bump damping to change from SLOW to FAST. [m/s]

DAMP_REBOUND=4650 ; Wheel damping rate for rebound travel when the wheel is traveling slower than the
DAMP_FAST_REBOUNDTHRESHOLD value. [N/m/s]

DAMP_FAST_REBOUND=1 ; Wheel damping rate for rebound travel when the wheel is traveling faster than the
DAMP_FAST_REBOUNDTHRESHOLD value. [N/m/s]

DAMP_FAST_REBOUNDTHRESHOLD=1 ; Transition point, or “knee” for the rebound damping to change from SLOW to FAST. [m/s]

BUMP_STOP_PROGRESSIVE=0 ; It works the same as PROGRESSIVE_SPRING_RATE but for the packers/bumpstops.

[HEAVE_FRONT] ; Section dedicated to heave springs (third elements).

ROD_LENGTH=0.015 ; heave (3rd spring) push rod length in meters. positive raises ride height, negative lowers it.
SPRING_RATE=166000 ; 3rd spring wheel rate stiffness in Nm. Do not use spring value but calculate wheel rate
PROGRESSIVE_SPRING_RATE=0 ; 3rd spring progressive spring rate in N/m/m
BUMP_STOP_RATE=165000 ; 3rd spring bump stop spring rate
BUMPSTOP_UP=0.035 ; meters to upper bumpstop from the 0 design of the suspension
BUMPSTOP_DN=0.035 ; meters to bottom bumpstop from the 0 design of the suspension
PACKER_RANGE=0.045 ; Total suspension movement range, before hitting packers
DAMP_BUMP=8276 ; Damper wheel rate stifness in N sec/m in compression
DAMP_FAST_BUMP=2262 ; Damper wheel rate stiffness in N sec/m in fast speed compression
DAMP_FAST_BUMPTHRESHOLD=0.028 ; Damper bump slow/fast threshold in seconds
DAMP_REBOUND=8680 ; Damper wheel rate stifness in N sec/m in rebound
DAMP_FAST_REBOUND=4365 ; Damper wheel rate stiffness in N sec/m in fast speed rebound
DAMP_FAST_REBOUNDTHRESHOLD=0.040 ; Damper rebound slow/fast threshold in seconds

[REAR] ; Similar parameters as seen for [FRONT], with additions for the specific suspension type.
TYPE=DWB ; For the rear AXLE and ML types can be used, as well as DWB and STRUT.
BASEY=0.03
RIM_OFFSET=0
TRACK=1.2
ROD_LENGTH=0.054
HUB_MASS=146

% ▼ In this example the rear has more linkages than the front.

WBCAR_TOP_FRONT=0.28, 0.01, 0.72
WBCAR_TOP_REAR=0.30, 0.06, -0.01
WBCAR_BOTTOM_FRONT=0.33, -0.20, 0.77
WBCAR_BOTTOM_REAR=0.47, -0.232, -0.01
WBTYRE_TOP=0.14, 0.10, 0.01
WBTYRE_BOTTOM=0.15, -0.20, 0.0015
WBCAR_STEER=0.47,-0.232, 0.10
WBTYRE_STEER=0.15,-0.220, 0.10
; Top front car side wishbone attach point.
; Top rear car side wishbone attach point.
; Bottom front car side wishbone attach point.
; Bottom rear car side wishbone attach point.
; Top tyre side wishbone attach point.

% ▲ The rear "_STEER" is a tie-rod and in typical suspension geometry is coplanar with one of the wishbones - so it looks like a rectangle instead of a
triangle, and you can just code it in as such.

TOE_OUT=0.00000
STATIC_CAMBER=0.0
SPRING_RATE=368
PROGRESSIVE_SPRING_RATE=0
BUMP_STOP_RATE=64000
BUMPSTOP_UP=0.1565
BUMPSTOP_DN=0.0601
PACKER_RANGE=0.1814
DAMP_BUMP=3150
DAMP_FAST_BUMP=1
DAMP_FAST_BUMPTHRESHOLD=1
DAMP_REBOUND=3155
DAMP_FAST_REBOUND=1
DAMP_FAST_REBOUNDTHRESHOLD=1
BUMP_STOP_PROGRESSIVE=50000 ; Adds the progressive rate on top of the base bumpstop rate. Requires CSP’s progressive rate fix.

[GRAPHICS_OFFSETS] ; Offsets for graphic adjustment of the suspension. They don’t affect physics.

% ▼ The following parameters can be used to make corrections on the visuals of the vehicle. Keep in mind that if you move the graphics, the physics won’t
change, for example moving the wheels outwards (or inwards) graphically, the car will behave as if it still had its wheels on the inside (or outside).
That is why these parameters should be avoided and kept to zero, unless you know what you’re doing. A correct positioning of the empties for wheels and
suspensions in your model is recommended from the beginning.

WHEEL_LF=-0.0 ; Left front offset of the wheel positioning in the x axis (width). + is left - is right movement
SUSP_LF=-0.1012 ; Left front offset of the suspension positioning in the x axis (width). + is left - is right movement
WHEEL_RF=0.0 ; As above for RF, LR and RR.
SUSP_RF=0.1018
WHEEL_LR=0.0
SUSP_LR=-0.462
WHEEL_RR=-0.0
SUSP_RR=0.462

% ▲ If you want to add fictional spacers for specific rims, you can make a copy of this file and change the offsets here. Always remember to keep backups
if you’re working on your own mods or someone else’s.

[DAMAGE] ; This section is for suspension damage, and influences both front and rear.
MIN_VELOCITY=60 ; Minimum velocity to start taking damage.
GAIN=0.00045 ; Amount of steer rod deflection for impact kmh.
MAX_DAMAGE=0.6 ; Maximum amount of steer rod deflection allowed.
DEBUG_LOG=1 ; Activates damage debug in the log.

LITTLE EXPLANATION
- Coupled to the tire is an unsprung mass element (which usually consists of the rim, the brake discs and calipers, the springs, suspension arms and shock
absorbers), which attaches to a sprung mass element (the car body) via a spring-and-damper system.
The location of the tire in relation to the sprung mass element is accomplished via several suspension TYPE options, mainly DWB, STRUT, AXLE, ML.
- Suspensions in Assetto Corsa are kinematically solved, which means that you must input in coordinates for joint locations and the program will generate
behaviour from them.
- When working on suspensions in-game you should use a variety of test tracks, most of which are in the attachments of this manual, including the
Suspensions Test Track by @chuky500, which you can find also here: https://www.racedepartment.com/downloads/suspensions-test-track.6770
- 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.

432
- Note that many modern roadcar suspension geometries incorporate elastokinematics into their design, which is currently not a feature of Assetto Corsa.
- The location of suspension links is accomplished for each wheel via the three-dimensional reference system 𝑲𝑲2𝑖𝑖 of Assetto Corsa, with origin 𝐎𝐎2𝑖𝑖
determined by the WHEEL_# dummies in the vehicle 3D model (see pag.).
Pro tip: (important for later) 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 (more details in the next paragraphs).

The suspension coordinates are relative to the wheel’s center of rotation, meaning that a position of (0, 0, 0) would be positioned in the middle of the
wheel, basically at the center of the touch point between HUB and RIM (Fig.).

Fig. – An example of a rear suspension linkage for a Lamborghini Gallardo. You can clearly see where the origin 𝐎𝐎2𝑖𝑖 = (0,0,0)𝑖𝑖 of the coordinates is.

It’s important to remember that since suspension components follow the reference system 𝑲𝑲2𝑖𝑖 :
• 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.

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

- Let’s discuss first the parts of suspensions.ini that deal with weight distribution, moments of inertia and center of gravity.
After working with MOIs and the sprung mass inertia box estimations, what you have left is the setup of the CG height. (total to sprung CGH conversion)
That’s where the BASEY value here comes into play. It is the vertical distance of the CG from the center of the wheel, referenced from the suspension design
height. It is the CG height (CGH) for the sprung masses. It can be thought of as the position of the connection between suspension and chassis.
A negative BASEY produces a positive CGH. The formula for each end of the car (front/rear) is RADIUS – BASEY, and the RADIUS value comes from
tyres.ini. For example, if the CG is 0.4m up from ground and the wheels of one axle are 0.3m radius, BASEY is -0.1m since it has to go down 0.1 from 0.4m
to get to that axle. Thus, you can see BASEY as a vertical vector going downwards from the geodetic elevation of the CG to the center of the wheels of one
specific axle (either front or rear). Bear in mind that the loaded tire radius should be used for accuracy.
The values of BASEY between the front and rear axles may be different, due to variations in suspension designs and tire size. It is a quite common practice
from vehicle manufacturers to employ multiple types of systems, to either reduce the costs 68 or solve technical issues (improving the handling). That’s why
the actual formula of the CG height for the entire sprung mass is:
(𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 + 𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹𝐹 𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵) + (𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 + 𝑅𝑅𝑅𝑅𝑅𝑅𝑅𝑅 𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵𝐵)[𝑚𝑚]
𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆𝑆 𝐶𝐶𝐶𝐶 ℎ𝑒𝑒𝑒𝑒𝑒𝑒ℎ𝑡𝑡 (𝐶𝐶𝐶𝐶𝐶𝐶) =
𝐶𝐶𝐶𝐶_𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿𝐿 [%]

Pro tip: the process for setting up BASEY correctly is:

1. Find plausible CG height for the sprung mass.
2. Ensure that -BASEY + RADIUS (tire loaded radius) is exactly equal to that number for front and rear suspensions. You accomplish this by going in-game and checking
that the CGH matches up with the Car Physics app.
3. Never edit BASEY again (unless you change your CGH, then repeat the process).
Typically all vehicles should have identical BASEY values for front and rear suspensions, as there is only one CG for the whole mass. The idea of BASEY being different front
to back is not supported by reality, as the values are both measuring the same thing, the CGH, without chassis flex anyway. Unless you have tires with different radii, then you
have to account for that and the numbers will be forcibly not identical.
Remember that as you change the BASEY value, your whole model will also visually move. You must add in a graphical offset (see car.ini) to keep the visual side correct.

68
An example is the adoption of leaf springs for the rear axle and double wishbone / McPherson struts for the front wheels.

433
Look at Fig. below for a simplified visualization of the BASEY value.

Fig. - WHEELBASE says how far apart the axles are. BASEY says how far down from the “red line” through the CG the axles are. CG_LOCATION is the weight distribution, that
says how the WHEELBASE is split up between front and rear, so a higher number means more wheelbase behind the CG.

- General features of suspensions portrayed by AC:

Usually suspensions share some basic components, like springs, dampers, bump stoppers, upper and lower arms. All of them are parametrized in AC within
the suspensions.ini script. For a quick visualization of the most important values, see Fig. below.

Fig. – PACKER_RANGE and the suspension travel (sustrvl=static spring deflection) move when you change ROD_LENGTH. If you modify the ride height by editing ROD_LENGTH
and you want the PACKER_RANGE to not move, you have to change it by the same amount.

Design height (or zero) is just the coordinate numbers in the .ini; when ROD_LENGTH=static deflection, the simulated height is at the design height (because
ROD_LENGTH is offsetting the springs deflecting under load and lifting the suspension back to the design height).
ROD_LENGTH can be adjusted in-game, while CGH cannot, so use it to move the suspension, adjusting the ride height, which then also moves the model
because it is connected to the suspension. (unsure if correct)

The formula for ROD_LENGTH should be static deflection + offset from “0 point” (measurement point) of suspension.

A ROD_LENGTH 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 suspension travel or “susp travel”. Negative being compression, from now on referred to as “bump”, and more positive
being extension, from now on referred to as “rebound”.
What is the push rod?
434
You change ride height by altering the rod length. ROD_LENGTH modifies the height of the car but it does NOT affect the actual suspension travel (to affect
the suspension travel you need to change the BUMPSTOP_UP and DOWN and the PACKER_RANGE values). Especially on race cars you don't want to change
ride height by altering the spring stiffness or preload. Specifically preload "is Satan", as said by a race engineer, so everybody stays away from it. You set the
rod length up and down and you modify the ride height while keeping your spring rates identical, which obviously is what you want to have correct handling
predictions in a proper race car.
- What are the bump stoppers (bumpstops) referenced by BUMPSTOP_UP, BUMPSTOP_DN and BUMP_STOP_RATE?
They are typically elastic components (usually made of hard synthetic rubber/plastic) which prevent hard metal-to-metal impacts when the suspensions reach
the extreme of their travel during a bump, hence the name. Without them, when you take huge bumps, you would very quickly damage the vehicle chassis,
the suspension arms and the axles. There are mainly two locations where the stoppers can be: on the upper and on the lower part of the suspension. Typically
only one stopper is needed per corner (Fig.).

Fig. – Rear axle with bump stop bushings highlighted.

You may ask: what happens during rebound travel? The extension of the wheel downwards is limited by the linkages or by the springs themselves. But if the
car is mid-air you won’t care that much about the suspensions, your problem will be the aerodynamics.

Fig. - leaf spring suspension with a pretty huge stopper.

Depending on the design, some are secured inside the space occupied by the spring, or in line with the piston rods of the shock absorbers, adding an extra
level of absorption when the shocks reach their limit, or simply between frame and axle, absorbing energy before the axle gets a chance to slam into the frame.
Alternatively stoppers can be placed above the lower arm (Fig. ). In AC, the up bumpstops are considered as the rubber stops mounted to the chassis, not on
the damper shaft. The down stoppers represent the end of the piston stroke inside the shock absorber, which resists droop. Most of the time it is not possible
to consider the BUMPSTOP_DN as a spring, so its elastic constant value must be set very high, to portray an infinitely stiff spring (= hard stop).
Pro tip: keep in mind that real-life bumpstops are progressive in rate and become very stiff fairly quickly, but are somewhat soft initially, so they’re good for controlling the
suspension travel without making the car overly stiff. They also have a little bit of damping, a very small percent compared to their spring rate. In AC the stoppers are linear
instead, unless you set the BUMP_STOP_PROGRESSIVE line to 1. However, this vanilla feature is buggy and doesn’t work properly. There is a correction brought by the
CSP mod which makes it work correctly, the progressive spring rates fix.

435
Packer is the actual "bumpstop" or packer springs

Fig. -

Various shapes can be employed, depending on the requirements. However, it shall be noted that bumpstops don’t need to be made out of rubber. They can
be adjustable hydraulic devices too. These are mostly employed in racing and tuned vehicles. In Fig. below you have a couple examples.

% ▲ BUMPSTOP_UP and BUMPSTOP_DN set the suspension travel in meters referenced from the neutral point (the design height). That’s the distance
above/below the wheel centre at which the spring rate will change from the SPRING_RATE to SPRING_RATE + BUMP_STOP_RATE. They should commonly be placed
farther than PACKER_RANGE.

As an example, if we set BUMPSTOP_UP to 0.1, the wheel can move upwards 100mm from the original wheel centre position, with respect to the car sprung
mass.

So if your suspension has 50mm of movement up and 50mm movement down, it'd be:

BUMPSTOP_UP=0.050
BUMPSTOP_DN=0.050

The total travel is 100mm, because it's 50mm allowed up and 50mm allowed down. 0.000 is not a coordinate in space: it just means there is no travel in that
direction.

% There are no general rules for setting these: use data that you find. At worst, learn enough to be able to estimate from pictures or just seeing the car
drive. Usually, the DN value is higher than the UP, but it can vary of course.

- Heave springs (HEAVE_FRONT)

They are a decoupled solution from conventional springs. The only deflect under vertical loads, which mainly are downforce and transitions under braking or
acceleration.
In the real world you can use them to adjust ride heights, minding the aerodynamic balance of the car (check heights in telemetry and use the aero
calculator to see where you want to be at that point of the track).
Ideally, you'd want stiff heave springs to keep ride height constant, but usually, you want a different height in corners and straights, to optimize the aero.
I'll give you an interesting example: with the Dallara P217 LMP2, if you are saving fuel, you'd rather want softer front heave springs, because your brakings
are smoother. But if you are braking late and hard, you'll want it stiffer so that the front doesn't drive too much.
Softer heave springs give more grip during heavy weight transitions to that end of the car. The sacrifice is less aero in higher speed corners.
Like always, the best is to test it and make your own understanding of it for the track and car.
A zero spring rate heave spring with a bumpstop doesn’t do anything. Just set it to 1 Nm, the code disables the heave spring if spring rate == 0. 1 Nm is
basically nothing.

436
Note: rear heave springs appear to get ignored when the front is not DWB: in such a condition, the AC log will print the following message:
IGNORING HEAVE SPRING BECAUSE SUSPENSION 0 IS NOT DOUBLE WISHBONE

- What if the car has a rake angle (Fig.)? If you have got the correct suspension measurements you don't need any corrections for the rake. Remember the
measurements have as a reference point the center of the hub, and the height of the center of the hub from the terrain is only relative to the tyre radius.
You can have the body at any rake and position you like, independently of the suspensions. Open the car.ini file and change:
GRAPHICS_OFFSET=value,value,value
GRAPHICS_PITCH_ROTATION=value

Fig. - Delta CGh axle= Z axle from CG *tan(Rake angle in radians). As a result, change the BASEY to match in the editor the value of CoG height front and rear.

- A guide to vanilla suspension types:

The designs available in AC by default are DWB (Double Wishbone), STRUT (McPherson strut), AXLE (for the rear axles) and ML (Multilink).
DWB is good for 90% of the applications, and STRUT is a bit better for, yeah, struts. But AXLE is pretty sub-optimal and ML is buggy. Let’s analyse each
type now.
DWB suspension
With the Double Wishbones you can simulate almost all the independent suspensions out there. The multi-point suspensions are made this way because of
lack of space in the actual real cars. The engineers want to create specific wheel movements but they don't have space in the chassis to make the wishbones
as long as they like, so they use multiple arms. In a sim you have infinite space so you could get the exact same wheel movements by using DWB that are
as long as the real multipoint suspension arms extension and tangents.
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 enabling the TORQUE_MODE_EX=2 fix (CSP addition). It can also replicate MacPherson Strut layouts to reasonable accuracy if there
is need to use some DWB2 features with it.
The example car in Fig. uses DWB.

437
 O20

Fig. – The front suspension layout of the Tatuus FA01 by Kunos (picture taken from the left side of the car).

Looks like this when you get the susp app working, minus all the labels. In blue is the origin O2𝑖𝑖 of the suspension reference system 𝐾𝐾2𝑖𝑖 .
The end points should be in the same place as the ball joints on the car.
For a rear suspension, the link created with WBCAR_STEER and WBTYRE_STEER becomes a tie-rod instead of a steering arm, and in typical suspension
geometry is coplanar with one of the wishbones - so it looks like a rectangle instead of a triangle, and you can just code it in as such. The tie rod is VERY
important.
The code for this suspension requires specifically the following lines:
TYPE=DWB
WBCAR_TOP_FRONT=
WBCAR_TOP_REAR=
WBCAR_BOTTOM_FRONT=
WBCAR_BOTTOM_REAR=
WBTYRE_TOP=
WBTYRE_BOTTOM=
WBCAR_STEER=
WBTYRE_STEER=

438
STRUT suspension
Looks like this:

Note that STRUT_TYRE and WBTYRE_BOTTOM are in the same place here - I believe that in general you want the STRUT purple line to be in the direction
the strut compresses & rotates around, and it's possible that in all real suspension designs, it does line up this way.
To switch to strut suspension, set
TYPE=STRUT
And, in place of WBCAR_TOP_ (front, rear, tyre) you have
STRUT_CAR=
STRUT_TYRE=

In STRUT the bumpstops, up and down, use a 500k Nm rate, hardcoded.

ML suspension
The ML (multilink) is still an independent suspension, just more flexible. It lets you define 4 links anywhere + tierod, by using the JOINT#_CAR and
JOINT#_TYRE, for # from 0 to 4. It does not work for front wheels, it’s not steerable.
Also, it requires the bumpstops and the packers to be set properly in the setup.ini file, otherwise they won’t work. PACKER_RANGE is not functional unless
inputted into setup.ini. Packers will always default to the MIN value.
There are some bugs with alignment not always setting correctly when first loading into the game. It also sets toe to random values sometimes in setup.
Kinematically it seems to work fine though. ML produces more or less correct suspension curves.
You can use DWB to solve the issues with the ML type, but you’ll want/need to use kinematic software to make such a conversion.
DWB is ML with welded outboard joints. The inside links are constrained.
The suggestion is to not use this type of suspension, you can however graph curves with it and use those to help in building a DWB version.
The code for this suspension requires specifically the following lines:
[REAR]
TYPE=ML
JOINT0_CAR=0.3534, 0.12674, 0.0800
JOINT0_TYRE=0.15369, 0.14219, -0.0400
JOINT1_CAR=0.3934, 0.13274, -0.0800
JOINT1_TYRE=0.15369, 0.14219, -0.0400
JOINT2_CAR=0.2498, -0.07777, 0.4000
JOINT2_TYRE=0.17184, -0.11425, -0.0625
JOINT3_CAR=0.42926, -0.10782, -0.0700
JOINT3_TYRE=0.07957, -0.11445, -0.0600
JOINT4_CAR=0.30933, 0.01046, 0.2200
JOINT4_TYRE=0.097911, 0.01257, 0.1600

AXLE suspension
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.
Pro tip: the reference point for the AXLE joints is the center of the live axle. This is valid only for this suspension type.

The code for this suspension requires specifically the following section to be added (this example comes from the official Maserati 250F by Kunos):

439
[AXLE] ; Add this section only if you’re using the AXLE suspension TYPE.
LINK_COUNT=4 ; Number of TOTAL suspension links used in AXLE suspensions, referenced by TYPE in [REAR].

% ▲ Due to high stiffness of suspension links, an input of 5 is not recommended and 3 or 4 should be used instead. 5 results in frequent, unintended
binding of the suspension assembly.

LEAF_SPRING_LAT_K=880000 ; Lateral coefficient for leaf springs; controls the lateral resistance springrate of the axle.
TORQUE_REACTION=-0.2 ; Torque reaction of AXLE suspensions.
ATTACH_REL_POS=0.729 ; “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

J0_CAR=0.4188,-0.072,0.541 ; Attachment point of the bottom left arm on the car.

J0_AXLE=0.438,-0.082, -0.031 ; tyre bottom left arm.
J1_CAR=-0.4188,-0.072,0.541 ; car bottom right arm.
J1_AXLE=-0.438,-0.082, -0.031 ; tyre bottom right arm.
J2_CAR=0.4188,0.080,0.541 ; car top right arm.
J2_AXLE=0.438,0.076, 0.031 ; tyre top right arm.
J3_CAR=-0.4188,0.080,0.541 ; car top right arm.
J3_AXLE=-0.438,0.076, 0.031 ; tyre top right arm.
J4_CAR=0.572171,0.00,0 ; car top right arm.
J4_AXLE=-0.572171,0.00,0 ; tyre top right arm.

% ▲ These lines are the coordinates of the suspension linkages for the AXLE suspension type. Again, keep in mind that the reference point is the center
of the live axle. They may be excluded depending on the value of the LINK_COUNT line below. For example you can exclude J4 if you use LINK_COUNT=4, since
the first index is zero.

- To start off, use the in-game Suspensions app (see par.) to analyse the positions of links and become comfortable with viewing the assemblies.

- The best way to learn the suspension is to enable the dev app and hit Backspace, this brings up an ingame representation where you can check the parts
are where you want them.

- What's the best way to make a swing axle suspension on AC? Use a double wishbone, but move all the on-car mounts onto the axis it swings around.

- As the physics creator you must also specify stiffness rates for the corner springs, the stabilizer bars, the corner spring dampers, the packers, bump and
rebound rubbers, heave springs and any possible future additions.

- The vanilla PROGRESSIVE_RATE for springs has got a bug. In the solver calculations, rate needs to get divided by 2, but in vanilla it doesn’t happen. CSP
brings a fix for this, adding the following section to suspensions.ini:
[_EXTENSION]
FIX_PROGRESSIVE_RATE=1

Obviously it doesn’t correct anything if you don’t have the mod installed.

- You can't change camber or toe in a live axle, at least not back in the days unless you hammer it. Mustang teams would hammer the rear axle to bend it a
bit and gain a tiny bit of toe... but AC doesn't simulate this.

- About Anti-Roll Bars: you have to consider that AC does not consider the torsional rigidity of the chassis so the ARB is applied to an infinitely rigid chassis
and is not representative of the real one. You should instead calculate the real roll angle and then adapt the ARBs to get it in game. If you want to do some
kinematic calculations, I can tell you that usual roll angle values at 1 G for passenger cars starts from 6 or 7 for small economic cars, passes through 4 or 5
for medium class and goes to 2.5 or 3 for sport cars. Those values are an average between front and rear, usually much of the stiffness is on the front so if
you want to use 4° you can set 3.5° front and 4.5° rear.

ksSusEditor, a basic suspension geometry viewer which is compatible with DWB and STRUT layouts. AXLE is buggy.

- How to create a suspension geometry in AC

When enough relevant information to somewhat form a car has been gathered, you can 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.

440
At worst, a photo-reference method may be used to create suspension geometries. With more sophisticated photo-matching methods, 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.

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.

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 (Fig.) 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.

441
Fig. –

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.

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 (Fig.) 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.

Fig. - 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. The
geometry in the picture is from the Honda S14 rear suspension.
When building typical Trailing or Semi-trailing arm geometries, the 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.

442
Auto Union type C: Trailing arm front suspension is just parallel A-arms, only the pivots are oriented front/rear rather than inside/outside. Make the base of
the A-arms very narrow, though that shouldn't matter in terms of game geometry.

Swing arm rear suspension are A-arms with a common chassis pivot at the u-joint.

The wrong antisquat is a big issue for weird use of DWB, the game actually has an internal fix for it but you can only access it with the shader patch (needs
setting a variable that's not in any ini)

Front suspension's same as a Beetle I think? torsion spring trailing arms? Doesn't really do anything crazy. You'd be close enough just making it regular
DWB with equal length arms.

(wip)
CSP ADDITIONS
- The mod brings alternative ways of applying torque to DWB-only or DWB & STRUT suspensions. It’s the fix for a Kunos bug that caused inaccuracies with
anti-effects (anti-squat, etc.) geometry. The following section shall be added to suspensions.ini.
[_EXTENSION]
TORQUE_MODE_EX=2 ; Values: 0 is default, 1 is broken, 2 recommended and should be physically accurate.

% ▲ EX=2 calculates the internal forces pointing to the contact patch instead of the wheel center (vanilla AC), so it's like real case.

In reality these lines enable a feature created by the developers that never made it to the final AC release due to its incompleteness and to other fixes that it
would have required to work.

- CSP brings a fix for a bug in the progressive springs and bumpstops: rates needed to get divided by 2 in the calculations, which doesn’t happen in vanilla.
[_EXTENSION]
FIX_PROGRESSIVE_RATE=1

CURIOSITIES AND AMENITIES

- suspension_graphics.ini
This file is an old config, left from early development, where the linkages were defined in a different way. It can be deleted, as it’s unused by AC; it will only
generate an error message in the command console, as the objects it’s searching for do not exist anymore in the vehicle 3D model (Fig.).

Fig. – The error displayed in the AC Console when starting a session.

It has already been deleted in many cars. There is still one with text in the Lotus 98T data files:
[CONNECTION_0]
SRC_OBJECT=CAR_BODY
TARGET_OBJECT=Braccetto_L
DST_OBJECT=WHEEL_LF
SRC_POINT=0.35 , 0.47, 1.12
DST_POINT=-0.18,0.18,0

[CONNECTION_1]
SRC_OBJECT=CAR_BODY
TARGET_OBJECT=Braccetto_R
DST_OBJECT=WHEEL_RF
SRC_POINT=-0.35 , 0.47, 1.12
DST_POINT=0.18,0.18,0

FAQ
QUESTION [1]: I need help with the HUB_MASS line: how much does a F1 tire+rim weigh?
ANSWER [1]: Look at Fig. . It’s self-explanatory.

443
Fig. -
PHYSICS (for suspensions.ini)
Wheels
Curious as it might sound, wheels are not really part of the suspension, except as tyre carriers, and in some areas of racing a poseur's delight. Leaving aside
wood and cast iron, variations on the theme of a circle keep a mini-industry successfully in business in steel and alloy, spoked pressed, cast, one piece, in
two halves and multi-section permitting variable offsets. This latter type gives the designer some elbow room in varying both the track and other clearances
if desperate.
In suspension terms, wheels are nonetheless the vital link between the geometry and the tyre contact patch, and as such have to have all those old virtues -
lightness, strength and reliability.

TYPES OF SUSPENSIONS

At this point we can separate different suspension types, making them fall into one of these main categories:
• Dependent
• Independent
• Semi-independent

What’s the difference?

These terms refer to the ability of opposite wheels to move independently of each other. A dependent suspension normally has a beam (a simple 'cart' axle)
or a (driven) live axle that holds wheels parallel to each other and perpendicular to the axle. When the camber of one wheel changes, the camber of the
opposite wheel changes in the same way (by convention, on one side, this is a positive change in the camber, and on the other side, this a negative
change).
In an independent suspension instead, the wheels move independently, hence the name, and the camber of one wheel does not affect the other.

444
Fig. -

We will talk about semi-dependent suspensions later on.

We will also highlight which systems are used more or less frequently, depending on whether they’re on the front or on the rear end of the vehicle.

DEPENDENT SUSPENSIONS

Dependent systems may be differentiated by the system of linkages used to locate them, both longitudinally and transversely. Often, both functions are
combined in a set of linkages.

Examples of location linkages include:

• Satchell link
• Panhard rod
• Watt's linkage
• WOBLink
• Mumford linkage
• Leaf springs used for location (transverse or longitudinal):
Fully elliptical springs usually need supplementary location links, and are no longer in common use
Longitudinal semi-elliptical springs used to be common, and are still used in heavy-duty trucks and aircraft. They have the advantage, that the spring rate can easily be
made progressive (non-linear).
A single transverse leaf spring for both front wheels and/or both back wheels, supporting solid axles, was used by Ford Motor Company, before and soon after World
War II, even on expensive models. It had the advantages of simplicity and low unsprung weight (compared to other solid-axle designs).

INDEPENDENT SUSPENSIONS

The variety of independent systems is greater, and includes:

• Swing axle
• Sliding pillar
• MacPherson strut/Chapman strut
• Upper and lower A-arm (double wishbone)
• Multi-link suspension
• Semi-trailing arm suspension
• Swinging arm
• Transverse leaf springs when used as a suspension link, or four-quarter elliptics on one end of a car are similar to wishbones in geometry, but are more compliant.
Examples are the front of the original Fiat 500, then Panhard Dyna Z, and the early examples of Peugeot 403, and the backs of AC Ace and AC Aceca.

TYPES OF SPRINGS
What are live axles and dead axles, and their role in an automobile?

What is the camber angle of a wheel?

Camber angle is the angle between the plane of the wheel and the vertical line from the ground. There are 3 types of camber angle: it is described as
positive when the top of the wheel leans outward, negative when the top of the wheel leans inward, and neutral or zero camber, when the top is aligned with
the contact point of the tire, so that the wheel axis is parallel to ground. Camber angle alters the handling characteristics of a suspension system.

445
• Positive camber is the most rarely used setting of the three camber settings. This is a specialised setting used in a few forms of motorsport, for example it was common in
F1 cars from 1920s to 1960s-1970s. This is because if the suspension was soft the nose of the vehicles could drop under heavy braking, thus giving much less camber
into hard corners, and without power steering turning the wheel took a fair bit of strength, that’s why the steering wheel was so large to be able to get leverage, and the
positive camber helped quite a bit too. It guarantees a smaller contact patch on straights, and therefore less rolling resistance. Under braking and through corners, the
weight transfer allows for more tyre on the track and more grip.
Usually it is seen on road cars only if there is damage to the suspension components. It is most commonly used in heavy load applications such as trucks where when the
vehicle is empty, the tyres have positive camber so that when the vehicle is at its normal operating load the tyres then settle to a neutral camber position due to the
camber gain of the system.
• Negative camber: In general, it improves handling when cornering. This works when a car is cornering, the lateral load transfer through the body causes the vehicle to roll.
When the car encounters roll, it raises the inside contact patch of the outside wheel. This reduces overall grip. If the camber is set to negative then it has a smaller contact
patch when it has zero roll but engages full contact patch as it corners rolling onto the full contact patch.
• Neutral camber angle is used in applications where hard cornering is not common, such as road cars, drag racing, off – roading. When a tyre is in its neutral position, the
full tyre contact patch is in full contact with the ground during zero roll situations. This is useful for acceleration purposes as it allows the entire contact patch of the tyre to
be run at optimum slip angle to generate as much dynamic grip as possible for better acceleration and stability.

FAQ

QUESTION [1]: About suspension failure (Fig.).

446
33. tyres.ini
With this script you can set all the parameters for the tires of your car. This is the most important part of our simulation, as it represents the base of every
interaction of the automobile with the tarmac. Don’t be surprised if modifying the values alters completely the vehicle’s behaviour – that’s something you
should expect at this point. Too grippy or too slippery tires will be unrealistic for a stock vehicle, but what we truly need to know are the specifications of the
tire we’re going to simulate; in the absence of such data, we can only estimate; we’ll see how to proceed in the following pages.
[HEADER]
VERSION=10 ; Version of the tire code that the physics engine will load. The suggested input is 10.

% ▲ Use VERSION=10 and do not care at all about what the older tire models did. They’re just outdated, and if you see a mod with a different number (to
be valid it must be 2 < n < 10, but some numbers may be skipped), it means that the tire code wasn’t updated and needs to be edited or replaced.

% To be fair, older tire models are quite good, but they don’t include a lot of features that the newer do, so they’re less accurate when trying to
represent a real-world tire, and more prone to bugs.

[COMPOUND_DEFAULT]
INDEX=1 ; Defines which tire is loaded in the setup by default.

% ▲ The first tire set is entry 0, while the second is 1 and so on. Bear in mind that currently, default pressure for the tire is loaded only from index
0 regardless of what is selected.

[VIRTUALKM]
USE_LOAD=1 ; Boolean. Whether to use load or not in wear calculations (0= no, 1= yes). The recommended input is 1.

% ▲ The normal load of the tire ceased to be considered in the wear calculation after a certain tire model iteration. This parameter adds it back (as it
should be).

[EXPLOSION]
TEMPERATURE=200 ; Temperature the tire should pop/explode at; feature introduced with AC 1.10. [°C]

% ▲ While tire internal structures do deteriorate at around 200°C, temperatures of 450°C 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.

[ADDITIONAL1]
BLANKETS_TEMP=50 ; Tire blankets temperature, used if blankets are enabled in the session configuration options.
PRESSURE_TEMPERATURE_GAIN=0.1 ; Pressure vs temperature gain.
CAMBER_TEMP_SPREAD_K=1.4 ; Camber spread tweak value. AC default is 1.4, higher numbers = more spread.

[FRONT] ; SYNTAX: Add ” _X” for every further compound. Example: FRONT_1 for the 2nd tire set in the index.
NAME=Nurburgring ; Display name of the tire in the setup screen.

% ▲ Uppercase and lowercase letters may be used alongside numbers, but some special symbols may not display correctly.

SHORT_NAME=V ; Display name of the tire compound in the leaderboard.

% ▲ Standard inputs are:

ST ; Street
SV ; Street 90s (ST90s, 1990s-2000s street tires)
SM ; Semislicks
US ; Slick Ultra Soft
SS ; Slick Super Soft
S ; Slick Soft (also Soft GP70)
M ; Slick Medium
H ; Slick Hard (also Hard GP70)
SH ; Slick Super Hard
HR ; Hypercar road
I ; Hypercar Trofeo
V ; Vintage (GP67; 1950s-60s vintage Grand Prix and street tires)
V70 ; Vintage GT70 (1970s GT tires)
V78 ; Vintage 78 (1978 Porsche 935 Moby Dick only)
E ; ECO
Q ; Qualifying (Lotus 98T only)

% You can find the prefixes also in the ks_tyres.ini script in the assettocorsa/server/manager folder. You can see how same prefixes can be used for
different types of tires. You should choose a prefix that makes sense, however anything can be input.

% ▲ It is currently recommended to stay to standard inputs if possible, so that auto-guessed (automatically generated) cphys (CSP) rain behaviour will
work correctly. CSP’s code is going to automatically turn tires of cars without extended physics into rain tires based on their short names. Cars with
extended physics active (in car.ini) will have to be completed with specific rain tires instead.

% ▲ AC servers can be set to not allow some tyre compounds.

WIDTH=0.135 ; Tire width for graphics effects (defines skid marks width). [m]

% ▲ Doesn’t affect physics but the visual representation of the wheel 3D model in the suspensions app and skid marks. When in doubt, input tire section
width.
% The vanilla AC’s tire model has got only one contact point with the ground, which is represented by a single vector. WIDTH doesn’t matter.

RADIUS=0.356 ; Unloaded tire radius at nominal inflation. Should match the tire radius of the 3D model. [m]

% ▲ Remember that tires’ size may differ from the datasheets. RADIUS does not directly affect the physical characteristics of the tire, such as stiffness
or flex, but it has an immediate impact on the car’s gearing (bigger wheels will make you go faster, but require more torque to be spun).

RIM_RADIUS=0.294 ; Rim radius. Add 1 inch more than nominal (1 inch = 2.54 cm = 0.0254 m). [m]

% ▲ This value is the radius of the rim, used for ground collisions when tires explode. It does not influence physical characteristics such as stiffness
or flex. Use the outer diameter of the rim, not the nominal one. 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. For example, an 18" rim may actually be 19” or 20" in outer diameter.

ANGULAR_INERTIA=2.82 ; Angular inertia of rim + tire + brake disc assembly and transmission axis if present. [kg∙m^2]

% ▲ Includes any other rotating unsprung masses on a specific suspension.

DAMP=550 ; Damping rate of the tire at nominal load and inflation. Values usually vary from 200 to 1400. [N/m/s]
RATE=278800 ; Vertical spring rate of tires. [N/m]

% ▲ This is the vertical spring rate 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 spring rate, adjust RATE while respecting PRESSURE_SPRING_GAIN.

% ▼ The functions DY0, DY1, DX0 and DX1 below are outdated load sensitivity values, obsolete from tire model V5 onward. They have to be included for
tyres.ini to load properly, but do not have any impact on the physics of the currently recommended version (v10).

DY0=1.9270 ; Lateral force. Unused since tire model V5 - still likely required for loading.
DY1=-0.220 ; Lateral load sensitivity. “ “ “ “ “ “
DX0=1.9770 ; Longitudinal force. “ “ “ “ “ “
DX1=-0.239 ; Longitudinal load sensitivity. “ “ “ “ “
WEAR_CURVE=wcurve_conti.lut ; Tyre wear lookup table filename to call.

447
% ▲ Specifies the look-up table to be used for wear characteristics. Works on "virtual Km" that are added depending on the slipangle/ratio and
temperature. The format is vkm | grip percent multipler, 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=0.004979 ; Speed sensitivity value (higher the value, the greater slip velocity's effect on tire grip).

%▲ 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=0.2792 ; Delay function for lateral loads. [m]

% ▲ Slip angle is instantaneous, so you need a delay function to represent the contact point’s movement, hence relaxation length exists. It’s the only
time-based physics effect. It's a "lag" in the tire response, that acts as a distance-based filter. In other words, it can be seen as the time it takes
for the side loads to build up after you turn a tire. It is also described as “the distance that a tire rolls before the lateral force builds up to 63%
of its steady-state value” (Wikipedia). One interesting fact about relaxation length is that camber is not influenced by it (and AC models this
correctly), so camber variation produce an instantaneous force while slip variations need space in order to build up... the space is controlled by the
relaxation length parameter.

ROLLING_RESISTANCE_0=11 ; Rolling resistance constant component (rolling resistance force = (ROLLING_RESISTANCE_0 +

ROLLING_RESISTANCE_1 * V^2 ) * normal force / 1000

ROLLING_RESISTANCE_1=0.000561 ; Rolling resistance velocity (squared) component - see above

% ▲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=3680 ; Rolling resistance slip angle component. Kunos-size values not recommended. Minimum of zero, maximum
of 1000 recommended and correlated via telemetry.

% ▲ 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~.

% ▲ The rolling resistance of a tyre raises when the tyre generates slip and friction. This is the typical behaviour that you can even hear on onboard
cameras (or your car if you ever pushed on track), when on a given turn, at maximum throttle aperture the engine loses rpm because it can't overcome the
friction of the tyres.
When the tyre goes over the peak slip angle or slip ratio, the rolling resistance plateau and stops raising.

FLEX=0.01492 ; Tire profile flex. Unused since v5 model, required anyway for loading.

% ▲ Increasing the number increases the flex, along with the added slipangle with load.
This is an outdated tire profile flex input. This value is not used since V5 anymore; it must be included for the tire code to load, but is otherwise
unused. Just leave it in tyres.ini anyway to avoid warnings/errors while loading. The functionality has been replaced by the FLEX_GAIN value.

CAMBER_GAIN=0.075 ; Camber gain value as slipangle additive. Default value is =0. (or =1?)

% ▲ Amount of camber thrust. It is a slip angle shift from camber angle. A typical value is 0.100.

% The formula that calculates the slipangle additive is the following:

Slip additive = CAMBER_GAIN * sin(camber angle)

Where sin(x) is the well-known mathematic trigonometric function. You can obtain this value with any scientific calculator, knowing the camber angle.

Now, what is camber thrust?

Camber thrust is a lateral force which is developed due to the camber angle of the wheel. Like any other lateral force, it is generated due to the
deformation of the contact patch tread of the tires.

DCAMBER_0=0 ; First parameter used by formula-based camber sensitivity.

DCAMBER_1=-4 ; Second parameter used by formula-based camber sensitivity.

FRICTION_LIMIT_ANGLE=10.5 ; Optimal slip angle of the tire at FZ0. An indication of slipangle peak. [deg]

% ▲ It is the peak lateral slip angle at nominal values to attain maximum grip. Due to AC tyre model complexity, this is not an exact number. Put all the
values first, then check the actual slipangle with the in-game TYRES Dev App and modify accordingly. 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.

XMU=0.20 ; Outdated friction parameter.

% ▲ Since VERSION=5 this value is not used in the calculations anymore. It must be included for the tire code to load, but is otherwise unused.

PRESSURE_STATIC=32 ; Static (cold) pressure. Always try to use the default manufacturer recommendation. [psi]

% ▲ The actual cold pressure will vary based on temperature conditions. RATE is referenced from this pressure.

PRESSURE_SPRING_GAIN=3580 ; Springrate gain due to a pressure increase of one unit, from the PRESSURE_STATIC inflation. [N/m]
PRESSURE_FLEX_GAIN=0.5 ; FLEX gain due to a pressure increase of one unit.

% ▲ 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=1.0 ; INCREASE IN RR RESISTENCE per psi

% ▲ controls the RR gain of the tire from the PRESSURE_IDEAL value for every one psi. NEEDS MORE DOCUMENTATION.

PRESSURE_D_GAIN=0.0055 ; Loss of tyre footprint with pressure rise.

% ▲ 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=40 ; Ideal (optimal) pressure for grip. [psi]

FZ0=1107 ; The reference load. [N]

It's the load at which some of the values indicated are true, it's used as a reference point for DX_REF and DY_REF.
Fz is in the car physics app named ""load"".
(But FZ0, if it's areasonable value, is not so important stated that the other affected parameters are changed accordingly. You can use, for example,
FZ0=1000 and put DY_REF to 1.7 or FZ0=3000 and DY to 1.2…)"

% is the reference load for much of the tire behaviour, 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_EXPX=0.86 ; The exponent used in the formula

% ▲ longitudinal load sensitivity exponential parameter used by Kunos-formula-based load sensitivity. LS_EXPX=0 means EXTREMELY linear load sensitivity,
which doesn’t happen in real tires, so avoid that value.

LS_EXPY=0.67 ; The exponent used in the formula

% ▲ lateral load sensitivity exponential parameter used by Kunos-formula-based load sensitivity. LS_EXPY=1.0 means no load sensitivity.

DX_REF=1.22 ; The D level at FZ0. The REF just indicates the grip at FZ0 (which is just the load reference).

% ▲ reference mu for the longitudinal load sensitivity formula, referenced from the FZ0 value.

448
DY_REF=1.22 ; The D level at FZ0. The REF just indicates the grip at FZ0 (which is just the load reference).

% ▲ reference mu for the lateral load sensitivity formula, referenced from the FZ0 value.

% ▲ Formula based load sensitivity should be avoided as it isn’t capable enough to produce faithful grip characteristics.

% ▼ Lut based load sensitivity: the lookup table is better when trying to match a real tire data.

In this case a simple lookup table is used for the parameters DY_CURVE and DX_CURVE. The lookup table can be "inline" ex.:
DY_CURVE=(0=3.0|1500=2.613|3000=1.680|4500=1.447|6000=1.257|12000=1.100)

or referencing an external file:

DY_CURVE=external_curve_file.lut

with the typical AC lut file format of KEY|VALUE

At runtime the lookup table is smoothly interpolated (thus you are not required to insert dozen of values)
Note that the 0 value is required in order avoid crazy numbers at very low loads due to the cubic spline interpolation.

DY_CURVE=tyres_dyF.lut ; 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 the mu coefficient.

Example: example_tire_195_55_15_lateral.lut
Example LUT format:

0|1.275
3000|1.10
6000|0.95

DX_CURVE=tyres_dxF.lut ; Same as DY_CURVE, except for longitudinal load sensitivity.

DCAMBER_LUT=tyres_camber.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=1 ; Toggles smoothing for DCAMBER_LUT on or off, with 0 being off and 1 being on.

% extended
DX_CAMBER_REF=3 ; reference angle (in degrees) - must not be zero
DX_CAMBER_MULT=0.98 ; grip multiplier at reference angle

COMBINED_FACTOR=2.20
COMBINED_FACTOR_1=0.4

% ▲ 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.

FLEX_GAIN=0.122 ; Parameter that influences the amount of flex of the tyre.

The formula are proprietary (KS) and will not be published however the value will roughly approximate a "widening" of the value at which the tyre reaches
max grip as function of load.
The parameter express the amount of slip added to the reference slip angle when load is twice FZ0. Example.
Let's say a tyre has a FRICTION_LIMIT_ANGLE of 10 deg, FZo=2000 N, and a FLEX_GAIN of 0.5 then the max slip angle will be: 10 deg @ 2000N 10 * (1 + 0.5)
= 15 deg @ 4000N
Bigger flex = the lateral force peaks at higher slip angles at increased loads. Values at a few loads are exposed in AC log.txt"

% 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=0.90 ; Lowest grip limit past grip peak (related to peak, so 0.9 is 90% of max grip).

% ▲ Recommended to use around 0.7-0.8 for most tires. Input is in percent, so 80% = 0.8.

% Adjusts the grip the tire will produce when slipping at infinite SR (slip ratio). In vanilla, falloff curve is shared between lateral and longitudinal,
while in real tires lateral dropoff is much lower than longitudinal.

FALLOFF_SPEED=1 ; The speed of grip drop-off after reaching the peak slip angle.

% ▲ In other words, it can be seen as how much time the tire takes to come to falloff level. It is a sort of gamma that defines the curve from the peak
(=1) to the FALLOFF_LEVEL (=0.9 for example); =2 was the standard till v6 tyres, =1 is linear so the tyre is "easier", higher numbers make the transition
sharper. In conjunction with the value of 0.7-0.8 for FALLOFF_LEVEL, values of 1-3 for FALLOFF_SPEED are recommended.

CX_MULT=0.976 ; It controls the cornering stiffness of the longitudinal part of the tyre force generation.

% ▲ Adjusts the optimal slipratio longitudinally. A value lower than 1.0 will make the longitudinal part less aggressive, a value of 1.0 will make it
exactly like the lateral, and higher than 1.0 values will make it stiffer. Values below 1.0 are not typically recommended because tires are typically
stiffer longitudinally than laterally. While this is interesting, the most important effect of this value is in the way longitudinal and lateral forces
are combined into a resultant force. Sadly data on combined forces is pretty rare so there isn't a "correct value" to suggest here.

Lower values of CX_MULT will create a tyre that feels more responsive to throttle/brake application. In other words, there will be more loss in lateral
friction when longitudinal friction is applied. Higher values will do the exact opposite by creating a tyre that is pointier and more composed. It's a
parameter that really has huge effects on the final car behaviour.

The formula for the longitudinal slipratio is:

Vanilla: tan(slip_angle_opt) / CX_MULT

Cphys: sin(slip_angle_opt) / CX_MULT

RADIUS_ANGULAR_K=0.082 ; This is the tyre radius increase as function of rotation speed.

It is a simple linear relationship where the dynamic tyre radius is: dynamic_radius = radius + (RADIUS_ANGULAR_K * abs(tyre_rotation) / 1000) Here
RADIUS_ANGULAR_K is in mm/rad/s and tyre rotation is rad/s, hence the division to convert to meters for the radius. Typical values for racing tires are
around 0.01

% 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=0 ; % additive to longitudinal grip under braking. It's a DX multiplier apparently (1 + BRAKE_DX_MOD).

Positive values will make the tyres better on braking than accelerations, and the opposite is true ... but usually tyres generate more slip on
acceleration than braking so using positive value is the way to go."
% 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.

[REAR]
[...] ; same as the FRONT tires, skipping everything.

449
[THERMAL_FRONT] ; SYNTAX: Add ” _X” for every further compound. Example: THERMAL_FRONT_1 for the 2nd tire set in the
index.
SURFACE_TRANSFER=0.017 ; How fast external sources heat the tyre tread touching the asphalt: Values 0-1
PATCH_TRANSFER=0.00027 ; How fast heat transfers from one tyre location to the other: Values 0-1
CORE_TRANSFER=0.00406 ; How fast heat transfers from tyre to inner air and back
INTERNAL_CORE_TRANSFER=0.00093 ; How fast rolling K transmits to core

This value is used to control how the heat generated by rolling (function of ROLLING_K , tyre angular velocity, load, pressure) transfer to the tyre
core. Example value: 0.004

FRICTION_K=0.03950 ; Quantity of slip becoming heat (generated by lateral sliding).

ROLLING_K=0.19 ; rolling resistance heat (generated by rolling driving straight).
SURFACE_ROLLING_K=0.75 ; Like ROLLING_K but dedicated to surfaces.

Prior to V6 the ROLLING_K value was used to generate heat as function of rolling both for Core and Surface, from V6, ROLLING_K is used for Core and
SURFACE_ROLLING_K is used for Surface.

PERFORMANCE_CURVE=tcurve_conti.lut ; File to use for temperature/grip relation

GRAIN_GAMMA=1.2 ; Gamma for the curve grain vs slip. higher number makes grain more influenced by slip
GRAIN_GAIN=0.6 ; Gain for graining.

How much gain raises with slip and temperature difference- 100 value = slipangle*(1+grain%)

BLISTER_GAMMA=1.2 ; Gamma for the curve blistering vs slip. higher number makes blistering more influenced by slip
BLISTER_GAIN=0.6 ; Gain for blistering.

How much blistering raises with slip and temperature difference. Think blistering more as heat cycles. 100 value = 20% less grip

COOL_FACTOR=0.860 ; Speed up surface cooling as function of the square of the car speed. Example value: 1.5

[THERMAL_REAR]
[...] ; same as the FRONT thermals, skipping everything.

% ▼ Below are the section headers for an optional second set of tires. Everything will be skipped as identical to the first set. Other sets of tires can
be added following the correct numeration. In order to avoid confusion, do not to give identical names to different sets.

[FRONT_1] ; next set of front tires.

[REAR_1] ; next set of rear tires.

[THERMAL_FRONT_1] ; thermal model of the front tires.

[THERMAL_REAR_1] ; thermal model of the rear tires.

LITTLE EXPLANATION
- The vanilla tire has got a single contact point with the driveable surface, determined by the vector with the origin at the center of the tire radial dimension
(simply its RADIUS, see tires.ini) and with the end touching ground (Fig.).

Fig. – In-game visualization of the tire contact point. Remember, even if tires.ini has a profile width, it’s for visual skidmarks only. All the interactions between the car and the road happen
only on the location of the point C. The green wireframe cylinders you can see with the Suspensions app, here displayed, are not physical (refer to the WIDTH line).

The tire has a spring and damping rate, it can also wear and manifest a thermal behaviour, which can be expanded with the use of Custom Shaders Patch.
Being a single spot, the dimensions of the tire have no real meaning, and only the compound affects the grip directly. If for example you want to make tires
wider, you need to modify the compound parameters to increase grip, to simulate more width (though I imagine the effect of wider tyres to be quite subtle).
- The question of the 1 contact point vs 5 contact points. Having driven on a true 5d flex model, I can tell you that adding more contact points would make
very, very little difference (and that's on a car that'd be incredibly sensitive to it). Again, the biggest thing is the data input. If the numbers you're using for
your tires are not really correct (especially if, for example, you're using the KS load sensitivity formula instead of a custom Look-Up-Table), that will do a lot
more to change the driving experience than any of the things you can discuss.

Something that a 5- (or more) point(s) tire model can fix is the errors in the collision of the tire with bumps: in Fig. we have an example of the wheel going
right through the curbside (Highlands track) in vanilla AC. This problem is mitigated by the CSP mod, which recently has brought also a new tire model with
more contact points.

450
Fig. – This problem is due to the single contact point: being at the center of the tire width, if it is still touching the road and is not on the curb, the wheel will fall through. See p.

- Since you’re probably at the beginning, until you acquire more experience, you may want to adopt for your car one of the vanilla tire compounds; at this
point let’s talk about them.
On Oct 23, 2017, Stefano Casillo from Kunos stated:
“We do not have any direct relationship with tyre manufacturers. We get data from either car manufacturers, teams, public literature and so on. I truly wish the reality of
things was that we could pick and choose between different manufacturers and models but that's just daydreaming and simply shows how detached you are from the process
of working on race simulators. Which totally is fine, considering that you do not.”
Regarding temperatures, the ranges are not perfect intervals but a min-max range instead, in which you might not be able to notice the difference in grip.
Temperatures also vary quite widely from straight to inside a turn, so optimally you need a tire that stays at the lower end of the optimum temperature just
before the braking zone and at the higher end of the optimum temperature at the exit of the turn. That isn’t easy to obtain.
In AC going outside the optimum range doesn't mean the car will become undriveable. This characteristic is a double sword. You might think the tires (and
the vehicle) are fine, but you're not driving on the optimum grip, so you may lose time on the lap without understanding why. There's a lot to be discovered
and explored within the AC tire model.
Another hint: as in real life, use more camber to heat faster a part of the tyre tread and then this dissipate to the rest of the tire. More camber, more heat,
less camber, less heat.
The following are the characteristics of the compounds you can find in vanilla AC (taken directly from the official Kunos FAQ).

Road legal tyres:

Street and semislicks are road legal compounds, used on the road. They wear out slightly. Their main problem is overheating, but after you have overheated them, you can
wait to cool down and then start stressing them again. They can give similar grip even after lots of kilometres. Eventually though they will wear and lose grip totally.
Optimal temperatures
• Street tyres: 75°C - 85°C; still easy under and over those temps. Very easy to overheat after some laps, especially on fast corners.
• Semislicks: 75°C - 100°C; a bit less grip under that and overheat quite faster over that. They have more grip of course and can resist more fast laps, but do not like much abuse and drifting.
They wear gradually and lose grip km after km.

GT2 slicks:
The main difference of the GT2 cars is that manufacturers are actively developing tyres during the season and bring different compounds on the various tracks. The AC
developers can't of course simulate specific compounds for specific tracks, but they offer 5 different ones.
Optimal temperatures
• SuperSoft: 90-105°C; they don't like to be driven under or over that range. They wear out very fast.
• Soft: 90-105°C; like Supersofts. They wear out fast.
• Medium: 85°C-105°C; Supersofts over their range. They wear out in a linear, gradual way.
• Hard: 80-100°C; a tiny bit easier than Supersofts outside their range but nothing too radical. They wear just a tiny bit after the initial laps and then stay quite stable for a long time until they
start to lose lots of grip.
• SuperHard: 80-100°C; like Hard. They wear a tiny bit and stay stable for many laps until they let go.

GT3 slicks:
The biggest difference between GT2 and GT3 cars are their tires. GT3 tires are fixed for the whole season and the organization decides what tyres the car have to use. Kunos
provided 3 compounds that are not equivalent to their GT2 counterparts (worse).
Optimal temperatures
• Softs: 80-110°C; wear VERY fast. We've been told that they were actually used only for a couple of times in qualifying.
• Mediums: 75-105°C; wear linearly and predictably. An all-around tyre.
• Hard: 70-100°C; wear a tiny bit after a couple of laps and stay stable for a long stint. Not great grip but they are predictable and can be used in a wide variety of tracks and temperatures. Often
"forced" by regulations on cars.

Hypercars Trofeo slicks (Pagani Zonda R and Ferrari 599XX):

They’re a bit worse parents of the GT3 tires. Let's say a generation behind. Rest of their characteristics is very similar to the GT3 tyres. They are not remotely close to street
legal tyres. Don't confuse the name with real-world Pirelli Trofeo tires; in AC they are used to emulate the cut slicks on the Pagani and were extended to other cars.

Vintage F1 67 tires:
AC provides just one compound for such tyres, although during that period (1960-70s) there were actually different compounds. As a matter of fact, there is documentation
reporting that Jim Clark chose the tyre that permitted him to slide more for the race at Monza. Unfortunately, there is not enough data for the compounds so Ks stick with just
one compound. If anybody has more info regarding the matter, I'd be happy to discuss with it.
Optimal temperatures
Range 50-90°C; the tyres are good at low temps, and can withstand overheating pretty well. The tyre wear is gradual, you can expect to do a full race without problems, except if you overdrive and
overheat them too much.

451
- Assetto Corsa uses a simplified brush tire model 69, which (from v5 onward) allows two methods of configuration for the relationships between the input
parameters (mainly load and slip, called load sensitivity):
• the first one adopts an empiric-based exponential formula (the so-called “Kunos tire formula”);
• the second one is look-up table (LUT) based system.
The formula-based is the system that Kunos’ official cars usually employ. It works with an exponential formula that derives from the observation of how the
contact patch varies as function of load influencing the pressure at contact patch, which influences grip.
The formula “seems to be able to match real tyres with a reasonable accuracy and has a solid physics reasoning behind it” 70. Three parameters from tyres.ini
are used:
• FZ0: the reference load.
• LS_EXPY (and LS_EXPX): the exponent(s) used in the formula.
• DY_REF (and DX_REF): the D level at FZ0.

The values are then used this way: a "MULT" parameter is calculated,
𝐷𝐷𝐷𝐷_𝑅𝑅𝑅𝑅𝑅𝑅∙𝐹𝐹𝐹𝐹0
𝑀𝑀𝑀𝑀𝑀𝑀𝑀𝑀 = MULT = (DY_REF*FZ0) / FZ0^LS_EXPY
(𝐹𝐹𝐹𝐹0)𝐿𝐿𝐿𝐿_𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸

then, at runtime, the D value as function of load (Fz) is the calculated as:
D = Fz^LS_EXPY * MULT / Fz

The look-up table system is better when trying to match a real tire data. In this case a simple LUT is used for the parameters DY_CURVE and DX_CURVE.

Pro tip: The LUT can be "inline", so written directly in tyres.ini, for example:
DY_CURVE=(0=3.0|1500=2.613|3000=1.680|4500=1.447|6000=1.257|12000=1.100)

or you can reference an external file like this:

DY_CURVE=external_curve_file.lut

You can see other examples in the script at page .

with the typical AC lut file format of KEY|VALUE

At runtime the lookup table is smoothly interpolated (thus you are not required to insert dozen of values).

Note that the 0 value is required in order avoid crazy numbers at very low loads due to the cubic spline interpolation.

- The formula for formula-based camber sensitivity is:

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

It can also be written like this:

1
𝐶𝐶𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 = (3.5)
1+(𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷_0 ∙ 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐)−[𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷_1 ∙ (𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐)2 ]

Where camberRAD is the absolute value of the camber angle in radians.

If you want to use the grip% and peak angle method:

DCAMBER_0= -2*grip%/((grip%+1)*peakangle)
DCAMBER_1= -grip%/((grip%+1)*peakangle^2)

Which can look like this:

−2∙𝒈𝒈𝒈𝒈𝒈𝒈𝒈𝒈% −𝒈𝒈𝒈𝒈𝒈𝒈𝒈𝒈%
𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷_0 = 𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷_1 = (3.6)
[(𝒈𝒈𝒈𝒈𝒈𝒈𝒈𝒈%+1)∙𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑] [(𝒈𝒈𝒈𝒈𝒈𝒈𝒈𝒈%+1)∙𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑𝒑2
Where

peakangle: the peak camber angle in Radian = DCAMBER_0/(2*DCAMBER_1)

grip%: the grip increase at the peakangle (like 5%) = (4*DCAMBER_1/(4*DCAMBER_1+DCAMBER_0²))-1

For example: If you want 7% more grip at a peak angle of -3.8°:

DCAMBER_0= -2*0.07/((0.07+1)*-0.0663)= 1.973

DCAMBER_1= -0.07/((0.07+1)*(-0.0663)^2)= -14.873

The -3.8° angle in degrees has been converted in radians (-3.8° = -0.0663 rad).

If you have experience from the classic Pacejka or RFactor tire model, you need to think in a slightly different way. In AC the model is so dynamic that creating a
simple load/slip curve would not cut it. It is not the curve that defines the tyre characteristics, but the rest of the values that define a dynamic curve and characteristics.
(Aristotelis Vasilakos, 2014)

69
“Simplified”, as it is a brush with only one bristle (or contact point).
70
As stated by Stefano Casillo. It represents a good choice when real-world data (e.g., telemetry, tire testing, etc.) is not available, recommended to use if you’re starting with your first project(s).

452
 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. 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. However, one
should exercise great caution when analysing tire data or trends. Real 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. 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 number of inputs is relatively low but the behaviour
generated is quite dynamic and appropriate in most situations. For example, rFactor doesn't have features like relaxation length.
You do not directly input physical characteristics like dimensions of the sidewall, or softness of the rubber or whatever such as in some other tire models. There is a
large degree of interactivity within the tire behaviour and complex situations can be generated from relatively few inputs resulting in relatively high telemetry correlation of
car handling.
A tire model such as Pacejka would require look-up tables and inputs for several more parameters, for many of which there is no data publicly available. (Arch, 2023,
p. 17)

- "Flex" in simulation tire models is a garbage word. In real life, you have 4 main types of flex: vertical, lateral, longitudinal, and torsional. Vertical is easy
and pretty much every sim does it in a way that's acceptable. The other three aren't as easy, but that's fine because they don't really matter. In a semi-
empirical model like AC (and pretty much every other sim), you use slip velocities to generate forces. If you delay these forces with respect to the distance
the tire travels, you can replicate flex. That's what RELAXATION_LENGTH is for. That parameter wouldn't be there if you had lateral + longitudinal +
torsion flex, because those are the things that contribute to it existing. It's a stand-in for "3d" flex that does as good of a job as you'd almost ever need,
being that your tire model is going to have WAY more error from your data input than its fundamental code.

But on the other hand, lateral tire deformation has to be entirely made up, because AC doesn't try to model it, as it only offers relaxation length. And
strangely, the RELAXATION_LENGTH parameter doesn't end up being anything like the actual relaxation length simulated, it's like...1/3. Typical AC values
range around 0.07 to 0.12 per Kunos recommendation; thus it is not comparable to real-world values, which have been found to be between 0.12 and 0.45
meters, with higher values corresponding to higher velocities and heavier loads. The value is pretty directly linked to the sidewall stiffness of the tire, but it
cannot be measured at steady state. How this feature works is still unclear.

- The elephant in the room: tire wear.

I'll start with some things you have to keep in mind regarding tyre wear in AC.
1. The USE_LOAD line under the [VIRTUALKM] section essentially toggles wear effects based on load and vkms, which stands for "virtual kilometres", a special unit in
Assetto Corsa that defines the distance a tire is travelling while slipping, overheating, underheating, overloading and a ton of other values which mean the tire is under
stress, even by the smallest amount. Obviously if you're drifting the vkms will rise very quickly, while if you're driving straight or cruising normally, they will increase very
slowly. So the smoother the driving style, the less the tire gets vkms, and thus wear.
2. Tires in this simulator don't really wear out meaningfully, you just get different traction from how long you've driven on them. Interpret "how long" as a distance traveled,
or rather, slipped. There is essentially no wear or heat simulation, nor realistic "heat cycles".
3. Vehicles are set up with tyre wear luts (look-up-tables), which contain data (you can create wear curves) with the following syntax: vKm | traction % (or grip%). So at the
input you have vKm, at the output you have simply the grip percentage. So you can just bake heat cycling + slip and rolling wear into the curve.
With the luts you can make a tire wear less or more with the same vkm. You only need to change the input | output relationships in the lut. In your case you want to increase
the wear? You have to decrease the traction % at the output for each vKm in the LUT.
Below here there is an example of a tyre wear look-up-table.

The inputs and outputs are separated by the | symbol as you can see (I already mentioned this at the beginning). For more examples open an official Kunos car and look at
the data. Usually wear LUTs with more than three lines are kind of wasted. The reason why three values are exactly what you need is that you need a point any time the wear
rate changes. With 3 points there's the wear on a new tire, then the wear once it's scrubbed, then the wear at fully worn.
You can add however many points you want but you need at most 6 or so, 3 are ideal and recommended if you just want a break-in, peak and dropoff for the wear curve.
Also, try to evenly space them. Look at the official content for reference.
In the tyres.ini script you can find all the lines where to reference these LUTs and there are also some multipliers to adjust the behaviour. (add more details)

4. Tyre wear is never really off, it just goes really really slowly even when it's set to "off" from the realism options in the Race preparation.
5. Camber doesn’t affect tyre wear in vanilla AC. This however is not very important, because physical wear is less important than chemical for peak grip.
6. In order to work with wear, I recommend to use the Sidekick app, as it reads the tyre wear LUT directly, so you can configure what "0% wear" actually is. Other debug
apps (included official ones) display wrong values.
7. Be aware that the tyre wear of the virtual AI opponents is much lower than the player's. Assetto Corsa has got many bugs regarding them. There are some mod projects
trying to fix them but they're still in development.

- Now, about tire explosion.

In AC the tire explodes (it's an optional setting for each car) based on a temperature threshold, if you look in the tyres.ini script you'll find the [EXPLOSION]
value for this, but from my understanding it is not what normally you would want to achieve. There isn't a parameter to make them directly rip due to wear.
The temperature however is influenced by wear (but not in a realistic way). Heating behaviour in Assetto is not very good at all.

453
- Heat is probably the weakest part about vanilla tires indeed. Most content has very incorrect rate of heating and manner of heating; there are no interactions
between brake temps and tire temps (and the brake heat is consequently not worth using). So you simply can't use the same tire heating strategies, or even
the same logic as in real life for vanilla AC. If you're going for performance, forget the real world completely and just optimize it within the simulation.
With CSP this changes, because a completely new, more accurate thermal model is introduced. Then it is possible to implement quite realistic tire and brake
heating and have them work. But many vanilla parameters are still required, so you can’t forget about tyres.ini.
- AC always assumes that every car has 4 tires and runs code only for those ones. That's very hardcoded. Vehicles with two, three, five or more wheels
aren’t possible without hacks that almost defy the physics (and maybe some special CSP-mod sauce too).
- In tyres.ini you can configure multiple sets of tires. You can add them below the first one. Just make sure you type in the needed .lut files and use the right
numbering. Each set should come with correct radius/width of the tires, but may result in the visual meshes to sink or hover on the ground. This problem
can be overcome with the CSP mod, otherwise it's probably fine to just leave a shared radius.
- Since the tire's modeled as a spring vertically, doing a more complicated collision mesh wouldn’t be very easy.
- Changing the spring rate (the RATE value) won't directly change grip in AC (there's no real contact patch simulation). You need to adjust DY_REF and
DX_REF (lateral and longitudinal grip coefficients at reference load) to directly adjust grip. The V5 Tires thread on the official forum (in the physics modding
section) has the equations to calculate grip at a given load.

ABOUT RELATED FILES

LUTs:

tyre_compound_wear_f.lut / tyre_compound_wear_r.lut

The physics engine applies a linear interpolation to the values, same as every other LUT (except camber).

CURIOSITIES AND AMENITIES

- ac_tyres.ini
This script is an old version of tyres.ini. You can find it in the Ferrari 458 GT2 data and in other cars. I’m just going to copy it below (formatted in columns),
because there is no information available about this file anywhere online. It’s just a relic of Kunos development, don’t be scared if you find it in the data files.
[FRONT_0] [REAR_0] [FRONT_1] [REAR_1]
NAME=Front tyre NAME=Rear tyre NAME=Front tyre NAME=Rear tyre
SHORT_NAME=S SHORT_NAME=S SHORT_NAME=SS SHORT_NAME=SS
WIDTH=0.300 WIDTH=0.310 WIDTH=0.300 WIDTH=0.310
RADIUS=0.325 RADIUS=0.355 RADIUS=0.325 RADIUS=0.355
RIM=0.2413 RIM=0.2413 RIM=0.2413 RIM=0.2413
SOFTNESS=1.7 SOFTNESS=1.7 SOFTNESS=1.7 SOFTNESS=1.7
SIDE_STIFFNESS=0.5 SIDE_STIFFNESS=0.7 SIDE_STIFFNESS=0.5 SIDE_STIFFNESS=0.7

Of course it can be deleted.

- There are mods that don't show any tire model reference in the loading screen (vanilla). Those are pre version v5. Tire model info was not included in the
loading screen (or tire.ini?) before v5.

- In the early days of the more accurate v10 tires, some people started complaining because they preferred the v5 model, which was simpler. What an
attitude… keep on comparing games…

CSP ADDITIONS
NEW TIRE MODEL with multiple contact points.

FAQ
QUESTION [1]: Can I use tires from another car for my mod?
ANSWER [1]: Yes, if you take the sets from the official content. Avoid swapping tires from another mod, as they may have been altered to make cars with the
worst handling driveable, being low-quality and low-effort. And the numbers may be completely invented. These are examples of bad practices. With
telemetry you can learn to recognize them. Tire sets made by Kunos are not bad at all, despite whatever people may say.

Q [2]: How do I update the tires of an old car mod? I'm trying to fix a broken mod. Currently it is on version 3. I want to update it to v10.
A [2]: As already explained in the parameter descriptions, the tire version in the [HEADER] indicates the properties of the tires, not really the version of the
file. This is because each VERSION number introduces different features that determine the accuracy of the behaviour based on real data. This means, for
example, that v10 tires are more faithful than v3, v5 or v7 tires, but they need also more values, being less simplified. That’s the “problem”. Tires cannot
really be updated, they have to be replaced with counterparts that produce a similar behaviour, or with brand new, well-made ones. Put your brain to good
use. And by the way, avoid CM’s automatic tyre machine, which relies on black magic.

Q [3]: We have a question about matching a real-life tire to AC tire:

“I'm modeling my real-life track car in AC, and the tire compound is somewhere between the vanilla Semislick and the Trofeo Medium Slick. The tire is a 255/40/17.
I have real life AIM data at a track that exists in AC. Assuming my vehicle model and track model is reasonably accurate, Is there any way I can adjust the global lateral/longitudinal
grip factor, and use telemetry to match the tire compound to the real tire?”

454
A [3]: All of the parameters pertaining to tires in Assetto Corsa are within the tyres.ini file and the corresponding LUTs. If there are any other parameters related
to tyres, we do not have a way to access them (for example, you can’t change the equations of the Kunos-formula-based tires). It's going to take a lot of trial
and error. Even the lead developer of AC, Stefano Casillo, refers to tire creation as a "black art". But we will shed some light on it. I have a torch with me.
Trying to match the grip of your real-world tire is going to be hard enough, but don't forget about the thermal properties. How they heat up and cool down
and spread that heat throughout the surface is equally important.
I would use one of the vanilla compounds that feels similar to the real car, and play with the values.
With telemetry, using lateral and longitudinal G (acceleration), you can try to match it as closely as possible by adjusting the DX_REF and DY_REF values
and obtain something like Fig..

Fig. – The top graph is speed, 2nd graph is Lat G, 3rd graph is Lon G. The red traces are the telemetry data from a Honda S2000 in real life. Blue traces are AC on the same track. This
was achieved by an enthusiast with no professional engineering background; while noting the skill demonstrated by this modder, one can still do better.

Q [4]: Why is it difficult to model drift cars in AC?

A [4]: It's near impossible to get data on extreme slip angles for tires, real world tests rarely pass 10-15 degrees, sure you can by observation realize that
drifting exists, but since it's "known" that it's not the fastest driving style, there's less effort to figure out what happens. I think partly it's because the tyre's
dynamic in too many variables at larger slip angles - you have heat moving around, rubber literally melting off the surface, etc. - it makes running consistent
tests more difficult.

Q [5]: How can I find real-life tire specifications?

A [5]: All tyres and rims are standardized to guarantee interchangeability, i.e. to guarantee the possibility of using tyres from different manufacturers but with
the same designation on one vehicle and to restrict the variety of tyre types worldwide. So when you find the definition of one of the standards, you can define
generic characteristics of tires that follow it. Just look at what’s written on the tire itself. I know, there are tires without specs printed or engraved on them; we’ll
talk about those later.
Within Europe, standardization is carried out by the European Tyre and Rim Technical Organization or ETRTO, which specifies the following:
• tire and rim dimensions;
• the code for tire type and size;
• the load index and speed symbol.
Passenger car tyres are governed by UNO regulation ECE-R 30, commercial vehicles by R 54, spare wheels by R 64, and type approval of tyres on the vehicle
by EC directive 92/23/EC.

In the USA the Department of Transportation (or DOT, see item in Fig.) is responsible for the safety standards. The standards relevant there are:
• Standard 109 Passenger cars
• Standard 119 Motor vehicles other than passenger cars.
The Tire and Rim Association, or TRA for short, is responsible for standardization in the US.
In Australia, binding information is published by the Federal Office of Road Safety, Australian Motor Vehicle Certification Board.
ARD 23 Australian Design Rule 23/01: Passenger car tyres is the applicable standard.
In Germany the DIN Standards (Deutsches Institut für Normung) and the WdK Guidelines (Wirtschaftsverband der Deutschen Kautschukindustrie Postfach
900360, D-60443, Frankfurt am Main) are responsible for specifying tyre data. All bodies recognize the publications of these two organizations.

455
At the international level, the ISO (International Organization for Standardization) also works in the field of tyre standardization and ISO Standards are
translated into many languages.
The most important information on the tire sidewall is the size number, indicated by 2 (Fig. ). To see the format of the size number, here is an example
explained:
P 215 / 60 R 15 96 H
P: Tire type. The first letter indicates the proper type of car that the tire is made for. P stands for passenger car. The first letter can also be ST for special trailer, T for temporary,
and LT for light truck.
215: Tire width. This three-number code is the width of the unloaded tire from sidewall to sidewall measured in [mm].
60: Aspect ratio. This two-number code is the ratio of the tire section height ℎ𝑡𝑡 to tire width 𝑤𝑤𝑡𝑡 , expressed as a percentage. Aspect ratio is shown by
ℎ𝑡𝑡
𝑠𝑠𝑡𝑡 = ∙ 100
𝑤𝑤𝑡𝑡
Generally speaking, tire aspect ratios range from 35, for race car tires, to 75 for tires used on utility vehicles.
R: Tire construction type. The letter R indicates that the tire has a radial construction. It may also be B for bias belt or bias ply, and D for diagonal.
15: Rim/bead diameter. This is a number in [in] to indicate diameter of the rim that the tire is designed to fit on. Typically rims are referred to with their size in inches, even in
countries which adopted SI units. That’s weird, it happens for screens and televisions too.
96: Load rate or load index. Many tires come with a service description at the end of the tire size. The service description is made of a two-digit number (load index) and a
letter (speed rating). The load index is a representation of the maximum load each tire is designed to support. It is generally valid for speeds under 210 km/h (≈130 mph).
If the load index is not indicated on the tire, then a tire with a size number such as 255/50R17 100V may also be numbered by 255/50V R17.
H: Speed rate. Indicates the maximum speed that the tire can sustain for a ten-minute endurance without breaking down. This was very useful for those guys from Bugatti
trying to go at 400 km/h.
Race tire markings
Race cars employed quite different tires than nomal vehicles. Sometimes you’ll have to understand what the numbers and units refer to, based on the context.
Size markings like 280/675-18, show nominal tread width [mm], overall tyre diameter [mm] and bead diameter [in]. Note that all dimensions are taken from
an inflated tire under unloaded conditions. For post historic tyres, the markings (e.g. 600/1200-15) are nominal section height, section width and bead
diameter in inches.
Certain rules call for maximum overall width to include rims.
With this you should be able to understand the various tire catalogues and product labels out there (Fig.).

Fig. – (left) Label of a Pirelli Cinturato P7 pneumatic. (right) Extract from a Goodyear tire catalogue.

Regarding the INFLATION PRESSURE CONVERSION:

PSI to BAR: divide by 14.5 (14.50377)
BAR to PSI: multiply by 14.5 (14.50377)

Regarding tire weight.

The average weight of a tire for passenger cars is 10-12 kg. The weight of a tire for light trucks is 14-16 kg, and the average weight of commercial truck tires
is 135-180 kg.

456
Fig. T.-1 - Explanation of the marking on the sidewall of a tyre manufactured by Pneumatiques Kléber SA.
Legal and industry standard markings on the sidewalls of tyres according to: FMVSS and CIR 104 | UTQG (USA) | CSA Standard (Canada) | ADR 23B (Australia) | ECE–R30 (Europe)
1 Manufacturer (brand or commercial name)
1a Product name
2 Size marking: 195 = nominal tyre width in mm; 60 = height–width ratio (60%); R = radial type; 14 = rim diameter in inches
3 Type of tire construction, here tubeless tire
4 Trade code
5 Country of manufacture
6 Load capacity index (LI)
7 Maximum load capacity for the USA
8 Tread: under the tread are 6 plies carcass rayon, 2 plies steel belt, 2 plies nylon). Sidewall: the substructure consists of 2 plies rayon
9 Maximum allowed tyre inflation pressure for the USA
10, 11, 12 USA: manufacturer’s guarantee of compliance with the Uniform Tire Quality Grade (UTQG) which specifies: 10 tread wear: relative life expectancy compared with US-specific standard
test values
11 Traction: A, B, C = braking performance on wet surfaces
12 Temperature resistance: A, B or C = temperature resistance at higher test stand speeds; C fulfills the legal requirement in the USA
13 Europe type approval mark and number. E 4 = tyre fulfils the European ECE R30 value requirements; 4 = country in which approval was carried out (4 = The Netherlands)
14 identity number according to ECE R-30
15 DOT = tyre fulfils the requirements according to FMVSS 109 (DOT = U.S. Department of Transportation)
16 Manufacturer’s code: CU = factory (Continental); L2 = tyre size; AXCT = model; 127 = date of manufacture: production week 12, 1987

Q [6]: How do I calculate tire data from the specifications seen in QUESTION [5]?
A [6]: Here are some examples.
Calculating tire diameter and radius.
We are able to calculate the overall diameter of a tire using the tire size numbers. By multiplying the tire width and the aspect ratio, we get the tire height. As an example, we
use tire number P 235/75R15.
hT = 235 × 75% = 176.25mm ≈ 6.94 in
Then, we add twice the tire height hT to the rim diameter to determine the tire’s unloaded diameter D = 2R and radius R.

457
D = 2× 6.94 + 15 = 28.88 in ≈ 733.8mm
R = D/2 = 366.9mm
Height of a tire based on tire numbers.
A tire has the size number P 215/60R15 96H. The aspect ratio 60 means the height of the tire is equal to 60% of the tire width. To calculate the tire height in [mm], we
should multiply the first number (215) by the second number (60) and divide by 100. ℎ𝑡𝑡 = 215 ∙ 60/100 = 129 𝑚𝑚𝑚𝑚. This is the tire height from rim to tread.
Weight of a car and load index of its tire.
For a car that weighs 2 tons = 2000 kg, we need a tire with a load index higher than 84. This is because we have about 500 kg per tire and it is in a load index of 84.

458
PHYSICS (for tyres.ini)
This part will be pretty heavy and comprehensive, as the tires are crucial functional elements for the transmission of longitudinal, lateral and vertical forces
between the vehicle and road. They’re the most important part of the whole simulation.
For now, grip is what our business is all about. Grip comes from tires, period. The racing driver’s best friend is the tire, followed closely by the sponsor.

1.0 - Wheels and tires

All road vehicles have wheels and almost all of them have wheels with pneumatic tires. Wheels have been around for many centuries, but only with the
invention and enhancement of the pneumatic tire it has been possible to conceive fast and comfortable road vehicles.
A tire is an advanced engineering product made of rubber and a series of synthetic materials cooked together. Fiber, textile, and steel cords are some of the
components that go into the tire’s inner liner, body plies, bead bundle, belts, sidewalls, and tread. Figure illustrates a sample of tire interior components and
their arrangement.

Fig. ** - (left) Illustration of a sample radial tire interior components and arrangement. (right) Radial design of passenger car tyres in speed category T; the number of layers and the
materials are indicated on the sidewall (see Fig.). The components are: 1-Running tread, 2-Steel belt, 3-Edge protection for the belt, made of rayon or nylon, 4-Sidewall, 5-Substructure
with two layers, 6-Cap, 7-Inner lining, 8-Flipper, 9-Bead profile, 10-Core profile, 11-Bead core

The main components of a tire are explained below:

• Bead or bead bundle is a loop of high strength steel cable coated with rubber. It gives the tire the strength it needs to stay seated on the wheel rim and to transfer the tire
forces to the rim.
• Inner layers are made up of different fabrics, called plies. The most common ply fabric is polyester cord. The top layers are also called cap plies.
• Cap plies are polyesteric fabric that help hold everything in place. Cap plies are not found on all tires; they are mostly used on tires with higher speed ratings to help all
the components stay in place at high speeds.
• An inner liner is a specially compounded rubber that forms the inside of a tubeless tire. It inhibits loss of air pressure.
• Belts or belt buffers are one or more rubber-coated layers of steel, polyester, nylon, Kevlar or other materials running circumferentially around the tire under the tread.
They are designed to reinforce body plies to hold the tread flat on the road and make the best contact with the road. Belts reduce squirm to improve tread wear and resist
damage from impacts and penetration.
• The carcass or body plies are the main part in supporting the tension forces generated by tire air pressure. The carcass is made of rubber-coated steel or other high
strength cords tied to bead bundles. The cords in a radial tire, as shown in Fig. left, run perpendicular to the tread. But we will discuss the tire types in more detail later.
The plies are coated with rubber to help them bond with the other components and to seal in the air.
A tire’s strength is often described by the number of carcass plies. Most car tires have two carcass plies. By comparison, large commercial jetliners often have tires with
30 or more carcass plies.
The sidewall provides lateral stability for the tire, protects the body plies, and helps to keep the air from escaping from the tire. It may contain additional
components to help increase the lateral stability.
The tread is the portion of the tire that comes in contact with the road. Tread designs vary widely depending on the specific purpose of the tire. The tread is
made from a mixture of different kinds of natural and synthetic rubbers. The outer perimeter of a tire is also called the crown.
The tread groove is the space or area between two tread rows or blocks. The tread groove gives the tire traction and is especially useful during rain or snow
and while driving on mud or offroad.

Fig.T.0 illustrates a cross section view of a tire on a rim to show the dimension parameters that are used to standard tires.

459
Fig. t.0 - Cross section of a tire on a rim that shows tire height and width.

The section height, tire height, or simply height, hT, is a number that must be added to the rim radius to make the wheel radius. The section width, or tire
width, wT, is the widest dimension of a tire when it is not loaded.
Tires are required to have certain information printed on the tire sidewall. Fig.T.-1 illustrates a side view of a sample tire to show the important information
printed on a tire sidewall.
The main features of any tire are its flexibility and low mass, which allow for the contact with the road to be maintained even on uneven surfaces. Moreover,
the rubber ensures high grip. These features arise from the highly composite structure of tires: a carcass of flexible, yet almost inextensible cords encased in
a matrix of soft rubber, all inflated with air 71. Provided the (flexible) tire is properly inflated, it can exchange along the bead relevant actions with the (rigid)
rim. Traction, braking, steering and load support are the net result.
It should be appreciated that the effect of air pressure is to increase the structural stiffness of the tire, not to support directly the rim. How a tire carries a
vertical load Fz if properly inflated is better explained in Fig. t1. In the lower part the radial cords encased in the sidewalls undergo a reduction of tension
because they no longer have to balance the air pressure pa acting on the contact patch. The net result is that the total upward pull of the cords on the bead
exceeds that of the downward pull by an amount equal to the vertical load Fz.

71
Only in competitions it is worthwhile to employ special (and secret) gas mixtures instead of air. The use of nitrogen, as often recommended, is in fact completely equivalent to air, except for the
cost.

460
Fig. t.1 - How a tire carries a vertical load if properly inflated.
The contact patch, tireprint or footprint, of the tire is the area of the tread in contact with the road. This is the area that transmits forces between the tire and
the road via pressure and friction. To truly understand some of the peculiarities of tire mechanics it is necessary to get some insights on what happens in the
contact patch.
Handling of road vehicles is strongly affected by the mechanical behaviour of the wheels with tires, that is by the relationship between the kinematics of the
rigid rim and the force exerted by the road.
The following paragraphs are devoted to the analysis of experimental tests. The and development of simple, yet significant, tire models will be done later.

461
1.1 - The tire as a vehicle component
A wheel with tire is barely a wheel, in the sense that it behaves quite differently from a rigid wheel 72. This is a key point to really understand the mechanics
of wheels with tires.
For instance, a rigid wheel touches the (flat) road at one contact point C, whereas a tire has a fairly large contact patch. Pure rolling of a rigid wheel is a clear
kinematic concept, but, without further discussion, it is not obvious whether an analogous concept is even meaningful for a tire. Therefore, we have to be
careful in stating as clearly as possible the concepts needed to study the mechanics of wheels with tires.
Moreover, the analysis of tire mechanics will be developed with no direct reference to the dynamics of the vehicle. This may sound a bit odd, but it is not.
The goal here is to describe the relationship between the motion and position of the rim and the force exchanged with the road through the contact patch:
rim kinematics ⇐⇒ force and moment
Once this description has been obtained and understood, then it can be employed as one of the fundamental components in the development of suitable
models for vehicle dynamics, but this is the subject of other chapters.
Three basic components play an active role in tire mechanics:
1. The rim, which is assumed to be a rigid body;
2. The flexible carcass of the inflated tire;
3. The contact patch between the tire and the road.

1.2 - Tire compounds

During World War II, supplies of natural rubber from Asia became difficult to come by, so chemical engineers in the U.S. and Russia came up with synthetic
rubber made from crude oil. Their products fulfilled wartime needs for rubber until rubber-tree supplies resumed after the war. During the 1950s, chemists
improved the formulas for synthetic rubber, and by the mid-1960s synthetic materials outpaced natural rubber in tires.
Today’s tubeless tires are a composite of up to 200 different chemicals. Each part of the tire — casing, sidewalls and tread — is manufactured to specific
performance criteria, using a variety of natural and synthetic rubber compounds. Racing tires are very different from passenger tires, which are very different
from truck tires. Various chemical formulations allow for tradeoffs among tire properties, such as resistance to aging, heat and wear, as well as the critical
aspect of traction.
During the 1950s, chemical engineers discovered that they could extend the life of tires by adding chemicals to slow the aging process. Ozone, a highly
reactive form of oxygen, is created as a byproduct of automobile exhaust. When ozone contacts rubber, it creates tiny cracks by breaking chemical bonds in
the long-chain molecules that give rubber its flexibility and resilience. The cracks grow larger and larger with more ozone exposure.
Compounds that capture ozone before it can break rubber’s chemical bonds proved to be a godsend in saving rubber from deterioration. A closely related
group of chemicals, the para-phenylene-diamines, proved especially effective at grabbing ozone when added to rubber. Such chemicals include 6PPD, the
most commonly used in tires today, as well as IPPD and DPPD.
Small amounts of these additives (0.5 to 2 percent) in rubber can inhibit ozone degradation by migrating to the surface of the tire, where they form a
microscopic film. Experts still debate whether the tire is better protected by the micro-film layer or by the rapid reaction between ozone and PPD, but both
come into play.
In any case, tiny bits of rubber eventually fly off onto the roadway and wash into streams. These bits of rubber carry with them a new chemical never added
to tires and apparently overlooked when studying the toxicity of tire-related compounds. This chemical is the mysterious, highly toxic compound believed
responsible for the deaths of many coho salmon. It’s called 6PPD-quinone, as quinone is a chemical group bearing oxygen atoms picked up during the
rapid reaction between 6PPD and ozone.

72
A rigid wheel is essentially an axisymmetric convex rigid surface. The typical rigid wheel is a toroid. Imagine a donut.

462
2.0 - Road-to-wheel contact
In this paragraph we will present some theoretical models useful for identifying the forces that are exchanged in the wheel-road contact.
2.1 – Coulomb’s model

Rim position and motion

For simplicity, the road is assumed to have a hard and flat surface, like a geometric plane. This is a good model for any road with high quality asphalt
paving, since the texture of the road surface is not relevant for the definition of the rim kinematics (while it highly affects grip).
The rim R is assumed to be a rigid body 73, and hence, in principle, it has six degrees of freedom (it can move along three directions and rotate in other
three). However, only two degrees of freedom are really relevant for the rim position, because the road is flat and the wheel rim is axisymmetric.

Let Q be a point on the rim axis 𝑦𝑦𝑐𝑐 (Fig.). Typically, although not strictly necessary, a sort of midpoint is taken. The position of the rim with respect to the
flat road depends only on the height h of Q and on the camber angle γ (i.e., the inclination) of the rim axis 𝑦𝑦𝑐𝑐 . More precisely, h is the distance of Q from
the road plane and γ is the angle between the rim axis and the road plane.

Fig. t.2 - Wheel with tire: nomenclature and reference system.

Sometimes, the distance h is called loaded tire radius. The word “radius” may be misleading. There is no circle with radius h.
Now, we can address how to describe the rim velocity field 74.
The rim, being a rigid body, has a well defined angular velocity Ω. Therefore, the velocity of any point P of the (space moving with the) rim is given by the
equation
𝑽𝑽𝑃𝑃 = 𝑽𝑽𝑸𝑸 + 𝛀𝛀 × 𝑄𝑄𝑄𝑄 (5342)

where 𝑽𝑽𝑸𝑸 is the velocity of Q and QP is the vector connecting Q to P. The three components of 𝑽𝑽𝑸𝑸 and the three components of Ω are, e.g., the six
parameters which completely determine the rim velocity field.

Reference system
A moving reference system Sw = (x, y, z; O) is depicted in Fig.t.2. It is defined in a fairly intuitive way. The y-axis is the intersection between a vertical
plane containing the rim axis 𝑦𝑦𝑐𝑐 and the road plane. The x-axis is given by the intersection of the road plane with a plane containing Q and normal to 𝑦𝑦𝑐𝑐 .
The intersection between axes x and y defines the origin O as a point on the road. The z-axis is vertical, that is perpendicular to the road, with the positive
direction upward 75. The unit vectors marking the positive directions are (i, j, k), as shown in Fig. t.2.
An observation is in order here. The directions (i, j, k) have a physical meaning, in the sense that they clearly mark some of the peculiar features of the rim
with respect to the road. As a matter of fact, k is perpendicular to the road, i is perpendicular to both k and the rim axis 𝐣𝐣𝑐𝑐 , j follows accordingly. However,
the position of the Cartesian axes (x, y, z) is arbitrary, since there is no physical reason to select a point as the origin O. This is an aspect whose
implications are often underestimated.
The selected point O is often called center of the footprint, or center of the wheel.

Rim Kinematics
The moving reference system Sw = (x, y, z; O) allows a more precise description of the rim kinematics. On the other hand, a reference system Sf = (xf, yf,
zf; Of) fixed to the road is not very useful in this context.

Let jc be the direction of the rim spindle axis 𝑦𝑦𝑐𝑐

𝐣𝐣𝑐𝑐 = 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝐣𝐣 + 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝐤𝐤 (ko2)

73
In physics, a rigid body (also known as a rigid object) is a solid body in which deformation is zero or so small it can be neglected. The distance between any two given points on a rigid body
remains constant in time regardless of external forces or moments exerted on it. A rigid body is usually considered as a continuous distribution of mass.
74
Which can be thought of at each instant in time as a collection of vectors, one for each point in space, whose direction and magnitude describes the direction and magnitude of the velocity of
the object at that point. The distribution of velocities is described by the vector function v (x, y, z, t). This represents the velocity of the object at the point with (x, y, z) coordinates at the instant t
and is called velocity vector field.
75
Sw is the system recommended by ISO (International Organization for Standardization).

463
where the camber angle γ of Fig.t.2 is positive. The total rim angular velocity Ω is

𝛀𝛀 = 𝛾𝛾 ′ 𝐢𝐢 + 𝜃𝜃 ′ 𝐣𝐣𝑐𝑐 + 𝜁𝜁 ′ 𝐤𝐤 = 𝛾𝛾 ′ 𝐢𝐢 + 𝜔𝜔𝑐𝑐 𝐣𝐣𝑐𝑐 + 𝜔𝜔𝑧𝑧 𝐤𝐤 = 𝛾𝛾 ′ 𝐢𝐢 + 𝜔𝜔𝑐𝑐 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝐣𝐣 + (𝜔𝜔𝑐𝑐 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 + 𝜔𝜔𝑧𝑧 )𝐤𝐤 = Ω𝑥𝑥 𝐢𝐢 + Ω𝑦𝑦 𝐣𝐣 + Ω𝑧𝑧 𝐤𝐤

where γ’ is the time derivative of the camber angle, 𝜃𝜃 ′ = 𝜔𝜔𝑐𝑐 is the angular velocity of the rim about its spindle axis, and 𝜁𝜁 ′ = 𝜔𝜔𝑐𝑐 is the yaw rate, that is
the angular velocity of the reference system Sw.

It is worth noting that there are two distinct contributions to the spin velocity Ω𝑧𝑧 𝐤𝐤 of the rim 76, a camber contribution ωc sin γ and a yaw rate contribution
ωz:
Ω𝑧𝑧 = 𝜔𝜔𝑐𝑐 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠 + 𝜔𝜔𝑧𝑧

Therefore, as will be shown in Fig., the same value of Ω𝑧𝑧 can be the result of different operating conditions for the tire, depending on the amount of the
camber angle γ and of the yaw rate 𝜔𝜔𝑧𝑧 .

By definition, the position vector OQ (Fig.) is

𝑂𝑂𝑂𝑂 = ℎ(−𝑡𝑡𝑡𝑡𝑡𝑡 𝛾𝛾𝐣𝐣 + 𝐤𝐤) (A43Q)

This expression can be differentiated with respect to time to obtain

𝛾𝛾 ′
𝑽𝑽𝑸𝑸 − 𝑽𝑽𝑶𝑶 = ℎ′ (−𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝐣𝐣 + 𝐤𝐤) + ℎ �𝜔𝜔𝑧𝑧 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝐢𝐢 − 𝐣𝐣� =
𝑐𝑐𝑐𝑐𝑐𝑐 2 𝛾𝛾
𝛾𝛾
= ℎ𝜔𝜔𝑧𝑧 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝐢𝐢 − �ℎ′ 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡 + ℎ � 𝐣𝐣 + ℎ′𝐤𝐤
𝑐𝑐𝑐𝑐𝑐𝑐 2 𝛾𝛾

since dj/dt = −𝜔𝜔𝑧𝑧 i. Even in steady-state conditions, that is h’ = γ’ = 0, we have 𝑉𝑉𝑄𝑄 = 𝑉𝑉𝑂𝑂 + ℎ𝜔𝜔𝑧𝑧 𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝑡𝐢𝐢 and hence the velocities of points Q and O
are not exactly the same, unless also γ = 0. The camber angle γ is usually very small in cars, but may be quite large in motorcycles (up to 60 deg).

The velocity Vo = VO of point O has, in general, longitudinal and lateral components (Fig. t.2)
𝑽𝑽𝑜𝑜 = 𝑽𝑽O = 𝑉𝑉𝑜𝑜𝑥𝑥 𝐢𝐢 + 𝑉𝑉𝑜𝑜𝑦𝑦 𝐣𝐣

As already stated, the selection of point O is arbitrary, although quite reasonable. Therefore, the velocities 𝑉𝑉𝑂𝑂𝑥𝑥 and 𝑉𝑉𝑂𝑂𝑦𝑦 do not have much of a physical
meaning. A different choice for the point O would provide different values for the very same motion. However, a wheel with tire is expected to have
longitudinal velocities much higher than lateral ones. that is |α| < 12°, as will be discussed with reference to Fig.

Summing up, the position of the rigid rim R with respect to the flat road is completely determined by the following six degrees of freedom:

• h(t) distance of point Q from the road (often, improperly, called loaded radius);
• γ(t) camber angle;
• θ(t) rotation of the rim about its axis yc;
• xf (t) first coordinate of point O with respect to Sf;
• yf (t) second coordinate of point O with respect to Sf;
• ζ(t) yaw angle of the rim.

However, owing to the circular shape of rim and the flatness of the road, the kinematics of the rigid rim R are also fully described by the following six
functions of time:

• h(t) distance of point Q from the road;

• γ(t) camber angle;
• ωc (t) angular velocity of the rim about its axis yc;
• 𝑉𝑉𝑜𝑜𝑥𝑥 (t) longitudinal speed of O;
• 𝑉𝑉𝑂𝑂𝑦𝑦 (t) lateral speed of O;
• ωz (t) yaw rate of the moving reference system Sw.

The rim is in steady-state conditions if all these six quantities are constant in time. However, this is not sufficient for the wheel with tire to be in a stationary
state. The flexible carcass and tire treads could still be under transient conditions.

Now, there is an observation whose practical effects are very important. If we are interested only in the truly kinematic (geometric) features of the rim motion,
we can drop the number of required functions from six to five:
𝑉𝑉𝑂𝑂𝑥𝑥 𝑉𝑉𝑂𝑂𝑦𝑦 𝜔𝜔𝜔𝜔
h, γ, , , (xh)
𝜔𝜔𝜔𝜔 𝜔𝜔𝜔𝜔 𝜔𝜔𝜔𝜔

Essentially, we are looking at the relative values of speeds, as if their magnitude were of no relevance at all. This is what is commonly done in vehicle
dynamics, as we will see soon. Again, we emphasize that a vehicle engineer should be aware of what he/she is doing.

76
In the SAE terminology, it is 𝜔𝜔𝑐𝑐 𝒋𝒋𝑐𝑐 that is called spin velocity.

464
Carcass features

The tire carcass C is a highly composite and complex structure. Here we look at the tire as a vehicle component and therefore it suffices to say that the
inflated carcass, with its flexible sidewalls, is moderately compliant in all directions (Fig. t.1).
The external belt (Fig. Xi) is also flexible along the radial axis, but quite inextensible transversally (i.e. when you take a bump it deforms mostly in a vertical
direction rather than any other longitudinal direction). For instance, its circumferential length is not very much affected by the vertical load acting on the tire.
The belt is covered with tread blocks whose elastic deformation and grip features highly affect the mechanical behaviour of the wheel with tire.
Basically, the carcass can be seen as a nonlinear elastic structure with small hysteresis due to rate-dependent energy losses. It is assumed here that the
carcass and the belt have negligible inertia, in the sense that the inertial effects are small in comparison with other causes of deformation. This is quite
correct if the road is flat and the wheel motion is not “too fast”.

Contact patch
Tires are made from rubber, that is elastomeric materials to which they owe a large part of their grip capacity. Grip implies contact between two surfaces: one
is the tire surface and the other is the road surface.
The contact patch (or footprint) P is the region where the tire is in contact with the road surface. In Fig. t.2 the contact patch is schematically shown as a
single region. However, most tires have a tread pattern, with lugs and voids, and hence the contact patch is the union of many small regions (Fig.).

Fig. - Typical contact patch (if α = γ = 0) with tread pattern.

It should be emphasized that the shape and size of the contact patch, and also its position with respect to the reference system, depend on the tire operating
conditions.

Grip depends, among other things, on the type of road surface, its roughness, and whether it is wet or not. More precisely, grip comes basically from road
roughness effects and molecular adhesion.
Road roughness effects, also known as indentation, require small bumps measuring a few microns to a few millimetres (Fig.), which dig into the surface of
the rubber.

Fig. - Road roughness description.

On the other hand, molecular adhesion necessitates direct contact between the rubber and the road surface, i.e. the road must be dry.

Two main features of road surface geometry must be examined and assessed when considering tire grip, as shown in Fig.:

Macroroughness: this is the name given to the road surface texture when the distance between two consecutive rough spots is between 100 microns and 10
millimetres. This degree of roughness contributes to indentation, and to the drainage and storage of water. The load bearing surface, which depends on road
macroroughness, must also be considered since it determines local pressures in the contact patch.

Microroughness: this is the name given to the road surface texture when the distance between two consecutive rough spots is between 1 and 100 microns.
It is this degree of roughness which is mainly responsible for tire grip via the road roughness effects. Microroughness is related to the surface roughness of
the aggregates and sands used in the composition of the road surface.

Footprint force
Any set of forces or distributed load is statically equivalent to a force-couple system at a given (arbitrary) point O. Therefore, regardless of the degree of
roughness of the road, the distributed normal and tangential loads in the footprint yield a resultant force F and a resultant couple vector MO

465
wip

The resultant couple MO is simply the moment about the point O, but any other point could be selected. Therefore it has no particular physical meaning.
However, if O is somewhere within the contact patch, the magnitude |MO| is expected to be quite “small” for the wheel with tire to resemble a rigid wheel.
Traditionally, the components of F and MO have the following names:
Fx longitudinal force;
Fy lateral force;
Fz vertical load or normal force;
Mx overturning moment;
My rolling resistance moment;
Mz self-aligning torque, called vertical moment here.
WIP

Grip, traction and everything in between

The ability of an automobile tyre to ‘grip’ the road and avoid skidding is ultimately dependent upon the events in the tyre-road interface.
This paragraph will describe some of the variables to be aware of in tyre performance, and it provides a ‘state of the art’ review of the friction processes
involved.
Considerable uncertainty exists concerning the importance of tyre-road traction (or friction). Intuitively most users of vehicles would endorse high friction on
the simple ground that it would increase safety. However, there has not yet been a complete study of driver-vehicle-environment system effectiveness to
determine how high friction should be. It is known that in many accidents a high tyre-road friction would not have reduced the severity of the consequences.
In many other instances high friction might have been useful, but only if the driver had been trained to handle his vehicle during extreme manoeuvring. Few
operators are experienced in vehicle manoeuvres involving accelerations in excess of 0.3 g.

The industry has been under some pressure to specify the limits and abilities of their product in a manner that is meaningful to the general public.
Unfortunately, the tire is a very complex structure and its role in the dynamics of vehicle handling is only slowly becoming understood. However, the more
difficult problem is to describe properly true behaviour over the wide range of operating conditions of tires. Some of these conditions will be discussed in
connection with the results of the skid resistance tests described in the following paragraphs. Many devices have been built to measure the traction ability of
a tire.
Usually, when the results of such test programmes are used to try to predict the behaviour of a vehicle equipped with the tyres tested, poor correlation is
found. Apparently the discrepancy lies in the fact that with full scale vehicles, many more dynamic quantities are at work than in the test devices. The tyre is
a deformable body and it bears a fraction of the weight of the vehicle that varies with time. Roads are never perfectly smooth, vehicles never proceed in a
straight line, and with every pitch, roll and bounce of the vehicle a great number of dynamic states is imposed upon the tyre.
As a result, the tyre could appear to produce a higher or a lower friction in a full-scale vehicle test than in a carefully controlled test with a single tyre.
An extreme analogy of the tyre is a pogo stick. To ask what is the average friction between the tyre and the road is somewhat equivalent to inquiring
as to the average friction between the pogo stick and the pavement.

The skid resistance measurement of tyres

There is a great interest in data on the tractive coefficient for a particular tyre on a particular road. However, complete data are difficult and expensive to
obtain. Measuring a single value is not a useful exercise because tyre traction varies in an unpredictable manner with speed, amount of water on the road
and many other factors. Illustrative data are given here for two conditions of tyre behaviour.
First, it is known that average locked wheel sliding forces vary with speed on virtually all but the roughest road surface textures.
According to the Coulomb Law, a friction coefficient S of a perfectly elastic body such as steel is determined by the load and the friction force of the body,
and the value of a friction coefficient cannot exceed 1.
However, an object such as elastomer (which a tire is) becomes deformed when an external force is applied. Thus, to describe the mechanism of this
process is far more complicated. The mechanism needs to be analysed in a totally different way on the texture of the road surface with which elastomer
contacts.
As shown in formula (X**/), the friction coefficient of elastomer is determined by adding three coefficients such as an adhesion friction coefficient of a
molecular interaction between the road surface and elastomer, a friction coefficient of a hysteresis on deformations of elastomer, and a friction coefficient of
the cohesion due to wear or tear.

𝜇𝜇𝑡𝑡𝑡𝑡𝑡𝑡 = 𝜇𝜇𝑎𝑎 + 𝜇𝜇ℎ + 𝜇𝜇𝑐𝑐 (X**/)

where 𝜇𝜇𝑡𝑡𝑡𝑡𝑡𝑡 is the total (overall) coefficient, 𝜇𝜇𝑎𝑎 is the adhesion mu, 𝜇𝜇ℎ is the hysteresis mu and 𝜇𝜇𝑐𝑐 is the cohesion mu.
Here, the adhesion, which is a friction mechanism of polymer interactions between surfaces of the tread rubber and the road surface, determines friction
characteristics on the smooth and dry road surface as shown in Fig.. The grip especially on the icy or snowy road surfaces depends on the friction
mechanism.

Typical data are shown in Fig. for tractive coefficient (equivalent to friction coefficient) over a range of initial vehicle speeds.

466
Fig. - Tractive coefficient (tractive force/vehicle weight) over a range of vehicle speeds for all tyres on dry roads, and for good and bald tyres on wet roads.

Data are shown for ‘dry’ and for wet roads for two states of wear of the tyre. Note the great difference in performance of ‘dry’ versus wet roads. Also note that
the amount of tread determines the speed at which very little tractive force is available for vehicle control. The condition on wet road where very low friction
coefficient occurs is often referred to as hydroplaning (or aquaplaning).

The braking force of a tyre varies with its speed of rotation relative to the speed of rotation of a freely rotating tyre. For example, if a vehicle is proceeding at
60 km/h and if one tyre on that vehicle is rotating at a speed consistent with a vehicle speed of 54 km/h that tyre is said to be ‘slipping’ 10%, or S=0,10.
During normal braking of a vehicle, most of the tyres are slipping to some extent, of the order of 5% or less. In fact, a braking force cannot be generated
without such slip. A freely rolling tyre has S=0 and a locked wheel has S=1.

The tractive coefficient in braking over this full slip range is shown in Fig. (Byrdsong 1968) for wet and dry concrete at 30 mile h-l.

Fig. – The mu, μ, the drag force (friction) coefficient of the tire, plotted against slip ratio on both wet and dry surfaces.

Tire designs

Tires are divided in two classes: radial and non-radial, depending on the angle between carcass metallic cords and the tire-plane. Each type of tire
construction has its own set of characteristics that are the key to its performance.
The most important difference in the dynamics of radial and non-radial tires is their different ground sticking behaviour when a lateral force is applied on the
wheel. This is shown in Fig..

467
Fig. - Ground-sticking behaviour of radial and non-radial tires in the presence of a lateral force.

The radial tire, shown in Fig. (a), flexes mostly in the sidewall and keeps the tread flat on the road. The bias-ply tire, shown in Fig. (b) has less contact with
the road as both tread and sidewalls distort under a lateral load. The radial arrangement of carcass in a radial tire allows the tread and sidewall act
independently. The sidewall flexes more easily under the weight of the vehicle. So, more vertical deflection is achieved with radial tires. As the sidewall
flexes under the load, the belts hold the tread firmly and evenly on the ground and reduces tread scrub. In a cornering maneuver, the independent action of
the tread and sidewalls keeps the tread flat on the road. This allows the tire to hold its path. Radial tires are the preferred tire in most applications today.
The cross arrangement of carcass in bias-ply tires allows it act as a unit. When the sidewalls deflect or bend under load, the tread squeezes in and distorts.
This distortion affects the tireprint and decrease traction. Because of the bias-ply inherent construction, sidewall strength is less than that of a radial tire’s
construction and cornering is less effective.

Radial ply tyres

The radial ply tire consists of two bead cores joined together radially (hence the name) via the carcass with reinforcing steel cable belts that are assembled
in parallel and run side to side, from one bead to another at an angle of 90° to the circumferential centerline of the tire (Fig.). A belt of cords provides the
necessary stiffness (Fig. X), whereas the external part of the tyre consists of the tread and sidewall and the interior of the inner lining, which ensures the tyre
is hermetically sealed (Fig. ).

Fig. - Substructure of a radial tyre. The threads have a bias angle between 88° and Fig. Xi - The belt of the radial tyre sits on the substructure. The threads are at angles
90°. of between 15° and 25° to the plane of the tyre centre.

This makes the tire more flexible radially, which reduces rolling resistance and improves cornering capability. Fig. shows the interior structure and the
carcass arrangement of a radial tire.

In passenger car tyres, the carcass is made of rayon or nylon, the belt of steel cord or a combination of steel, rayon or nylon cord, and the core exclusively
of steel. Due to the predominance of steel as the material for the belt, these tyres are also known as ‘steel radial tyres’. The materials used are indicated on
the sidewall (Fig., points 7 and 8). In commercial vehicle designs this is particularly important and the carcass may also consist of steel.

The stiff belt causes longitudinal oscillation, which has to be kept away from the body by wheel suspensions with a defined longitudinal compliance,
otherwise this would cause an unpleasant droning noise in the body, when on cobbles and poor road surfaces at speeds of less than 80 km/h. The only
other disadvantage is the greater susceptibility of the thinner sidewalls of the tyres to damage compared with diagonal ply tyres. The advantages over cross-
ply tyres, which are especially important for today’s passenger cars and commercial vehicles, are:

• significantly higher mileage

• greater load capacity at lower component weight
• lower rolling resistance
• better aquaplaning properties
• better wet-braking behaviour
• transferable, greater lateral forces at the same tyre pressure
• greater ride comfort when travelling at high speeds on motorways and trunk roads.

468
Diagonal ply tyres

The non-radial tires are also called bias-ply and cross-ply tires. The plies are layered diagonal from one bead to the other bead at about a 30° angle,
although any other angles may also be applied. One ply is set on a bias in one direction as succeeding plies are set alternately in opposing directions as they
cross each other. The ends of the plies are wrapped around the bead wires, anchoring them to the rim of the wheel. Fig. shows the interior structure and the
carcass arrangement of a non-radial tire.

Fig. - Example of a non-radial tire’s interior components and arrangement.

In industrialized countries, cross-ply tyres are no longer used on passenger cars, either as original tyres or as replacement tyres, unlike areas with very poor
roads where the less vulnerable sidewall has certain advantages. The same is true of commercial vehicles and vehicles that tow trailers, and here too radial
tyres have swept the board because of their many advantages. Nowadays, cross-ply tyres are used only for:

• temporary use (emergency) spare tyres for passenger cars (due to the low durability requirements at speeds up to 80 or 100 km/h);
• motorcycles (due to the inclination of the wheels against the lateral force);
• racing cars (due to the lower moment of inertia);
• agricultural vehicles (which do not reach high speeds).

Cross-ply tyres consist of the substructure (also known as the tyre carcass, Fig.) which, as the ‘supporting framework’ has at least two layers of rubberized
cord fibres, which have a zenith or bias angle of between 20° and 40° to the centre plane of the tyre (Fig.).

Fig. - Design of a diagonal ply tubeless car tyre with a normal drop rim and pressed-in inflating valve.

469
Fig. - The diagonal ply tyre has crossed-bias layers; the zenith angle was 30° to 40° for passenger cars. The 4 PR design should have two layers in each direction. Smaller
angles can be found in racing cars. Rolling resistance, lateral and suspension stiffness are significantly determined by the zenith angle.

Rayon (an artificial silk cord), nylon or even steel cord may be used, depending on the strength requirements. At the tyre feet the ends of the layers are
wrapped around the core of the tyre bead on both sides; two wire rings, together with the folded ends of the plies, form the bead. This represents the
frictional connection to the rim. The bead must thus provide the permanent seat and transfer drive-off and braking moments to the tyre. On tubeless tyres it
must also provide the airtight seal.
The running tread, which is applied to the outer diameter of the substructure, provides the contact to the road and is profiled. Some tyres also have an
intermediate structure over the carcass as reinforcement.
At the side, the running tread blends into the shoulder, which connects to the sidewall (also known as the side rubber), and is a layer that protects the
substructure. This layer and the shoulders consist of different rubber blends from the running tread because they are barely subjected to wear; they are
simply deformed when the tyre rolls. This is known as flexing. Protective mouldings on the sides are designed to prevent the tyre from being damaged
through contact with kerbstones.
There are also GG grooves, which make it possible to see that the tyre is seated properly on the rim flange. Cross-ply design and maximum authorized
speed are indicated in the tyre marking by a dash (or a letter, Fig.) between the letters for width and rim diameter (both in inches) and a ‘PR’ (ply rating)
suffix. This ply rating refers to the carcass strength and simply indicates the possible number of plies (Fig. 2.5).
The marking convention is:

5.60-15/4 PR (VW rear-engine passenger car, tyres authorized up to 150 km/h)

7.00-14/8 PR (VW Transporter, tyres authorized up to 150 km/h)
9.00-20/14 PR (reinforced design for a commercial vehicle)

and on the temporary use spare wheel of the VW Golf, which requires a tyre pressure of pT = 4.2 bar and may only be driven at speeds up to 80 km/h (F
symbol)

T 105/70 D 14 38 F
(WIP)

Tubeless or tubed

In passenger cars, the tubeless tyre has almost completely ousted the tubed tyre.

The main reasons are that the tubeless tyre is easier and faster to fit, plus the inner lining is able to self-seal small incisions in the tyre.

In tubeless tyres the inner lining performs the function of the tube, i.e. it prevents air escaping from the tyre. As it forms a unit with the carcass and (unlike
the tube) is not under tensional stress, if the tyre is damaged the incision does not increase in size, and this avoids rapidly causing loss of pressure and
failure of the tyre. The use of tubeless tyres is linked to two conditions:

• safety contour on the rim

• its air-tightness.

Because this is not yet guaranteed worldwide, tubed tyres continue to be fitted in some countries. When choosing the tube, attention should be paid to
ensuring the correct type for the tyre. If the tube is too big it will crease, and if it is too small it will be overstretched, both of which reduce durability. In order
to avoid confusion, the tyres carry the following marking on the sidewall:

• tubeless (Fig. point 3)

• tubed or tube type.

Valves are needed for inflating the tyre and maintaining the required pressure. Various designs are available for tubeless and tubed tyres (Fig and ). The
most widely used valve is the so-called ‘snap-in valve’. It comprises a metal foot valve body vulcanized into a rubber sheath, which provides the seal in the
rim hole (Fig. 2.20). The functionality is achieved by a valve insert, while a cap closes the valve and protects it against ingress of dirt.

470
At high speeds, the valve can be subjected to bending stress and loss of air can occur. Hub caps and support areas on alloy wheels can help to alleviate this
(see Fig. and Section in R).

Height-to-width ratio

The height-to-width ratio H/W – also known as the ‘profile’ (high or low) – influences the tyre properties and affects how much space the wheel requires (Fig.
2.8).

As shown in Fig. 2.9, the narrower tyres with a H/W ratio = 0.70 have a reduced tread and therefore good aquaplaning behaviour (Fig. 2.35).
Wide designs make it possible to have a larger diameter rim and bigger brake discs (Fig. 2.10) and can also transmit higher lateral and longitudinal forces.

W is the cross-sectional width of the new tyre (Fig. 2.11); the height H can easily be calculated from the rim diameter given in inches and the outside
diameter of the tyre ODT. The values ODT and W are to be taken from the new tyre

(WIP)

Lateral and longitudinal slip

(wip)

Tyre load capacities and inflation pressures

The authorized axle loads mV, f,max and mV,r,max (see Section 5.3.5), and the maximum speed vmax of the vehicle, determine the minimum tyre pressure.
However, the required tyre pressure may be higher to achieve optimum vehicle handling (see also Section 2.10.3.5 and Fig. 2.44).

Tire wear

Each tyre compound has an optimal range of operation. When in this range, the tread provides the most adhesion. Cold tyres are not as adhesive. This is why
it is not uncommon to see even experienced drivers spin the car out, when they get aggressive with the throttle pedal, as they exit the pits on cold, new tyres.
Overheated tyres perform about as well as cold ones. The softer compounds operate in higher temperature ranges, and the harder ones a bit cooler. And the
softer tyres get up to operating temperature more quickly, but they also tend to overheat more easily. On the other hand, the harder tyres may not get up to
operating temperature at all, unless driven at an adequate speed. The medium compound tyres usually take a lap or two, before they reach their optimum
temperature.
The front tyres heat up rapidly, during corner-entry braking. And once on the straights, they cool down quickly, because they do not generate thrust forces
and because they are exposed to the airstream, especially on open-wheel cars. So, when braking hard at the end of a very long straight, realise that your front
tyre temperatures maybe below optimum.
The rear tyres heat up during acceleration, and they remain warm while travelling on the straights, since they must continually generate thrust. The only time
they may have a chance to cool down somewhat is when the rear wheels unload during braking. This difference in temperature profiles may create an imbalance
in traction between the front and the rear, when braking hard. Moreover, the brakes, especially the fronts, would also have cooled, while flying down a long
straight. Hence, a long straight that ends in a sharp corner can be tricky to get right, especially if the braking zone is on a downslope.

Driving the car much too aggressively can heat the tyres beyond their design limit, and damage their treads permanently. Aggressive driving rubs the tyre
tread against the carcass of the tyre, as well as the surface of the track. The excessive heat generated by this double whammy boils the rubber, and causes
air bubbles to form inside the tread. These bubbles expand with the rising tread temperature. A bubbling tread becomes uneven, so the wheel begins to
vibrate. Eventually, the tread gets too hot, and these air bubbles burst. When they blow, they take with them chunks of rubber, leaving behind a ruined tread
dotted with large pits. This condition is called blistering.
When the tyres overheat and start to blister, a wide, dark stripe forms on the tread, longitudinally. On an open-wheeler, the driver can not only feel, but also
see, the onset of blistering. He can see from the cockpit the dark stripes beginning to form on the front tyres. But by then, there is not much the driver could
do, but to plan for a pit stop. The lack of traction and the vibrations confirm that blistering is afoot. When faced with an overheating problem during the race,
the only option the driver has is to tone down the aggression, or return to the pit for a new set of tyres. Both options are undesirable. So, learn to save your
tyres by driving smoothly. And remember that softer compounds are more susceptible to blistering. Rain tyres are designed to heat up, even if the track is
cold and wet. As such, when the rain lightens up and the racing line begins to dry, rain tyres quickly overheat. In that case, driving over pools of water on the
track will cool down the tyres, thereby stretching them for a few more laps until the return of the rain or the return to the pit. But since AC does not model
wet weather, this bit of information is merely for your edification. The opposite problem of overheating is when the tyres will not heat up, because the car is
not driven fast enough. Tyres are too cold, so they do not provide a sufficient amount of grip, and without grip it is difficult to drive fast, so the tyres cannot
heat up. However, a driver with superior car-control skills can go fast enough in a twitchy car, so his tyres get up to temperature more quickly, and hence he
goes faster, all other factors being the same. Yes, life is unfair. Aggressively sliding the car about on cold tyres in hope of heating them up, however, may
create a bigger problem. Aggressive driving can twist the cold tyre beyond its slip angle design limit, before it has had a chance to warm up to the operating
temperature. This causes thin, parallel striations to form on the tread, longitudinally, due to the top layer of the rubber peeling away in thin strips, as the
rolling tread scrubs sideways against the track. These striations reduce the tyre’s traction capacity, making the car slide around more, thereby worsening the
problem. This phenomenon is called graining, because the parallel striations on the tread resemble wood grains. If allowed to progress, graining can destroy
the tread, permanently. But by backing off for a few laps to let the grainy top layer of the tread scrub off, the tyres may recover their traction capacities. Here
471
is a quick summary. Graining occurs on cold tyres. It makes the car feel slippery. Graining is temporary, and it will pass if the driver takes timely action by
toning down aggressive driving, until the tyres come up to operating temperature. Blistering occurs on hot tyres. It not only makes the car feel slippery, it
also vibrates the car. The deep pits on the tread caused by blistering permanently destroy that part of the tread. To encourage the cold tyres to heat up
quickly, the wheels can be installed in a pronounced negative camber, so that their tops are tilted inward. This forces the inside shoulder of the tyre treads to
be used more than the outside shoulders, thereby heating up the inner portions more quickly. The heat then propagates to the rest of the tyre tread. This
approach is not the best use of the tyres, however. A cambered wheel’s tyre has smaller contact patch area, so it generates less traction. And severe
cambering wears out the inside shoulder more quickly, thus shortening the tyres’ service life. Before the cars line up on the grid for a race start, they go
slowly round the track once, to conduct a final system check. During this installation lap, drivers briskly weave their cars about on the track. This side-to-side
movement rubs the tyres against the track, and heats them up in preparation for the launch. Drag racers have a different pre-race ritual, called the burnout,
which achieves the same effect: they spin their rear tyres, before lining up for the start.

472
Computational tire models

In vehicle dynamics, a tire model is a type of multibody simulation used to simulate the behavior of tires. In current vehicle simulator models, the tire model
is the weakest and most difficult part to simulate.

Why should we take a look at computational tire models? The answer is that we can look at a specific model and to Assetto Corsa’s one, compare them,
make our tire LUTs with it, see how they behave in AC and get realistic results, interpreting them while knowing that simulation tire models follow the
industry standard. This can actually lead to an amateur/enthusiast professional-grade production of tire behaviour for our simulator.

Introduction to simulation software and tire models

In recent years, there has been a tremendous push towards the simulation of complex systems. This, coupled with the growing desire by automotive
manufacturers to push the limits, has created an industry devoted specifically to automotive dynamic behaviour. In this industry, tires play a large role in the
actions of the vehicle. As such, the accurate modeling of said tires is critically important in obtaining accurate results. With the number of varying models out
there, it is typically a difficult decision. Tire models can be classified on their accuracy and complexity, in a spectrum that goes from more simple empirical
models to more complex physical models that are theoretically grounded.

Empirical models include Hans B. Pacejka's Magic Formula, while physically based models include brush models (although they are still quite simplified),
and more complex and detailed physical models include RMOD-K, FTire and Hankook.
Brush models were very popular in the 1960s and '70s, after which Pacejka's models became widespread for many applications.

Fully physics-based tire models have been typically too computational expensive to be run in realtime driving simulations. For example, to since CDTire/3D,
a physics-based tire model, cannot be run in realtime, for realtime applications typically an equivalent semi-empirical "magic formula" type of model, called
CDTire/Realtime, is derived from it through experiments and a regression algorithm.

In 2016, a slightly less accurate version of FTire, a physics-based tire model, was adapted to be run in real time. This realtime version of FTire was shown in
2018 to run on a 2,7 GHz 12 Core Intel Xeon E5 (2014, 22nm process, about $2000), with 900 contact road/contact patch elements, a sample frequency of
4.0 kHz including thermal and wear simulation.

The typical tire model sampling rate used in automotive simulators is 1 kHz. However, running at higher frequencies, like 2 kHz, might mitigate lowered
numerical stability in some scenarios, and might increase the model accuracy in frequency domain above about 250 Hz.

In January 2020 Cosin scientific software showcased that they were able to run their physical tire model FTire in realtime with rFpro.

Classification of the most important tire models by purpose:

Driving dynamics models

• Brush model (Dugoff, Fancher and Segel, 1970)
• Hohenheim tire model (physical approach)
• Pacejka Magic Formula Tire (Bakker, Nyborg and Pacejka, 1987)
• TameTire (semi-physical approach)
• TMeasy (semi-physical approach)
• Stretched string tire model (Fiala 1954)

Comfort models
• BRIT (Brush and Ring Tire)
• CDTire (Comfort and Durability Tire)
• Ctire (Comfort tire)
• Dtire (Dynamical Nonlinear Spatial Tire Model)
• FTire (Flexible Structure Tire Model)
• RMOD-K (Comfort and Durability Tire)
• SWIFT (Short Wavelength Intermediate Frequency Tire) (Besselink, Pacejka, Schmeitz, & Jansen, 2005)

This paragraph should help clarify the strengths and weaknesses of the major ones.

The software used to conduct these tests is Adams. Adams is one of the leading multibody dynamics simulation software. There is a module within the
software called Adams/Car which specifically handles vehicle dynamics. Within Adams/Car there are specific protocols that handle tire solutions. These
protocols utilize various models that have been created, or at least incorporated into the software, by the software’s manufacturer, MSC.
In February 2017, the company was acquired by Swedish technology company Hexagon AB. It operates as an independent subsidiary.

This software can be obtained from MSC’s website (http://www.mscsoftware.com) in both student and professional forms. The student version can be
obtained for free (with software limitations) after student standing has been confirmed, or the full version can be obtained at sizable cost, but there are
discounts for professors.

It is also necessary to have a computer capable of running the software. Exact requirements can be found on MSC’s website. The computer utilized during
these tests was a custom-made workstation specializing in demanding processing. It features 3 terabytes of hard drives, 16 gigabytes of RAM, and a 3.7 GHz
quad core processor.

The simulated vehicle used was a template provided by MSC software employees. It was not created under the direction of MSC but more as a side project
to help students who participate in Formula SAE to get started using Adams/Car in a reasonable amount of time.
473
The tire models used by Adams described herein include the PAC2002, PACTIME, PAC ’89, PAC ’94, 521, UA-Gim, and FTire. The first 4 of which use the
same basic approach but with slight variances. The 521 and UA-Gim models use a relatively more simplistic approach, and the FTire model utilizes a
completely different approach than any of these. The PAC models all work on the basic premise of research that was developed using what’s called the
“Magic Formula.” This is basically a curve fit that can be used to solve for things such as the forces and moments acting on the tire. The forces and moments
are the most important aspects that need to be modeled due to their impact on the vehicle performance.

Since these models vary significantly in their performance and applicability, MSC had provided a reference table designed to help decide which model to
use. That one is not the chart below. This new table was modified to reflect the findings of a study by Andrew R. Wheeler (University of Arkansas,
Fayetteville, Computational Tire Models and their Effectiveness).

MSC Software originally stated the best overall tire model was the PAC2002. Based off the findings stated within the study, this is not true. They are even
aware of the inaccuracy of the Pacejka models at low speeds, yet indicate in their table that it is best to use at these speeds. Such incongruities roused
suspicion initially. Once it was found out that the creator of the PAC models is MSC, it was clear that there may have been some bias.

MD Adams Event / Maneuver Adams / Handling Tire

PAC2002 PAC-TIME PAC89 PAC94 FTire 5.2.1 UA Tire
Stand still and start 2 2 1 1 2 3 2
Parking (standing steering effort) 3 0 0 0 3 0 0
Standing on tilt table 3 3 3 3 3 3 3
Steady state cornering 2 3 1 1 3 1 2
Handling Lane change 2 3 2 2 3 1 2
ABS braking distance 3 2 2 2 3 1 2
Braking/power-off in a turn 3 3 1 1 2 1 1
Vehicle roll-over 3 1 1 1 3 1 1
On-line scaling tire properties 3 0 0 0 1 0 0
ABS braking control 2 1 1 1 3 1 1
Shimmy 2 1 1 1 3 1 2
Chassis Steering system vibrations 2 1 1 1 3 1 1
Control Real-time 2 2 2 2 0 2 2
Chassis control systems > 8 Hz 2 0 0 0 3 0 0
Chassis control with ride 0 0 0 0 3 0 0

Based on the aforementioned research, it is contended that the FTire model consistently outperforms the PAC2002 model. Every test conducted resulted in
the FTire model being at or very near the average of all the results.

One complication that arouse during the initial stages of this research was how to determine the validity of the tests. Because there is no true result that can
be obtained via computation, the approach taken to determine the effectiveness of each model was to compare each individual result with the mean of all of
the results. Greater deviation from the mean would therefore imply a less effective model for that given test.
Several complications were encountered during the tests. The software used, Adams/Car by MSC Software, proved to be somewhat temperamental.
Sometimes simulations would run perfectly fine. The same simulation would try to be ran again with no changes and an error would occur. Sometimes,
certain models refused to run on certain courses. This is not due to incompatibility with the models and road, but to software inconsistencies. Examples of
this include the UA-Gim tire model not running properly on the skidpad test, but being the only one to provide realistic results on the fish-hook maneuver.

PAC2002 Tire Model

The PAC2002 Tire Model is the industry standard when it comes to computational tire/force interaction.
It is based off a book by a renowned vehicle system dynamics and tire dynamics Professor emeritus at Deft University of Technology in Deft, Netherlands
named Hans Pacejka. Over the past two decades, Pacejka has been designing tire models that have little to no physical basis or structure of the formulas
chosen. Because of this, they are commonly referred to as the “magic formula” models. During the solving process, each tire is characterized by 15-20
different coefficients that represent different forces exerted on the tire’s contact patch. Most of these can be seen in Fig.

474
Fig. - Basic notation for the road/wheel interaction. Directions shown are positive.

Generally speaking, a Magic Formula (MF) tire model describes the tire behaviour for roads with surface roughness of up to 8 Hz.
This characterizes most roads and makes the model applicable for situations including:
• Cornering at steady-state
• Single-lane change
• Braking (including split-mu and ABS)
• Most turning maneuvers
• Other common maneuvers on applicable roads

For vehicles with camber angles (𝛾𝛾) less than 15°, the PAC2002 tire model has also proven to be valid.
In pure slip conditions (cornering with a free rolling tire), both the longitudinal force, 𝐹𝐹𝐹𝐹, as a function of longitudinal slip, 𝜅𝜅, and the lateral force, 𝐹𝐹𝐹𝐹, as a
function of the lateral slip, 𝛼𝛼, have a similar sine-arctangent shape that can be represented by the general equation:

𝑌𝑌(𝑥𝑥) = 𝐷𝐷𝐷𝐷𝐷𝐷𝐷𝐷 {𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶𝐶[𝐵𝐵𝐵𝐵 − 𝐸𝐸(𝐵𝐵𝐵𝐵 − 𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎𝑎(𝐵𝐵𝐵𝐵)]}} (XXX)

where B, C, D, and E are constants obtained from curve fittings and 𝑌𝑌(𝑥𝑥) is either of the aforementioned forces with their respective independent variable.

The characteristic curves for these can be seen in Fig..

Fig. - Characteristic Curves for Fx and Fy under pure slip conditions.

Since this is by no means a regularly seen curve, a little more in-depth look at it is necessary. The coefficients in the MF each affect the curve in different
ways. The way the curve changes will directly change the force or moment being solved for. Fig. illustrates how these changes interact.

Fig. - The Parameters of the MF Explained.

Equation (XXX) is the standard form of the Magic Formula. It can be applied to more than just the aforementioned forces. Its other primary use is that of
solving for the moments acting on the tire in all 3 directions.

475
The movements of the vehicle are a direct result of the road forces on the tires. These forces are directly dependent on not only the tire’s properties, but also
the road’s properties. In this model, the tire is assumed to act as a parallel spring with damper (both linear) in the radial direction with a single point of
contact.
(WIP)

PAC-TIME Tire Model

The PAC-TIME model is a new version of the PAC2002 model. The only modification made is in the equations for the aligning moment 𝑀𝑀𝑀𝑀 and side force
𝐹𝐹𝐹𝐹.
(WIP)

’89 and ’94 Pacejka Tire Models

The ’89 and 94’ Pacejka models are also in the magic formula family. They are the older versions of the PAC2002 model. While the PAC2002 model has
been kept up to date, the ’89 and ’94 models have been mostly abandoned. They are still applicable and relatively accurate; so much so that they are still
included in the Adams/Tire software due to their continued use in the industry.
(WIP)

521-Tire Model

The 521-Tire Model is one of the simpler models in Adams. It utilizes only a handful of parameters and experimental data. One of the primary benefits of this
model is its flexibility. It can solve for the moments and slip forces using two different methods. These methods are the Equation Method and the
Interpolation Method. The Equation Method utilizes a set of generalized equations based off research done in the 1990s while the Interpolation Method uses
an AKIMA spline to calculate the forces and moments relative to the camber, slip, or vertical load. The basic notation of this can be seen in Fig.

Fig. - Directional vectors of the 521-Tire model.

MSC states that this model has been superseded by newer tire models and recommends the use of these other models for more accurate work. They state
that this model is only included for backwards compatibility.

UA-Gim-Tire Model

The University of Arizona Tire Model, abbreviated UA-Gim tire model, was developed based off the research of Dr. Gwangun Gim. His thesis, Vehicle
Dynamic Simulation with a Comprehensive Model for Pneumatic Tires, originally published in 1988, prompted MSC to create a computational tire model in
their Adams software. The model calculates the forces and moments at the contact point as a function of the tire’s kinematic states. One of the new concepts
presented by Dr. Gim was that of the Friction Circle.
Seen in Fig., it limits the total friction achieved by the wheel/ground interface but allows for different values of the longitudinal and lateral friction. For
example, if 𝜇𝜇𝜇𝜇 is at its limit (greatest braking or acceleration in the longitudinal direction without slippage) then no lateral forces can occur without resulting
in slip.

Fig. – The Friction Circle.

476
FTire Model

The final model to be discussed is the FTire Model. The FTire, or Flexible Ring Tire Model, varies significantly from most other models. No form of the
magic formula is used. It relies almost exclusively on analytical means to solve problems using classical mechanical and thermodynamic approaches.
Instead of using lengthy pre-processing of the road data, it simply resolves road data as it is defined. This allows the model to be used as a more effective
means for analysing ride comfort and modeling the reactions on harsher terrain. An example of a harsh ride comfort simulation can be seen in Fig..

Fig. - Harsh terrain capabilities of FTire.

This model was created and is kept up to date by Cosin Scientific Software. MSC Software incorporates its solving capabilities into Adams.

The approach taken by the FTire model is similar to finite element analysis. The belt of the tire is described as a ring with elasticity and stiffness properties. It
is broken up into subsections and given degrees of freedom for movement. They are connected to each other by what can be represented by a spring (Fig.).

Fig. - FTire bending stiffness representation.

These connections are used to represent the tire’s bending stiffness. A similar approach is used for torsion and lateral bending. Because of the complexity of
this model’s approach, it takes a significantly longer time to simulate. It is also suggested by the manufacturers to use a minimum of 1000 steps per
second for the integrator. This is due to the high resolution of the model and the way it was developed to deal with tire vibration and road irregularities.

(WIP)

PAC 96 tire model used by netKar Pro.

477
34. wing_animations.ini
This config file can be used to add animations for the active wings of the vehicle. It can also be re-purposed for other parts. The movement can be managed
thanks to the controllers present in aero.ini.
[HEADER]
VERSION=2

[ANIMATION_0] ; Wing animation identifier. SYNTAX: [ANIMATION_ID], ID starting from zero.

WING=3
TIME=0
FILE=WING_L.ksanim ; Specifies which animation file to use for the specific wing.
MIN=0
MAX=80
NEXT=1
SPEED=4
INVERTED=0

% ▼ As you can see below, not all the parameters are required, it depends on the result you want to get.

[ANIMATION_1]
WING=4
FILE=WING_R.ksanim
MIN=0
MAX=50

[ANIMATION_2]
[ANIMATION_3]
[...] ; A vehicle can have as many [ANIMATION] as necessary.

LITTLE EXPLANATION
- To add the movement of the air intake butterfly valve opening and closing when the throttle is pressed (Fig.), create the animation for it (simple rotation
around the throttle blades axis with just two keyframes should be fine), then export it the same way you would any other animation like doors or wipers
(@Stereo 's add-on makes it way easier).

Fig. -

Subsequently add a wing element in aero.ini and its [ANIMATION] in wing_animations.ini, with the respective WING number. You can link the movement
to throttle actuation with a controller in the aero.ini file.

478
CHAPTER 12 – ADJUSTMENTS DURING / AFTER A RACE SESSION
This chapter is dedicated to everything you can do within a race session to observe, check and debug any desired or undesired behaviour of your vehicle.

12.1 – AC DEBUG CONSOLE COMMANDS (LIVE FIX)

Lights (front, rear, brakes), flames, digital instruments, display panels and the ground collider can be adjusted with real time in-game feedback, using the
built-in debug console commands.

Press the HOME button on your keyboard to open the AC command window (Fig. 7.0). Please note that with CSP comes an option to deactivate the console,
so if you can’t open it, check the Custom Shaders Patch settings.

Fig. 7.0 - The AC debug console.

Type after the set command one of the functions below to enter edit mode, where AC will display real-time any adjustments in the data files.
• set observeLights [value] ; enables edit mode for lights.ini
• set observeFlames [value] ; enables edit mode for flames.ini
• set observeDigital [value] ; enables edit mode for digital_instruments.ini
• set observePanel [value] ; enables edit mode for digital_panels.ini
• set editBoxes [value] ; enables edit mode for colliders.ini

% ▲ [value] can be 1 (AC will read the new values in the config files) or 0 (AC won’t read the changes in the scripts; this is the default value).

The commands and functions are case sensitive.

When [value] is set to 1 (Fig. 7.1), any change to the lines of code in the respective config file will appear in the game real-time. For example, if you edit
the colour of headlights in lights.ini, with the set observeLights command you will see the colour change in-game.

Fig. 7.1 - Just type the number directly after the command, you don’t need brackets or other symbols.

The set command is multi-purpose however, and can also be used with this syntax: set [var] [value] and the following variables (case-sensitive!):
• set axisMode
• set sunHeading
• set sunPitch
• set hideGroove
• set hideHead
• set headRoll
• set headPitch
• set headYaw
• set headMaxG
• set headFilter
• set lodDebug ; Shows info on screen for which vehicle LOD is currently active and its coordinates. [Boolean]

479
• set debugDamage
• set steerAssist
• set FUEL_STEP ; Overrides the same parameter in analog_instruments.ini for debug purposes.
• set FUEL_ZERO
• set FUEL_MIN
• set RPM_STEP
• set RPM_ZERO
• set SPEED_STEP
• set SPEED_ZERO
• set wATER_STEP
• set WATER_ZERO
• set WATER_MIN
• set debugDirt
• set exposure
• set editCMesh
• set restrictor
• set fov
• set aniso
• set driverEye.x
• set driverEye.y
• set driverEye.z
• set graphicsOffset.x ;
• set graphicsOffset.y ;
• set graphicsOffset.z ;
• set graphicsPitchRotation
• set bias0
• set bias1
• set bias2
• set ffMult
• set maxLayer
• set AUTOFLIP_RECOVERY
• set DISABLE_SHOW_MODE
• set PROVIEW_MODE
• set RENDER_SPLINE
• set aiSteerGain
• set aiPush
• set aiLookAhead
• set aiLookAheadSpeed
• set freeCamFov
• set freeCamDof
• set freeCamDofFocus
• set freeCamExp
• set freeF5 ; The F5 camera is movable with the mouse and arrow keys, but still attached to the vehicle. [Boolean]
• set minExposure
• set mirrorpos.x
• set mirrorpos.y
• set mirrorpos.z
• set shadowBias
• set hdrHPLevel
• set hdrBloomLevel
• set hdrBloomBaseLevel
• set bodyDamageLevel0 ; Specify the amount of damage for the front bumper (if damage.ini is properly set). It is cumulative.
• set bodyDamageLevel1
• set bodyDamageLevel2
• set bodyDamageLevel3
• set bodyDamageLevel4
• set engineDamageLevel

In the variables above the [value] parameter will often work as a Boolean (0=false, 1=true) like in Fig. 7.1, but there are exceptions, where you will be
allowed to input numbers.

Remember that the changes done from the console are not saved: the commands are mostly for debug purpose, so they can help you finding correct
parameters which you’ll have to remember or write down on a piece of paper; try for example the ’set RPM_STEP 10’ command and look at what the
gauge on the car dash does.

Other commands are the following:

• getSteerAssist ; Returns the current steer assist setting.
• refresh_instruments ; No parameters needed.
• testCrash ; Initiates an AC session crash for testing purposes.
• saveff ; Saves the current ffMult value in car.ini
• rSsA ; Resets the Steam Achievements.
• help ; Displays the available commands in the console. Can be used to list other functions (e.g. set help).

Pro tip: some people may want to use a shader injection tool called Reshade; just avoid binding the HOME key to the opening of its shaders’ configuration window, because
the AC console will open every time and it will be annoying, unless you use CSP and deactivated it in the mod’s settings.

Are there any other commands? Yes, in the code there are PLUGIN functions, but Kunos didn’t reveal nor document them.

what is acnotify.py?

480
12.2 - AC DEBUG LOGS (wip)
- Python has its own log: py_log.txt
- race.ini and race_out.json are printed in log.
- Go to %ROOT%/system/cfg/assetto_corsa.ini, change WARNING_AS_ERRORS=1. With this setting, the game will always crash for the smallest errors and
write down the errors towards the end of the user Documents/logs/log.ini file.

12.3 – APPS
What are apps in Assetto Corsa?
Apps are part of the UI and HUD in any race session of our simulator. When you start a session, move your mouse to the RIGHT SIDE of the screen to reveal
the list of all the awesome APPS the game has to offer. Simply click on the respective icons to open them.
You are free to move them anywhere on the display. Even on a different monitor, if you have a double or triple-screen setup. They can be fixed in place and
closed whenever you want (Fig. 7.2). The interface becomes quite modular.

Fig. 7.2 – AC makes no compromises in terms of customization.

You can choose from a multitude of apps that display a variety of information. Exactly how much and how detailed that info should be, is up to you.
Assetto Corsa has a completely moddable interface, you can change any icon quite easily indeed. Some mods recreate the look of other games, like Gran
Turismo or Forza, or even the graphics of the official F1 leaderboards. If you want a fresh experience, you just need to search a bit in the world of AC mods.
Keep in mind that apps have always been fps-hungry. Since the early days of AC opening apps has always had an impact on the rendering performance.
That’s part of the reason why the main apps are really clean and sometimes quite spartan, but they do their job well.
We can divide apps in two categories: basic, mostly useful while driving as Head-Up display (HUD), and developer apps, very useful while making mods, as
debug tools.

12.3.1 - BASIC APPS AND HUD

This paragraph is dedicated to basic apps, the ones that the common user usually sees during his normal driving routine. The info these apps give is simplified
and mostly in the form of a graphic visualization output, because if you aren’t a skilled driver and you just want to have fun, you don’t need detailed specs (for
example, you just need to know that the accelerator pedal is working, not its percentage).
The following are the most important basic apps you will find:
1. Essentials
2. Gears
3. Pedals
4. Track map
5. Onboard settings
6. Graphic stats
7. Render stats
8. k

Let’s take a look at each one of them, analysing each parameter displayed.
1. Essentials

2. Gears

Simple, yet very nicely made and quite fancy.

481
 White arc: RPM
Red arc: Turbo boost
Blue arc:
Green arc:
Yellow arc:
Center number: Selected gear
Lower number: Current speed + unit (kmh/mph)

Fig. -
3. Pedals

Blue indicator: Clutch pedal input

Red indicator: Brake pedal input
Green indicator: Throttle pedal input +
Grey indicator: FFB (Force Feedback)

Fig. - Be sure to set your FFB gain in such a way, that it doesn't “clip”, so the bar not to turn red the majority of the time.

4. Track map

track_map.jpg

Look at the map while exiting the pitlane or returning onto the track from an off-road.

5. Onboard settings

Adjust your seating/view position, FoV and pitch. These settings will be saved individually by car. You may raise your seating position to improve your view
out of Formula cars.

You can't save car.ini and Dash for cars with encrypted data folder like the Kunos McLaren in your screenshot. Those two buttons are supposed to be used
when making cars (and don't usually show up with data not being editable).

Does it save the view position on a per car basis? Yes, if you use that app it applies changes only to the car you're in.

482
6. Graphics stats
Parameters:

UPD:
REND:
HUD:
PHYS:
CPU:
AUDIO:
DIFF:

7. Render stats
APP for physics

DIP and B.Size are the most relevant numbers to tell if you have roughly the right object size (dip is total # objects,
b.size is their average polycount) TRI tells you how much is actually getting rendered, splitting up objects and
setting LOD distances appropriately brings that down.

PHY is the percent of a physics frame (3ms) it takes for the cpu to finish calculating physics.

PHY_LATE is number of frames that finished calculating after the real time they were supposed to be done... if it's a
temporary spike it'll just add 1, it'll be counting up if your game can't run at 100% speed.

Time of day
timeofday.jpg
Time of day does advance in SP and does not in MP (as of 15.08.14)

12.3.2 - DEVELOPER APPS

These are the most powerful tools you can get from any game session. A lot of data is displayed on these utilities, so don’t miss them, because they’re usually
hidden from commoners and nerds. You’ll have to enable them if you want the benefits of their power. How is it done?

Go into the AC install folder: %root%\assettocorsa\system\cfg and open assetto_corsa.ini with a text editor, then find and edit the following value:
[AC_APPS]
ENABLE_DEV_APPS=0 ; Enables/disables developer apps; =1 to enable, =0 to disable (default value).

About the root folder at par. 2.3 of the AC User Guide at the beginning of this manual.

The following are the most important dev apps you’ll have to use:

1. AI app
2. Camera editor
3. Car physics
4. Graphics stats
5. Setup debug
6. Suspensions
7. Tyre debug
8. Tyre tester
9. Wings app

Let’s take a look at each one of them.

483
AI app
The AI app (Fig.) is very useful to configure the artificial intelligence parameters of the single vehicles, but it’s fundamental for the creation of track AI splines
and testing the virtual opponents in general.
Normalized Pos:
Target Steer Distance:
Points count:
Interpolation Mode:
Outside offset:
Gas Brake Target
IS grid on:
Prj RPM:
Distance from target:
BASE:
NCM:
DTNC:

Graphs:

Start recording:
Start pits:
Save cons:
LAT_OFF: Lateral offset
XX1: Speed the AI wants to brake at. [km/h] XX2: Current speed of the AI. [km/h]
XX3:
D: stands for distance. It represents how many meters are left before hitting the XX1 speed.
If the D value is positive before a corner, the AI managed to brake faster (earlier) than it “thought”, so you
have to do is bring up the Brake hint.
Magic:
CP:
aiPush:
Steer LA:
Steer gain:
Aero hint:
RPM gear up:
Gear down %:
Brake hint:
Tyre hint:
Save AI:
- Trail hint is missing from the app. In a video of development by Stefano Casillo we see eight boxes in the lower part of the app, not seven. Why was it
removed?

- While the car is in self-driving mode (enabled with Ctrl+C in any session except practice), it is possible to edit many of the ai.ini parameters directly live in-
game. When the AI has the control of your car, it runs at 100% strength, so it’s got no oscillation in the hint levels. That’s why the self-driving AI is not identical
to the opponent cars’ one, which can't be put on the player’s car.
- If the AI goes too wide in a corner, the brake hint or the TRAIL_HINT (the latter in the ai.ini) may be too high. Usually 30 is a good starting point for
every car. Move them from there.

Pro tip: when working on the car-specific AI parameters, be conservative: there is no point in spending too much time trying to optimize one track. The fact that the system
works well on one map doesn’t mean that it will translate well on other circuits or other conditions (e.g., temperatures).

484
Camera editor

Fig. – car with packed data.acd

Edit vehicle cameras with the app

-save dash only appears if you unpack data

485
Car physics
Parameters:

SM: Tyre compound short name as in tyres.ini (in this example, Slick Medium).
CGH: sprung mass CG (center of gravity) height from ground (GH = ground height) in meters [m];
DY F: tire grip level (front of the vehicle)
DY R: tire grip level (rear of the vehicle)
LD0: current vertical load Fz for tire LF in Newtons [N]
LD1: current vertical load Fz for tire RF in Newtons [N]
LD2: current vertical load Fz for tire LR in Newtons [N]
LD3: current vertical load Fz for tire RR in Newtons [N]
DISTR: Weight distribution of the car as a percentage on the front axle.
SA LF:
SA LR:
AVEL_Y:
GLAT: lateral acceleration in Gs: [G]
GLON: longitudinal acceleration in Gs: [G]
DI: dynamic index of the vehicle; inertia related
DSPEED:
BOOST: turbo boost pressure in psi?
VKM F: slip distance in kilometres (front of the vehicle); slipping laterally will add more vkm than slipping longitudinally
when traveling forward
VKM R: slip distance in kilometres (rear of the vehicle); same as VKM F
AP: air pressure (you can do all of your aerodynamic calculations and evaluations with this value)
ELIFE:
BOV: turbo blow off valve
DYN_TRK: current grip level on track in percent (0.963 means a grip of 96.3% and so on)
BOOST: turbo boost pressure (again?)
GRAIN F: Front tires graining
GRAIN R: Rear tires graining
BLISTER F: Front tires blistering
BLISTER R: Rear tires blistering
FLAT L: Tire LF flat-spotting
FLAT R: Tire RF flat-spotting
KERS:
KERS_KJ:
CONS: fuel consumption of the vehicle for AI calculations, saved by AI app (save fuel cons button)
NCP:
RPM: rotational regime of the vehicle’s engine in [RPM], rotations per minute
FSPEED:

486
Setup debug

AIR PRESSURE #: Single tire pressure in [bar]; 0 is, 1 is, 2 is, 3 is

camberRAD #:

camberDEG #:

accG:
engineRPM:
limiterRPM:
isEngineLimiterOn:
steer:
gas:
brake:
clutch:
gear:
cgHeight:
worldPosition:
velocity:
Tyre Comp.:
lapTime:
lastLap:
bestLap:
lapCount:
performanceMeter:
FUEL:

AEROMAP:

ROD LENGTH #:

GEARS #: Gear ratios of the vehicle, user-defined in drivetrain.ini or through

transmission-related files (.rto); affected by setup choices.

FINAL RATIO: Final gear ratio, user-defined in drivetrain.ini or through

transmission-related files (.rto); affected by setup choices.

wheelAngularSpeed #:

slipAngle #:

slipRatio #:

load #:

tyreDirtyLevel #:

suspensionTravel #:

ndSlip #:

487
Suspensions app

Coordinates

GRAPHS (four corners): Slip angle; if violet line is perpendicular = none.

SA: Slip angle. STR: Steering angle, zero is neutral. [deg]

SR: Slip ratio. CASTER: Front wheels castor angle. [deg]
C: Camber angle relative to the road surface. [deg] KPI: King Pin Inclination. [deg]
T: Toe angle. SCRUB: Scrub radius. [mm]
Yellow/red bars: Slip ratio/angle graphs for each wheel (red=100% slip).
If you stop pressing the gas and brake pedals, they'll all even out.
If your car is RWD for example, there will almost always be more slip ratio on the rear than the
front - it is normal.
Tire visualizer (red=hot): Tire temperatures are plotted on a 3x12 array for each tire; the top row is
inner, bottom row is outer, and it goes around the radius of the tire.

IMO [ℕ1 ℕ2 ℕ3]: Instantaneous Inner / Middle / Outer tire temperatures. Race car engineers
measure temps in these zones across the tread.
I: Vertical load on the tire
P: Instantaneous tire pressure. [psi]
CP: Contact point

Vertical white graph: Rear bumpsteer. It is toe gain on bump and rebound.

Fig. –

- Keyboard shortcuts:
• Numpad 1-4 keys toggles the wheels' physics locations (vs. graphics locations.): 1 is WHEEL_LF, 2 is WHEEL_RF, 3 is WHEEL_LR, 4 is WHEEL_RR.
• Pressing backspace on your keyboard toggles the suspension linkage visualization ON/OFF.
• Pressing Ctrl (left/right) or Alt Gr on your keyboard toggles the

- Front wheels on a racing car are typically installed with a pronounced negative camber. The front camber counteracts the front suspensions’ tendency to tilt
the top of the outside-front wheel outward, in response to corner-entry load transfer. If the car is not set up properly and hence cannot be driven hard through
the corners, the outside edge of the front tyres will not be used as much. The inside edges will accordingly be hotter. Hence, the IMO temps are a crude but
effective way to diagnose poor setups, and sometimes poor driving techniques as well.

At lower tiers of racing, the engineers have no real-time telemetry data of the car’s performance parameters; the only information they possess when setting
up the car are the tyre temperatures and the driver’s feedback about the car behaviour. The engineers obtain tyre temperatures by sticking a probe into the
tyre tread at inner, middle, and outer areas. The engineers sometimes employ the same probe on the driver forcibly to extract feedback, when the driver is not
forthcoming with the information upon his return to the pit.
Pro tip: do not use the Suspensions app during replays, as the physics are not calculated. If you were to do this inadvertently, you might encounter situations similar to what
you can see in Fig. below.

Fig. - Phantom axle, detached from the car and refusing to follow it when the cameras roll. The app sticks to the most recent frame that was simulated.

488
Tyre debug

Fig. -

Tyre tester

Fig. -

489
Wings app
Here's a screen of the Wing App in action with the Mercedes AMG GT3 (Fig.). I chose that as I know the GT3 class is very popular, and it has a widely used
setup (body, front, rear wings and diffuser, some other cars have many more or less, but this is quite common and easy to understand).
I'll start from the left column on top.

NAME: Name of the wing, as specified in aero.ini. With the app open, you can see the wings that these refer to
displayed as green rectangles (or red if it’s a fin, I think).
AOA: That is angle of attack, basically the angle of the wing is relative to the air. Usually the body is a positive, but
can be a negative under heavy braking, depending on the car. This is live, so although your rear ring may be set
at 10 degrees, it could well be 9.5 degrees or 11 degrees, depending on the cars current position and rake angle.
GH: Ground Height, so height in [mm] of the element relative to ground. Very useful for noting when the front
wing or diffuser might start to stall. The front splitter and the rear diffuser perform differently depending on the
height.
CL: Coefficient of lift (or downforce) times wing area. It represents the lift or downforce you are producing real
time for each wing. Use this to help decide how much wing angle you want (along with CD). This number is pulled
from the aero files and will vary live, depending on angle and height for splitter and rear wing/diffuser. If the wing
stalls the number will drastically decrease.
CD: Coefficient of drag times wing area. Same as lift but it's drag force. Useful for knowing if the wing changes
you make are efficient (i.e., you get a good amount of downforce against drag). You might find that the very high
wing settings only add drag, not downforce, so keep an eye out.
°: Angle of the wing in degrees. This is just the static angle, so is not affected by the live pitch of the car.
YAW: The yaw angle of each wing relative to the air. Not super useful, but since most wings are affected by yaw
angle (they become less efficient), you can monitor this, though I've never been in a situation where this was
necessary.

Fig. – The Wings app.

On the bottom row AC will do the sum of all the CL and CD of the wings; put those in your formulas that will include element width, car speed and air density
and then you will know the total lift and drag in kgs of force. It also gives you the forces repartition (aero balance) between front and rear axle in %.
TOT CL: This is the total Coefficient of Lift taking into account all wings. Very useful for getting a quick and easy picture of how much downforce you have.
@ XX% front: This is your Aero Balance, very handy for setting the car up. The percentage shows ratio of generated downforce (how much of the total downforce is pushing
down the front axle). Generally you want this to match your weight distribution (that’s at least a good starting point). For most cars this is fine anywhere between 40% and 50%.
The real center of pressure is a little bit less (3-4% rearwards) because the drags of the aero elements increase rear tyre load and reduce front tyre load (squat).
Note: drag forces do have an impact on wheel loads, only the app does not include them in lift repartition %.
TOT CD: This is the total Coefficient of Drag taking into account all wings. Very useful for getting a quick and easy picture of how much drag you have.
EFF: The aero efficiency: lift divided by drag =CL/CD. The higher the better, as it means you have more downforce per quantity of drag. On some tracks (like Monaco) you can
sort of forget this and go for maximum drag, but it’s important for most tracks. A lift to drag ratio of 7 is not reasonable for any car. Modern LMP1 cars max out at around 4.9,
GT2 cars around 3, F1 cars around 2.9.
TOT(KG) DOWNF: This is your actual amount of downforce in KG - though its not as easy or useful to read at the CL because it changes with speed. Only really useful for
modding, if you have data that states a certain amount of DF at X speed, otherwise just use the CL.
TOT(KG) DRAG: This is your actual amount of drag in KG - though its not as easy or useful to read at the CD because it changes with speed. Only really useful for modding, if
you have data that states a certain amount of Drag at X speed, otherwise just use the CD.
- The drag/lift values (CD & CL) you see at the AERO app are total values. The drag/lift coefficients of the car are multiplied by the frontal area (CdA & ClA).
That’s one thing to note as you try to compare the CD in the wings app to the drag figures you may see published.
The frontal area of modern cars is around 2 (small variations make a difference) and that's why you may think that in AC all the CD values are x2. But you
are wrong. As a litmus test, for example:
In the aereo.ini you can have a wing with the following specs: And you'll need a wing_body_AOA_CD.lut:
NAME=BODY -10|1
CHORD=1 0|0.31
SPAN=1.81 2|0.32
POSITION=0,0.23,0 5|0.34
LUT_AOA_CL=wing_body_AOA_CL.lut 8|0.36
LUT_GH_CL= 10|0.38
CL_GAIN=1.0 12|0.50
LUT_AOA_CD=wing_body_AOA_CD.lut 14|0.51
LUT_GH_CD= 16|0.53
CD_GAIN=1.0 20|1.00
ANGLE=0

This way your CD at 0 angle will be 0.31; multiply this by the frontal area: CHORD ∙ SPAN = 1.81; multiply the CD with frontal area: 1.81∙0.31 = 0.56,
so 0.56 is the number you will see in the Wings app in-game and it is the total drag.
Pro tip: the two main things to watch and maximize on Kunos aero cars is the FRONT CL and DIFFUSER CL. They will always grow as the car gets lower and lower up to a
point they will drop sharply when GH gets too small. The goal is to keep these two elements near their maximum CL as much as possible.
In AC a common thing in GT cars is that if you lower the front too much you may lose your front downforce when you hit the brakes hard at the end of a straight.
Such thing generally does not happen in real life, only for certain designs but not for conventional splitters (at least not until you reach much lower heights than in AC, where
they seem to stall at 3 cm from the ground). Finetuning ride height is one of the things the app helps a lot with.

490
12.3.3 - FAQ
QUESTION [1]: How do you guys use the apps for physics debug? I mean do they work in replays or do you glimpse them while driving? And if while
driving, is it necessary to really push the car to get correct readings?
ANSWER [1]: Hey, these are two questions in one. Slow down, kid.
Some guys can concentrate on the live readings while driving but for the people (like me) who can't there's the telemetry dump that can be opened with
RaceStudio.

1. Make sure you have set DEBUG_PHYSICS=1 under [TELEMETRY] in Steam\steamapps\common\assettocorsa\system\cfg\assetto_corsa.ini so you have all
telemetry channels in the telemetry dump file.
2. Download RaceStudio, open RS2 Analysis and import telemetry_dump.act from your user Documents\Assetto Corsa\aim using import Assetto Corsa file.
3. Now you can choose the aero channels you want and it will plot a nice curve for the laps you have selected.

Alternatively, you can use Motec for live telemetry, but we will talk about it in the next Paragraph. And if you dont trust the apps, simply check telemetry.

Finishing with the second part of the question, there is no need to be pushing 100% while driving. For example, regarding the Wings app, the wings’ height
won't change much if you are 5-10 km/h off your normal speeds. No need to constantly monitor it either. Fast corners and hardest braking zone of the track
are the spots where you want to be glancing at it.

491
12.4 – TELEMETRY
Due to the difficulty to gain real life racing experience, many sim-racers have little to zero knowledge about what is needed to improve their own
performance on the track. Studying and reading are never a foolish thing, and racing and sim-racing are not exceptions.

One of the best ways to analyse and understand whether your own and your vehicle’s behaviour is good or not is the same used by all kinds of racing
teams: telemetry.

,.bkvjhdhfgd yeeeeeahh

Fig. – The telemetry interface of the MoTeC i2 Pro software with data taken directly from an AC race session.

12.4.1 – WHAT IS TELEMETRY

The level of technology that today's motorsport world has reached means that engineers, technicians, drivers, insiders and even fans are increasingly talking
about telemetry. All the data that a racing car is able to generate on the track is meticulously analysed by professionals to find those precious tenths of a
second that make the difference between winning a race... and finishing behind your opponent.

All of this, of course, has also become an integral part of the world of sim-racing, where the quest for performance is now closely linked not only to driving
precision, but also to the meticulousness with which the data collected from a training session on the (virtual) track is studied and interpreted. At this point,
therefore, curiosity reigns supreme: what is telemetry really? How does it work? What is its history?

Let's start this new journey by answering the first question: what is telemetry?

In a nutshell, this term identifies a system capable of collecting remotely a whole series of data (physical quantities) on a racing car that track engineers then
analyse in detail. This ranges from speed to the G-force experienced between corners and acceleration, from the travel of the gas and brake pedals to the
temperature of each individual tyre, from the steering angle to the presence of oversteer or understeer in a given part of the circuit.

The stopwatch can be considered the first rudimental form of telemetry: you’re measuring the time taken to complete each lap on a circuit.

The purposes of telemetry are multiple: on the one hand, the data collected during a track session serves to constantly monitor the various parameters of the
car in order to consolidate the reliability of its components. On the other hand, telemetry is used as a valuable tool to analyse in detail the performance of the
car-driver system from lap to lap, or to compare the performance of a driver with an opponent or, more frequently, with his teammate.

Generally speaking, telemetry is used in every series that makes up the world of motorsport: from karts (in a simplified way) to GT, from prototype categories
to single-seaters... and, of course, Formula 1.

Over the course of time, the top championship series has always been used as a testing ground for various mechanical, electronic and aerodynamic
solutions that have subsequently found their way into other series or the automotive world. Just think, for example, of traction control or, more recently,
energy recovery under braking, today the cornerstone of the most important electric and hybrid cars.

492
Telemetry, in this case, has not been outdone: it was introduced in Formula 1 towards the end of the 1980s and since then has been developed hand in
hand with electronic driving aid systems, permitted and then banned several times over the course of the various seasons. Its use was initially mono-
directional and the sole responsibility of the driver, who could make certain adjustments (such as braking distribution or engine power level) via the 'knobs'
and 'selectors' on the steering wheel.

Then, at the beginning of the 2000s, the FIA allowed the use of bi-directional telemetry: instead of the driver, at that time it was the engineers from the pits
who controlled the various parameters of the single-seater, varying what was most needed depending on the situation on the track. In this way the driver
could concentrate solely on driving, having at his disposal a car that, theoretically, was practically perfect in every sector of the track.

Just as happened in 1993 with Alain Prost's Williams-Renault FW15C and later in 1994 with Michael Schumacher's Benetton-Renault B194, which were
challenged for all those electronic aids that gave them a considerable advantage over their rivals, in 2003 the Federation backtracked and banned bi-
directional telemetry, once again bringing into focus the importance of the driver as the sole protagonist of his own performance on the track.

Today, telemetry, therefore, has become a very powerful tool with which Formula 1 teams keep an eye on what is happening on their single-seaters, sending
all the relevant communications to the driver on what to change on the wheel in order to be competitive in every corner and sector of a circuit.

12.4.2 – HOW DOES TELEMETRY WORK

Always taking the top series as a reference, each Formula 1 car is equipped with a special data collection unit, which is connected to a series of sensors
located on the various components of the car itself: engine/power unit, tyres, gearbox, suspension, pedals, front and rear wing and many others.

On each lap of the track, such a car is able to collect up to 35 megabytes of data through its sensors, totalling around 30 gigabytes of information over the
course of a single race weekend. The sensors, specifically, analyse various physical parameters of the single-seater in real time, which are then transmitted
to the control unit which, in turn, sends them to the track engineers' computers via the antenna positioned on the front nose, or using the various
transmitters located in specific parts of each circuit on the calendar.

At this point, the pit wall has received all the data in question in real time, suitably encrypted and ready to be analysed. (one of) The software used to
interpret them is currently developed and supplied by McLaren Applied Technologies and is called ATLAS, which stands for Advanced Telemetry Linked
Acquisition System (Fig.).

Fig. – The ATLAS Express software in all of its glory.

On a practical level, this programme looks very much like an Excel worksheet, containing a series of tables and graphs showing the parameters collected by
the sensors on the single-seater.

493
But what are the parameters that the engineers of an F1 team are constantly analysing on a single-seater? Through ATLAS, the values that are kept under
observation approach a thousand and require up to a hundred people, either directly on the track or 'remotely', to monitor them effectively and efficiently.
This is, of course, a choice, because it would be impossible to monitor, moment by moment and during the entire race weekend, all the parameters of such
a racing car.

Usually the telemetry parameters are obtained through a very precise sampling frequency: those of the transmission, for example, are obtained at a cyclic
rate of 200 Hz, so the data is acquired two hundred times per second. In the case of unusual vibrations that may lead to possible malfunctions, however, the
frequency is increased to 10 kHz in order to achieve even higher sampling accuracy.

The most common parameters that are monitored through telemetry systems are as follows:

• Speed
• Engine revs
• Steering angle
• Brake pressure (front and rear)
• Braking distribution
• Throttle use
• Engaged gear
• Level of understeer/oversteer
• Inflation pressure of each individual tyre
• Operating temperature of each individual tyre (inner, outer and middle)
• Lateral and longitudinal G-force
• Hydraulic system pressure
• Internal engine temperature
• Engine mapping (ERS)
• Aerodynamic load (downforce)
• Number of revolutions
• Fuel load
• Delta last lap
• Use of DRS
• Wind incidence (speed and direction)
• Plank load cell: any contact of the wooden skid on the bottom of the car with the ground

On every Formula 1 race weekend, therefore, a single-seater is constantly monitored in all its parts: specific engineers study a specific component and
communicate any anomalies and useful information to the track engineer in order to improve performance on the track. In all of this, however, the difference
is still the driver's job: he too has the ATLAS software at his disposal and can present his requests and feelings to his engineer, so that he can solve, for
example, understeer in a corner or perfect the car's entry in another part of the circuit.

The gyroscopes, accelerometers and all the sensors with which a racing car is equipped, in fact, are only able to detect data, but are not currently capable of
assessing whether what they have acquired is a parameter that goes in the direction of maximum lap performance or not. The values for understeer and
oversteer, for example, are an end in themselves and cannot simultaneously communicate whether these effects contribute to the correct handling of the car
on the track.

This evaluation is the task first of the engineers, then of the track engineer and, finally, of the driver, the true protagonist of this system who, with his
feedback, will be able to indicate to his technician the sensation perceived in that specific part of the circuit. His contribution, therefore, is still decisive not
only in Formula 1, but in general throughout the world of motorsport. As well as in that of sim-racing, which today offers specific tools to be able to
meticulously analyse the most important parameters of one's favourite car, especially within AC.

12.4.3 - REAL LIFE VS SIMULATED TELEMETRY

Race car data acquisition used to be limited to well-funded teams in high-profile championships. Nowadays, the cost of electronics has decreased
dramatically, making them available to everyone. But the cost of any data acquisition system is a waste of money if the recorded data is not interpreted
correctly.

Whether measuring the performance of a Formula One vehicle or a road-legal street car on the local drag strip, the dynamics of vehicles and their drivers
remain nearly the same. Almost identical analysis techniques apply.

In the real-word, the sensing and measuring of information happens at some remote location and then that information is transmitted to a central or host
location. There, it can be monitored and used to control a process at the remote site (Fig.).

494
Fig. – This is the block schematic of a basic real-world telemetry system. In a simulator (in our case AC), both ends are at the same place.

Purpose and function(s) of each of building-block or element of the system shown in Fig. are briefly described below:

1. Transducer or Sensor: Converts the physical variable to be telemetered (that is, the measurand) into an electrical quantity. This quantity in most cases
is either an electrical parameter (variable resistance, inductance or capacitance) or an electrical signal (voltage or current).
2. Signal Conditioner #1: Converts the electrical output (which may or may not be a signal, as explained above) of the transducer (or sensor) into an
electrical signal compatible with the next element, i.e. the transmitter. The incompatibility could be either in the form (such as parameter versus signal,
voltage versus current, analog versus digital, etc) or in the magnitude of the signal (that is, it is too weak to be used by the next element).
3. Transmitter: Its purpose is to transmit the information signal (a signal containing information, i.e. a signal which is a function of the value of the
measurand) coming from the signal conditioner #1 using a suitable carrier signal to the receiving end. It may perform one or more of the following
functions:
• Modulation: Modulation of a carrier signal by the information signal.
• Amplification: As and if required for the purpose of transmission.
• Signal Conversion: As and if required for the purpose of transmission. For example, voltage to current conversion, or analog to digital
conversion, or electrical signal to radio wave conversion, or electrical signal to optical beam conversion, depending on the nature of the carrier
signal and the signal transmission medium.
• Multiplexing: If more than one physical variables need to be telemetered simultaneously from the same location, then one of the following
multiplexing techniques is used: time-division multiplexing (TDM), frequency-division multiplexing (FDM), and wavelength-division multiplexing
(WDM).
• Signal Transmission Medium: It is the medium or link that connects the sending or transmitting end to the receiving end, over which the
transmitter can transmit its output signal to the receiver. Broadly, there are three signal transmission media in use: copper wires, radio link, and
optical fibre.
4. Receiver: Its purpose is to receive the signal(s) coming from the transmitter (located at the sending end of the telemetry system) via the signal
transmission medium and recover the information from the same. It may perform one or more of the following functions:
• Amplification: Amplification of the received signal as and if required for the purpose of further processing.
• Demodulation: Demodulation of the received signal to recover information signal. The demodulation process has to be complementary of the
modulation performed by the transmitter.
• Reverse Signal Conversion: This conversion is generally the reverse of the conversion performed by the transmitter. Thus the receiver is required
to perform current to voltage conversion, or digital to analog conversion, or radio wave to electrical signal conversion, or optical beam to
electrical signal conversion, depending on the nature of the carrier signal and the signal transmission medium.
• De-multiplexing: It refers to the process of segregating or separating various information signals so that they can be delivered to their respective
end devices. The process in the receiver has to be essentially the reverse of the multiplexing carried out by the transmitter.
5. Signal Conditioner #2: Processes the receiver output as necessary to make it suitable to drive the given end device
6. End Device: The element is so called because it appears at the end of the system. Depending on the purpose of the telemetry in the given application,
the end device may be performing one of the following functions:
• Analog Indication: Analog indication of the value of the measurand through the deflection of a pointer on a scale. The device used is very often a
permanent magnet moving coil (PMMC) meter.
• Digital Display: Digital display of the value of the measurand on LEDs, LCD, monitor screen etc.
• Digital Storage: Storage of the digital value of the measurand in electronic or optical storage device for a later use.
• Data Processing: The digital values of the mesurand may be given to a data processor, such as a microprocessor, digital signal processor or
computer, for analysis etc.

495
Various mediums or methods of transmitting data from one site to another have been used. Data radio provides a wireless method for transmitting the
information. Telemetry using radio waves or wireless offers several distinct advantages over other transmission methods. Some of these advantages are:

• No transmission lines to be cut or broken

• Faster response time
• Lower cost compared to leased lines
• Ease of use in remote areas where it is not practical or possible to use wire or coaxial cables
• Easy relocation
• Functional over a wide range of operating conditions
• Properly designed radio links can provide low cost, effective and flexible data gathering systems that operate for many years with very little
maintenance.

At the remote site, a sensor or sensors are typically the data source. The output of the sensor(s) is converted to digital data by a small computer device or
RTU (Remote Terminal Unit). The RTU is interfaced to a modem device that converts the digital data into an analog signal that can be transmitted over the
air. The radio transmitter then transmits the signal to the host site radio receiver. Now the process is reversed. The modem takes the analog signal received
and converts it back to a digital form that can be processed by the data recovery equipment.

In a typical application, the base or host site requests data from the remote site(s). The base transmits a request to the remote unit telling it to send its data.
The base reverts to a receive mode and awaits the transmission from the remote site. After the remote sends its data, it goes back to a receive mode waiting
for further instructions to come from the base. Once the base receives the remote site information, it may send additional instructions to that site or continue
on to request data from the next remote site. This polling process continues until all the remotes in the system have sent their data.

Telemetry radio systems are normally configured as a fixed base station that obtains information from another fixed station at a remote site. The FCC has
allocated certain frequencies that can be used for fixed operation. There are certain frequencies available in the VHF band (150-174 MHz), UHF band (450-
470 MHz) and 900 MHz band (928-960 MHz) for this type of operation.

WIP

Our main advantage using sims is that we ignore completely FM signals and the testing/troubleshooting of sensors in the different parts of the vehicle.

WIP

12.4.4 - THE IN-GAME AC TELEMETRY

We’re going into the details of what the simulation world offers: the current technology allows us to use a professional software tool like MoTeC i2 Pro,
which has also been used for years in real motorsport series. However, to begin understanding the graphs that characterise telemetry, let’s analyse two laps
on the Imola circuit (Fig.) with the Ferrari F2004, on the AC interface.

Fig. – Personally I love this circuit. It was really dangerous back in the 80s and 90s though, especially the first curves, which over time have been split into three corners, especially
after many deaths of pilots and the infamous 1994 Grand Prix, where Roland Ratzenberger and Ayrton Senna died (and that changed the motorsport world forever).

In our simulator’s GUI there is a simplified version of the telemetry graphs that we will be analysing soon with MoTeC (Fig.). This tool, although basic, will
allow us to interpret the values provided by the most important parameters of our vehicle, including the pressure we exerted on the brake pedal, the use of
the accelerator and the speed we maintained.
496
Fig. – The basic telemetry interface incorporated in the AC UI.

The analysis of speed

Let’s begin our analysis with the fundamental parameter that underlies telemetry systems: the speed that our Ferrari reached during the two laps, bearing in
mind that the vehicle in question had the basic setup, except for the seventh gear (one step longer), fuel at minimum and Medium tires.

Past the initial straight we are faced with the first challenge of the Imola circuit: the Tamburello variant. Here our reference is the 100-meter sign, which
imposes a strong braking during which we’re going to downshift four gears. The maximum speed reached in the best lap (in RED) and slowest lap (in
WHITE) is 319 km/h, which can be seen by placing the mouse pointer just before the moment when we hit the brakes (Fig. A). Then the speed decreases
dramatically and rises again near the Villeneuve variant.

Fig. -

497
On entry we reached 293 km/h in each hotlap, and, as can be seen from the graph, our speed remained similar on both laps even at Tosa, the Imola hairpin
bend: near its braking point there was a slight 3 km/h gap in favour of the slower lap (Fig. B), due to the fact that we braked more gently and with less
intensity than on our fastest lap.

The first major difference that consistently influenced the 305-thousandths delta between the two laps, however, we found as we exited Piratella, the drop-off
that then leads towards Acque Minerali. On our best lap we braked harder and released the brakes earlier than on our second attempt, which allowed us to
project into the next part of the track with a speed of 203 km/h (Fig. C).

On the lap marked in white, however, the exit speed is 195 km/h, almost ten less: this gap significantly affected our performance at Acque Minerali, where
on entry we reached 291 km/h vs 288 on the slower lap (Fig. D).

Also different was the exit from the second corner of Acque Minerali, 125 km/h vs 121, as well as the braking at the Variante Alta, where the performance
gap between the two laps materialized in 2 km/h (Fig. E). The last sector, on the other hand, showed no particular differences, despite a quite different use of
accelerator and brake between the two laps.

The analysis of the brake pedal

Let's move on to analyse the use of the brakes: looking at the screenshot below, we can see that on our best lap we maximized the potential of our F2004's
pedal in the first corner, pressing hard and then gradually releasing the pressure by taking advantage of the "trail braking" technique. In the slowest lap, on
the other hand, we had an initial uncertainty and then reached 85% braking force relatively late: this affected the exit from Tamburello, because if we pay
attention, we can see that the red line, related to our hotlap, first reaches the exit speed (equal to 152 km/h) and then resumes in the direction of the
Villeneuve variant (Fig. A).

Fig. -

At the Villeneuve variant our best performance is marked by 30% braking on entry compared to 19% on the second lap (Fig. B) and 44% braking on the
change of direction (compared to 31% on the second lap), leading towards Tosa (Fig. C). At the hairpin we basically repeated the same script as in the first
variant: on entry we reached 70% braking power in our best hotlap, which we then gradually released by taking advantage of trail braking. In the second
hotlap, however, there is a step from 28% braking power to 67% (Fig. D), which was reached late in the first lap: this caused a delay when it was time to
take the throttle back in hand, resulting in a widening of the ideal trajectory in the next straight towards Piratella.

It is at Acque Minerali, however, that we notice a marked difference in the use of the brake pedal: on our best lap we got to the right pressure of 42% right
away, while on our slowest one we "messed up" on entry and then too gradually (and inevitably late) got to an even lower pressure of 36% (Fig. E), then
rose noticeably to 44% when, on our other attempt, we were already letting off the brakes and letting our Ferrari slide (Fig. F).

Very similar was our behaviour at the braking of the Variante Alta: on both laps we pressed the brake pedal to 70%, and then gradually released it so that the
single-seater entered the change of direction firmly. At Rivazza, on the contrary, we got on the brakes early in our worst hotlap, with 70% pressure (Fig. G);
In our hotlap, on the other hand, we disconnected later and with a slightly higher intensity of 76 percent.

498
The analysis of the accelerator pedal
It only remains for us to go over the use of the gas pedal, mainly when exiting the various corners that distinguish the Imola Autodrome. At Tamburello,
because of the mistake made on the second flying lap, we were back on the throttle late, with an intensity of 48%: at this point, however, we were already at
66% of the pedal in our best attempt (Fig. A).

Fig. -

At the Tosa braking, then, another gap can be seen: on our best lap we released the throttle early, at 26% versus 64% on our worst attempt (Fig. B). Having
"messed around" with the brake, however, did not help us come out strong enough towards Piratella, where another big difference can be seen. The higher
speed maintained in this section of the track allowed us to get on the gas pedal sooner, with a 78% better throttle pressure on our hotlap than the 26% we
experienced in our second attempt (Fig. C).

At Acque Minerali we notice another difference in our use of the throttle: the red line shows an early release of the relevant pedal, which we then recalled
briefly before attaching to the brakes. If we look at the white line, on the other hand, we can see that we "held down" longer (albeit slightly) and released the
pedal more firmly ... only to make a mistake in going for the right brake pedal pressure. So the behaviour we kept on our best lap rewarded us: even on the
exit to the Variante Alta, where we were able to accelerate more effectively since we were on the gas already at 72% vs the absolute zero of our worst attempt
(Fig. D).

The last point to emphasize is what happened at the Rivazza braking: in our best hotlap we arrived on the brakes later, maintaining maximum throttle travel
for a longer time than in our worst hotlap. Here, in fact, we released the pedal earlier (30% intensity) to anticipate braking, but this did not allow us to gain
anything once we passed under the checkered flag (Fig. E).

Conclusions
We have come to the end of this installment: we have seen what is offered by the software present in Assetto Corsa, which provides us with a very basic but,
at the same time, important analysis to understand the fundamentals of telemetry systems. The graphs we studied show lines that oscillate up and down and
can be observed simply by hovering over them with the mouse pointer. This way we discover the value of a given parameter at that precise point on the
track, which can be compared at the same time with another value belonging to a second lap taken as a cue to compare our performance.

The comparison between one hotlap and another represents the ultimate purpose of telemetry in terms of performance: we can figure out at what point and
with what braking pressure it is most appropriate to break off on corner entry, and then identify the best time and level of intensity to get back on the gas on
exit. In addition to this, telemetry provides us with the indispensable speed graph, with which we can note the most important differences between one of
our launched laps and our best attempt ever between the curbs.

Putting together everything good that was done in our two hotlaps we would get the "perfect lap" on the Imola Autodrome, again keeping in mind the
conditions we used to perform this test. Because the goal of telemetry, after all, is just that: to go in search of the best possible result, taking into account
even individual thousandths of a second. In the next paragraph, the work we did with AC will take a different and more professional turn: it's time to move
onto the ACTI and MoTec!

499
12.4.5 – THE AC TELEMETRY INTERFACE (ACTI)
ACTI is a standalone client that together with an in-game app allows live access to and recording of Assetto Corsa telemetry data. Some of its key features
are:

• Record telemetry data in Motec i2 compatible log files (i2 v1.0.21.30 currently supported).
• View live telemetry data in user-configurable workspaces.
• Remote telemetry access (recording / viewing live data from a friend / teammate located anywhere in the world while they are on track).
• Easy in-game control over telemetry acquisition.

The complete ACTI tool package can be found right here. Included in the package are:

• The acti client.

• The in-game acti trigger control app.
• Motec i2 installer.
• Sample Motec i2 Project based on the data channels currently available from Assetto Corsa.

JKHLKJH

WIP

12.4.6 - IN-DEPTH ANALYSIS OF TELEMETRY DATA (WIP)

Much of the workload for the data acquisition engineer consists of comparative analysis. Comparing data from different laps or runs with previously collected
data reveals the effect of setup changes or driver performance. Most data analysis packages offer similar techniques for comparing different data sets. This
paragraph covers these techniques and provides a basic interpretation of the patterns showing up in the sensor signals most often used.

Obviously some of the real-word details you’ll see here aren’t present in AC, since there aren’t actual “sensors” in a simulation. However they may be
interesting, especially for curious people.

1 - Lap Markers and Segment Times

Performance analysis usually begins with figuring out where on the track time is gained or lost before actual events are investigated. A quick way to assess
this is to investigate lap segment times.
Lap times are determined by the analysis software measuring the time it takes for the car to pass the lap beacon. This beacon represents the location on the
track where a lap ends and the next one begins. It can be an infrared pulse logged by the data system or a manually entered beacon point in the data. Most
data analysis packages offer the option of placing additional virtual beacons around the track at certain distances from the start/finish beacon. Lap segment
times are determined by measuring the elapsed time between two consecutive beacons. Placement of these beacons depends on what needs to be analyzed.

Engine performance can be evaluated best on a straight track segment where the car is accelerating. Corners can be defined as separate segments, but the
corner itself can also be divided into entry, apex, and exit to investigate cornering performance.

WIP

Great care should be taken in placing importance on the theoretical fastest lap because a slower time in one segment can result in a faster time in the next.
The driver may take a driving line through one corner that is faster in the particular corner but compromises speed in the next one. Missing braking points
also can cause inconsistent segment times.

The confidence level of this performance indicator also depends on the location of the segment beacons. Segment times in areas bordered by beacons
placed at the apex of a corner are more sensitive to inconsistencies than those bordered by beacons placed at the middle of a straight.

The fastest rolling lap is the lap time achieved between beacons that are not necessarily at the end of a lap—an indication of the performance potential when
there is heavy traffic on the track. It is a lap time the driver actually achieves.

WIP

Another issue that requires attention when calculating the theoretical fastest lap is thenumber of track segments. The more track segments incorporated, the
faster the ideal lap is. There must be an optimum number of segments that provide a realistic theoretical fastest lap. Sound judgment is necessary here, both
in choosing the right number of segments and having confidence in this performance indicator.

2 - Comparing Laps

500
The most powerful tool in any data acquisition software package is overlaying and comparing different laps. Most analyses performed on race car data are
comparative. When something is changed on the car, comparing a run to previous ones indicates the difference of that change.

By overlaying two traces as a function of distance, the performance of the vehicle and the driver can be compared at the same point on the track. Overlaying
against time does not bring any meaningful conclusions because events at the same time probably happen at other locations, and the traces tend to diverge
over the length of the lap.

WIP

3 - Track Mapping

Track maps are graphical representations of the location at which logged data was recorded. It is a helpful software feature for lap navigation and a visual aid
for drivers and engineers that can be used while analysing the data. To draw a track map, three signals should be present: wheel speed, lateral acceleration,
and a lap beacon. Wheel speed integration gives the covered distance; combined with lateral acceleration, the heading of the vehicle can be calculated. The
lap beacon indicates the start and finish point of the lap. This technique is called inertial mapping.

It is, however, just a graphical representation of the racetrack and has its limitations.

4 - The beginner’s data logging

Any data logging system intended for the analysis of race car and driver performance should log at least the six basic signals: engine RPM, vehicle speed,
throttle position, steering angle, and lateral and longitudinal acceleration. These signals already contain a vast amount of information to analyse. Even in a
state-of-the-art data acquisition package with numerous sensors, these six signals remain the most important and most used data resource for the engineer.
The next logical step is to add suspensions to the system. In this section, the traces created by these sensor signals are explored and a feel for reading the
graphs developed.

4.1 - Logging Engine RPM

Engine RPM often is recorded from a magnetic sensor placed near a teethed trigger wheel on the engine’s crankshaft. This sensor counts the pulses
generated by this trigger wheel and converts them into the number of crankshaft revolutions per unit of time.

4.2 - Logging Vehicle Speed

The speed trace is the results graph. It is the best way to conclude if a change on the car or in driving style produced any result. This is the reason why
most analysis work is done with the speed graph as a reference. It is also the easiest trace to use for track navigation. Because this graph represents a
typical layout of each track (indicating corners between acceleration and deceleration zones) and the signal is used so much in analysis work, an
experienced data engineer looks more closely at the speed trace rather than at a track map to find a location on the track.

4.3 - Logging Throttle Position

The throttle position signal measures what the driver is doing with his right foot on the accelerator pedal. Throttle position usually is expressed as a
percentage, with zero percent meaning the driver is completely off the accelerator pedal and 100% equaling full throttle.

4.4 - Logging Steering Angle

As with throttle position, steering angle is a driver activity channel. It records the angle at which the steering wheel is turned and, just like throttle position, is
an invaluable diagnostic tool. Steering angle can be expressed as degrees turned by the steering wheel, spindle, or rim, as well as steering rack travel in
millimeters.

4.5 - Logging Lateral Acceleration

Lateral g-force is the channel logged as the acceleration perpendicular to the car’s centerline, and strictly speaking it measures cornering force. This channel
usually is displayed in units of g-forces (1 G = 9.81 m/s2).

4.6 - Logging Longitudinal Acceleration

Longitudinal g-force is the acceleration logged along an axis parallel to the car’s centerline (i.e., perpendicular to the lateral g-force). It is basically the
acceleration created by the engine’s power or the deceleration due to application of the brakes. A positive value is used for acceleration. For deceleration, the
sign for the longitudinal g-force is negative.

Longitudinal acceleration displayed with lateral g-forces in an X-Y graph forms the popular traction circle, a useful visualization technique illustrating how the
potential of the tires is used.

WIP

4.7 - Logging Suspension Travel

501
The six basic signals covered in the previous sections already give the engineer a significant amount of information about chassis and driver performance.
Equipping the vehicle with four suspension travel sensors helps in further diagnosing vehicle dynamics. Because suspension travel is used extensively in
the following chapters in mathematical channels, a review of basic properties of the signal is needed.

Suspension movement typically is measured as shock absorber displacement. With this signal, a sign convention and a short explanation of nomenclature is
necessary. (move it to suspensions.ini?) All ingoing shock travel from static ride height is considered positive. When the wheel goes up relative to the
chassis, the sensor signal has a positive sign. This motion is called bump. The opposite is true for all outgoing shock travel from static ride height. This is
called droop (Fig.). Shock absorber specialists use the names bump and rebound, but this actually refers to the gradient of the sensor signal. A positive
gradient (ingoing shock travel, regardless of static position) is called bump travel, while a negative gradient (outgoing shock travel, regardless of static
position) is referred to as rebound travel.

Fig. -

There are two different categories of suspension movement:

1. Low-speed movement
This includes the suspension movement in response to chassis attitude changes due to weight transfer (pitch and roll) and to the varying aerodynamic
loads at different speeds.

2. High-speed movement
The suspension movement induced by road irregularities and curbs takes place at a higher frequency than the low-speed movement.
Remember that suspension travel is being measured here, not wheel travel (Fig.).

Fig. - Suspension travel versus wheel travel.

When the motion ratio of the suspension is known, wheel travel can be calculated from the suspension travel signal using equation ()
∆𝑥𝑥𝑤𝑤
𝑀𝑀𝑀𝑀 =
∆𝑥𝑥𝑠𝑠

where MR = motion ratio, ∆𝑥𝑥𝑤𝑤 = wheel movement, ∆𝑥𝑥𝑠𝑠 = suspension movement.

WIP

502
CHAPTER 13 – SOUND
One of the most overlooked aspects of a driving simulation is sound. The audio signal gives feedback both about the vehicle state and the surrounding
environment. Depending on the experience of the driver, audio queues affect speed judgment, urgency, operator performance, alertness, and fatigue. As we
drive we use many audio clues for making decisions, such as using the pitch of the engine sound to decide to change gears.
Particular cases, such as low frequency (infra) sound (Sandberg, 1983) or combinations of sound and vibrations (Ihs, Andersson, Kircher, & Bolling, 2010)
have shown to affect driver behaviour in earlier simulator studies. One of the key requirements of a simulated environment is to achieve what is generally
called “presence”, i.e. the feeling of “being there” (Larsson, Västfjäll, & Kleiner, 2004). For auditory information this means providing a realistic sound field
allowing our hearing to perceive the expected spatial nature of the surroundings (Blauert, 1997). The more realistic the sound is the better the experience will
be for the driver and, perhaps more importantly, the more reliable the inference from experiments.
In a simulation out of place and inaccurate sounds can also distract a participant and negatively affect results.
In the past, sound engines have mostly been based on proprietary DSP (Digital Signal Processing) based solutions. Consumer PC based hardware simply did
not have the real-time signal processing capabilities to support a 3D sound engine. However over the last decades the capabilities of consumer sound hardware
have greatly increased. Today, 3D sound has become a standard feature of most computer video games; this has lead to a large number of 3D sound API’s.
In terms of software APIs Assetto Corsa developers chose FMOD, by the Australian based Firelight Technologies (www.fmod.org). FMOD offers functionality
to handle 3D sound placement and Doppler shifts. Also it provides a node based DSP engine with important functions such as pitch shifting, white noise and
sine wave generation, signal filtering, and supports geometry based wave tracing to calculate reverb, obstruction and occlusion.
In the next chapters you will learn some general basics, the bare minimum to let you understand the theory and the practice behind a good sound. You will
be able to navigate in the world of audio better than before, especially if you don’t know anything. Then we will apply what you will learn to our beloved
simulation.
If you think you know everything about sound, you may skip paragraphs 8.1 and 8.2, as they contain some of the most important principles. Par. 8.3 is useful
for those who still haven’t decided which audio setup they will use. You can go directly to par. 8.4 if you want to learn how audio queues work in AC.

13.1 - LECTURES ON APPLIED ACOUSTICS

Can you hear me?

13.1.1 - EMISSION, PROPAGATION AND RECEPTION

Acoustics is the science that studies the following three components of sound:
• Emission: a mechanism by which a sound source causes an oscillatory motion in an elastic medium.
• Propagation: the motion is transmitted and diffused through the medium.
• Reception: the oscillation is revealed and transformed into a physiological stimulus (human ear) or a measurable signal (measuring instrument).
The analysis according to the emission-propagation-reception scheme is very useful in setting up the study of characteristics of:
• The sources that emit sound. For example: primary sources, such as the human voice, musical instruments, the means of transportation, working tools, etc.; secondary
sources (which reproduce the sound produced by the primary sources) such as loudspeakers.
• Waves that carry the energy transferred from the source to the propagating medium. For example: sine waves (pure tones), periodic complex waves (harmonic sounds),
random aperiodic complex waves (noises).
• Sound perception. For example: psychoacoustics, e.g., auditory effects produced on the human auditory system (ear + brain), measurement of sound perception with
acoustic instrumentation, microphones.
Let's explore this system in more detail.
Emission
Objects that emit sound are called sources, which always consist of vibrating masses. Typical examples:
• Oscillating solid bodies: stringed instruments, percussion instruments, cones/diaphragms of loudspeakers, machinery
• Oscillating air columns: wind instruments, organs
• Bodies in rapid movement: propellers, whips
• Gases in rapid exit from containers: rockets, jet engines, exhausts from industrial plants
• Rapid increases in pressure: detonations

Propagation
As the source vibrates, it sets the surrounding air in motion, sending alternating peaks of compression and rarefaction radiating outward from the object.
Sound can then be interpreted as a wave phenomenon that propagates in a material medium, fluid or solid. The most common medium is air.
The fluctuations are far too small and far too rapid ever to be registered by a barometer. A microphone, on the other hand, can be thought of as a kind of
extra-sensitive electrical barometer capable of detecting these rapid fluctuations in the air pressure, unlike a normal barometer, which can only indicate
relatively slow pressure changes.
Physical quantities involved in the propagation are:
• Displacement of the particles in the medium from the equilibrium position
• Vibration velocity of the particles
• Speed of wave propagation

503
• Local pressure changes in the medium due to wave propagation

The rate of the vibration is called frequency, and is quoted in hertz [Hz] or cycles per second (cps). 1000 Hz is termed 1 kilohertz (1 kHz).
Sound information is transmitted by the amplitude and frequency of the vibrations, where amplitude is experienced (perceived by the ear) as loudness and
frequency as pitch.

13.1.2 -
13.1.3 - WAVES
The familiar movement of an instrument string is a transverse wave, where the movement is perpendicular to the direction of travel (Fig.). Sound waves are
longitudinal waves of compression and rarefaction in which the air molecules move back and forth parallel to the direction of wave travel centred on an average
position, resulting in no net movement of the molecules. When these waves strike another object, they cause that object to vibrate by exerting a force on them.
The forces that alternatively compress and stretch a spring (Fig.) are similar to the forces that propagate through the air as gas molecules bounce together.
Air molecules are in constant motion as a result of the thermal energy we think of as heat. (Room temperature is hundreds of degrees above absolute zero,
the temperature at which all motion stops.) At rest, there is an average distance between molecules although they are all actively bouncing off each other.
Regions of compression (also called condensation) and rarefaction (expansion) radiate away from a sound source in proportion to the movement of the source.
It is the net force exerted by the moving air that acts on our ears and on transducers like microphones to produce the sensation of hearing and the electrical
signals that become sound recordings. The same physics that describe oscillating mechanical systems like springs can be used to describe the behaviour of
gases like air: the equations derived to describe weights on springs can also be used to describe acoustics. Since a force implies a certain quantity of energy,
here transferred to the medium (usually air), we can also measure the quantity of heat that a sound generates, and most of the time it’s infinitesimal and
definitely negligible. Furthermore, electrical circuits exhibit similar behaviour and can be described using very similar mathematical equations. Springs are
even used to simulate reverberation, particularly in guitar amplifiers. This helps unify the field of sound recording, since mechanical, acoustical and electrical
systems are all employed in the recording of sound.
Fig. shows how energy is interchanged between kinetic and potential energy in an oscillating system.

Fig. -

Potential energy is energy that is capable of doing work, while kinetic energy is the result of active motion. As a mass suspended on a spring bounces up and
down, it exchanges the potential energy of a raised mass and tension stored in a spring with the kinetic energy of the moving mass back and forth until friction
depletes the remaining energy. At the top of its vertical motion, the mass has only potential energy due to the force of gravity while the spring is relaxed and
contains no energy. As the mass falls, it acquires kinetic energy while tension builds in the spring. At the mid-point of its fall, the mass reaches its maximum
velocity and then begins to slow as the force exerted by the spring’s expansion builds to counter the force of gravity. At the bottom of its travel, the mass stops
moving and therefore no longer has kinetic energy while the spring is maximally stretched and its potential energy is at its maximum, pulling the mass back
upwards. Since air has both mass and springiness, it behaves much the same way as the mechanical spring and mass.
Fig. shows how the time-varying characteristics of a sound wave may be measured and represented on a graph, called waveform, with amplitude plotted on
the vertical (y) axis and time plotted on the horizontal (x) axis. The amplitude can be measured as either pressure, velocity, or particle displacement of the air.
Pressure is often used because it is predominantly what is perceived by the ear and by many microphones.

504
It will be seen that both positive and negative ranges are shown on the vertical axis: these represent compressions (+) and rarefactions (−) of the air. This
graph represents the waveform of the sound. For a moment, a source vibrating in a very simple and regular manner is assumed, in so-called simple harmonic
motion, the result of which is a simple sound wave known as a sine wave. The simplest vibrating systems oscillate in this way, such as a mass suspended
from a spring, or a swinging pendulum. It will be seen that the frequency (f) is the inverse of the time between peaks or troughs of the wave (f = 1/t). So, the
shorter the time between oscillations of the source, the higher the frequency. The human ear is capable of perceiving sounds with frequencies between
approximately 20 Hz and 20 kHz; this is known as the audio frequency range or audio spectrum.
Peaks of increased pressure and troughs of reduced pressure alternate as they radiate away from the source. The distance between two adjacent peaks is the
wavelength, and is often represented by the Greek letter lambda (λ). Their wavelength and period can be used to describe the flow of the wave. The reciprocal
of the time between peaks or troughs is the frequency (f) in cycles/second or Hertz (Hz). The distance between peaks as they move outward is the wavelength
(l). The two quantities are related by the speed of sound (c), about 340 m/s or 1130 ft/s.
𝑐𝑐
𝜆𝜆 =
𝑓𝑓
The pressure variations associated with sound are extremely small compared to the average air pressure. Barometric pressure at sea level is about 101 kPa
[Pa (pascal) = N/m2] or 14.7 lb/in2. The pressure variation considered the threshold of audibility is 20 µPa, on the order of one billionth of atmospheric
pressure! The sensitivity of the ear is quite impressive. This also begins to explain why sound transmission is so hard to control. Further, any device used to
convert sound into electricity must be similarly sensitive and able to respond over a huge range of pressures and frequencies.
As a vibrating object begins to move, it forces the air molecules in contact with its surface to move. Thus, the air is accelerated by the sound source, causing
a net increase in particle velocity. Particle velocity refers to the movement of a hypothetical small mass of air rather than to the turbulent individual air molecules
that vibrate locally with extreme velocities but only over infinitesimal distances. (Volume velocity is also used to describe the velocity component - it’s the flow
of bulk fluid - air in this case.) The dimensions of nitrogen and oxygen molecules are on the order of about 3 Angstroms (10-10 m). This is many orders of
magnitude smaller than wavelengths of sound so considering air as a bulk mass is sensible. As the movement continues outward from the source, the
molecules are forced together, increasing the local pressure. Very near a sound source, most of the energy is contained in the form of particle velocity while
far from the source the energy is transmitted predominantly in the form of pressure (Fig.).

Fig. -

Close to a small source, the sound wavefront expands in two dimensions as the spherical surface area grows with the square of the distance from the origin
(Fig.) Far from the source, the wavefront is practically planar and the energy radiates through the same area as it flows outward hence there is no decrease
in sound pressure due to geometric dispersion. This distinction affects how sensors respond to the sound, as some are sensitive only to pressure while
others are sensitive to the velocity of the sound wave that is driven by the pressure difference along the axis of movement.

EVENT CONE ANGLE FOR FMOD

505
The ear functions mainly as a pressure sensor as do omnidirectional microphones, designed as pressure sensors.
Other types of microphones are sensitive to the air pressure gradient (often called velocity microphones.) These behave differently than pure pressure sensors,
as we will see when we examine microphone design and performance. The core of this difference depends on the fact that pressure is a scalar quantity while
velocity is a vector quantity 77. In order for a microphone to respond differently with respect to the direction from which a sound originates, it must be at least
somewhat sensitive to the velocity vector while pressure microphones respond only to the pressure of a sound wave and not to the direction from which it
originates.
In directional microphones, it is the pressure difference between two points (the front and back of the microphone), the pressure gradient, that is responsible
for the forces that are converted to electrical signals in the transducer. While some directional microphones do respond to the velocity directly, like dynamic
and ribbon microphones, others use multiple pressure-sensitive elements to produce a signal proportional to the pressure difference without actually moving
at the equivalent velocity. For this reason, it is preferable to refer to directional microphones in general as pressure-gradient microphones.
Air is a gas mixture, predominantly nitrogen and oxygen. The molecules are in constant motion. The hotter the gas, the more frequent and energetic the
molecular collisions. The kinetic energy of the gas exerts a force on other objects in contact with the air, which we call pressure. The relationship between
the pressure and volume occupied by the gas in a closed system is reflected in the basic law of gases, Boyle’s Law:
𝑃𝑃𝑃𝑃 = 𝑛𝑛𝑛𝑛𝑛𝑛
where P is pressure, V is volume, n is the amount of gas in moles, R is a constant and T is the absolute temperature. The most important aspect of this
relationship is that the product of pressure and volume is constant – if one goes up, the other goes down. (Related changes in temperature may complicate
this relationship slightly.)
The pressure goes up when the gas is compressed by reducing the volume it occupies because the molecules are forced closer together where their collisions
become more frequent. The compressibility of air can be observed using a syringe. With the plunger half-way into the syringe body, block the open end of
the syringe and push or pull on the plunger. When you release the plunger, it returns to its original position much like air molecules do during a passing
sound wave.
There is plenty of confusion about how to measure sound amplitude. Sound intensity is the product of pressure and velocity and reflects the power
(energy/time) of the sound wave:
Intensity = pressure x velocity = power / area
Near the sound source, intensity decreases with the square of the distance from the source. Intensity measures the total power of the sound wave - its ability
to do work. What we hear as loudness is more closely related to the pressure of the sound wave, which decreases linearly with distance from the source.
When we are concerned with our perception of loudness, we need to consider the sound pressure level rather than the intensity. We can also consider only
the pressure when we use omnidirectional pressure microphones. When using directional microphones, however, we will need to also consider the velocity
component of the sound wave.
Directional microphones have the ability to respond differently to sounds originating from different directions because they are sensitive to the sound wave
pressure gradient, which changes as a function of the angle from which the sound originates. It is more complicated to measure the velocity of a sound wave
than it is to measure its pressure, therefore most audio systems use sound pressure as a measure of amplitude. Most often, amplitude is measured as sound
pressure level (SPL).
The distinction between spherical and plane waves is of practical importance because it explains how different microphone types respond depending on their
distance from the sound source. For spherical waves, the intensity decreases with the square of the distance but the sound pressure level decreases linearly
with distance.
A spherical wave sound pressure decreases by 1/2 or 6 dB for a doubling of distance. In a more distant plane wave, any decrease in sound pressure is due
to absorption and scattering rather than geometric considerations.
In theory, plane wave pressures do not decrease with distance as they do for spherical waves. Equations for spherical and plane waves are presented below.
These equations show how pressure p and velocity u change as a function of both time and distance from the source and as a function of wavelength.

13.1.5 –

77
A scalar quantity has only a magnitude (i.e., defined by a number) while a vector has both magnitude and direction.

506
13.1.2 - THE SINE WAVE
As the sine wave is so useful it will be treated here in detail. Fig. 2.5 shows a constant speed rotation viewed along the axis so that the motion is circular.
Imagine, however, the view from one side in the plane of the rotation. From a distance only a vertical oscillation will be observed and if the position is
plotted against time the resultant waveform will be a sine wave. Geometrically it is possible to calculate the height or displacement because it is the radius
multiplied by the sine of the phase angle.

Fig. 8.4 - A sine wave is one component of a rotation. When a rotation is viewed from two places at right angles, one will see a sine wave and the other will see a cosine wave. The
constant phase shift between sine and cosine is 90 ° and should not be confused with the time variant phase angle due to the rotation.

The phase angle is obtained by multiplying the angular velocity ω by the time t. Note that the angular velocity is measured in radians per second whereas
the frequency f is measured in rotations per second or Hertz [Hz]. As a radian is unit distance at unit radius (about 57°) then there are 2π radians in one
rotation. Thus the waveform at a time t is given by sin(𝜔𝜔𝜔𝜔) or sin(2𝜋𝜋𝜋𝜋𝜋𝜋).
Imagine a second viewer who is at right angles to the first viewer. He will observe the same waveform, but at a different time. The displacement will be given
by the radius multiplied by the cosine of the phase angle. When plotted on the same graph, the two waveforms are phase shifted with respect to one another.
In this case the phase shift is 90 ° and the two waveforms are said to be in quadrature. Incidentally the motions on each side of a steam locomotive are in
quadrature so that it can always get started (the term used is quartering).
Note that the phase angle of a signal is constantly changing with time whereas the phase shift between two signals can be constant. It is important that these
two are not confused.
The velocity of a moving component is often more important in audio than its displacement. The vertical component of velocity is obtained by differentiating
the displacement. As the displacement is a sine wave, the velocity will be a cosine wave whose amplitude is proportional to frequency. In other words the
displacement and velocity are in quadrature with the velocity lagging. This is consistent with the velocity reaching a minimum as the displacement reaches a
maximum and vice versa.

13.1.4 – COMMON WAVE TYPES

At this point we'll look into the main waveforms that are usually adopted as the basic ingredients of any respectable sound lab. You can easily generate most
of them with Audacity or any other software for your audio mixes.
Sine wave
You have already gotten acquainted with it in the previous paragraph. You have learned, for example, that this type of waveform is the simplest of all; it’s a
basic and isolated sound, involving no harmonic nor in-harmonic sounds, and its frequency determines the pitch of the sound in question. As you will see,
the sine wave is at the origin of all the other waveforms listed in this chapter.
Pro tip: if you’re looking to create a smooth sub bass sound that doesn’t interfere with the feel of the vehicle, then deploy a sine wave to create a beautiful deep tone. I recommend
a low intensity and frequencies up to 150 Hz. Anything below 100 Hz is perfect for interior sound in modern, well-isolated vehicles.

Square and pulse wave

The square wave differs from the sine wave in that, besides the fundamental frequency, it also contains odd harmonics. The sum of these harmonics and the
fundamental give it its square shape (Fig.).

507
Fig. – Waveforms can be displayed on oscilloscopes. These devices are designed to analyse a wide range of signal types on the time domain.

A square wave sounds richer and buzzier. You can make aggressive, crunchy kick drums. But for cars it’s probably not very useful.
Moreover, real square waves in electronic devices often aren’t as perfectly accurate as their ideal theoretic counterparts (Fig.). This is valid for every type of
wave. It depends on the accuracy of the circuits, on the quality of the components and their specifications.

Fig. – These two circuits (probably oscillators) produce noticeable ripples and noise. Various factors can contribute to these kinds of effects.

Its cycle is equally divided into two alternating constant amplitudes above and below the baseline. That’s why it’s called a symmetrical wave and, thus, a true
square wave. Otherwise, if the time the wave spends above the baseline, called duty cycle, differs from the time below the baseline, the wave is asymmetrical
and it’s called a “rectangular” or pulse wave. A square wave is a pulse wave where the positive portion of its cycle equals the negative portion, also called a
“50% duty cycle”. If the two halves are not equal, it's generically a pulse wave.
Duty cycle, literally interpreted, refers to how long something receives power or is activated. We use duty cycle-related devices all the time. Say you have a
food blender with 10 varying speeds, from slow to fast. The blender, OFF, has a duty cycle of 0% or 0/100. If you set the blender to Speed 1, it activates and
a duty cycle is assigned for 10/90, that is 10% of the time, the device is activated and 90% of the time it is not. If you pressed Speed 6, it would adjust the
duty cycle to 60/40, that is the device is active 60% of the time and inactive 40% of the time. The technique of adjusting the duty cycle is called Pulse Width
Modulation (PWM). Many variable-speed motors work this way.
The pulse wave is a more generic form of square wave. It uses PWM and the duty cycle can be modified in real time. Basically, the circuit can create signals
with different shapes. So the shape is usually not symmetrical (Fig.).

Fig. – Different pulse waves. A square wave happens when Ton = Toff.

The pulse wave is applied a lot in electronics, for example in vintage gaming consoles and arcade machines. The Nintendo NES’s pulse waves have the
ability to change from duty cycles 12.5%, 25%, 50% and 75%. Each one of them has a different timbre. This technique is widely used also in the circuits of
dimmers designed specifically for LED lights.
Triangle wave
The triangle wave is comparable to the square wave in that it contains a fundamental sound, plus odd harmonics (Fig.).

508
Fig. – The harmonic structure of a triangle wave.

However, the power of each harmonic in the triangle wave is twice as low as their counterparts in the square wave. Thus, the power of the harmonics in the
triangle wave is reduced twice as fast as in the square wave.
A triangle wave can be more or less symmetrical. It sounds clearer, maybe even brighter than a sine wave.
Sawtooth wave
The sawtooth is the most extreme asymmetrical triangle wave. It can adopt two shapes: A progressively increasing ramp followed by an abrupt drop, or a sharp
rise followed by a progressive descent (Fig.).

Fig. – The sawtooth wave generated from an electronic circuit displayed on an oscilloscope.

When it comes to frequency, the sawtooth is the richest in terms of harmonics ─ it has them all! This richness makes it particularly interesting for subtractive
synthesis, which is when you construct a sound by filtering out frequencies, rather than adding them on.
13.1.1 - PERIODIC AND APERIODIC SIGNALS
Sounds can be divided into these two categories and analysed both in the time domain in which the waveform is considered, or in the frequency domain in
which the spectrum is considered. The time and frequency domains are linked by transforms of which the most well-known is the Fourier transform.
Fig. 8.0 (a) shows that a periodic signal is one which repeats after some constant time has elapsed and goes on indefinitely in the time domain.

509
Fig 8.0 - (a) Periodic signal repeats after a fixed time and has a simple spectrum consisting of fundamental plus harmonics. (b) Aperiodic signal such as noise does not repeat and has
a continuous spectrum. (c) Transient contains an anharmonic spectrum.

In the frequency domain such a signal will be described as having a fundamental frequency and a series of harmonics or partials which are at integer multiples
of the fundamental. The timbre of an instrument is determined by the harmonic structure. Where there are no harmonics at all, the simplest possible signal
results which has only a single frequency in the spectrum. In the time domain this will be an endless sine wave.
Fig. 8.0 (b) shows an aperiodic signal known as white noise. The spectrum shows that there is equal level at all frequencies, hence the term ‘white’ which is
analogous to white light containing all wavelengths. Transients or impulses may also be aperiodic. A spectral analysis of a transient (Fig. 8.0 (c)) will contain
a range of frequencies, but these are not harmonics because they are not integer multiples of the lowest frequency. Generally the narrower an event in the
time domain, the broader it will be in the frequency domain and vice versa.
Considering the wave types we already dealt with in the previous paragraphs, we can say that sine, square, triangle and sawtooth waves are periodic, while
pulse waves can be aperiodic if the PWM changes with respect to time.

13.1.3 - PROCESSING SIGNALS: THE FOURIER TRANSFORM (wip)

An audio signal is a complex signal composed of multiple single-frequency sound waves (basically sine waves) which travel together as a disturbance (pressure
change) in the medium. When sound is recorded, we only capture the resultant amplitudes of those multiple waves. Fourier Transform is a mathematical
concept that can decompose a signal into its constituent frequencies. Fourier transform does not just give the frequencies present in the signal, it also gives
the magnitude of each frequency present in the signal (Fig.).

Fig. – (right) Graphical representation of a signal (red line) that is obtained via the Fourier Transform. The input is a sawtooth wave (black lines), and the output is obtained by varying
the number of secondary harmonics (in violet), for a maximum of 20, that approximate it in the sum.

The inverse Fourier Transform is just the opposite of the Fourier Transform. It takes the frequency-domain representation of a given signal as input and does
mathematically synthesize the original signal (Fig.).

510
We talked about square waves, being composed by various harmonics. Let’s use the Fourier transform to approximate it, visualizing them (Fig.).

Fig. - Fourier series approximation of a square wave. N is the number of number of terms used to approximate the square wave.

Fourier transforms are not as useful for analysing transient signals, compared to time-domain analysis or even wavelet analysis. Transient signal analysis is a
complex endeavour. However, keep in mind that all the information in the signal is retained in the Fourier transform, albeit in a quite hard to interpret form.
So it’s possible to use it, it’s just more difficult. A better tool should be able to display any transient features more apparently at its output, which Fourier
transform will not; unlike the case where it displays the periodicity information so well.

13.1.4 - FREQUENCY RESPONSE AND LINEARITY

The sine wave is extremely useful in testing audio equipment because of its spectral purity. It is a goal in sound reproduction that the timbre of the original
sound shall not be changed by the reproduction process. There are two ways in which timbre can inadvertently be changed, as Fig. 8.1 shows.

Fig. 8.1 - Why frequency response matters. Original spectrum at (a) determines timbre of sound. If original signal is passed through a system with deficient frequency response (b), the
timbre will be changed (c).

In (a) the spectrum of the original sound shows a particular relationship between harmonics. This signal is passed through a system (b) which has an unequal
response at different frequencies. The result is that the harmonic structure (c) has changed, and with it the timbre. Clearly a fundamental requirement for
quality sound reproduction is that the response to all frequencies should be equal.
Frequency response is easily tested using sine waves of constant amplitude at various frequencies as an input and noting the output level for each frequency.

511
Fig. 8.2 shows that another way in which timbre can be changed is by non-linearity. All audio equipment has a transfer function between the input and the
output which form the two axes of a graph. Unless the transfer function is exactly straight
or linear, the output waveform will differ from the input.
A non-linear transfer function will cause harmonic distortion which changes the
distribution of harmonics and changes timbre. As the sine wave is spectrally pure, the
creation of harmonics by a non-linear process is at its most obvious. Consequently the
use of a sine wave test signal and a spectrum analyser is a useful way of testing for
harmonic distortion.
At a real microphone placed before an orchestra a multiplicity of sounds may arrive
simultaneously. The microphone diaphragm can only be in one place at a time, so the
output waveform must be the sum of all the sounds.
An ideal microphone connected by ideal amplification to an ideal loudspeaker will
reproduce all of the sounds simultaneously by linear superimposition. However, should
there be a lack of linearity anywhere in the system, the sounds will no longer have an
independent existence, but will interfere with one another, changing one another’s timbre
and even creating new sounds which did not previously exist. This is known as
intermodulation. Figure 8.3 shows that a linear system will pass two sine waves without
interference. If there is any non-linearity, the two sine waves will intermodulate to
Fig. 8.2 - Non-linearity of the transfer function creates harmonics by distorting produce sum and difference frequencies which are easily observed in the otherwise pure
the waveform. Linearity is extremely important in audio equipment. spectrum.

Fig. 8.3 - (a) A perfectly linear system will pass a number of superimposed waveforms without interference so that the output spectrum does not change. (b) A non-linear system causes
intermodulation where the output spectrum contains sum and difference frequencies in addition to the originals.

13.1.4 - ROOT MEAN SQUARE MEASUREMENTS

Let’s approach the power of the sound. Fig. 8.5 (a) shows that according to Ohm’s law, the power dissipated in an electric resistance (here the coil of an ideal
speaker) is proportional to the square of the applied voltage.
𝑉𝑉 𝑊𝑊 𝑉𝑉 2 𝑚𝑚2 ∙𝑘𝑘𝑘𝑘
The measure unit of electric resistance is the Ohm, [Ω], and it is defined by the aforementioned law as �Ω = = = = �. A resistor has a
𝐴𝐴 𝐴𝐴2 𝑊𝑊 𝐴𝐴2 ∙𝑠𝑠 3
resistance of 1 Ohm when a potential difference of 1 volt at its ends generates a current of intensity equal to 1 ampere.

512
Fig. 8.5 – (a) Ohm’s law: the power developed in a resistor is proportional to the square of the voltage. Consequently, 1 mW in 600 Ω
 requires 0.775 V. With a sinusoidal alternating
input (b), the power is a sine square function which can be averaged over one cycle. A DC voltage which would deliver the same power has a value which is the square root of the mean
of the square of the sinusoidal input.

This causes no difficulty with direct current (DC), but with alternating signals such as audio it is harder to calculate the power. Consequently a unit of voltage
for alternating signals was devised. Fig. 8.5 (b) shows that the average power delivered during a cycle must be proportional to the mean of the square of the
applied voltage. Since power is proportional to the square of applied voltage, the same power would be dissipated by a DC voltage whose value was equal to
the square root of the mean of the square of the AC voltage. Thus the volt rms (root mean square) was specified. An AC signal of a given number of volts
rms will dissipate exactly the same amount of power in a given resistor as the same number of volts DC.
Fig. 8.6 (a) shows that for a sine wave the rms voltage 𝑉𝑉𝑟𝑟𝑟𝑟𝑟𝑟 is obtained by dividing the peak voltage 𝑉𝑉𝑝𝑝𝑝𝑝 by the square root of two. However, for a square
wave (b) the rms voltage and the peak voltage are the same.

Fig. 8.5 - (a) For a sine wave the conversion factor from peak to rms is p2. (b) For a square wave the peak and rms voltage is the same.

Most moving coil AC voltmeters only read correctly on sine waves, whereas many electronic meters incorporate a true rms calculation. On an oscilloscope it
is often easier to measure the peak-to-peak voltage which is twice the peak voltage. The rms voltage cannot be measured directly on an oscilloscope since it
depends on the waveform although the calculation is simple in the case of a sine wave.

13.1.5 - THE DECIBEL (dB)

The first audio signals to be transmitted were on telephone lines. Where the wiring is long compared to the electrical wavelength (not to be confused with
the acoustic wavelength) of the signal, a transmission line exists in which the distributed series inductance and the parallel capacitance interact to give the
line a characteristic impedance. In telephones this turned out to be about 600 Ω. In transmission lines the best power delivery occurs when the source and
the load impedance are the same; this is the process of matching.
It was often required to measure the power in a telephone system, and one milliWatt (mW) was chosen as a suitable unit. Thus the reference against which
signals could be compared was the dissipation of one milliWatt in 600 Ω. Fig. 8.5 showed that the dissipation of 1 mW in 600 Ω was due to an applied
voltage of 0.775 V rms. This voltage is the reference against which all audio levels are compared.

513
The deciBel is a logarithmic measuring system and has its origins in telephony where the loss in a cable is a logarithmic function of the length. Human
hearing also has a logarithmic response with respect to sound pressure level (SPL). In order to relate to the subjective response audio signal level
measurements must also be logarithmic and so the deciBel was adopted for audio.
Fig. 8.6 shows the principle of the logarithm. To give an example, if it is clear that 102 is 100 and 103 is 1000, then there must be a power between 2 and
3 to which 10 can be raised to give any value between 100 and 1000. That power is the logarithm to base 10 of the value, e.g. log10 300=2.5 approx.
Note that 100 is 1.

Fig. 8.6 - (a) The logarithm of a number is the power to which the base (in this case 10) must be raised to obtain the number. (b) Multiplication is obtained by adding logs, division by
subtracting. (c) The slide rule has two logarithmic scales whose length can easily be added or subtracted.

Logarithms were developed by mathematicians before the availability of calculators or computers to ease calculations such as multiplication, squaring,
division and extracting roots. The advantage is that armed with a set of log tables, multiplication can be performed by adding, division by subtracting.
Fig. 8.6 shows some examples. It will be clear that squaring a number is performed by adding two identical logs and the same result will be obtained by
multiplying the log by 2.
The slide rule used a lot by engineers back in the day (and still used) is an early calculator which consists of two logarithmically engraved scales in which
the length along the scale is proportional to the log of the engraved number. By sliding the moving scale, two lengths can easily be added or subtracted and
as a result multiplication and division is readily obtained.
The logarithmic unit of measurement in telephones was called the Bel after Alexander Graham Bell, the inventor. Formula (4514f56s4d) shows that the Bel
was defined as the log of the power ratio between the power to be measured and some reference power. Clearly the reference power must have a level of 0
Bels since log10 1 is 0.
𝑃𝑃1 1 𝑃𝑃1
1 𝐵𝐵𝐵𝐵𝐵𝐵 = 𝑙𝑙𝑙𝑙𝑙𝑙10 ; 1 𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑𝑑 = 𝐵𝐵𝐵𝐵𝐵𝐵 ⇒ 𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃𝑃 𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 (𝑑𝑑𝑑𝑑) = 10 ∙ 𝑙𝑙𝑙𝑙𝑙𝑙10
𝑃𝑃2 10 𝑃𝑃2
The Bel was found to be an excessively large unit for many purposes and so it was divided into 10 deciBels, abbreviated dB. Consequently the number of
dB is 10 times the log of the power ratio. A device such as an amplifier can have a fixed power gain which is independent of signal level and this can be
measured in dB. However, when measuring the power of a signal, it must be appreciated that the dB is a ratio and to quote the number of dBs without
stating the reference is about as senseless as describing the height of a mountain as 2000 without specifying whether this is feet or metres. To show that the
reference is one milliWatt into 600 Ω, the units will be dB(m). In radio engineering, the dB(W) will be found which is power relative to one Watt.
And this is where the confusion begins: there are a lot of types of decibels! Suffixes are commonly attached to the basic dB unit in order to indicate the
reference value by which the ratio is calculated. In cases where the unit value of the reference is stated, the decibel value is known as "absolute". If the unit
value of the reference is not explicitly stated, as in the dB gain of an amplifier, then the decibel value is considered relative. This form of attaching suffixes to
dB is widespread in practice, albeit being against the rules promulgated by standards bodies (ISO and IEC), given the "unacceptability of attaching
information to units" and the "unacceptability of mixing information with units". Outside of documents adhering to SI units, the practice is very common as
illustrated by the following examples. There is no general rule, with various discipline-specific practices. Sometimes the suffix is a unit symbol
("W","K","m"), sometimes it is a transliteration of a unit symbol ("uV" instead of μV for microvolt), sometimes it is an acronym for the unit's name ("sm" for
square meter, "m" for milliwatt), other times it is a mnemonic for the type of quantity being calculated, or otherwise a general attribute or identifier about the
nature of the quantity. The suffix is often connected with a hyphen, as in "dB‑Hz", or with a space, as in "dB HL", or enclosed in parentheses, as in
"dB(sm)", or with no intervening character, as in "dBm" (which is non-compliant with international standards). It’s not worth explaining all of them, it’s easier
to understand which one you’re working with by yourself.
Although the dB(m) is defined as a power ratio, level measurements in audio are often done by measuring the signal voltage using 0.775 V as a reference in
a circuit whose impedance is not necessarily 600 Ω. Figure 8.6 (b) shows that as the power is proportional to the square of the voltage, the power ratio will
be obtained by squaring the voltage ratio. As squaring in logs is performed by doubling, the squared term of the voltages can be replaced by multiplying the
log by a factor of two. To give a result in deciBels, the log of the voltage ratio now has to be multiplied by 20.

514
Whilst 600 Ω matched impedance working is essential for the long distances encountered with telephones, it is quite inappropriate for audio wiring in a studio.
The wavelength of audio in wires at 20 kHz is 15 km. Most studios are built on a smaller scale than this and clearly analog audio cables are not transmission
lines and they do not have a characteristic impedance. Consequently the reader is cautioned that anyone who attempts to sell exotic analog audio cables by
stressing their transmission line characteristics is more of a salesman than a physicist.
In professional audio systems impedance matching is not only unnecessary it is also undesirable. Figure 2.11(a) shows that when impedance matching is
required the output impedance of a signal source must be artificially raised so that a potential divider is formed with the load. The actual drive voltage must
be twice that needed on the cable as the potential divider effect wastes 6 dB of signal level and requires unnecessarily high power supply rail voltages in
equipment. A further problem is that cable capacitance can cause an undesirable high-frequency roll-off in conjunction with the high source impedance.
In modern professional audio equipment as shown in Figure 2.11(b), the source has the lowest output impedance practicable. This means that any ambient
interference is attempting to drive what amounts to a short circuit and can only develop very small voltages. Furthermore shunt capacitance in the cable has
very little effect. The destination has a somewhat higher impedance (generally a few k ) to avoid excessive currents flowing and to allow several loads to be
placed across one driver.
In the absence of a fixed impedance it is now meaningless to consider power. Consequently only signal voltages are measured. The reference remains at
0.775 V, but power and impedance are irrelevant. Voltages measured in this way are expressed in dB(u); the most common unit of level in modern systems.
Most installations boost the signals on interface cables by 4 dB. As the gain of receiving devices is reduced by 4 dB, the result is a useful noise advantage
without risking distortion due to the drivers having to produce high voltages. In order to make the difference between dB(m) and dB(u) clear, consider the
lossless matching transformer shown in Fig.. The turns ratio is 2:1 therefore the impedance matching ratio is 4:1. As there is no loss in the transformer, the
power in is the same as the power out so that the transformer shows a gain of 0 dB(m). However, the turns ratio of 2:1 provides a voltage gain of 6 dB(u).
The doubled output voltage will develop the same power in to the quadrupled load impedance.
In a complex system signals may pass through a large number of processes, each of which may have a different gain. Figure 2.13 shows that if one stays in
the linear domain and measures the input level in volts rms, the output level will be obtained by multiplying by the gains of all of the stages involved. This is
a complex calculation.
The difference between the signal level with and without the presence of a device in a chain is called the insertion loss measured in dB. However, if the input
is measured in dB(u), the output level of the first stage can be obtained by adding the insertion loss in dB. The output level of the second stage can be
obtained by further adding the loss of the second stage in dB and so on. The final result is obtained by adding together all of the insertion losses in dB and
adding them to the input level in dB(u) to give the output level in dB(u). As the dB is a pure ratio it can multiply anything (by addition of logs) without
changing the units. Thus dB(u) of level added to dB of gain are still dB(u).
In acoustic measurements, the sound pressure level (SPL) is measured in deciBels relative to a reference pressure of 2 ð 105 Pascals (Pa) rms. In order to
make the reference clear the units are dB(SPL). In measurements which are intended to convey an impression of subjective loudness, a weighting filter is
used prior to the level measurement which reproduces the frequency response of human hearing which is most sensitive in the mid-range. The most
common standard frequency response is the so-called A-weighting filter, hence the term dB(A) used when a weighted level is being measured. At high or
low frequencies, a lower reading will be obtained in dB(A) than in dB(SPL).
13.1.6 - AUDIO LEVEL METERING
There are two main reasons for having level meters in audio equipment: to line up or adjust the gain of equipment, and to assess the amplitude of the
program material.
Line up is often done using a 1 kHz sine wave generated at an agreed level such as 0 dB(u). If a receiving device does not display the same level, then its
input sensitivity must be adjusted. Tape recorders and other devices which pass signals through are usually lined up so that their input and output levels are
identical, i.e. their insertion loss is 0 dB. Line up is important in large systems because it ensures that inadvertent level changes do not occur.
In measuring the level of a sine wave for the purposes of line up, the dynamics of the meter are of no consequence, whereas on program material the dynamics
matter a great deal. The simplest (and cheapest) level meter is essentially an AC voltmeter with a logarithmic response. As the ear is logarithmic, the deflection
of the meter is roughly proportional to the perceived volume, hence the term Volume Unit (VU) meter.
In audio recording and broadcasting, the worst sin is to overmodulate the tape or the transmitter by allowing a signal of excessive amplitude to pass. Real
audio signals are rich in short transients which pass before the sluggish VU meter responds. Consequently the VU meter is also called the virtually useless
meter in professional circles.
Broadcasters developed the Peak Program Meter (PPM) which is also logarithmic, but which is designed to respond to peaks as quickly as the ear responds
to distortion. Consequently the attack time of the PPM is carefully specified. If a peak is so short that the PPM fails to indicate its true level, the resulting
overload will also be so brief that the ear will not hear it. A further feature of the PPM is that the decay time of the meter is very slow, so that any peaks are
visible for much longer and the meter is easier to read because the meter movement is less violent. The original PPM as developed by the BBC was sparsely
calibrated, but other users have adopted the same dynamics and added dB scales, Fig. shows some of the scales in use.

515
Fig. - Some of the scales used in conjunction with the PPM dynamics. (After Francis Rumsey, with permission).

In broadcasting, the use of level metering and line up procedures ensures that the level experienced by the listener does not change significantly from program
to program. Consequently, in a transmission suite, the goal would be to broadcast tapes at a level identical to that which was obtained during production.
However, when making a recording prior to any production process, the goal would be to modulate the tape as fully as possible without clipping as this would
then give the best signal-to-noise ratio. The level would then be reduced if necessary in the production process.
13.1.7 - AUDIO CABLING and GROUND LOOPS
Balanced line working was developed for professional audio as a means to reject noise. This is particularly important for microphone signals because of the
low levels, but is also important for line level signals where interference may be encountered from electrical and radio installations. Fig. shows how balanced
audio should be connected. The receiver subtracts one input from the other which rejects any common mode noise or hum picked up on the wiring. Twisting
the wires tightly together ensures that both pick up the same amount of interference.
The star-quad technique is possibly the ultimate interference rejecting cable construction. Figure 2.19 shows that in star-quad cable four conductors are
twisted together. Diametrically opposite pairs are connected together at both ends of the cable and used as the two legs of a differential system. The interference
pickup on the two legs is rendered as identical as possible by the construction so that it can be perfectly rejected at a well-engineered differential receiver.
The standard connector which has been used for professional audio for many years is the XLR which has three pins. It is easy to remember that pins 1, 2 and
3 connect to eXternal, Live and Return respectively. External is the cable screen, Live is the in-phase leg of the balanced signal and Return is self-explanatory.
The metal body shell of the XLR connector should be connected to both the cable screen and pin 1 although cheaper connectors do not provide a tag for the
user to make this connection and rely on contact with the chassis socket to ground the shell. Oddly, the male connector (the one with pins) is used for
equipment signal outputs, whereas the female (the one with receptacles) is used with signal inputs. This is so that when phantom power (see Chapter 5) is
used, the live parts are insulated.
When making balanced cables it is important to ensure that the twisted pair is connected identically at both ends. If the two wires are inadvertently interchanged,
the cable will still work, but a phase reversal will result, causing problems in stereo installations and preventing the continuity of absolute phase through any
system.
In consumer equipment differential working is considered too expensive. Instead single-ended analog signals using coax cable are found using phono, DIN
and single pole jack connectors. Whilst these are acceptable in permanent installations, they will not stand repeated connection and disconnection and become
unreliable. Very expensive gold-plated phono connectors are available which are advertised as being hand polished by Peruvian virgins or some such, but,
however attractive they may look, they have absolutely no effect on the sound quality.
Effective unbalanced transmission over long distances is very difficult. When the signal return, the chassis ground and the safety ground are one and the same
as in Fig, ground loop currents cannot be rejected. The only solution is to use equipment which is double insulated so that no safety ground is needed. Then
each item can be grounded by the coax screen. As Fig shows, there can then be no ground current as there is no loop. However, unbalanced working also
uses higher impedances and lower signal levels and is more prone to interference. For these reasons some better quality consumer equipment will be found
using balanced signals.

13.1.10 - TYPES OF REPRODUCTION

The first audio systems were monophonic (from the Greek ‘single sound’), invariably abbreviated to mono. There was one loudspeaker fed by a single signal.
Whatever the position of the original sound sources, all of the sound would appear to come from one place, i.e. the loudspeaker. However accurate the
reproduction of the sound waveform by a mono system, the spatial representation is clearly completely incorrect.

516
Stereophonic (from the Greek ‘solid sound’) systems attempt to reproduce spatial attributes of the sound. Early experiments involved large numbers of
microphones, each feeding an independent speaker. Clearly this would be expensive and the technology of the day did not permit the recording or
broadcasting of multiple channels.
Today’s practical stereo systems are derived from the work of Alan Blumlein who showed that an infinity of virtual sound sources can be created at any
points between only two loudspeakers fed by two separate signals as shown in Fig. 7.0(a).

Fig. 7.0 – (a) The stereo system invented by Blumlein created virtual sound sources at arbitrary positions between only two loudspeakers needing only two channels. (b) A dummy head
connected to headphones gives realistic spatial effects but signal format is incompatible with (a).

The signal representing each virtual source is fed simultaneously to both speakers and its location is determined by the relative intensity in the two channels.
This is known as intensity stereo and it is a fundamental requirement that coincident directional microphones are used so that only intensity differences are
obtained. Loudspeakers must be used for reproduction as both ears must hear both speakers for the effect to work.
Intensity stereo recordings cannot be reproduced accurately on headphones as the sound appears to be in the centre of the listener’s head.
An alternative is shown in Fig. 7.0(b) where microphones are fitted in a dummy head and connected to headphones worn by the listener. This is known as
binaural stereo. The realism obtained is very high because the listener’s ears have been projected into the original sound field. However, as soon as the
listener turns his head the effect is lost. Another problem is that binaural signals cannot be reproduced directly on loudspeakers because the signals to each
ear cannot be kept separate.
The spatial coding of intensity stereo and binaural stereo is fundamentally different and incompatible with one another and with mono, and standards
conversion is required to interchange program material between standards.
Conversion to mono is achieved by adding the two stereo channels as shown in Fig. 7.1(a).

517
Fig. 7.1 – (a) Intensity stereo of Fig. 7.0(a) can be converted to mono reasonably well by adding left and right signals. (b) Mono signals can be reproduced on intensity stereo speakers
by supplying an identical signal to both channels. A central sound image results. (c) A sound image from a mono source can be moved or ‘panned’ by changing relative proportion of
signals fed to left and right speakers. (d) Pop record production pans many different mono signals into an artificial stereo image.

Intensity stereo gives good results as the spatial information simply collapses without affecting the tonality. As there are no phase differences in intensity
stereo, adding the channels and dividing by two is always the correct procedure to obtain a mono equivalent without a level change.
Adding the two channels of a binaural signal gives very poor results as the spacing between the microphones produces timing and phase differences
between them. Depending on the direction and frequency of the original sound, adding the channels may result in reinforcement or cancellation and this
causes a serious change in tonality as well as loss of spatial information. It is not clear what gain factor should be used to avoid a level change. This poor
mono compatibility is the main reason why broadcasters primarily use intensity stereo.
Mono signals can be reproduced on stereo systems simply by feeding both channels equally as in Fig. 7.1(b). The result is a central image with no spatial
information as might be expected. Mono signals from single instruments can be positioned within the stereo image by varying the relative intensity of the
signal fed to the two channels using a panoramic potentiometer or panpot (Fig. 7.1 (c)).
Today most pop records are made by panning a number of different mono signals into different locations in the stereo image (Fig. 7.1(d)).
Fig. 7.2 shows that in order to listen to intensity stereo on headphones a device called a shuffler must be used. This electronically simulates the missing
paths from each speaker to the opposite ear and moves the virtual sound sources to their correct forward location.

Fig. 7.2 - A standards converter known as a shuffler is necessary to listen to intensity stereo signals using headphones. This replicates electronically the fact that both ears hear both
loudspeakers.

One might be forgiven for thinking that personal stereo systems using headphones should incorporate such a device. In practice hardly any do and most
give a disappointing inside-the-head image.
Transaural stereo attempts to reproduce binaural stereo on loudspeakers by simulating the unwanted crosstalk between each speaker and the opposite ear
and adding it in anti-phase to the signals. The listener then obtains, over a limited area, an approximation to the original binaural waveform at each ear.
The transaural stereo processor is essentially an inverse shuffler. The above stereophonic techniques give reasonably accurate spatial representation of the
sound sources. Other techniques are used, such as spaced omnidirectional microphones, which produce both phase and intensity differences between the
two channels. These are quite incapable of reproducing the spatial information in the original sound field, but instead a diffuse spacious effect is obtained.
This is preferable to the point source of mono but it is only an effect.
Stereophonic systems only give accurate spatial information in an arc between the two speakers. Surround sound systems attempt to encircle the listener with
sound sources. Many of these use only two signal channels so that existing stereo recording and transmission equipment can be used. The two signals are
encoded in such a way that the decoder can determine the direction from which the dominant sound source is coming. The sound is then steered to the
appropriate speaker(s). Dolby Surround Sound and UHJ both work in this way.
In the late 1960s quadraphonic consumer equipment was made available in which four independent channels were conveyed. The technology of the day was
not adequate and the system was a commercial failure. Recently with digital techniques it has become possible to multiplex an arbitrary number of audio
channels into one transmission without crosstalk. This makes possible true surround sound.

13.1.11 - DIRECTIONALITY IN HEARING

Much greater spatial realism is obtained by using more than one loudspeaker. Generally, a reproduction system having some spatial realism will be preferred
to a technically superior monophonic system.
The human listener can determine reasonably well where a sound is coming from. An understanding of the mechanisms of direction sensing is important for
the successful implementation of spatial illusions such as stereophonic sound.
As Fig. 7.3 shows, having a pair of spaced ears allows a number of mechanisms. At (a) a phase shift will be apparent between the two versions of a tone
picked up at the two ears unless the source of the tone is dead ahead (or behind). At (b) the distant ear is shaded by the head resulting in reduced response
compared to the nearer ear. At (c) a transient sound arrives later at the more distant ear.

518
Fig. 7.3 - Having two spaced ears is cool. (a) Off-centre sounds result in phase difference. (b) Distant ear is shaded by head producing loss of high frequencies. (c) Distant ear detects
transient later.

If the phase-shift mechanism (Fig. 7.3(a)) is considered, then it will be clear that there will be considerable variation in this effect with frequency. At a low
frequency such as 30 Hz, the wavelength is around 11.5 metres. Even if heard from the side, the ear spacing of about 0.2 metres will result in a phase shift
of only 6 ° and so this mechanism must be quite weak at low frequencies.
At high frequencies such as 10 kHz, the ear spacing is many wavelengths and variations in the path-length difference will produce a confusing and complex
phase relationship. The problem with tones or single frequencies is that they produce a sinusoidal waveform, one cycle of which looks much like another
leading to ambiguities in the time between two versions. This is shown in Fig. 7.4(a).
Pure tones are extremely difficult to localize, especially as they will often excite room-standing waves which give a completely misleading impression of the
location of the sound source. Consequently the phase-comparison mechanism must be restricted to frequencies where the wavelength is short enough to give
a reasonable phase shift, but not so short that complete cycles of shift are introduced. This suggests a frequency limit of around 1500 Hz which has been
confirmed by experiment.
Phase differences are only useful at low frequencies and shading only works at high frequencies. Fortunately real-world sounds are timbral or broadband and
often contain transients, especially those sounds which indicate a potential hazard. Timbral, broadband and transient sounds differ from tones in that they
contain many different frequencies. A transient has a unique aperiodic waveform which Figure (b) shows has the advantage that there can be no ambiguity in
the inter-aural delay (IAD) between two versions.

Fig. 7.4 – (a) Pure tones cause ambiguity in timing differences. (b) Transients have no ambiguity and are easier to localize.

The inter-aural phase, delay and level mechanisms vary in their effectiveness depending on the nature of the sound to be located. A fixed response to each
mechanism would be ineffective. For example, on a low-frequency tone, the time-of-arrival mechanism is useless whereas on a transient it excels. The
different mechanisms are quite separate on one level, but at some point in the brain’s perception a fuzzy logic or adaptive decision has to be made as to how
the outcome of these mechanisms will be weighted to make the final judgement of direction.

13.1.12 - THE STEREOPHONIC ILLUSION

The most popular technique for giving an element of spatial realism in sound is stereophony, nowadays abbreviated to stereo, based on two simultaneous
audio channels feeding two spaced loudspeakers. Fig. 7.5 shows that the optimum listening arrangement for stereo is where the speakers and the listener
are at different points of a triangle which is almost equilateral.

519
Fig. 7.5 – Theoretic configuration used for stereo listening on the left, plausible setup on a desk on the right.

Stereophony works by creating differences of phase and time of arrival of sound at the listener’s ears. It was discussed above (par. 7.1.2) that these are the
most powerful hearing mechanisms for determining direction.
Fig. 7.6(a) shows that this time of arrival difference is achieved by producing the same waveform at each speaker simultaneously, but with a difference in the
relative level, rather than phase. Each ear picks up sound from both loudspeakers and sums the waveforms. The sound picked up by the ear on the same side
as the speaker is in advance of the same sound picked up by the opposite ear. When the level emitted by the left loudspeaker is greater than that emitted by
the right, it will be seen from Fig. 7.6(b) that the sum of the signals received at the left ear is a waveform which is phase advanced with respect to the sum of
the waveforms received at the right ear. If the waveforms concerned are transient the result will be a time-of-arrival difference. These differences are interpreted
as being due to a sound source left of centre.

Fig. 7.6 - (a) Stereo illusion is obtained by producing the same waveform at both speakers, but with different amplitudes. (b) As both ears hear both speakers but at different times,
relative level causes apparent time shift at the listener. ∆𝑡𝑡𝐿𝐿 = inter-aural delay due to loudspeaker; ∆𝑡𝑡𝑉𝑉 = inter-aural delay due to virtual source.

The stereophonic illusion only works properly if the two loudspeakers are producing in-phase signals. In the case of an accidental phase reversal, the spatial
characteristic will be ill-defined and lack images. At low frequencies the two loudspeakers are in one another’s near field and so anti-phase connection
results in bass cancellation.
As the apparent position of a sound source between the two speakers can be controlled solely by the relative level of the sound emitted by each one, stereo
signals in this format are called intensity stereo. In intensity stereo it is possible to ‘steer’ a monophonic signal from a single microphone into a particular
position in a stereo image using a form of differential gain control.

520
Fig. 7.7 shows that this device, known as a panoramic potentiometer or panpot for short, will produce equal outputs when the control is set to the centre. If
the panpot is moved left or right, one output will increase and the other will reduce, moving or panning the stereo image to one side.

Fig. 7.7 - The panpot distributes a monophonic microphone signal into two stereo channels allowing the sound source to be positioned anywhere in the image.

In audio preamplifiers and amplifiers usually this device is represented by the balance knob (Fig. 7.8).

Fig. 7.8 – The typical balance control in Hi-Fi audio equipment (in this example located on a stereo amplifier).

If the system is perfectly linear, more than one sound source can be panned into a stereo image, with each source heard in a different location. This is done
using a stereo mixer in which monophonic inputs pass via panpots to a stereo mix bus. The majority of pop records are made in this way, usually with the
help of a multitrack tape recorder with one track per microphone so that mixing and panning can be done at leisure.
It is important that your speaker system is correctly balanced for a correct sound reproduction. You can use a mono audio input to check whether your setup
is good or not. If the apparent source is not exactly in front of you, but off-centred to the left or to the right, the balance control can be adjusted to fix the
problem. This is fundamental when you cannot place your speakers following the aforementioned triangle shape.

13.1.13 - HEARING IN REVERBERANT CONDITIONS

We live in a reverberant world which is filled with sound reflections. If we could separately distinguish every different reflection in a reverberant room we
would hear a confusing cacophony. In practice we hear very well in reverberant surroundings, far better than microphones can, because of the transform
nature of the ear and the way in which the brain processes nerve signals.
When two or more versions of a sound arrive at the ear, provided they fall within a time span of about 30 ms, they will not be treated as separate sounds,
but will be fused into one sound. Only when the time separation reaches 50 60 ms do the delayed sounds appear as echoes from different directions.
As we have evolved to function in reverberant surroundings, reflections do not impair our ability to locate the source of a sound. The fusion will be impaired
if the spectra of the two sounds are too dissimilar. A moment’s thought will confirm that the first version of a transient sound to reach the ears must be the
one which has travelled by the shortest path. Clearly this must be the direct sound rather than a reflection. Consequently the ear has evolved to attribute
source direction from the time of arrival difference at the two ears of the first version of a transient. Later versions which may arrive from elsewhere simply
add to the perceived loudness but do not change the perceived location of the source.
This phenomenon is known as the precedence or Haas effect after the Dutch researcher who investigated it. Haas found that the precedence effect is so
powerful that even when later arriving sounds are artificially amplified (a situation which does not occur in nature) the location still appears to be that from
which the first version arrives. Fig. 7.9 shows how much extra level is needed to overcome the precedence effect as a function of arrival delay.
Experiments have been conducted in which the delay and intensity clues are contradictory to investigate the way the weighting process works. The same
sound is produced in two locations but with varying relative delay and shading dependent level. The way in which the listener perceives an apparent sound
direction reveals how the directional clues are weighted.

521
Fig. 7.9 - The precedence effect is powerful. This curve shows the extra level which is needed in a later sound to overcome it.

Within the maximum inter-aural delay of about 700 µs the precedence effect does not function and the perceived direction can be pulled away from that of
the first arriving source by an increase in level. Fig. 7.10 shows that this area is known as the time-intensity trading region. Once the maximum inter-aural
delay is exceeded, the hearing mechanism knows that the time difference must be due to reverberation and the trading ceases to change with level.
Fig. 7.10
It is important to realize that in real life the hearing mechanism expects a familiar sound to have a familiar weighting of phase, time of arrival and shading
clues. A high-quality sound reproduction system must do the same if a convincing spatial illusion is to be had. Consequently a stereo system which
attempts to rely on just one of these effects will not sound realistic. Worse still is a system which relies on one effect to be dominant but where another is
contradictory. Time-intensity trading is an interesting insight into the operation of the hearing mechanism, but it cannot be used in quality sound
reproduction because although the ear is fooled, it knows it is being fooled because it is attempting to resolve conflicting stimuli and the result is inevitably
listening fatigue.
In the presence of an array of simultaneous sound sources the hearing mechanism has an ability to concentrate on one of them based on its direction. The
brain appears to be able to insert a controllable time delay in the nerve signals from one ear with respect to the other so that when sound arrives from a given
direction the nerve signals from both ears are coherent. Sounds arriving from other directions are incoherent and are heard less well. This is known as
attentional selectivity but is more usually referred to as the cocktail-party effect. Monophonic systems prevent the use of this effect completely because the
first version of all sounds reaching the listener come from the same loudspeaker. Stereophonic systems allow the cocktail-party effect to function in that the
listener can concentrate on specific sound sources in a reproduced stereophonic image with the same facility as in the original sound.
One of the most frustrating aspects of hearing impairment is that hearing loss in one ear destroys the ability to use the cocktail-party effect. In quiet
surroundings many people with hearing loss can follow what is said in normal tones. In a crowded room they are at a serious disadvantage because they
cannot select a preferred sound source.
Laterally separated ears are ideal for determining the location of sound sources in the plane of the earth’s surface, which is after all where most sound
sources emanate. Our ability to determine height in sound is very poor. As the ears are almost exactly half-way back on each side of the head it is quite
possible for sound sources ahead or behind, above or below to produce almost the same relative delay, phase shift and shading resulting in an ambiguity.
This leads to the concept of the cone of confusion where all sources on a cone with the listener at the vertex will result in the same IAD.
There are two main ways in which the ambiguity can be resolved. If a plausible source of sound can be seen, then the visual clue will dominate. Experience
will also be used. People who look up when they hear birdsong may not be able to determine the height of the source at all, they may simply know, as we all
do, that birds sing in trees.
A second way of resolving front/back ambiguity is to turn the head slightly. This is often done involuntarily and most people are not aware they are using the
technique. In fact, when people deliberately try harder to locate a sound, they often keep their head quite still making the ambiguity worse.
Intensity stereo recordings (see par. 7.1.1) are fundamentally incompatible with headphone reproduction. A further problem with headphones is that they turn
with the wearer’s head, disabling the ability to resolve direction by that means.
The direction-sensing ability has been examined by making binaural recordings using miniature microphones actually placed down the ear canals of a volunteer.
When these are played back on headphones to the person whose ears were used for the recording, full localization of direction including front/rear and height
discrimination is obtained. However, the differences between people’s ears are such that the results of playing the recording to someone else are much worse.
The same result is obtained if a dummy head is used.
Whilst binaural recordings give very realistic spatial effects, these effects are only obtained on headphones and consequently the technique is unsatisfactory
for signals intended for loudspeaker reproduction and cannot used in pre-recorded music, radio or television.

13.1.14 – HEARING LOSS (unsure if to be kept)

Noise-Induced Hearing Loss, or NIHL, happens when you listen to loud sounds. These sounds can last a long time, like listening to a concert, or they can be
short, like from gunfire. Three factors put you at risk for NIHL:

• How loud the noise is

522
• How close you are to the noise
• How long you hear the noise
Sound-level meters measure noise levels. We record noise levels in decibels, or dBA. The higher the noise level, the louder the noise. You can listen to
sounds at 70 dBA or lower for as long as you want. Sounds at 85 dBA can lead to hearing loss if you listen to them for more than 8 hours at a time.
Sounds over 85 dBa can damage your hearing faster. The safe listening time is cut in half for every 3-dB rise in noise levels over 85 dBA. For example, you
can listen to sounds at 85 dBA for up to 8 hours. If the sound goes up to 88 dBA, it is safe to listen to those same sounds for 4 hours. And if the sound goes
up to 91 dBA, your safe listening time is down to 2 hours.
The World Health Organization and International Telecommunication Union 2019 document, WHO-ITU Global Standard on Safe Listening Devices and Systems,
recommends that manufacturers equip devices like smartphones and personal audio players with information that explains safe listening (for adults, a total of
40 hours of weekly exposure to volume levels no higher than 80 dB is recommended; for children, the level is 75 dB); usage warnings and tracking information;
cues for taking safe listening actions; options for limiting volume levels; and volume limiters expressly for parents to use. The recommendations would also
have safe listening information appear on external product packaging and advertising, as well as on manufacturers' websites.
Signs That Noise Is Too Loud
You probably don't always carry a sound level meter with you. So how can you know if noises are too loud? Here are some signs:
• You must raise your voice to be heard.
• You can't hear or understand someone 3 feet away from you.
• Speech around you sounds muffled or dull after you leave the noisy area.
• You have pain or ringing in your ears after you hear the noise, called tinnitus. It can last for a few minutes or a few days.
How do loud noises hurt your hearing? It may help to first understand how you hear:
Sound goes into your ear as sound waves. The louder the sound, the bigger the sound wave. The outer ear, which is what you see on the side of your head,
collects the sound wave. The sound wave travels down the ear canal toward your eardrum. This makes your eardrum vibrate.
The sound vibration makes the three middle ear bones move. The movement makes the sound vibrations bigger. The last of the three middle ear bones
moves the sound vibrations into the inner ear, or cochlea. The cochlea is filled with fluid and has tiny hair cells along the inside. The vibrations make the
fluid in the inner ear move. The fluid makes the hair cells move, too. The hair cells change the vibrations into electrical signals that travel to your brain
through your hearing nerve.
Only healthy hair cells can send electrical signals to your brain. We recognize sounds in our brains and use that information to figure out how to respond.
You may lose some of your hearing if the hair cells get damaged. How does this happen?
• Hair cells are sensitive to big movements. If sounds are loud, they move the fluid in the inner ear more, and that can damage the hair cells.
• Hair cells that are damaged by loud sounds do not send signals to the brain as well as they should. The first hair cells that are hurt are those that send high-pitched
sounds to the brain. This can make sounds like /t/ in "tin", /f/ in "sin", or /k/ in "kin" harder to hear.
• Short, loud noises - like a firecracker or an explosion - can damage hair cells. Listening to loud sounds for a long time, like when you are at a rock concert, also
damages hair cells.
Ringing in your ears, or tinnitus, is an early sign of noise-induced hearing loss. There is no way to fix damaged hair cells. Hearing aids or other devices can
help you hear better, but your hearing will not come back on its own.
Protecting your hearing
Knowing how noise impacts you is the key to protecting your hearing. You've taken that first step by reading this information. The next step is to avoid loud
noise whenever possible. Remember, if you have to shout to be heard, it is too loud. You should get away from the noise or find a way to protect your ears.
Here are some things you can do:
1. Wear hearing protection. Cotton in the ears will not work. You can buy things that protect your hearing, like earplugs or earmuffs, at the store or online.
• Earplugs go into your ear so that they totally block the canal. They come in different shapes and sizes. An audiologist can make some just for your ears. Earplugs can
cut noise down by 15 to 30 decibels.
• Earmuffs fit completely over both ears. They must fit tightly to block sound from going into your ears. Like earplugs, earmuffs can reduce noise by 15 to 30 dB,
depending on how they are made and how they fit.
• Earplugs and earmuffs can be used together to cut noise down even more. You should use both when noise levels are above 105 dB for 8 hours or more. You
should also use both if you might hear impulse sounds that are more than 140 dBP.
2. Do not listen to loud sounds for too long. Move away from the loud sound if you don't have hearing protection. Give your ears a break. Plug your ears with your fingers
as emergency vehicles pass on the road.
3. Lower the volume. Keep personal listening devices set to no more than half volume. The World Health Organization recommends a total of 40 hours of weekly exposure
to volume levels no higher than 80 dB for adults and 75 dB for children on personal listening devices. Don't be afraid to ask others to turn down the volume of their
devices if you can hear them. Ask the movie theater manager to turn down the sound if the movie is too loud.
4. Be a good consumer. Look for noise ratings on appliances, sporting equipment, power tools, and hair dryers. Buy quieter products. This is especially important when
buying toys for children.

Don't be fooled by thinking your ears are "tough" or that you can "tune it out"! Noise-induced hearing loss is usually slow and painless. But, it is permanent.
The hair cells and hearing nerve cannot be fixed. If loud sounds don't bother you, you may already have some hearing damage.

You can avoid noise-induced hearing. Protect your hearing for life.

523
13.2 – THE AUDIO EQUIPMENT
One important thing to keep in mind is that the sound synthesis process will only be as effective as the devices (mostly the speakers) used to monitor the
playback during the analog/digital mastering (still recording on tape?), the digital sampling and the final mixing. Let’s dive into this for a bit.

13.2.1 - SOUND QUALITY

It is possible to talk about sound quality in physical or technical terms, and in perceptual terms. In physical terms, it generally relates to certain desirable
measured characteristics of audio devices, transmission channels, or signals. In perceptual terms, however, it relates to what is heard, interpreted, and judged
by human listeners. In an ideal world, one domain could be related or mapped directly to the other. However, there may be aspects of sound quality that can
be perceived, even though they cannot be measured, and some that can be measured but not perceived. One of the goals of perceptual model research is to
find better ways of measuring those aspects of audio signals that predict perceived quality.
Sound quality can be defined in both objective and subjective terms. The term objective is often related to measurable aspects of sound quality, whereas
subjective is often related to perceived aspects of sound quality. However, the term objective, in one sense of the word, means “free of any bias or prejudice
caused by personal feelings”, and it has been shown that some descriptive attributes of sound quality can be evaluated by experienced listeners in a reliable
and repeatable way that conforms to this definition. This can result in a form of perceptual measurement that is almost as objective as a technical measurement.
For this reason, it may be more appropriate to differentiate between physically measured and perceived attributes of quality, reserving the term subjective for
questions such as liking and preference.
One of the biggest mistakes that can be made when talking about sound quality is to confuse liking with correctness. One cannot automatically assume that
the sound with the least distortion or flattest frequency response will be the most liked, although in many cases it is so. Some people actively like the sound
of certain kinds of distortion, and this may have something to do with the preference shown by some for analog recording systems or vinyl LP records, for
example. Learning and familiarity also play an important role in determining preferred sound quality. In one early experiment (source), for example, students
who had spent a period of time listening to restricted frequency range audio systems demonstrated a preference for those compared with full-range systems.

13.2.2 - SOUND SYSTEMS

There are many different uses for audio equipment and the performance criteria are quite different. Here some typical audio systems are outlined. A distinction
commonly made is between professional and consumer equipment.
• In general professional equipment is a tool which someone uses to do his or her job. Failure or inconsistent performance is unacceptable as it could cause loss of income
or a damaged reputation. Rugged construction is desirable for reliability.
Before making a purchase most professionals insist on a demonstration or even a loan of the products under consideration to see how they function under the intended
conditions. It is not unusual for manufacturers to take prototypes into the field to gauge reaction and obtain the views of skilled listeners.
• A great deal of consumer equipment is purchased on its appearance without test. A number of low-cost loudspeakers are produced by injection moulding and many of these
have imitation tweeters and reflex ports which are completely non-functional but give the appearance of a more sophisticated unit. No mass manufacturer displays prototypes
as consumers would not understand why they were imperfect.
Consumer equipment is for entertainment and is mostly produced at low cost to variable standards. The common user will generally have little technical knowledge and the
equipment installation will often be compromised by poor loudspeaker placement.

13.2.3 - PORTABLE CONSUMER EQUIPMENT

Despite political correctness these portable units have come to be known almost universally as “ghetto blasters” or “boomboxes” (Fig. 7.11).

Fig. 7.11 – Boomboxes have a bad reputation, but there are a bunch of better-than-average products (which aren’t necessarily the ones in the pictures above). I’m touching grass too.

A constant problem with portable products is that battery power is extremely limited. Battery life is usually extended by failing to reproduce low frequencies
and by having very lightweight cones in the speakers to improve efficiency. These are then insufficiently rigid and the results are almost always disappointing.
With the high cost of batteries, most of today’s products contain an AC power supply or can be used with an external power supply. A mechanical switch
disconnects the batteries when the external power connector is fitted.
There is no audiophile boombox, leastwise not an old one. They weren’t and aren’t by their very nature, sacrificing pretty much every potential positive
characteristic for portability. Most old ones objectively are bad, and even the best that can be done with modern tech is bad in comparison to real loudspeakers.
The huge compromise in terms of sound fidelity is obvious, given the common audible distortion. Most of the times these devices don’t have an audio input,
so they aren’t useful for our work.
The difficulties of portable loudspeaker reproduction are overcome in personal players which are designed only to drive headphones, but those usually don’t
have inputs either.
524
13.2.3 - FIXED HI-FI CONSUMER EQUIPMENT
Fixed equipment gives much better quality than portable units. The traditional component high-fidelity system can be seen in Fig. 7.12.

Fig. 7.12 – A standard fixed audio setup. We’re interested in the yellow path, as we’ll work with a PC. You should connect it to your setup (if you have one). Single unit Hi-Fi places every
function in one enclosure. Performance is often compromised because the cost of performing every function well would make the unit price high.

A preamplifier acts as a signal selector and has volume and tone controls as well as determining which signals will be recorded/played back. The preamplifier
drives the power amplifier which is connected to a separate loudspeaker. Each signal source is in a separate box.
Signal sources include radio tuners, cassette or open reel tape decks, vinyl disk players and CD players. In stereo systems the same units are present, but
there are two loudspeakers and every circuit is duplicated (to have a separate path for each channel). A balance control is added to adjust the relative level of
the two channels.
The advance of microcircuitry has meant that the bulk and cost of domestic electronics has shrunk dramatically. A lot of hi-fi components are literally near-
empty boxes with a few microchips in the corner. It is not unknown for the manufacturer to incorporate a thick steel plate to make the unit feel more substantial.
An early result of circuit miniaturization was the receiver (US) or tuner amplifier (UK), containing a radio tuner, preamplifier and power amplifiers.
As Fig. 7.12 shows, this requires external speakers and has connections for external units such as tape decks, CD players and vinyl turntables.
The receiver approach was followed by the single unit hi-fi in which everything except the speakers is in a single box. In principle there is no reason why such
a unit should not sound as good as a component system, provided that the same circuitry is used. In practice few people will pay what appears to be a high
price for one box and so these integrated units are normally built to a price rather than to a standard and the loudspeakers are usually marvels of penny
pinching. A dramatic improvement can usually be had by discarding the standard speakers and using better models.
The traditional hi-fi sports a forest of control knobs and is difficult for nontechnical users to wire up and operate. The appearance of a typical system is
unimaginative, especially the loudspeakers which are usually box shaped. The lifestyle audio system has evolved for people who prefer equipment which is
easier to use and which has a more imaginative appearance. Lifestyle systems usually have dramatic styling, few knobs, immaculate standards of surface
finish and “intelligent” remote-control systems.

13.2.4 - HIGH-END HI-FI

The high-end hi-fi market caters for the obsessive customer who often spends more time tinkering and comparing than actually listening for enjoyment.
High-end products are frequently over-engineered, employing massive chunks of expensive materials for reasons which do not withstand scrutiny. Often
a particular shortcoming is ruthlessly eliminated by some expensive technique. Whilst this improvement may be genuine, it is often at the expense of
serious neglect in other areas. Consequently, most high-end installations are unbalanced because too much attention is concentrated in a few places and
because each unit is ‘perfected’ without considering how it will operate in a system.
A common failing is that too much has been spent on the electronics and not enough on the loudspeakers. Precise signals are generated which the loudspeakers
cannot reproduce. Despite the high cost of these systems, their ergonomics are usually very poor and they represent extremely low value for money although
the high cost is usually sold as imparting exclusivity. The alleged quality of these products is not worth the price, exceeding the cost of professional equipment.
A small industry has sprung up producing accessories for high-end hi-fi, many of which appear to defy the laws of physics and all of which operate in the
area of diminishing returns. Naturally magazines are available to cater for the tastes of high-end hi-fi fans. In general these are difficult to read because the
technical terms they contain often mean what the writer wants them to mean rather than what the skilled person would understand them to mean. The term
pseudoscience has been coined to describe this kind of thing. Let’s not talk about the audiophile placebo effect and the sound of cables 78! The take-away is
not that audiophiles are crazy, it's that one needs to have restraint and know when enough is enough. And trying different equipment in person instead of
only reading colored reviews is really the most important part. Blind tests often debunk all the myths.

78
Interconnecting cables, both those that go to the speakers and those that interconnect between the various devices, were for a long time considered completely irrelevant to the sound performance
of a High-Fidelity system. Since the early 1980s several companies have begun to offer special cables for HiFi. To the general amazement and disbelief, audiophiles and trade magazines began to
argue that cables also had a great influence on the sound of a system, and since then it has been an unstoppable crescendo until the follies of the present day when people go so far as to pay as
much as 5000€ (euros) for one meter of special cable. This is the background. What actually matters for a cable is the gauge (diameter of the conductor wire) and the shielding. The only way a cable
can audibly alter the sound is by degrading the signal, especially if too long (over 2 meters), or without an appropriate resistance/impedance spec.
525
13.2.5 – PROFESSIONAL AUDIO: STUDIO MONITORS
Finally some juice. Studio Monitors are a type of loudspeaker with a linear frequency response. It’s mostly flat, so they’re really useful if you want to get a
sound faithful to the characteristics of the input source. The response in the mid and high portion of the audible spectrum can often be adjusted too, based
on the mixing room/desk layout.
These products fall in the professional category as they are employed in recording studios, and also used by audiophiles who want the cleanest sound possible.
A pair of monitors, if correctly set up, can sound better than systems worth tens of thousands of dollars (or euros). I do recognize that they are not exactly
cheap, but still quite affordable (the price range goes from 100 to 1000 bucks more or less, depending on size and brand).
We don’t want to be nit-picky as audiophiles can be (there’s nothing wrong about it, but it’s a rather expensive hobby), so I will give you just an example of a
very good pair of speakers, the JBL 4311 Control Monitors (Fig. 7.13).

Fig. 7.13 – Truly vintage; they were made since 1974 (this is the first version of the 4311). They won’t be elegant without the black covers, but they deliver in terms of audio fidelity.
These are professional speakers in all respects.

They require a good amount of power to be driven, so at least a decent amplifier is required. Nothing too pretentious anyway (50-100 W).
Why did I choose this as an example? Well, because I own a pair of these 4311s and I’ve had a long story with them. This doesn’t mean you have to buy
anything expensive 79, and I’m not here to discuss which one is the best speaker in the world. But these JBL 4311s (and especially the more expensive
models from the 43 series) were very popular in professional studios & cinema theatres, and are still considered a reference point.
If you want a newer alternative, maybe less expensive, you can buy another model of Studio Monitors. There are also consumer models from JBL, like the
L-100 which has the same drivers as the 4311’s. Quite a few revisions have been made of the same 4311 model, so you may find the 4311B, C, G, SE, etc.;
the whole 43 series from JBL includes pro speakers, even bigger and more imposing. I would suggest to buy the later models, as the sound quality did
improve over the years (Fig. 7.14), all thanks to modern computer design simulations.

Fig. 7.14 – (left) The JBL 4312G Control Monitors. As you can see they maintained almost the same style over time. Good things never change. (right) The difference in size and weight
between the new woofers of the JBL L100 Classic (on the left side of the table) and the vintage woofers of the L100 Century (year 1974, on the right side).

These speakers are made to last, not like disposable products with planned obsolescence. The drivers in the later models have passive radiator canals to cool
down the magnets (heat can damage them) when used at full power and the electronics inside (the crossover filter) are minimal as possible.

79
And don’t get scammed on used markets, where people always want to finance their damn bank loans with easy money.

526
This is not advertisement though, so feel free to choose another speaker type or manufacturer if you want. Mine is a suggestion based on personal experience
and on the fact that JBL created the standard for Studio Monitors back in the seventies. It’s part of the history.
As cheaper and simpler alternatives I can recommend the entry level models from the same brand, like the JBL Stage A130, a 2-way stand speaker (Fig. ). It
inherits all the most proven technologies of its big brothers, but offering a good value for money. Otherwise you can go for even less costly products like the
Polk Audio XT15 monitors (Fig.). Polk Audio has always been famous for speakers that produce perfect bass.

Fig. – (left) The entry-level Stage A130 from JBL. (right) A pair of Polk XT15. Their tweeter can go up to 40 kHz.

Nothing will stop you from using the Logitech LS11 (obsolete, the new model is the Z150) or the Logitech Z120 speakers for your PC (Fig. 7.15):

Fig. 7.15 – My suggestion is to avoid such cheap artifacts. They’re not completely scrapped and some can actually be improved with a few fixes 80, but they lack a lot of bass and power81.
If speakers are out of your league, use headphones instead. They need to be good though, and that will be another problem for your wallet.

What you have to be aware of is that the average house speakers or the “home theatre” HiFi loudspeakers are DESIGNED to make just about everything sound
good. If you’re mixing/recording on them and the sound needs more bass or treble, you’re not going to hear what the audio source really needs to be good
at an absolute level, because the speakers are lying to you. They’ve actually been designed to boost the intended frequencies (in order to reduce the resonance
of the wooden/plastic enclosure and to give them a particular “feel”, see Fig. 7.16), so your mix may sound good on those specific speakers, but when you
go play it on another system (like your car, or at your friend’s house) that’s going to sound totally different (and probably bad).

Fig. 7.16 – Frequency response of different speakers. The scale of the plots is not the same, however I tried to align them as much as possible without image distortion. On the left, the
Yamaha MSP5 Studio Monitors, on the right the Celestion G12P-80 guitar speakers. You can see how the treble takes most of the dynamic range on the rightmost graph. The monitors’
delta stays in a ±2.5 dB range instead. This doesn’t mean that the product on the right is bad, just that it’s been tuned, for a particular instrument in this case; it will probably make your
guitar sound very “warm”. This is obviously a design choice by the manufacturer. You can’t do anything about it, other than buying a product that suits your needs.

That’s why studio monitors exist, to reproduce the source with the highest degree of fidelity.

80
How do I know? I own two pairs of the Logitech LS11 speakers. I damped the screws of one couple with paper (you can use rubber too) on the holes inside, tightened them more, and it’s slightly
better than the other ones without dampening. You can also try putting some fiberglass inside too, to make them sound bigger. Spending a couple euros to modify them may be worth it.
81
Don’t even bother searching for the frequency response graphs of these products. They simply do not exist. What do you expect from something made in China?

527
Besides, small speakers can have an excellent sound resolution. This means that the detail is there even at low volume levels. Professional audio is not louder
nor expensive like people usually think. It’s more accurate, and with accuracy you notice defects!
Bigger doesn’t necessarily mean better, but for bass going smaller comes with compromises and disadvantages. When I listen to music I’m not a bass lover,
but cars and particularly engines do have a lot of low frequency sounds, so choose your equipment wisely!
Pro tip: always check the dimensions of the speakers you want to buy/use: they may be too big for the space at your disposal!

In the end, it doesn’t really matter what you mix on (to some extent). To be honest, you can use a hardware equalizer (for a pro reference, see the Behringer
DEQ2496) or a software EQ to compensate the natural tuning of your speakers, bringing them to a somewhat flat sound. This won’t improve their resolution
nor their power.
It’s important to learn which are the audio characteristics of your speakers. Exporting your audio mix and test it on various different systems before finalizing.
Test on your HiFi system, on your earbuds, on your headphones, on your car, etc. What’s important is creating as much as possible with what you can afford.
Do the best you can on what you have and build on it from there. Also, prioritize your investments. If you’re working with a crappy old computer, you should
probably get a new one before buying any other hardware. Take into consideration also buying a PCI-express audio card (even if nowadays motherboards
already have good built-in audio chipsets). Your PC is by far your most valuable asset, because without it you can’t create.
Pro tip: your listening environment is the most important source of resonance and distortion! Quoting Anthony Grimani, an expert in home theatre acoustics and design (his
career includes executive positions at Dolby and Lucasfilm THX):
“It doesn’t matter how expensive the gear is, the room is going to screw it up! And there is no way that a fifty thousand dollar speaker is less effected by a room than a three
hundred dollar speaker”. (Los Angeles and Orange County Audio Society presentation, date unknown)

13.2.6 – HEADPHONES
There’s a lot of confusion on this topic. People tend to generalize different devices with the generic term “headphones”, but that’s not always correct. Let this
guide make some light.
First of all, the developers of Assetto Corsa at Kunos Simulazioni use as part of their setup the AKG K240 MKII headphones, descendants of the vintage
professional AKG K240 Studio Monitors from the 1980s (Fig.).
The K240 has been around for over three decades (they keep making them!) and established itself as a go-to choice for studio owners and audiophiles looking
for reliable audio for mixing, mastering, and monitoring. The AKG brand comes from Austria, and it’s recognized as one of the best headphone manufacturers,
offering professional-grade equipment that includes some of the finest microphones ever made. They definitely earned their trust.
It’s pretty obvious that these are not earbuds that can fit in your ear canal. In order to reproduce accurately low frequencies, which are very important for our
purposes (car engine, wind, ambience sounds), the drivers must be fairly large. The tiny speakers inside your AirPods are obviously a compromise.
In spite of the plastic which most of it is built on, the adjustable head-straps and large earcups are comfortable enough for extended periods of usage. Albeit
on a budget. So the durability of the materials used has been subject to some justified skepticism. Higher-end models incorporating metal on the headband
and suede materials for the earcups like the AKG K701 do offer a much classier feeling. That being said, these headphones are lighter. This helps in the
overall comfort referred to earlier. So the trade-off feels fair enough.

Fig. – (left) The AKG K240 Studio Monitors, designed and made in Austria in 1981. (right) The AKG K240 MKII, nowadays made in China, along with the “new” cable connection.

This might be a good time to understand what ‘semi-open’ or ‘open-back’ earcups are and the pros and cons that come with them.
Long story short, the earcups on these won’t clamp around your head in a vacuum-like enclosure to isolate sound for you and away from the people around
you. They let your ears breathe; as a result there is an organic, more natural perception of sound. They’re also more comfortable. The flip side to this is that
you can only use them in quieter environments where you aren’t disturbed by external noises. Inversely, the sound is easily audible for anyone around you.
The cable is attached with a connector on the left ear. This can be detached and replaced if ever needed, which is a great plus (at least, this is possible in the
later revisions: for the early 1980s version the cable is not removable). The other end can be plugged into all your musical gadgets through a 3.5 mm input.
One thing changed with respect to the 1980s K240s: the impedance of the new products has been reduced from 600 ohms to 55 ohms. So they will be
easier to drive (and probably will work fine, but not too much, on the jack of your phone). NOTE: HEADPHONE IMPEDANCE
528
From basses to low-mids to mids to treble, the sound is flat, neutral, and transparent. This is a fantastic piece of equipment for checking up on a mix where
vocals, guitars, piano, and/or acoustic drums are the main characters. And the clarity it gives you is testimony to why it has established itself as an industry-
standard over the years.

13.2.7 – AMPLIFIERS
I want to talk about the objective hierarchy of importance of different factors that affect sound quality. At the very bottom, as in being the least important, is
the electronics. There is not going to be a huge difference between competently made components.
The most typical configuration for an amplifier is the Lin topology (Fig. ), developed in the 1960s by Hung-Chang Lin, a researcher of RCA labs. With very
little modifications over the years, it is still the dominant power amp layout up to date, as it covers more than 90% of all the semiconductor amplifiers produced
and commercialized (Self D., Cordell B., etc source).
One of the main advantages of this design is the ability, thanks to distinct and mutually coupled stages, to isolate the function of each stage and to manage
the performance control of most parameters that characterize the entire device. Nowadays, with the progress of IC (Integrated Circuits) manufacturing
technology, using discrete components (aka separate transistors, diodes, etc.) is only a choice to be made when an integrated component with the desired
specifications is not available or does not exist, which for audio is not a thing anymore. Thus most of the time there are packages containing all the circuitry
needed, capable of producing signals with a high degree of fidelity, with high power and negligible distortion (Fig. ).

Fig. -

The sound you hear on your vinyl records has probably gone through at least ten IC opamps, in the studio mixers, in the professional analog/digital equipment
and so on. So the “analog” sound theory goes a bit down the drain.
Valve amplifiers add a colour to the sound that can be recreated with a DSP or a very subtle equalization. Musicians use them for their peculiar frequency
response to record instruments (especially guitars and bass) with a warm feel, but any sound engineer would avoid valve amps when mixing. The sound is
already “coloured”, so it is best to not alter it any further (not only for the pleasure of the final listener, but also to respect the intent of the author(s) of the
music piece). Often you can see a guitar player record with a microphone the audio coming straight out of the amp (Fig. ). Now you know why 82.

Fig. -

Being a physical phenomenon, an audio signal follows the laws of entropy, and thus cannot be “enhanced” on its way to the speakers. Anything added to its
path, whether you like or not the result, will introduce losses and distortion. The quality of a component is not measured by how much it can improve
sound, but instead by how much it can be transparent to it. The only deeply meaningful way to improve sound quality is to get a better signal source, like a
better microphone, and more accurate recording/mixing equipment. Then, the simpler an amplifier design is (with less circuitry), the better.
Any amplifier with more than 50 watts will be pretty much overkill for any room listening purpose, unless you want to lose your hearing. The smaller the
room, the less power you will need.

82
And you may ask: but recording audio from the speaker doesn’t reduce quality? Yes, but remember that in a studio there is professional equipment, microphones included.

529
13.3 - THE PRINCIPLES OF VEHICLE SOUND SYNTHESIS
In-car noises come primarily from three separate sources: road/tire noises, wind, and engine/power train. Most of the inputs into our sound engine are
based on accurate vehicle dynamics simulation. For example the engine model uses RPM and torque values from an engine simulation. Without a good
physical simulation of the driving environment it would be impossible to create a realistic audio.
Most audio simulators use a sample-based synthesis approach, also known as a wave table approach. This technique uses a collection of sound samples
that are manipulated and/or mixed to simulate some sounds.
An integral part of our simulation is the use of graphs. The graphs are simply a lookup table that matches input values to output values. Points in between
defined points on the graph are linearly interpolated. The graph files are loaded at run-time; this allows us to change the characteristics of our audio without
rebuilding the sound engine.

13.3.1 – THE SURROUND SOUND AND ASSETTO CORSA

Assetto Corsa uses a 7.1 channel surround mix as baseline, and you will need to set it properly before you export from the FMOD Studio editor.
If you want to listen to your audio the best way possible, a 5.1 or a true 7.1 speaker setup will be the choice, because it will let you listen and control
completely your mix; for example, you can adjust the LFE (Low Frequency Effects) channel separately. Such surround technology can be expensive though,
and it is actually difficult to balance properly in a specific room (Fig. 7.18), so you’d have to learn a lot about how it works (which implies some calculations,
and it can sometimes be a challenge for sound engineers too).

Fig. 7.18 – Simulation of the acoustic pressure field in a room with a quadrophonic setup. Sound reflects all over the place, thus creating interference and distortion.

In most cases our audio sources will be stereo or even mono (usually being videos/samples from the net) even if you can record your sounds from the real
car with a mic, so a stereophonic setup will do the job fine, especially if you learn comparing your audio with the reference standard by Kunos, or with
popular sound mods, and you may be able to obtain even better results if you have good source material. A quadrophonic setup can be used too, but at this
point you may use only the front speakers.
The most important thing during the whole process will be our attention to detail for each sound.
Since most of the interior car noise is in the low frequency range, it is important to have a good low frequency response in any system used. A subwoofer
can come in handy here. This doesn’t mean boombox-like sound. It is important to properly set the equalization, delays and other relevant settings to insure
proper playback. A setup with good loudspeakers and a dedicated amplifier will be a huge step up for audio editing, so if you own HiFi equipment, keep it
ready for use at this point.
Headphones may be used too, but sincerely I prefer the old school approach with loudspeakers. The professional standard doesn’t force you to choose, it’s a
personal preference, but it’s recommended to check the sound you get on both.

13.3.2 – MEANS OF VEHICLE SOUND SIMULATION

In simulators as well as in computer games it is common to represent the sound from a vehicle engine by snippets of recorded sound played in a loop,
where the snippet recorded at a speed of revolution close to the current virtual engine speed of revolution is continuously chosen. While this is a perfectly
valid method for representing sound inside a vehicle, there are some limitations that may become problematic.
First, obtaining the sound snippets themselves is a challenge in itself since the recorded sound is relatively complex. A pure sine tone, which is as simple as
a sound can be, can be divided into snippets by identifying where the recorded sound wave is at its minima, so that the onset and offset of sound coincides
with the sound wave boundaries. As soon as the sound is becoming complex such natural boundaries are difficult if not impossible to identify (Fig.).

530
Fig. - Simple sine tone (left) compared to complex recorded sound snippet (right).

This means that the onset and offset of the sound will be audible as a repeating click. To hide such clicks the sound snippet needs to be slowly faded in and
out, and to avoid silent periods while the sound is being faded another copy of the same sound is started just before the previous has ended, thus cross-
fading between the two.
Second, if the properties of the simulated vehicle are changed, a corresponding change of engine sound requires a cumbersome repetition of the process of
identifying new sound snippets. When their amount is smaller, fewer physical properties that can be portrayed in the generated environment, due to lack of
variety.

13.3.3 - ENGINE SOUNDS

Engine sounds are generally not as loud as road noises when driving, although you tend to notice engine sounds more, especially in sport cars which don’t
have any form of acoustic insulation. Engine noises also tend to be more interactive. In many instances the driver tends to use audio queues for deciding
when to change gears. It is important that our sound model performs fairly accurately, and that matches the vehicle that is being simulated. If the car you’re
driving a McLaren it should actually sound like a McLaren.
Do different cars have different sounds? Yes, but actually no.
Each propulsor has a typical tone that most of the times depends on the frequency of the pistons moving inside the engine block, and their number is a key
factor in determining what type of noise will be produced: we can group engines into these categories:
• Multiples of three
• Multiples of four

wip

How engine sounds can be made in FMOD

The engine sound synthesis mostly uses a wave table technique; Our samples are recorded at set RPM levels. During playback, the samples are cross-faded
depending on their own specific RPM level. In other words, if the current RPM level from the engine model is outputting 1650 RPM, samples taken at 1500,
and 2000 would be played at 70% and at 30% respectively. Each sound sample has its own chart that measures RPM input vs. sound output. The sum of
the engine outputs from each sample should sum to 100% while fading. Each individual sample would also be frequency shifted by a factor of:
𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸𝐸 𝑅𝑅𝑅𝑅𝑅𝑅 𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙
𝑅𝑅𝑅𝑅𝑅𝑅 𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙𝑙 𝑜𝑜𝑜𝑜 𝑡𝑡ℎ𝑒𝑒 𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟𝑟 𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠𝑠

Usually recordings are taken from the manifold and the exhaust. The manifold samples tend to contain more high frequency components, while the exhaust
sound tends to have more of a lower frequency sound. The mixture between manifold and engine sounds is done “by ear” for each cab in professional
simulators.

531
As we can see in the example schematic of Fig., a pure
tone (sine wave) using the pulse frequency can be
added (this is not present in original Kunos-standard
content, but it can help us improve our sound), we’ll
see why. The pulse frequency for a 4-cycle piston
engine is equal to:
𝑅𝑅𝑅𝑅𝑅𝑅
𝑓𝑓 = 𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛𝑛 𝑜𝑜𝑜𝑜 𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐𝑐 ∙
120
The amplitude of the pure tone is determined through
an RPM versus amplitude chart. The pure tone can be
used to give an additional tone where the mixture of
samples is found lacking. For instance some sound
sample sets have a lot of the low frequency sound cut
out. So for lower RPM levels a large pulse frequency
tone can be added in, and as RPM levels increase, the
pulse tone amplitude decreases.

To make the pure tone you can use the sample

generator in Audacity, or ETG (Expression Tone Generator). The latter is also useful if you want to make an engine sound from scratch, with mathematic
functions. An example of a low-rev sound made with ETG is in Fig..

Fig. – With this small software you can create any sound you want from basic trigonometric functions, like sin(x), cos(x) and tan(x). Try copying the formula shown here
and listening to it, that should be a really basic example of an interior engine sound.

You can change the duration of the samples. It is also possible to export the waves obtained with this software in the .wav format. It’s pretty easy to use if
you know the basics of mathematics.

Overall the pitch of the engine sound is affected only by the RPM level, while the amplitude shouldn’t. The amplitude of the engine is controlled by a
combination of throttle position and the torque output. Both the throttle position and engine torque are compared to a lookup tables for a multiplier. If the
torque output is not available a window function is used to filter the throttle position to prevent the amplitude from increasing too fast (not sure if this
happens in the Ac project).

There are some people that don’t like the official motor sound in Assetto Corsa, they watch videos on YouTube saying they prefer the “real thing”. Funny is
that raw sounds would be fatiguing as hell to your ears, remember that race car drivers uses helmet and many also use ear plugs for hearing damage
protection, so they hear the car engine muffled, with rolled off mid and high frequencies, 99% of the time.

I get that one may want more unfiltered engine sounds but very few titles have truly superb sounds, and most of those have vast libraries of reference
material and expertly engineered samples. The amount of money invested in recording quality reference sounds and engineering samples alone probably
exceeds AC's entire development budget.

I also think that, with the huge amount of cars in AC, Kunos just was not able to spend much time on the mixes for each car. Sometimes I spend months or
even years to get the sounds to perfection in my ears, and still there is room for improvement.

13.3.4 - PASSING VEHICLE NOISES

Passing vehicles sounds are composed of three components: aerodynamics noises, engine/power train noises, and road noises. These sounds also have a
Doppler shift applied to them. Fortunately, FMOD has functionality for handling the Doppler Effect.

Assetto Corsa provides the speed, direction, and position of the listener and sound source and FMOD performs the necessary frequency adjustments.

532
For simplification, a much simpler model for the road and engine sounds is used. For the engine sound, each vehicle is given an engine sound and an
adjustment value for the engine volume. The engine samples are usually taken from vehicle exhaust and generally match the vehicle type. The amplitude of
the engine sound is adjusted using the speed of the vehicle.

Tire sounds are handled similar to engine sounds. A simple generic road sound is used for passing car sound. The volume of the road sound component is
adjusted by the size and speed of the vehicle (again, needs to be verified, however you can use directly the sounds already in the kunos Fmod project).

Aerodynamic sounds are adjusted for the speed and size of the vehicle. The speed for the wind sound is calculated as the relative speed of the vehicle from
the participant’s vehicle. A “sound cone” is used; it is a directional sound source supported by FMOD.

The programmer can specify a degree and width that the sound is projected from the sound source. The sound cone can be placed slightly ahead of the
passing car and projected towards it. This gives the effect of the interaction of the turbulent wave of the passing vehicle.

13.3.5 - WIND SOUNDS

Wind sounds come from aero-acoustic interaction of the vehicle with the atmosphere. In a typical passenger car, these sounds tend to be transmitted into
the cab from the windshield, passenger windows, and from the front A-pillar. Automotive designers tend to spend a lot of time trying to reduce the amount
of wind noise a car produces as well as ways to reduce how much of the noise is transmitted into the cab.

Automotive designers tend not only worry about the amount of noise that is produced, but also the harshness. A highly irregular wind noise that frequently
changes pitch and amplitude, caused by say buffeting, can cause a much greater level of annoyance to the driver than a noise with a consistent sound.

Aerodynamic sounds produced by automobiles are a very complicated subject. They are complicated fluid-dynamic events; as on-coming cars pass each
other their turbulent wakes interact. Modelling these systems in real-time would not be practical. Given these limitations, AC devs decided to use two
recorded samples of wind sound at different pressures for each car, taken at an unknown speed (for now). Look at Fig.

Fig..

Typically, recordings of in-car wind sounds are done within a wind tunnel. We don’t know if vanilla AC wind sounds come from one of those facilities.

We can also consider that a shotgun microphone pointed at the windshield or side windows during a real world drive with a passenger car could have been
used. The alternative, which is also the most plausible option within official sounds, is creating a reasonable sound with randomly generated noises.

For the random noise we can simply take a white noise generator
and apply a low-pass filter with at around 600Hz with the Q value
set at 1. The Q value affects the steepness of the roll-off slope.
The higher the Q value the steeper the slope. FMOD’s low-pass
filter supports Q values from 1 to 20. The frequency of the low
pass filter is gradually increased with speed of the vehicle, up to
a maximum of about 700Hz. Also a random value between -50 to
50 will be added to the low-pass filter at the rate of 120 Hz. This
randomization helps to simulate turbulence, and harshness.

The amplitude of the wind sound is increased at an exponential

rate with the speed of the vehicle. Through wind tunnel testing
with a typical passenger car, in-car wind sounds generally
increase by about 4db per 20 km/h or approximately 12.5 mph.
Also, a car traveling at 120 km/h (74.5 mph) presents a sound
pressure level of around 73 db (A) (source). Generally try to
match that value. Look at the graph in Fig. for the generic output
of wind sound generated by the audio engine, with the use of white noise.

The result should have the same tone of a brown noise. In audio engineering, electronics, physics, and many other fields, the color of noise or noise
spectrum refers to the power spectrum of a noise signal, produced by a stochastic process (a random function). Different colors of noise have significantly
different properties. Brown noise is not actually named after the color; the name comes from the fact that the signal mimics the “random walk” pattern
produced by Brownian motion, or the random movement of particles in liquid.

533
The practice of naming kinds of noise after colors started with white noise, a signal whose spectrum has equal power within any equal interval of
frequencies. The United States Federal Standard 1037C, titled “Telecommunications: Glossary of Telecommunication Terms”, defines white, pink, blue, and
black noise.

White noise:
White noise is a signal (or process), named by analogy to white light, with a flat frequency spectrum when plotted as a linear function of frequency (e.g., in Hz). In other
words, the signal has equal power in any band of a given bandwidth (power spectral density) when the bandwidth is measured in Hz. For example, with a white noise audio
signal, the range of frequencies between 40 Hz and 60 Hz contains the same amount of sound power as the range between 400 Hz and 420 Hz, since both intervals are 20 Hz
wide.

Fig. – Frequency spectrum of white noise.

Brown noise:

Pink noise:
For audio testing, a pink noise source is an invaluable tool. It is essentially a flat frequency response noise source, and will quickly show any anomalies in speaker systems,
room acoustics and crossover networks.

USEFUL TOOLS IN FMOD (WIP)

The loudness meter of FMOD. It can be used to check the audio levels.

(wip)

At this point you have two alternatives: make the soundbank almost from scratch, or copy it from a pre-existing car. We’ll consider both options.

534
13.6 - RECORDING SAMPLES
How to record audio from a car? I think there will surely be people interested about this, especially if the car mod being created is the owned vehicle. It’s just
easier sometimes to record samples if you already have it available every day, as too often the sources online do not offer a decent enough quality (or they
don’t have the specific sound you’re searching for at all).
The following paragraphs will dive deeper into this subject, from the devices you need to the proper techniques to capture the sound of real vehicles.

13.6.1 - AUDIO RECORDING INTERFACES AND CONNECTORS

We’re going to talk about recordings, acknowledging that there are various ways to create them, either with analog (reel-to-reel tapes/cassette tapes) or
digital devices (DAT: Digital Audio Tape, PCM recorders, etc.), so we’ll take for granted that after an analog recording you’ll have to use an A/D converter
(analog-to-digital, also called ADC) to obtain actual digital samples to use on your PC. If you have such a device, you will be able to connect any analog
source (for example a tape/cassette deck, but also a microphone) and record audio from it with a program like Audacity.
Since the late 1980s-early 1990s, Personal Computers started to include ADCs, incorporated in optional add-in sound cards 83, as the latter were becoming
more and more popular since their first iterations. Audio cards can not only play, but also record sound.
The quality of the microchips and the electronic circuits has been continuously improved in the professional field. As a consequence, today also the average
consumer equipment can be considered enough for our needs. However, if you want more quality from your system, you can still purchase a separate
internal or external card. It will likely have less background hum thanks to additional filtering circuitry, and a higher S/N (signal to noise) ratio. But it’s not
really worth the expense unless you’re a musician/producer and you want the absolute best.
Large desktop or office Windows machines typically come with a sound card integrated in the motherboard and connections such as coloured jacks (Fig.).

Fig. – Rear panel of a motherboard. These jacks allow the connection of up to eight speakers: with proper configuration in the device driver’s settings, this integrated sound card can
indeed output the signals for a 7.1 channel surround system.

The colours are standardized by the PC System Design Guide 84. Let’s take a look at them.
- Green is generally stereo Line Out. High level stereo sound comes out of this jack and you can connect it to small stereo speakers, earbuds, stereo
headphones, or a lead to the "AUX IN" on your large stereo sound system, or larger amplified computer speakers.
- Blue is the next and it's usually stereo Line In. This is the connection that will accept sound from a line-level stereo sound device such as a stereo mixer,
cassette or reel-to-reel player, the analog connections of a USB turntable, the headphone output of an MP3 Player or even a CD or DVD player - portable or
not. Microphone preamps and guitar pickups fall into this group even though they're not stereo.
Both Line-In and Line-Out can be connected to other sound equipment with a stereo jumper cable or a stereo adapter cable or other adapters as needed.
- Pink is last and is usually Mic In. It's mono, not stereo. It can be used to connect the following types of devices:
• headsets with dedicated microphone jack
• condenser / dynamic / ribbon / multi-pattern / bass / shotgun / boundary / lavalier / cardioid / bidirectional / omnidirectional and every other kind of microphones
• (not preamplified, RIAA equalized) monophonic vinyl turntable with MM (moving magnet) or MC (moving coil) head
• any mic-level device not preamplified to line level
The last element of the previous list lets us ask a question: What is mic level compared to line level?
A mic-level or microphone-level signal describes the voltage generated by a microphone when it picks up sound, typically just a few thousandths of a volt.
This voltage varies in response to changes in sound level and distance. Of the main types of audio signals, mic level is the weakest. Microphone level is
usually specified between -60 and -40 dBu. (dBu and dBV are decibel measurements relative to voltage). Thus the Mic In jack always carries special internal
wiring for the amplification of the signal to bring it up to line level, and it is designed to be sensitive to a very low voltage.
A line-level signal instead is approximately one volt (typically 1,2V maximum), about 1000 times stronger than a mic-level signal, so the two do not
ordinarily use the same input and should not be mixed together. The line signal is used to standardize the audio levels. It is the same kind of signal that
travels from your pre-amp to the amplifier that powers your speakers.
There are two standard line levels:
• -10 dBV for consumer equipment (HiFi system)
• +4 dBu for professional equipment (mixing desks and signal processing gear)

83
Some of the most popular: AdLib PCMS (1987), Creative Labs Game Blaster (1988), Roland LAPC-I (1988), Creative Labs Sound Blaster (1989), Gravis Ultrasound (1992), Creative Labs Sound
Blaster 16 (1992), Creative Labs Sound Blaster AWE32 (1994).
84 Compiled by Microsoft and Intel between years 1997-2001, also known as the PC 97, PC 98, PC 99, or PC 2001 specifications.

535
If you plug a stereo signal intended for the Line level into the pink jack, you may be missing the right channel, and the left channel (commonly used for
mono sound) has a good chance of being too loud, horribly distorted, crackly, popping or crunchy. There is no recovery. Because of the way microphone
connections work, you usually can't simply adjust your way out of trouble and there are no tools to repair the damage. You may never get the right channel
recorded at all.
There is usually a lot of confusion about this, because the connector is the same, but they DO NOT have the same PURPOSE. Never plug a LINE level device
to the MIC IN jack!
Other jacks, which you can see in Fig., may be missing. This is based on the specifications of the sound chip: if only stereo systems are supported, the
additional connections (e.g., 5.1, 7.1 surround channels, including center/rear/side/subwoofer) are not required.
Pro tip: the headphone out jack exists too, and is often confused with the Line Out. It is amplified and thus designed for high impedance headphones (e.g. 50~600 Ω), so if
you have the connector on your motherboard, use it! The line output is too low for those. Earbuds typically have a low impedance instead and you could connect them to the
Line Out jack, however always prefer the headphone out if available.

It's common for Windows laptops to be missing the blue jack (Fig.). Some laptops have a blue jack, but those are not common. Another recent arrival is the
"Mic Line-In" (Fig.). That's usually a combined mic and line input jack, switchable via the system options. Read your PC’s user manual if you have any
doubts.

Fig. – (left) This laptop has got only headphone out and mic in jacks. (right) Either this is done to save a few cents on the connector, or it’s just fancy stupidity with OEM non-
interchangeable parts (the board does not even follow the ATX standard).

If you don’t have one, you can artificially create a "blue jack" or line stereo input with an external USB sound device such as the Behringer UCA-202, or a
cheaper USB dongle that you can trust very deeply. The same is valid if you don’t have any audio features on your PC (imagine a server motherboard). But
at that point you’re better off buying a sound card directly.
To connect the PC to a loudspeaker sound system a 3,5mm jack to RCA adapter shall be employed (Fig.) along with proper cables.

Fig. – Both adapters work fine. I prefer the second one, as it gives more freedom of movement, and the jack is usually of a better quality.

Obviously some cards do feature other types of connections, like balanced XLR: most of the time it’s just a matter of choosing the correct interfaces/adapters.
You can use digital connections too, those are even better.

13.6.2 – AUDIO RECORDING DEVICES: MICROPHONES

536
13.6.2 – SOUND RECORDING PROCESS
Since the end product of any sound reproduction system can only be as good as the original recording 85, emphasis has to be placed on creating the highest
quality samples possible.

The samples that would be required for the new system break down naturally into two main areas of interest: cab-specific sounds (such as engine and
power train) and external sounds (such as road noise, autonomous vehicles, and environmental audio). While the cab-specific recordings would be tailored
to specific vehicle types, external sounds would be generic recordings that could be used in any scenario.

The tendency is to use stereo miking, as close-miking in mono can result not only in an unnatural-sounding magnification of detail, but also in tonal
imbalances such as overly bright tones, sibilance, boominess.

13.6.3 – ENGINE SOUND

Using two pairs of microphones and a portable digital recorder, samples can be taken at the exhaust pipe and engine manifold of specific target vehicles.
These two sample sets are combined at playback to create a realistic reproduction of engine noise.

Ideally, engine samples would be recorded using a vehicle mounted on a load cell dynamometer. A commercial dynamometer is not always available, so in
such a situation, all engine sounds have to be recorded using a stationary vehicle in neutral, with load to be induced artificially at playback.

RPM levels can be captured at 500 RPM intervals, from idle through max RPM, using two recording “nodes” (each comprising of a discrete left and right
channel) and a portable recorder.

At each recording node, a pair of matched microphones are set up in an ORTF configuration. ORTF combines the characteristics of volume difference
(provided as sound arrives on- and off-axis at two cardioid microphones spread to a 110 angle) with timing difference (provided as sound arrives at the two
microphones spaced 17 cm apart). Since the cardioid polar pattern of each microphone rejects off-axis sound, less of the ambient environmental
characteristics are picked up, thus creating an accurate representation of isolated sound in less-than-ideal surroundings.

Fig. - An Illustration of the ORTF stereo recording technique.

Normally the mixing and mastering phases involve transferring all four channels via an AES/EBU link to an audio workstation. You will do it with your PC.
Using an off-the-shelf audio editing program, the left and right channels are combined and normalized into two sets of looped, stereo WAV files; one set for
manifold sounds and another set of corresponding exhaust sounds. As necessary, equalization is applied to compensate for anomalies.

Fig. - The signal path for recording engine sounds.

13.6.4 – EXTERNAL SOUNDS

External sounds are very straightforward to record. Depending on the source and circumstance, multiple techniques can be used.

It is possible to record the large majority of environmental recordings (such as ambient sounds) with various omnidirectional microphones, since specific
positioning and orientation information were not required. Recorded channels are transferred to the DAW, where multiple channels are mixed, bounced
down to a single track, looped, normalized, and saved as a stereo 48 kHz WAV file.

Specific external sounds (such as tire/surface interaction, passing vehicles, etc) can be captured, again utilizing two KM 184 microphones in an ORTF
configuration to maintain a good stereo image. Similar to the recording of engine sounds, specific external audio is recorded on two discrete monaural
channels, looped (if necessary), normalized, and mixed into a single stereo 48 kHz WAV file.

85
Don’t forget about the playback devices though! See paragraph 7.1.1.

537
13.7 – EXTRACTING AUDIO SAMPLES FROM A SOURCE

13.8 - CREATE A CUSTOM VEHICLE SOUND WITH SAMPLES

FMOD is a sound engine that can greatly enhance the audio compartment of our simulator. It is also quite difficult and complicated to start with. That's why
the AC dev team has prepared and shared with the modding community a complete project with additional instructions on how to work.

The following paragraphs will explain how to build a sound bank, starting from the aforementioned example. The knowledge about the basic functions of
FMOD Studio is important, so it is recommended to read the official FMOD Manual; however, the most important features for our job will be illustrated here
too for completeness.

13.8.1 - STARTING WITH FMOD

Use only FMOD 1.08.12, as recommended at the beginning of this manual. To be fair, it works with 1.08.13 too, but newer releases of the software lack
some plugins required by AC (Fig. ). If you don’t use the correct FMOD release, you may encounter an error (Fig.).

Fig. 7. – (left) Plugins missing in newer Fmod releases. (right) This error is due to the missing Distance Filter plugin.

In order to get the software, you shall register an account at the official website (https://www.fmod.com) and log in, then go to the downloads page, choose the
version you need and download it for your OS (Fig.).

Fig. – The FMOD download page after logging in with your account.

Since an email is required for the registration, you may not want to do it. To solve this problem, in the attachments of this manual there are the installers of
the release 1.08.12 for Win 32-64 bit and Mac OS systems.

538
Open the AC project file

wip

Setting the proper Project Platform:

Go in the “Edit” menu and select “Preferences”. Check that the “Desktop” platform is configured like the picture below:

Fig. -

13.8.2 – EVENTS AND PARAMETERS

FMod Studio works with Events and their Parameters. Some are mandatory for Assetto Corsa in order to make the sound bank work, some are optional and
depend of the car type. For example, a Lotus 98T (Fig.) has no doors, horn and so on, so the related Events can be omitted.

Fig. – The Lotus 98T as portrayed by AC.

The project example brought to you includes all the Events supported in AC, so you can make practice and experiment different methods to achieve the
same result.

539
The first thing to remember is that some Events work as "global", because they are common for every car, original and modded ones. In order to make the
sound set as much customizable as possible. Many events are car specific, such as the skid sound, brake whistle, wind and tyre rolling noise, transmission,
turbo, rev limiter, traction control and so on. Just as an example, you have the freedom to assign a different tyre squealing sample depending of the car.

There are several ways and techniques in FMod that allow you to achieve the same results; some are better, some are easier. It's up to you to find the way
that meets your tastes and needs, but above all, keep it simple!

In Fig., you can see all the global events made by Kunos’ sound designers.

The events are divided in three folders, for better reading and organization. Taking surfaces as an example, you can easily
understand that kerb, grass, extraturf and sand are global sounds that are applied to all the cars in the game, even the ones
made by 3rd party / modders.

The showrooms deserves a separate discussion: modders will be able to add their own soundtrack for a new showroom.
We'll see how to achieve this, at the end of this guideline.

IMPORTANT: Please take extreme care of the names syntax and folder structure, an error will make the game crash trying to
load the related sound bank.

Fig. -

The following table contains the whole list of Events, with related Parameters and short description. It is also indicated which Events are mandatory (required
by the audio engine to work). The other are optional.

EVENT NAME EVENT DESCRIPTION EVENT PARAMETER PARAMETER DESCRIPTION RANGE MANDATORY
rpms engine rpms 0 .. as needed yes
throttle gas pedal position 0 .. 1 yes
engine_ext exterior engine sound
Distance (built-in) 0 .. as needed yes
Event cone angle (built-in) 0 .. 180 yes
rpms engine rpms 0.. as needed yes
engine_int interior engine sound
throttle gas pedal position 0 .. 1 yes
bodywork car body sound susp_travel_speed suspension travel speed 0 .. 1 yes
gear_ext exterior gearshift sound state down / up 0/1 yes
gear_int interior gearshift sound state down / up 0/1 yes
speed car speed 0 .. as needed yes
wind wind noise
air_pressure air pressure on the car 0.8 .. 1.5 yes
brake brake pedal position 0 .. 1 yes
wheel tire rolling noise speed car speed 0 .. as needed yes
inflation tyre inflation (puncture) 0 .. 1 yes
skid_int tire skid sound for gameplay views yes
skid_ext tire skid sound for track camera views (F3) yes
gear_grind sound when miss shift no
backfire_ext exterior backfire throttle gas pedal position 0 .. 1 no
backfire_int interior backfire throttle gas pedal position 0 .. 1 no
horn car horn no
door car doors state close / open 0/1 no
tractioncontrol_ext exterior TC sound decay no
tractioncontrol_int interior TC sound decay no
drivetrain_speed drivetrain speed 0 .. as needed no
transmission transmission sound
throttle gas pedal position 0 .. 1 no
boost boost (in bar) 0 .. as needed no
turbo turbo sound
bov blow off valve pressure 0 .. 1 no
limiter rev limiter sound decay no
Tab. X

FMod's built-in parameters are always optional and are well explained in the official FMod manual.

Sound emitters position

Each event in tab.X is related to an emitter with respect to the vehicle. It’s basically a “sound source”. In Fig., each emitter position related to the car is
described.
540
Fig. - The Tatuus FA01 is taken as example.

541
Before proceeding with the project, please define the engine position through the related parameter located in the data\sounds.ini script:
[ENGINE]

% ▲▼ Optional. If this section is not present, the engine sound emitter is on the CoG of the vehicle. It is recommended to add these lines in your script
and input a correct value.

POSITION=rear ; Position of the engine sound relative to the car’s configuration. Available options: front, rear.

The above is required in order to set the correct emitter position regarding the engine sounds. Important note about the “rear” engine emitter position: as
reported in Fig., it is located 0,5 meters ahead of the rear axle, in order to cover reasonably both cases of mid-engine and rear-engine vehicles.

13.8.3 – THE AC FMOD PROJECT

IMPORTANT!

Don’t modify the existing sound set example in the project, but create a new folder under “cars” event folder.

Right click on the “tatuusfa1” folder, select Duplicate and start your work on the new generated folder (Fig.).

Fig. – Pay attention to the name you give to your copy of the event folder. It must be identical to the mod’s FIN folder name we talked about in par. 1.2.

This will create different GUIDs.txt strings, so modders will not overwrite sounds each other as happened in old AC versions due to identical GUIDs strings.

Now let's start working on the FMOD Studio project. The example in the SDK provides the Tatuus FA01 project, with transmission and turbo noises
emphasized on purpose and with fictional backfires, so you can experiment all the events available in Assetto Corsa (exception made for the gear grinding,
as this car has a semi-automatic gearbox).

In the Event list there's a parent folder named cars (Fig.) that is mandatory in order to make the sound bank work once
built.

It is necessary that the car's events folder is equal to the car folder name located in Assetto Corsa/content/cars path.

For a better understanding, start from the interior engine samples. The operation is very easy: each sample is triggered
in the rpms parameter and needs an autopitch automation related to their own natural rpm reference. Volume between
engine load and coast is made by a throttle volume curve.

The other events basically work in the same way. Experiment with the provided example project, the operation is very
intuitive.

Do not edit priorities and polyphony of the events. Wrong settings could end in disappearing or stuttering sound.

Fig. -

542
The following picture (Fig.) shows how the engine_int event is structured. There are two tracks, named "fa01 load" and "fa01 coast". The first one contains
the sound samples when the gas pedal is pressed, the second one when the gas pedal is off.

As you can see, there are various samples, recorded at different RPMs of the engine.

Fig. – Crossfades can be used to create a transition between different samples. This is the standard Kunos workflow.

(replace pics)

Pro tip: the interior engine volume for official cars usually peaks to -9dB in the output mixer (Mixer window). Exterior sounds are a little bit louder (+1/+1.5dB, depends of the
car). In order to have a consistent behaviour between official and modded cars, please take this in account.

If you don’t want to hear the transitions between different samples, you can completely avoid using FMOD’s crossfading effect (see Fig. 0.0 above) and do all
the work with an external audio editor, to create a single full track (Fig. 0.0) that eliminates any of the possible issues related to the aforementioned effects,
like phasing. You will be able to align all the sounds separately and they will not phase, even when all on top of each other.

Fig. – This engine_ext event has got multiple samples for the exhaust (yeah, you can add tracks). The entire sound is covered with full tracks and no crossfadings. The same technique
can be applied to any other event in your project.

543
13.8.4 – BUILDING THE SOUND BANK
In order to make your project working in game, it is necessary to create and build a sound bank. The creation of a bank, as reported in the FMod manual, is
very simple: select all the events of your new car, open the context menu with right click, select "Assign to Bank", then "New Bank" and confirm (Fig. 0.0).

Fig. -

Remember that the bank must have the same name of the car folder.

In the Banks tab, the result will be like in Fig..

Fig. – FIX PICTURE

Then open the File menu and select "Export GUIDs...". The result file "GUIDs.txt" is located in the "Build" subfolder of the FMod project.

Now is time to build the sound bank: open the File menu (or right click on the related car bank in the “Banks” tab) and select "Build..." and the building
process will start.

The bank file will land in the "Build/Desktop" subfolder of the FMod project (Fig.).

Fig. – FIX PICTURE

Please note: a *.strings.bank file is also generated, but it is not needed unless you need to use the FMOD profiler in order to monitor channels.

544
13.8.5 - EDITING THE GUIDs
The generated “GUIDs.txt” contains ALL the events, the mixing groups and other settings of the FMOD project, but only the ones related to your car (plus
the “bus” lines) are needed.

Please open the file with a text editor and remove the unneeded lines. At the end, it should appear like in Fig..

Fig. – The lines are not folder names, they just refer to the events that a car generates. So AC loads the bank with the right filename, then uses GUIDs.txt to associate events with the
sounds in that bank. For example, a car named mazda_mx5 will play mazda_mx5/shift_up when it shifts. The GUID itself refers to the sound bank.

As you can see, all the lines related to “showroom”, “surfaces”, “collisions” and so on were removed because it is supposed that they are not modified by the
modder. Done that, please save the file.

Copy both files (the modified "GUIDs.txt" and "your_car.bank") in the related "sfx" folder of the car and check that the new sound works in game.

AC only loads sound banks that are in the folders of cars you use in the race session; if you only load two cars together then it'd be fine to share identical
GUIDs across them (eg. have mazda_mx5_s2/shift_up use the same GUID as mazda_mx5/shift_up), but then if you don't load the "base" version, you won't
get sounds. That’s why if some cars have the same sounds, you CANNOT put the soundbank only in the first one and omit it in the other.

Each car must have its own .bank file with the corresponding GUIDs.

What if the .bank does not have a GUIDs.txt file?

There's a default one that Kunos soundbanks use, that lists all their GUIDs. \steamapps\common\assettocorsa\content\sfx\GUIDs.txt

13.8.6 – MIXER
Fmod's mixing is very powerful, but at the same time it can be painful as the project grows up and becomes complicated. Try to keep it as simple as
possible.

545
 The necessary Mixer Groups are already provided in the example project. Keep the original mixer structure for your audio
project, otherwise sound will not work in game. Don't remove any of the existing mixer groups and don't change their name.

Looking at Fig., it is straight-forward that you can change every single group volume by just selecting it and tweak the
related volume slider. This is very useful if your project contains multiple cars. According to this design, an interesting idea
is to distinguish wheel and wind noise between open and closed cockpit/wheels cars. Since the provided one is an open car,
its wind and wheel events volumes are managed in the appropriate mixer groups. If you are building a closed cockpit car,
you can assign its “wheel” and “wind” events to the proper “grp_wheel_closed” and “grp_wind_closed” mixing groups, in
order to manage both volumes separately.

Surfaces, showroom and other “common” events are out of any group (so they are in the "Master Group").

When you make your project, please double check that the events are routed in the right mixer group as reported in picture.
This is very important.

Fig. -

8.8.7 - SETTING UP AC FOR SOUND MODDING

All the audio levels shall be set to identical values (Fig.). You don’t know which preferences do people have, so your audio must be balanced.

Fig. – Example of incorrect setup.

all soundmods should be tested in the end with spectrum analyzer to see if you don't peak at max volume.

Careful with the loudness equalization in Windows.

AC can try to go beyond peak db if compressor is removed from masterbus

546
13.9 - USE AN EXISTING SOUND FROM ANOTHER VEHICLE
I mean, you really want to skip everything huh? I guess you don’t have much time, but if every car in AC had the same sound people would’ve complained a
lot, right? You should make a custom sound for your vehicle in the future. I’m not here to judge anybody though, so let’s get to it!

The whole process is pretty quick and easy. We’ll start in a completely vanilla way; using Content Manager everything will be even faster. Both methods are
included in this manual for completeness and because I can.

13.9.1 - FULLY VANILLA METHOD

This method is dedicated to people with vanilla AC, so no CM and mods. No special software is required; the MS Windows system tools will do the job fine.

The steps are:

1. Open the MS Windows File Explorer (there are many ways to copy files from a folder to another and the command prompt can be used too, but I think
that would just be an unnecessary complication).
2. Choose the car you want to take the soundbank from. You should pick a vehicle with a similar engine configuration. Keep in mind that official cars don’t
have some types of engines, like 8 cylinders (If this is false I will fucking kill myself), so you’ll have to do some compromises.
3. Open the GUIDs.txt file text editor and

13.9.2 - CONTENT MANAGER METHOD

This method is so quick you’ll be able to change 30 sounds in a minute if you want.

Be careful not to replace the sound of cars you wanted to leave untouched! Doing things too quickly can lead to errors, and you don’t want to reinstall
everything just because you accidentally overwritten your Porsche 911 Carrera Turbo sound by mistake.

13.10 – HOW TO INSTALL SOUND MODS FOR VEHICLES

547
CHAPTER 14 - RELEASING A MOD
If you think of sharing your mod with other people on the internet, please read CHAPTER 8 in its entirety. Knowledge doesn’t hurt, right?

14.1 - PACK YOUR FINAL MOD

At this point of your journey, you’ll need to archive your mod into a single file, ready to be uploaded and shared; you may have already packed the data
folder into the data.acd file (more info at chapter ), even though that’s not mandatory.

In order to do this, you can choose any software you like that creates and manages compressed files/folders; some are mentioned under THE TOOLS YOU
WILL NEED, see pag.; for our example below, we will use 7-zip.

These are the main steps:

1. Create a folder in your Documents (or where you’re comfortable the most on your PC) dedicated to your mod. In this example the path will be called Documents\YOUR
CAR ARCHIVE.
2. Make sure one last time that your vehicle works in the simulator. You can also check whether it’s compatible with vanilla AC or not, in case you used CSP features, by
disabling the patch temporarily. If it is not compatible, you should specify it afterwards in the README.txt file of step 7.
3. If the mod works, make a backup copy of the FIN folder (we talked about it at par. 1.2) anywhere you want. This is not mandatory but it’s a precaution due to the next step.
Actually, always backup your work often, you never know when you may lose your data. Prevention is the remedy to any issue.
4. Remove from the FIN folder any file that isn’t required as obsolete, considering your development history; this includes things you made in the past that you consider
wrong or simply outdated, like multiple versions of data files you have been working on, for example drivetrain.ini.old, tire_v75.lut.old, brakes.ini_v3.old,
old_neon_lights.ini, or unused textures and skins. This is also your last chance to fix (or hide???) any mistake you made. You can move the obsolete files in another path
if you want to keep them, but it must be located outside of the mod’s folder you want to share. This is basically a clean-up operation to reduce the final archive size to the
bare minimum.
5. Check again if the mod is still driving fine in Assetto Corsa.
6. Copy the FIN folder you just cleaned under the path mentioned in step 1; see Fig. 9.0, where we continue from our example at par. 1.2.

Fig. 9.0 – These are the contents of your definitive archive. You can choose any name you want for the folder in your documents, but keep things simple and recognizable.

7. You can add a README.txt file where you put the mod’s credits or other instructions (Fig. 9.0 & 9.2). It can be created with any of the suggested text editors.
8. If you want to add extras, for example manuals, brochures or other documents in the .PDF format, along with pictures, it is recommended to create an EXTRAS folder for
them (Fig. 9.0). This way you increase the size of the archive though. It is not advised to include extra files for a total bigger than 20MB. This is more than enough for any
brochure/catalogue/showcase of the mod you may include.
9. Pack the entire folder in a compressed archive. If you have 7-zip installed with the File Explorer context menu, you can follow Fig. 9.1. If you don’t have the context menu
enabled, just open the software, navigate to the folder and click on Add. With other programs it’s almost identical.

Fig. 9.1 – If you choose Add to archive…, you will be asked few parameters (which you can leave to default) and you will be able to add a password or change the compression
method and the name of the archive before its creation. The other two options, highlighted in red, create the archive directly with the name of the folder. Choose the .ZIP format instead
of .7z if you want to offer more compatibility with other (and older) programs.

10. You obtained your archive. Share it anywhere you want.

11. If you want to be extra careful, you can test your mod on another system with an AC install (the PC of your colleague, brother/sister, friend, etc.). Otherwise, you can ask
people if they want to be your beta testers. This part depends on whether you want to make your unfinished product public or not.

At times you will have to include more files and folders outside your FIN folder, for example if you created specific fonts for your vehicle displays (under the
assettocorsa\content\fonts folder, or used custom/new shaders (for examples of those, see pag.), or anything else. In that case, just recreate the folder tree
starting from the AC install location, to include all the assets in a single folder (Fig. 9.2).

548
Fig. 9.2 – Everything is under the content and system folders typical of AC; thus, they can be extracted directly to the simulator’s install folder. As you can see the README.txt file has
been included correctly too. There aren’t extras, but if needed they can be added.

Many files can be left missing with tunes and custom versions of official content, where you already have the vanilla models, while only the data files have
been heavily edited or recreated from scratch (Fig. 9.3). This can be done in order to reduce the download size, and to avoid sharing official content illegally.

This may create some trouble for people who do not own all the DLCs, but this manual is for the Ultimate Edition of AC, and technically it’s an end-user
problem, so mod creators should ignore those people. Sharing official content is worse than trying to satisfy everyone’s requests, especially when the
majority of users has already got the full version of the simulator.

Fig. 9.3 – On the left is a customized version of a vehicle that was originally part of the official content. This kind of mod requires you to copy the 3D models from the original
Alfa Romeo 33 Stradale by Kunos in order to work. This is good because the models don’t have to be shared illegally online. However there are some things wrong: the
brand, the logo and the power curve (the car has a higher power spec but the graphs and the torque values are identical); the author credits are almost right, next time write
Kunos instead of ks.

549
14.2 - YOUR BOUNDARIES AS A MOD CREATOR
Thank you fellow reader for getting this far in my guide. The following paragraphs are here to clarify some of the mechanisms that trigger when you share
your mods with other people. I have done some research on what you will read, however take it critically.

14.2.1 – COPYRIGHT, LICENCES AND MODEL RIPPING (CONVERSIONS)

Let’s talk about game assets and copyright now. It may be interesting, as there are a few things you should keep in mind before releasing your mods to the
public.

According to the World Intellectual Property Organization (WIPO), intellectual property:

“…refers to creations of the mind, such as inventions; literary and artistic works; designs; and symbols, names, and images used in commerce."

It is a blanket term for a variety of assets created by the mind otherwise classified as intangible property. The rights to the intellectual property can be
claimed exclusively by the creator or recipient of ownership transfer and covers the expression of an idea rather than the idea itself.

Intellectual Property law includes ways to protect the creative expressions of the intellect that carry commercial and moral value. There are several types of
intellectual property including:

• Trademarks
• Patents
• Industrial designs
• Copyright

First, copyright is the protection extended to the creator of an original work. It provides the sole rights to the use and distribution of the work and normally
ends after a specific period of time. As the creator of your work, you have the right to control all the different ways it’s put out into the world – and a license
is simply the permission you give to another person to use your creations and to define the boundaries of how they may use your work.

Strictly speaking, permission is required anytime someone uses something you have created. Many of these licenses are informal- a friend asks to use a
picture on his website and you say okay; or implied- someone uses an image in an article about you and you make no objection. These informal agreements
or uses are okay because under copyright law, the rights holder is not obligated to act in every case of infringement, and failing to act does not jeopardize
the copyright holder’s status as the rights holder. Unlike other forms of intellectual property, copyright is not a “use it or lose it” right. Other licenses,
however, are very structured and tracked with written documentation.

On the other hand, intellectual property is protected by laws specific to the expression of an idea. Copyright is the law specific to the expression of ideas in
visual or audio form. Unlike a trademark that indicates a specific item or design is protected, copyright covers a different expression of thought.

The term copyright contains within it the meaning of the term: the right to the copy. Copy is anything written, photographed, drawn, painted, or otherwise
produced as an audible, written, or visual piece of intellectual property.

You cannot compare copyright with intellectual property (Fig. 9.3); copyright is a form of intellectual property. Defending a copyright requires different
expertise from defending a trademark.

Fig. 9.3 – There’s a reason why different symbols exist. It’s because different types of intellectual property exist.

Back to Assetto Corsa: let’s consider that you started making your mod from zero.
In terms of the car’s 3d models and physics models; this is all your own work. Sim racers like to think they are driving the real car, only sucked into some
kind of TRON neon-retro-futuristic environment. This is not the case; you are driving a 3D thingy in a computed mathematical model.
550
Part of the simulation is made possible by the game engine, which “allows” mods to be added, part of it by the modder trying to replicate the car “feel” as
good as possible using often very vague reference data.

This, along with the building of the model, is a lot of work, which is recognised by most intellectual property laws as the work of the artists and considered
3D art, at least until you make an actual mod with OEM data and trademarks.

The licenses video game developers need to buy are for the use of logos and names, which are trademarks, and they need to get various permissions to
make racing tracks too (in the order of tens and hundreds of thousands euros/dollars 86). The vehicle physics are made with data that usually comes from the
car manufacturers themselves. It’s not an easy thing at all for them. So there aren’t licences in the game for your “artistic” 3D representation and for some
“scattered” (pretty ironic here) config files defining the handling of your vehicles, unless you actually pay the car manufacturers or Kunos buys your mod
(which happened in the past a few times). The build process of vehicles is not protected though, unless patented, and most automotive solutions are not
patented but kept secret and as a patent expires the innovation ends up in the public domain.

3D art is, well, art. An artist is free to make and sell his art, manage his copyright and rights, and profit, if it’s just a computer-generated model/render/image
of a car. And it can be a very good piece of art too (Fig. 9.4).

Fig. 9.4 - The comparison between 3D art and a complete mod. The main difference is that 3D art comes only with a model, or a picture, while a mod is able to work in the simulator,
and can be surrounded by OEM data files, depending on which sources the physics use.

3D Modelling is as valid as a profession as anything else, people pay good money for talented modellers – in other words it has value. The problems come
when you convert art into a mod for AC. Two completely different issues. So how to public your mod if there are copyright issues?

Every asset you create and share, unless you pay to have a licence for trademarks from the original authors and owners (we’re talking about car
manufacturers, body designers, sponsors etc.) and you made an explicit agreement with the game developers’ company (for Assetto Corsa: KUNOS
Simulazioni Srl), has to be considered under the Fair Use terms (unless otherwise specified) if the purpose of making it available to the public is any of the
following: education, criticism, commentary, scholarship, research, reportage, review, satire and parody.

Fair use is the worst part of copyright law due to its terrible vagueness. For those who don't know - Fair Use allows certain uses or the edit of copyrighted
work without permission of the copyright owner for purposes deemed "Socially Beneficial". The nature of the work, the amount and substantiality of the work
can weigh in as well. Then there's the impact on the commercial value of the work. Please search and read the Section 107 of the US Copyright Act about
Fair Use, and the DMCA laws (or the laws currently active in your country) in order to avoid complications. In addition to the above, other factors may also
be considered by a court in weighing a fair use question, depending upon the circumstances. Courts evaluate fair use claims on a case-by-case basis, and
the outcome of any given case depends on a fact-specific inquiry.

So just because a mod is scratch made it doesn't mean it is legal.

If you created a car mod from scratch, don’t expect to be able to sell it in a legal way if you don’t have any licence for trademarks and logos, unless you are
under the terms of Fair Use, or otherwise specified (yeah, Fair Use doesn’t force you to release your contents for free, but this happens for rare, very specific
cases, and depends on many factors decided in court, so don’t take it as granted). Most of the times a non-licenced, fully working mod should be free of
charge, and having to pay for such assets is unfair to the final user (which finds himself in possession of the so-called “grey area” assets, that means “not
properly regulated content”).

Things like what you see in Fig. 9.5 are not valid by any means.

86
Cars are usually under 10k €/$ each, regarding their licensing costs. Kunos got also reference CAD models in licensing deals: they obtained some for the Ferrari F1 cars (surely for the F2004),
with key mechanical parts and data removed of course. However, tracks are on a completely different budget scale for their authorization prices. All that money for some smelly asphalt.

551
Fig. 9.5 - Aside from grammar errors this didn’t age well. You do not own any rights on Kunos’ assets nor those from any other game. Ignore the statements that some modders put in
their credits. You don’t need any permission from them, unless they have the authorizations and licences from the real-world owners, which is not the case here. Obviously NEVER pay
for things like these, if they are priced; you should not be forced to join any Discord server either, especially if you don’t trust it 87.

The model will never be completely “yours” because it cannot be separated from the brand's intellectual property it depicts, unless it consists of your own
interpretation of a specific vehicle design and thus it can be considered 3D art, which can be sold (or, yeah, you guessed it, otherwise specified); this
implies the removal of any trademarked logos and brands (Fig. 9.6). Sharing a mod that is not 3D art, with official logos, outside the Fair Use rules/context
without trademark licences is illegal. Do car manufacturers have the time and the energy to stop you from doing it? Most likely not, as the Internet is a place
“where everything ends lost in time and space”, but this is not a reason to break the law. You may receive a letter of cease and desist from Porsche though.

Fig. 9.6 - The differences between the real vehicle, the game developers’ work and the modders’ work.

You may be asking: how can you bring back the official logos on an unbranded mod? You use skins (Fig. 9.7). But separately from your product, and it’s
better if someone else does it on your behalf. Keep in mind that we’re still talking about scratch-made and legally allowed content.

Fig. 9.7 - How skins can be used to bring real manufacturer logos to an unbranded mod. https://www.racedepartment.com/downloads/pessio-garage-scorpion-1000-tc-gr-5-real-factory-skins.34310

In addition, whenever a game developer wakes up and decides to bring your model into a game licenced by the car manufacturer without letting you know,
he has all the rights to do so if he pays for it, in case it’s for sale. If the price tag of your own assets is really low or inexistent, this is ethically wrong for you,
the creator who put the real effort, since a popular game will make a lot more money from a single vehicle than any profit you can make by yourself, thanks
to marketing and advertisement. This already happened with AC mods (Fig.), be aware of it.
Again, if you plan to make an un-licensed mod of a racing car, instantly recognizable due to shape/design, with branding from third-party companies (also
non-licensed), non-licensed logos, and sound (where do you get the sound from? You may ‘rip’ it from a copyrighted source), you can’t go anywhere
outside the Fair Use terms if you don’t have an official authorization (except for the application of a different legislation). As an example of this, NetKar Namie
(by Kunos) included the Ferrari 250 GTO and other real cars that were not licenced (Fig. at pag. 22), but they were allowed since the software was free.

87
Discord is actually a dangerous social platform, and you should think twice before joining it. If you’re not careful, you can be doxxed (private info leaked), blackmailed, swatted (police called on
you for no reason), and there are a lot of other crimes committed by malicious users. Being full of underage people, generally I prefer avoiding its chats altogether. As usual, stay safe.

552
Fig. 562– (top) On the left column a free scratch mod for AC, the Ferrari F2002 by @SalamanderSoldier (RaceDepartment); on the right column the same model, taken without prior
notice by Codemasters for their F1 2017 game. The 3D model was unknowingly sold by the author for 159$, with a non-commercial end-user license (Royalty free for Editorial Usage).
Quoting said license,
"Content published with the Editorial label [..] may not be used for any commercial, promotional, advertising or merchandising use. However, in certain very limited instances, you may otherwise have the rights to IP in content that is labeled Editorial. For instance, you may
be the advertising agency for a brand/IP owner or you may be the brand/IP owner itself purchasing content. If that is the case, you may use the Editorial content commercially, assuming you have the rights clearance through other means."

Creating the model is what you’re getting paid for, not the licensing, but this is an example of bad business practices from an AAA game company. There must be agreements before
using others' content for commercial purposes. Luckily Kunos developers always gave an adequate remuneration to the third-party artists and modders that contributed to the official
content with their vehicle models, letting them know in advance of their intentions. (bottom) Side by side comparison: in blue is F1 2017’s model, in red the modder’s work. They’re
basically the same.

553
If you do have a licence agreement with a real brand and copyrighted your work instead, making something for free isn’t equal to "anyone can take it and
use it as they please". If someone takes your copyrighted assets and reposts them without asking, or sells them as his own, they’re violating your rights and
the intellectual property of the brand.

If you designed and licenced/copyrighted your own car instead and a game/software company uses it in their game without your permission, that would
constitute intellectual property and copyright infringement.

The problem with conversions: you didn’t create by yourself the assets, so you may be violating their copyright, plus if you don’t have any
trademark licence to distribute them after you’ve edited them you may be violating intellectual property too.
You’re basically taking (ripping) 3d models from other games or sources to bring them into Assetto Corsa.

Then you have “doubled” the trouble:

1. To avoid damaging intellectual property, you need to pay (and a lot) to get a licence from the car manufacturer(s), unless you keep your content under the requirements of
Fair Use (or any similar legislation you must observe in your country).
2. To avoid damaging the copyright owner(s) (the developers of the game you ripped assets from, or the 3D artists of the model you got from another source), you still need
to ask for permission before you can edit and redistribute the assets. Editing doesn’t make them yours and even owning a copy of the game you took them from does not
give you the right to share them, unless under Fair Use purposes\context (however this may change due to various factors, for example the quantity of content you
copied).

If the author of the mod you’re editing doesn’t have the licences too, but he’s under the Fair Use (or similar legislation) terms\context, mentioning him is the
least you can do to appreciate his work ethically (unless he’s breaking laws).

Taking all of this into consideration, if the intent of sharing the assets is non-commercial, educational, and involves only a few assets, but not the entirety of
the game is shared, it's likely Fair Use as it does serve a beneficial purpose to the public without significantly impacting the value of the source material.
Selling copies on the other hand, that's just wrong. Just to be clear however, there is no formula to ensure that a predetermined percentage or amount of a
work may be used without permission.

Ripping the assets from a game is much like opening a toy to get a look at how it works, if you just do it for non-commercial purposes.
Downloading/exporting a file in order to fiddle around with it in 3DsMax or Blender is completely legal, as it could easily be explained as "for use in
educational purposes". A teacher can even demonstrate to a class how models are made.

Fair use allows you to use the works from a game in the ways mentioned above, and if you can make a serious case in any one of those areas then you are
fine, but if not then you should just attempt to get a permission\licence (and it’s not always possible).

Ripping game assets for your own personal use is considered fair use, redistributing outside of a Fair Use context definitely isn’t. While one person may use
the model for educational purposes, you cannot distribute the model to the open public due to the fact that you cannot possibly guarantee that it will be used
for educational purposes only.

What about roads?

All the concepts explained in the previous pages are valid for maps too! You need a permission to create a legal model of a racing circuit. Many tracks are
owned by private associations, while game assets are fictional but still property of the respective authors.

There are some track mods that have been authorized from the authors, for example the conversion to AC of the Blackwood circuit models from Live For
Speed has been allowed by the LFS development team (Fig. 9.8).

Fig. 9.8 - Peace is always an option, sadly it’s rare to be found.

554
The conclusions:
As the author. Whenever you’re making a mod, and you share it, do it at your own risk and accept any consequence of your actions, unless you adopt/get
legal protection for your content, or rely on third parties to protect it. Complaining that your rights have been violated afterwards is futile if you release your
mods under Fair Use terms (or similar legislations), because in this case you generally can’t make any profit and the damage you receive is only moral.

As the final user. Always check if modders publish trademarked/copyrighted content; if the permits/licences are not clearly written and you’re in doubt, avoid
paying any sum of money; mods consisting of ripped assets are a fraud that can be discovered by checking if the same 3D model is present in another
racing game. Keep in mind that the vast majority of mods for Assetto Corsa aren’t properly licenced nor legalized. Without a written permission from the
original owners of the models and the official brands, the mod author(s) are not allowed to sell anything, and if they do, it’s illegal. Also, never encourage
people who use content from others without giving them any credit, it is proof of a poor ethical conduct. NEVER BUY ANYTHING FROM SUCH
INDIVIDUALS!

Mods should not be more expensive than the base game, whose price is most of the times very low nowadays. A mod is just a small fraction of the entire
software. If mods are overpriced, never buy them, as there are no regulations on the current market and every creator sets his own fair or unfair prices. Do
your calculations then. In the end the money is yours, so look at the price of AC, then look back at the price of the mod you want. Compare them. Is it really
worth that much when it's only a small part of the game? Think about it. Try getting it from free if you understand or come to know that it's a non-licenced
mod. You won't be committing a crime with respects to the mod author. You will probably commit a crime against the original owners of the content, but
you’re only the final user, what can they do about it? It doesn’t have any sense to pursuit the end user.

DISCLAIMER: Do not take anything written above as legal advice, ask a lawyer if you need it; if you require legal advice on a copyright issue, make sure the
attorney you select understands your particular needs. Just because someone is a patent lawyer does not mean he or she can knowledgeably defend your
copyright.

14.2.2 – DISCRIMINATION OF CONTENT CREATORS

In any community individuals tend to discriminate each other, based on differences in wealth, abilities and health.The Assetto Corsa community is not
different from any other association of people: some modders and groups are appreciated, some aren’t.

Usually the factor that plays a major role in determining if you’re a “good” or a “bad” author is seen by others in your abilities, and the logic is pretty obvious:
you make good mods, you’re loved, you make bad mods, you’re hated. Just to be clear, we are not talking about people that commit frauds here.

Obviously there always are subjects who unconditionally love or hate someone, just for fun. Discrimination is also due to reasons of sympathy/antipathy,
lack of confidence and self-esteem. It happens everywhere after all, and humans will always be humans. There’s very little me and you can do about it.

Ostracizations can occur, too. Some groups and associations can ban or exile members, given fair or unfair and logic or illogic reasons. Often emotions are
crucial for success in a creator’s career. This is because after all modding is most of the time a hobby, and when people judge your work, whether in a
positive or a negative way, you are always touched in the feels, even if you think you’re insensitive. It gets even worse if you’re making mods as a job, and
the opinion of the public becomes heavier, stressful and overwhelming. Defamation can be really damaging in this case.

We are not invincible, made of steel; our mind cannot protect ourselves forever from the damage that comes with the environment around us. Similarly to
our skin, our brain is like a sponge. Our subconscious is active all day and filters everything. There is always something lingering in our thoughts, unless we
are in a condition of apathy. All kinds of things happen to your identity when you expose it to others. Men shape each other.

Discrimination can be really hurting, however don’t take it personally too often, do it only when it’s necessary. If you’re not very skilled, be open to
suggestions and criticism, but not to the point where people actually damage your individuality, because respect is an important part of being in public. It is
the medium that allows every social interaction to happen in a civil way. And too often it is missing nowadays. Be aware that what can be perceived as polite
in some communities might be conceived as rude and ignorant in others.

You may feel bad at the beginning: you can accept criticism, but if you perceive that there’s an abuse in your respects, return it to sender. One's freedom
ends where another's begins, and the public must learn to have some mercy and let individuals improve themselves. Everyone deserves a second chance.

I wouldn’t care about being banned from a community if you defended your dignity against disrespectful subjects. For you that association has harmful and
negative individuals inside; it means that it’s unhealthy and you shouldn’t waste your time there. Move on and keep pushing your projects on some other
place that deserves your attention and dedication.

If, with time, you become a well-known author, try being humble and don’t look at others from top to bottom. This will open the doors for a proactive
climate.

In any case no one should arrogate the right to condemn or glorify your skills as a modder. Yeah, it goes both ways. This is wrong especially if you start
making a list of who’s the hero and who’s the villain (Fig. 9.9).

Often people don’t realise that discriminating they’re not only hurting you, but also themselves. Why, you may be asking. The answer is that they’re blocking
the progress of an individual, and that individual is part of the community, so in the end that whole, collective entity is slowed down. Also, not to be sexist,
but modders in the gaming world are mostly males, and generally males are highly competitive when positively stimulated. Ambition pushes a man beyond
his boundaries. Thus, the observation here is that the negative influence of one person is more powerful than you may think, considering that
psychologically we tend to remember more intensely our sad, hurting or anger experiences.

555
Fig. 9.9 - I analysed a bit this webpage and it gets worse as you read it. My conclusions may seem fussy, but in reality I am just giving a weight to the words. You have to look at this
as an example of a veiled, merciless and disrespectful behaviour from “modders” to modders. The AC community is not roses and flowers, and this shall make you understand it.

My suggestion is: if you want to preserve yourself, avoid the public, and avoid other creators. If you’re a sensible person and you don’t want to be judged,
it’s better if you keep your mods to yourself. People can be aggressive, depressing and hard on you for no reason at times. Trust me.

556
14.2.3 - ABOUT VANILLA ENCRYPTION
People often tend to ignore or forget the origins of the Assetto Corsa modding world. Things weren’t supposed to be free and open as they’re today. The
main proof of this is in the simulator’s assets. They’re encrypted formats.

There are two categories of files that are encrypted within the assets regarding vehicles in the Assetto Corsa folders:
• Models, consisting of .kn5 files (this is valid also for tracks)
• Car data, consisting of .acd files (the extension stands for Assetto Corsa Data, if it wasn’t obvious)

Why do we (i.e., modders) usually say that we’re “unpacking” files? Well, it’s just a nice and “foggy” way to say that you’re decrypting something. Obviously
for development and educational purposes, never forget this part (do you feel the irony?).

I believe that the original plan of Kunos developers was to explain modders how to make autonomously their own data files (which already happened), while
keeping the official content secluded and protected from modifications and theft of licenced information.

During 2013 you could get permanently banned in the official forum just for mentioning the editing of licensed AC files. Only a few people had the
possibility to decrypt such assets, and they were smart enough to not mention it often, and not even consider uploading anything property of Kunos without
permission. The problem is that someone managed to “crack open” the official encryption of the models and released a python code for it (Fig. 9.10).

Fig. 9.10 - Look at the date. I bet someone still has that little tool (obsolete anyways).

Anyway I'm sure there is no encryption that can't be cracked open, so it would’ve happened sooner or later.

Meanwhile, regarding vehicle physics, modders weren’t showing contents of the ACD files, they were re-encrypting the data so that it was no more
accessible than the original, thus not revealing and compromising anything 88, following the suggestions from the staff (Fig. 9.11).

Fig. 9.11 – A post by Aristotelis Vasilakos (Kunos development team) about the decryption of data of the official vehicles.

By the end of 2013 and during the whole 2014 however, as the general public started to access the files inside the ACDs due to leaks, it became too late for
Kunos to repair the damage, even after blocking users (Fig. 9.12). Changing the encryption wouldn’t have helped when the data had already been exposed.

Fig. 9.12 – How Kunos responded to the editing of official files.

88
In reality, the physics data of a mod or official car for the game does not consist of truly sensitive information, so there is very little to no point in encrypting it. Most of the time it does not
originate from telemetry data, and even when it does, it’s just an unreliable, secondary, derived type of data, modified to fit within the heavy limitations of AC. More than once Kunos developers
publicly stated that they had to entirely make up new theories and strategies for missing info. The simulator doesn’t model real life phenomena entirely (it clearly is a lacking simplification), so its
data cannot be considered a valid source of information for any serious purpose. Actual engineering applications and simulations rely on literally terabytes of data, for single drive sessions! The
.acd file encryption is really a marketing strategy that allows the developers to maintain an aura of mystery and curiosity from the public. This is particularly evident, given the fact that copies of the
files for the old tires of all official vehicles are included in the AC SDK (under %ROOT%\sdk\dev\v1.5_tyres_ac).

557
Not to mention the conversions of models from other games and third-party sources. It was necessary to put a remedy to the situation, at least on the official
forum.
You see, Italian laws specify that on a moderated and private (i.e. needs account registration) forum, the owners are co-responsible for the content of the
posts of the forum users. The Kunos team has its base on an amazing country, famous for its culture, art, nature and... food. But at the same time also
famous for its bureaucracy, complex law system and confusing law decisions. So when they get complaints from other big titles about converted material in
their forums, or when they see illegal mods in their forums, or when they’re asked to make the referee between mod teams wars, stolen material, personal
issues and such, then it is time for them to take action.
It's not a matter to simply moderate, because even if they had the time to do it (which they didn't have), they would have been still in a very grey area that
couldn't always be dealt with. So due to some community members’ behaviour and legal uncertainty, they decided to close the subforums where people
could post almost freely their content, in order to avoid illegal content to be posted there (Fig. 9.13).

Fig. 9.13 – Explanation from the KS dev team of their decision.

Moreover, quoting a post by Stefano Casillo:

“There was a basic misunderstanding about the role and the meaning of the "3D Models" and "Tracks" subsections of the modding forum. This is mainly a support forum
and not a community forum. It is supposed to be a place where people interested in either fixing a problem with AC, or doing something with AC come to find information.
Sadly those forums turned into showcases of stuff instead of places to ask questions regarding mods, it was simply not the intended use of a tool that we wanted to offer. In
the future we'll either re open those forums or open new ones with the clear intent of offering support to those with questions regarding modding and not as an artist showcase.
I understand the decision will make some people happy, and I am totally fine letting you vent your disappointment in this thread (as long you are able to keep it civilized) ...but
I am pretty sure your lives will be fine just as they were fine before AC came out. People wanting to showcase their works will have to find another place on the internet, luckily,
there are very good candidates available... I am confident the new support forum for modding will remain a great reference for those looking to create content or AC. I apologize
for the abrupt decision, but it was one of those things that it was going to hurt more the more it was going to be allowed to go on, this is a learning process for us and we're
always trying to do what we think is the best for the project. Tutorials and relevant info threads WILL NOT BE DELETED. That is the ENTIRE point of having those forums. If
somebody thinks this decision will want to make them stop using AC then good luck to them for their future endeavours, it was a great pleasure to have you here.”

The way I see it is this: the official forum is owned by Kunos, and tied to Assetto Corsa and to KS as a company, therefore KS is responsible for what is
posted and hosted there and can also be held legally accountable for it, e.g., hate speech or illegal content. That's why there are rules against those things.
A month later, on the 26th Aug 2016, AC would have been released for Play Station 4 and Xbox One in Europe. Modding continued on other places.
Unregulated and unrestrained. But this time the KS team was free from its chain.

After all, outside of their official forum, lawyers can’t blame them for what people are doing. AC kept having encrypted files to make checksums work for the
online multiplayer (to prevent cheaters), and to protect the licenced data (even if that effort had already become pointless).
Editing copyrighted data is still wrong to this day. Luckily websites like RaceDepartment check if you’re using ripped models or physics for your mods.

In the end we have to thank Stereo for his little leak. I think that AC wouldn’t have gotten so far without him (and some other people that won’t be mentioned
here). Back then the CSP mod and tools like CM didn’t exist. Modding was really harder and not intuitive at all.

14.2.4 - THE SITUATION WITH CSP NOWADAYS: THE UNOFFICIAL ENCRYPTION

Custom Shaders Patch can encrypt too. Models with unofficial encryption work only in Assetto Corsa with CSP installed, or, optionally, with the Custom
Showrooms of Content Manager.
The comparison between how unofficially encrypted models look in vanilla vs AC modded with CSP is in Fig. 9.14.

Fig. 9.14 – That’s a huge difference. An unofficially encrypted model, on the left displayed with vanilla AC, on the right with CSP. The meshes are “crystallised” because AC cannot deal
with the unofficial encryption.

558
The unofficial encryption brought by CSP has been made by modders to control people, aka other modders. This creates loads of problems.
Keep in mind that at the beginning of AC the modding procedures were somehow “legal” and “moral” because they were officially created, controlled and
limited by the software developers, who were keeping the patented and copyrighted files encrypted. You could only create your files, or at least copy the
given generic project examples and templates. That’s why the data folder exists, to let modders mess with physics without interfering with protected content
(.acd files). The same principle was applied to 3D models (.kn5 files).
The information about how scripts work was taught, not leaked. At least that was the plan. There was a sort of principle of authority. Kunos ruled.
Nevertheless, today anyone can edit protected AC vehicle and track files (for development purposes, obviously…?).
Considering AC mods, Kunos is not an active intermediary anymore, since they started working on ACC, and AC reached the EOL (End Of Life) state. This
doesn’t mean that they disappeared. They’re passive but still exist. As a consequence, everything that claims to take the place of the developers is to be
considered illegal or unethical, as not regulated by any law. The new encryption brought by CSP has not been allowed explicitly by Kunos (any agreement
about it does not exist), nor has a legal value or a tangible impact on the assets, due to its unknown and unclear strength and entity. It cannot be classified
as a preventive measure, as the assets themselves can be retrieved anyway, with methods that differ from the canonical AC modding practices. And a single
private citizen (the creator of CSP) can decrypt the mods anytime, because he owns all the encryption keys, and having created it he knows perfectly how it
works. This unofficial encryption is not a process performed in Kunos’ interest, so what is it? I will let your imagination run free.

We don’t know the true reason why it was introduced, but we can look at the consequences it brought.

1. It makes mod authors believe that their mods are “protected” from editing, when the truth is that they aren’t. The hypocrisy is that most of the times said authors do not own
any rights on the assets themselves (see par. 8.2.1), but for whatever reason they think they’re defending “their” copyright; we aren’t talking about scratch-made content,
we’re talking about fully working mods with ripped models and OEM data. The amount of work inherent in the process of a conversion is minimal. There is no reason to
consider the mod an original work when the only thing that has been done is to follow the rules for correct physics (config files, LUTs, ...) and models (e.g. shaders, textures,
etc.). There is not an imagination or originality input from the modder. It is a mere process of copying. So there is not even a moral reason to lock such contents.
With scratch-made content the deal is different, but it’s still not really justified. Locking assets based only on the fact that you put your effort is a backwards logic, because
you can always learn from people, both in positive and in negative. If you’re in doubt I suggest to not release anything, it’s always the best choice for that case.
2. Other modders cannot edit assets easily. This puts a limit on the modding community. But with skills and time it is possible. It’s just a laziness problem, often caused by the
hope of finding a better mod to replace the unofficially encrypted one. Anybody can still get the original models with textures using certain tools to directly intercept data
from the GPU (but don’t worry, there are also other transversal ways, for example [hehee yOu’LL fEaR tHiS]). If you’re encrypting someone else’s content without permission,
the original authors might also get a decryption software for “your” ripped models and do whatever they want with them. Quoting Don Estridge, “I guarantee that whatever
scheme you come up with will take less time to break than to think of it”.
3. Players, the end users, cannot customize their mods with little and simple edits, an example is creating skins.
4. Often encryption is used to hide bad mods. I’d say this happens 99.9% of the time. Thus you can’t even fix them. People that make good mods do usually show off their
work instead of locking it, this way people know that they’re capable of delivering good content and everyone will get back to them for more.
5. Strange enough, CSP itself offers some workarounds to edit unofficially encrypted mods. This is inherently contradictory.
Now, there are different versions of the CSP model encryption: V1, V2, V3, V4 and V5.

When everyone commits a crime, it becomes a legal activity. Only that’s not true.

Do not support or endorse the work of modders who lock contents with the UNOFFICIAL, unauthorized encryption brought by CSP, consisting of illegally
RIPPED / CONVERTED content from licenced and copyrighted sources (third-party authors or game devs). Do not pay for such mods!

Unless the aforementioned authors prove that they have a valid licence for their content, they’re wrong while saying that you’re not allowed to edit their mods
(Fig.). You’re allowed to do anything you can (within the laws in your country) with their content if it’s not licenced or copyrighted by them 89 (and most AC
mods aren’t).

Just the fact that mods with unofficial encryption don’t work in vanilla AC (Fig.) should allow you to edit them. But this last sentence is just my opinion.

Why do cars with unofficial model encryption show the meshes as blue crystals?
There are three reasons why a car’s model encrypted with an unofficial standard may appear as in Fig. (left):

1. Your game is only vanilla; since it is the CSP mod that was used to encrypt the car mod, it is also required for its decryption, which happens while the session is loading.
2. Your version of the Custom Shaders Patch mod is outdated, as its creator updated the encryption method(s). So you need to update CSP. This issue is very common.
3. You’re using Reshade. CSP and Reshade do very similar things to the game, they alter or replace its shaders. While CSP can deal with encryption, being its source,
Reshade can’t, and that’s why the weird blue crystals appear on the model. It vanishes the decryption.
In recent versions of CSP has been added compatibility with Reshade.

89
Especially if you’re the owner of the intellectual property. In that case, nobody can stop you.

559
CHAPTER 15 - CAR MODS FROM THE COMMUNITY
You probably know that thousands of vehicle mods are available for Assetto Corsa.
You can download them online from websites & forums; that’s the easy part, you still have to install them to be able to drive them in the simulator, and that’s
even easier! We can also talk about how you can edit mods from other authors, so there’s plenty of things you can learn here.

15.1 - HOW TO INSTALL CARS

If you read CHAPTER 8, you may be aware that mods are packed in a compressed archive, so you just have to extract the contents inside it with the tools
mentioned at the beginning of this manual.
Let’s look at the whole process then, working with 7-Zip (granted that you already installed this or a similar tool on your PC).
After you downloaded your car mod, you have different ways to install it:
A. FASTEST: Click on the file in the Downloads tab of your browser and the archive will open automatically in 7-Zip; identify and select only the main car folder (you can
recognize it because it’s the FINAL folder, page), then drag and drop it in one of the following paths (which you will have to open in a File Explorer window), depending
on the type of AC installation you have:
- STEAM default: C:\Program Files (x86)\Steam\steamapps\common\assettocorsa\content\cars
- STEAM default if you installed AC in a different (secondary) drive: [Drive letter]:\SteamLibrary\steamapps\common\assettocorsa\content\cars.
- STEAM custom: You changed the path during the AC install process. To locate it use the method shown in par. 2.2 of the AC User Guide (pag.).
- Pirated version: Locate the respective assettocorsa main folder (may be named Assetto Corsa) and extract the mod under %root%\content\cars; if you don’t remember
where it is, right click on the AC icon you should have on your desktop and select “Open file path”.
Look at Fig. below for reference.

Fig. – UPDATE IMAGE (sorry Ben)

B. PRECISE: Click on the “Show in folder” menu/drop-down menu/icon next to the downloaded file in your browser. Your downloads folder will pop up and you will be able
to open the archive from there. Then in 7-Zip, click on the Extract button and change the destination folder to one of the paths in option A. Otherwise directly open your
downloads folder, and do the same.
If you enabled 7-Zip integration with MS-Windows drop-down menus, you can also right-click on the file and select 7-Zip > Extract the files… > choose the path.
Why is option B precise? Because dragging & dropping files can be glitchy and buggy, especially when rushing things. I know from personal experience. You may find
your files inside the wrong folders if you’re not careful.
C. SECURE: Same as B, but before opening or extracting the archive, scan it with your anti-virus software of choice.
Sometimes authors put in their package manuals and other kinds of stuff. Don’t copy those files in your AC assets, if you want to keep them just create a
special folder in your documents. On few occasions however, cars come with custom driver models, fonts and shaders, see Fig. 9.2, so you do need to copy
those (unless you already have them). Be curious and look at what’s inside each folder. That’s the spirit.
Do not install mods automatically with Content Manager. It has an auto-install feature but it’s often buggy. You will avoid mistakes and errors with the methods
recommended here (A, B and C).

FAQ
QUESTION [1]: I downloaded a car mod, and I moved it to the "cars" folder, but it doesn't appear in-game. What did I do wrong?
ANSWER [1]: You probably moved the wrong folder. Also, in vanilla AC you need to restart the launcher (AssettoCorsa.exe) in order for the mod to be
loaded. This doesn’t happen with Content Manager, where it is immediate.

560
15.2 - HOW TO UPDATE CAR MODS
You re-download the new version of the mod, delete the old mod version from your AC folder and copy the new one in. Overwriting files is generally not
recommended, especially for cars and tracks.

15.3 - HOW TO EDIT CARS

The basic principle around editing is that you aren’t the original creator of the mod. You want to obtain a custom or a better product for either yourself or the
community. Remember, always give credit to the authors of the assets you’re modifying.
There are some issues that can happen:
1. When extracting the contents of a KN5 file, the model & animation are a package deal, you can only switch both together. Also, animations cannot be retrieved, so if you
change the model, you’ll likely have to remake those from scratch. Same to a lesser degree for instruments and other dashboard elements, as they are part of the model
and referenced in the car data files.
2. Handling has some small ties to the model but is fairly reasonable to modify. See pag. for more instructions about swapping physics.
3. Sound is no issue, as long as the engine RPM limit is the same.
4. The more you learn about a car, the more you want to correct a low-quality problematic mod. You become a fixer.

You can use some tools to edit cars in either destructive or non-destructive ways.

15.2.1 – EXTRACTING THE MODELS

Our goal here is to be able to alter the visual part of the vehicle. This includes changing the geometry, swapping parts, changing textures and editing
shaders. (WIP)

METHOD 1:

Use the QuickBMS tool (currently 0.11 release). It doesn’t require CM and CSP, as it is a small standalone software.

Fig. – The QuickBMS tool. The file selection window (File explorer) will open automatically.

The program is available in the extras of this manual, with its extraction script (assetto_corsa.bms) required specifically for AC models, as this utility can be
used to decrypt files from many other games. You can also download it from here: https://aluigi.altervista.org/quickbms.htm (QuickBMS) and
https://zenhax.com/viewtopic.php?t=90 (the specific .acd encryption scripts).

The usage is simple and quick, after extracting the tool’s package in any folder you like:

1. Double-click on quickbms.exe;
2. Select the script for the type of archive you want to extract/decrypt, in our case assetto_corsa.bms;
3. Select the input archive or multiple files, so at this point you will select the model in the mod’s folder.
4. Select the output folder where the files will be extracted. This time you will have to create the data folder from File Explorer.
5. Watch the progress status of the extraction and the final message.
6. If everything went smoothly, you finished.

If it doesn’t work, try opening the program as Administrator (right click on quickbms.exe > Run as Administrator). Otherwise stick to method 2.

With QuickBMS you cannot rebuild the .kn5 model from a .fbx file.

METHOD 2:

Use CM.

15.2.2 – EDITING THE MODELS AND DATA

15.2.3 – EDIT THE DRIVER
How to change the driver model in vanilla AC
Sometimes the default driver model for some cars in Assetto Corsa can look a bit out of place, particularly with road or old race cars. Wip

561
15.3 - HOW TO TAKE NICE SCREENSHOTS
Yeah, you will probably have some fun in the community posting pictures of your favourite mods. This has almost become an art, anyway in the next pages
let’s talk about how to improve your skills for a nice composition of your shots.

Let's look at a bad example first (Fig.).

Fig. – An image taken with really low to none effort.

This is mainly what's wrong with it (prioritizing the most important things):

1. Really dull composition; I'll be talking more about this later.

2. Overused Bokeh, you may call it aesthetic, but it's actually just bad.
3. The graphics look weird and low-quality in general.
4. You can see that there's no AO (Ambient Occlusion) on the radiator. It seems lit from upside down.
5. There is no motion blur at all but the car is actually moving.

Below there are a couple other examples (Fig.).

Fig. – On the left the scene is too dark, you can’t see anything. On the right you lose the sense of depth: everything is compressed on the screen, and the exposure is wrong.

So, how do we start making passable (and possibly nice) screenshots?

First, we have to speed up the job and make it less tedious. Then there is space for the improvement of the vanilla look, with graphics mods.

The basics:

1. Use CM (Content Manager) to work with AC; you can find more info under THE TOOLS YOU NEED, at the beginning of this manual. Please do not skip this passage, as
this launcher is a lot better than the original Kunos launcher. Chances are if you play AC frequently, you already have it.
2. Some stock game settings need to be changed. Press the Settings button on the top right corner. Then press Assetto Corsa and System tab. In here, you should enable
Allow Free Camera and disable Orbit mode for F5 camera.

562
3. Download CSP from CM, try the newest first. Do not skip this as you will need it.
4. There are many graphical settings for CSP. I suggest you just get a preset that takes care of everything. I'll be talking more about this in a bit.
5. Install a graphical mod called Sol. It is an excellent thing, and you'll need this too, as it brings custom weather with new beautiful skyboxes. Download it here:
https://www.racedepartment.com/downloads/sol.24914
6. Install the Pure mod in combination with Sol.
7. Get PP Filters (Post-Processing Filters). They are like photo filters that run in real-time and drastically alter your scene’s look. Stock Kunos PP Filters are old and won't do
the best job. Just search online; you can also make one by yourself if you’re curious enough. You can view filters in CM too, under Content > Miscellaneous > PP Filters.
The folder containing all the stock AC PP filters is under %root%\assettocorsa\system\cfg\ppfilters. This is also where you will install new ones you download from the
web.
8. DO NOT use showrooms for your screenshots. This is because showrooms do not have CSP implementation and everything is wrong. For example, refractions. Just take
your pictures in a race session.
9. DO NOT use Assetto Corsa’s stock photo mode (the one available during replays). Instead, use the Photo Mode app from CSP.
10. If you want to share your screens on social platforms like Discord, better change their format to PNG, as Discord will not load heavy JPGs.

What you shall do during a session:

Simply drive; while you can take a screenshot any time, I recommended you take pictures in the replay screen so you have better control of the scene.
Travel a bit and pause the game, then hit the replay button.

There are two camera modes that you should use, F5 cam and F7 cam. F5 cam tracks the car, so it can be used for rolling shots. If you want you can also
use another app called BoxCam, made by Stereo, which has a different tracking behaviour, which you can also adjust. You can get it here: asdgfasdfhdasfhj

F7 cam does not track the car, so you cannot use it for rolling shots, but you have better control of the camera, including zoom, use this for stationary shots.

The default FOV is 45. The general advice is that you should reduce the FOV for easier composition as most people do not know what to do with the "wide"
frame. As you can see on Fig. the main subject is small, and most of the photo is filled with blank uninteresting road. Very ugly.

However, you should keep in mind that high FOV is not equal to a bad screenshot, see Fig..

Fig. - This screenshot is taken with a relatively high FOV, higher than the default.

Some general tips on photo making:

I can't tell you exactly how to compose your shots; you can read articles online but don't expect to read them and became a photo master in an hour. You'll
need plenty of practice to get good. I will give you some tips though.

• You need to fill the frame with something (Fig.).

A common mistake is that people have a car and absolutely nothing else in their shots. This is a no-no. However, don't put too many things in your picture, otherwise it
becomes a chaotic mess. You should make it balanced, as all things should be.

563
Fig. - The car is very small in this photo, but there are plenty of things to fill the frame.

• Pick a location that complements the car.

Different terrains and settings will work better for different cars. If you’re photographing a Jeep that does well off the beaten path, you might want to take it onto some rocky
terrain. On the other hand, a car built low to the ground might look best on a smooth city street or in front of an old brick wall by a factory.
The color of the car will also help determine the best setting for the shoot. Black and white cars are really the only ones that you can take pretty much anywhere. If you’re
dealing with a special color, those get tougher. I’d say the hardest paint coat on a car is probably purple. Purple is a really challenging color to capture. You have to find the
right lighting.
Aim for a background that offers contrast to the car’s hue and shade. Darker cars look great against brighter backgrounds. If I’m shooting cars that are brighter, like an
orange car, I would shoot in a darker spot, either during sunset or where there’s a shadow.

• Plan your shoots for golden hour.

The time of day can make a big difference. As with most types of outdoor photography, direct sunlight can lead to glare, drastic shadows, or washed-out colors. Shoot cars
during golden hour - the hour after sunrise and before sunset - to limit the intense glare and shadows caused by midday sun. If you want to shoot midday, work around
harsh light with the help of trees and buildings that provide shade over the car.

• Be ready to capture all the angles.

Make sure to get the classic car “poses” before you get creative. Shoot the car from straight on at eye level, get side views, and capture shots at 45-degree angle views of
each corner of the car. Every car looks best at a three-quarters angle. That’s kind of like the go-to shot. You can practice with any car, it doesn’t even have to be a fancy car.
Once you’ve captured good angles of the entire vehicle, move on to cropped shots. You can shoot the side of the car from a low angle that starts at the front wheel, for
example. Next, dive into the detail shots like close-ups of the headlights, front badge, arrow bits, side skirt, and mirrors - get in tight on any details that make the car unique.
If the location isn’t right or is affecting your ability to follow the rule of thirds (or other photo composition best practices), play around with where and how the car is
positioned. Keep the scenery and your composition in mind. Just because your subject isn’t human, it doesn’t mean you can’t have it work with you to get the right pose.

• Work with colour.

The overall colour of your scene will definitely have a huge impact on the result, and can make the difference between a good and a bad job.
In the following example (Fig.), I tried to recreate a shot I had taken months before with a different post-process filter.

It is important to play with ppfilters then; you should find one that behaves well for most of the locations.

564
Fig. – In my opinion the first shot (image on top) is much better, in terms of colour but also contrast wise. Also, the sense of depth is really there, and the slight roll gives dynamism.
The bottom image is washed out, still it’s pretty decent. This demonstrates that not all the shots you will take in your life will be perfect: you can have bad days too!

• No matter where you position the car, you should think about its surroundings. People usually put their car in the center of the frame, which is fine if you plan your shot
around it. Ideally, you should at least try to come up with some interesting car placement. If you want to do a low effort shot that's passable, just position your car slightly
left or right from the center, but don't overdo it.

565
Fig. - A standard low effort car to right shot. It works.

• Consider the foreground, adds layers to your photo (Fig.).

Fig. - A shot with foreground also highlights the speed of the car.

• Avoid excessive roll.

• There's no need to edit the photo; of course, you can, but you may end up ruining the shot.
• Don't use the Resolution multiplier if you don't want ugly artifacts in your photo. Keep it to 1x. You can find this in CM under Settings > Custom Shaders Patch > Nice
Screenshots.
• When people criticize your picture, don't come up with all kinds of excuses, just take the criticism.
• Just try different things. Who said that you have to shoot only cars? Tracks are so beautiful...

This should be all you need to know about how to make a passable photo in Assetto Corsa.

566
567
 PART 3:

TRACK MODDING

568
INTRODUCTION (#2, if the first one wasn’t enough)
Making track mods is not like making car mods. Usually, if not always, it is easier.
If you haven't read PART 2 yet, take a look at it. If you already did, you will definitely have the knowledge of which are the steps of making a generic game
asset for AC: creating your models, using a correct naming for their objects, eventually adding empties for specific functions, then setting textures, materials,
shaders, exporting and finally generating the data for a faithful physical simulation.
Then, in this manual, between PART 2 and PART 3 some things will be similar, some won’t, so we’ll organise our content following a linear path like before.
When you want to start producing content for any racing game or simulator, beginning with roads can be less challenging and will teach you very quickly
many things that you can apply on a large scale: from modeling with performance in mind, to basic NULL/mesh hierarchies and much more.
My advice is to start small if you are going to try for the first time. Lower your expectations. Create something little and learn the basics of getting it to work
in AC before you try some 40+ miles epic monster adventure track. One step at a time, because you don't want to go far and then realize how much things
you'll have to redo. Prepare the best possible references for modeling. Watch out for dimensions and scales.
What you see, DOES matter. But many things are hidden.
One of the most important things about a map is visuals; if your aspiration is to make something really good, you don’t have to be an environment designer,
but learning how to make a good landscape will definitely improve your skills. Don’t worry, you will manage to create something.
But we cannot ignore other aspects of our “beautiful sceneries”: collisions. Yeah, the rock-bottom phenomenon. You don’t want to hit a wall and be launched
like a projectile, then maybe noclip (= fall through) into the ground and fly in the empty space (Fig. 0.1).

Fig. 0.1 – Falling into the void. On the left with vanilla AC, on the right with artefacts brought by CSP.

These aren’t happy accidents, but actual mistakes. Proper collider meshes have to be created and applied to walls, to ensure correct behaviours (Fig.). They
won’t be rendered, but they will interact with the various vehicle colliders that you probably already saw if you read PART 2: CAR MODDING of this manual.

Fig. – The real objects involved in the collisions with fences, guardrails and walls are not visible.

569
Not only that, another thing is usually invisible: the physical road, which represents the underlying source of the circuit’s “feel”, letting you know of every
little bump on the tarmac.
The simulator is lying. Or is it? Your tires do not touch the asphalt your eyes see. But this will be discussed after you’ll have learned the principles.

Tracks can have some configuration files around the 3d model, for example to give every surface a different behaviour, from the vibrations on curbs to the
rolling resistance; this means you’ll have to type some numbers (or copy them) sooner or later.

This time we will talk less about NULLs and more about meshes and their proper naming. How you will call a mesh will change its function, so our attention
will be focused on that part.

Finally, another thing you’ll have to get used to will be the long loading times of ksEditor with big maps. It can take up to five minutes to load a very complex
scenery; if you don’t have good hardware, even more.

Generally speaking, a lot of tracks have been made and/or converted to AC, including some of the best historic recreations of Nürburgring, Monaco, Monza,
Imola, Fuji, Hockenheim, Le Mans, and many other modern and vintage maps and roads.

Fig.

As a rule of thumb: if the track encourages you to go faster/crash harder, then it’s well made.

570
TABLE OF CONTENTS:
These are the steps to make a track mod. You can go to each respective chapter of PART 3 – TRACK MODDING for its discussion:

1. Prepare and populate the folder structures;

1.1 – Create a development (DEV) folder; p.23
1.2 – Create the final (FIN) folder; p.
1.3 – Add some common files to your mod p.

2. Modelling phase: with your 3D software (Blender, 3DS Max, Maya, etc): p.
2.1 - Make the actual track meshes with a good workflow (skip for conversions, you already have the model); p.
2.2 - Use the correct 3D coordinate system; p.
2.3 - Respect the dummy naming; p.
2.4 - Respect the scene structure and the hierarchy between dummies and mesh; p.
2.5 - Animate your model p.
2.6 - Add materials and textures; p.
2.7 - Create LODs for your final product to achieve better in-game performance; keep in mind also the poly budget; p.
2.8 - Make a collider for the physics engine; p.
2.9 - other stuff p.

3. Export to FBX up to 2014/2015 format (2016 is unsupported); p.

4. Transfer phase: With ksEditor.exe: p.

4.1 - Import the track .fbx model(s); p.
4.2 - Define the shaders/materials; p.
4.3 - Export to .kn5; p.

5. Data entry phase: edit some files for every surface behaviour, physics, etc. p.
5.1 - Data configuration & physics p.
5.2 - Use the debug tools p.

6. In-game adjustments: p.
6.1 - Use apps to fix some things p.
6.2 – Track limits p.

7. Make ‘em sound! Yes, you can add sound to your tracks. (CSP features?) p.

8. If you want to release your mod to the public, think about it a little first. p.
8.1 - Pack your files p.
8.2 - Understand your boundaries as a mod creator p.

9. Track mods from the community. p.

9.1 - How to install track mods p.
9.2 - How to edit track mods (possible with skins?) p.

Page numberssss

WIP

571
CHAPTER 1 - FOLDER STRUCTURES
If you read PART 2 - CAR MODDING, you will already know some of the basics. We’ll start from zero again though, it may be easier for you 90.

According to the size of your project, building a track might take from an hour to a few months. It's up to you to set the limits.

Here we have a schematic very similar to its first iteration in this book, but very slightly adjusted to this type of project (Fig.). Technically it’s your roadmap.

Fig. - Again, some of these steps can be done earlier, some later. It’s up to you the choice of an optimal strategy. TEMPORARY PIC (fix?)

In order to work as neatly as possible, you need to create 2 separate folders for your track mod: a project development (abbreviated DEV) folder wherever
you want in your PC, with all the main reference data, the 3d models and their textures, and a definitive, "final" (also called FIN here) folder in the
%root%\assettocorsa\content\tracks path, which will contain the assets that are actually used by the game engine.

1.1 - PROJECT FOLDER STRUCTURE (DEV)

Well, the DEV folder for tracks is a lot simpler: for most projects you will have one file with the entire track’s model from your 3D editor software, along with
the FBX export and the respective persistence config to work with ksEditor (the persistence file is created with the latter).

If however your map has got more than one layout, for example with GP/Endurance/Motorbike layouts, you may need to create more models, which
translates to more FBX and persistence files. In Fig. is then represented a basic track with two layouts.

Fig. – PLACEHOLDER IMAGE

90
Well, almost. For many things you will gladly be asked to consult the cross-references to PART 2 - CAR MODDING, where a lot of concepts are already explained.

572
1.2 - FINAL FOLDER STRUCTURE
Pay attention: there are naming restrictions for track folders, from shared memory definitions you have:

Max length - track folder name: 32 characters

Max length - additional track layout folder name: 15 characters

Fig. – PLACEHOLDER IMAGE

\yourtrackname.kn5
the main track file, containing track's geometry, materials and textures

We’ll see what .kn5 files are and how they’re created later on; at the moment you can ignore them.

We have some folders:

\ai
This folder contains the data for the path the AI will use to drive on your track. It can be left empty, but the virtual opponents won’t work.
You can usually find these files inside:

- fast_lane.ai, which is the trajectory that AIs follow on the track lap. It can be opened with ksEditor

- pit_lane.ai, which is the trajectory that AIs follow on the pitlane.

If however, you wish the AI at this point, see THIS thread on how to do it.

\data
Here you'll be able to define specific surfaces to be used in your track (should you wish so), edit the cameras, to define specific lightning, to define specific
audio sources and more. There are two possible scenarios:
1. You are building a basic track (and usually this is the case if you’re doing it for the first time), so you can avoid creating this folder, or just leave it empty; otherwise you
could copy a data folder from an existing track, and modify the files you wish to look into).
2. If you plan on customizing your track further, follows an explanation of all the files that can be contained in the data folder (not all of them are mandatory).

- audio_sources.ini - used to create reverb zones thanks to dummy emitters placed in your scene.

- cameras.ini - used to define camera sets (TV type); you can define it manually or in SDK Editor. It needs the AI line to automatically switch from one
camera to another; otherwise it will remain blocked on the first camera in the set. You can define as many sets as you like, just name them cameras.ini,
cameras_1.ini, cameras_2.ini, etc.

- crew.ini - used to define the position of the PIT guy to the left (1) or right (-1) side of your car.

573
- groove.ini - used to define the behavior of the groove overlay. How fast it gets darker and by how much.

- lightning.ini - used to define the pitch and angle of the sun

- surfaces.ini - probably the most important, because you can use it to define new types of surfaces.

\ui
In this folder there are files that define the basic data displayed in the game UIs:

- preview.png, which is the preview image of the map, shown in the selection menu;

- outline.png, an image with the track layout, created from the road meshes, that will be overlayed over preview.png in the UIs;

- ui_track.json; This file contains basic info about the track;

Example from Imola:
{
"name": "Imola", ; Name of the circuit.
"description": "Autodromo Enzo e Dino Ferrari", ; Description of the track (short).
"tags" : ["circuit","original","Italy"],

% ▲ Tags can be different, but I suggest you to stay true to the official ones instead of creating new. Tags are used as filters in the selection menus,
so if you are faithful to vanilla it will be easier for people to manage their mods and sort them for a race.

"geotags": ["lat", "lon"], ; You can add geotags, the latitude and the longitude of your map, if it is real.
"country": "Italy", ; Country of the circuit.
"city": "Imola",
"length": "4909", ; Length of the specific track layout. [m]
"width": "15", ; Average width of the circuit. [m]
"pitboxes": "24", ; Number of pitboxes available for the specific layout.
"run": "anti-clockwise" ; Global travel direction on the circuit, can be clockwise or anti-clockwise.
}

- map.png is the image used by the track map app(s) in the driving sessions.
\subfolder for skins/layouts

574
1.2.1 - TRACK LAYOUTS
In AC a single track can have more than one layout. Taking the official Nordschleife for example, you have four of them: Standard, Tourist, Endurance,
Endurance Cup.
This is done via files and subdirectories located under the circuit’s FIN folder. If you look into the %root%\assettocorsa\content\tracks\ks_nordschleife, it's
pretty straightforward.
The primary thing to know is that there has to be the main track .kn5 model inside the your_track_name folder. It is required by the simulator in order to
recognize all the other assets in the FIN folder, and you have to use it to store all the common road/landscape elements and objects. Timing and spawn
objects (see par. ) can be included too. Any variations between different layouts are stored in different .kn5 files. So if you have a layout that needs a barrier,
you should create a model with just that object, and keep the main map as clean as possible (Fig.). This is also useful if you want to create a specific
physical mesh for each layout (see par.).

Fig. – Various models of the Short layout of the Kunos Black Cat County track. (top) landscape. (left) visual and physical meshes of the driveable surfaces. (right) Bushes and rocks.

Let’s say that you have multiple layouts, called layout1, layout2, layout3, etc. Then the following subfolders are needed:
your_track_name\layout1, your_track_name\layout2, your_track_name\layout3, etc.
Inside each of these directories must be included all the respective data files and folders we discussed about earlier, that will be treated in detail going forward.
All the layouts are managed with config files inside the track’s FIN folder, that specify which .kn5 models are to be used for each layout. So in our case we
will have to create the following files:
your_track_name\models_layout1.ini, your_track_name\models_layout2.ini, your_track_name\models_layout3.ini, etc.

The models_ prefix for the config script is MANDATORY. The names that follow it must be identical to the names of the respective folders.

Follows the script you must use, in this case taken from the official Black Cat County Short layout by Kunos:
[MODEL_0] ; Model identifier. SYNTAX: [MODEL_ID], ID starting from zero.
FILE=5.kn5 ; Specifies which 3D model file shall be used for the ID above.

% ▲ If only the .kn5 model is specified in this field, it must be present in the main folder of the track.

POSITION=0,0,0 ; Adjustment of the position of the model in x,y,z coordinates, with respect to .
ROTATION=0,0,0 ; Adjustment of the rotation of the model.

575
[MODEL_1]
FILE=ks_black_cat_county.kn5

% ▲ The filename references don't necessarily have to be files in the main track folder. Anything can be done with a regular MS-Windows folder path, so
if you write kn5s/left_fence.kn5 for example, you will be able to put the model into a subfolder named kn5s. If you write ../magione/magione.kn5, the
script will load Magione's main track, and so on.

POSITION=0,0,0
ROTATION=0,0,0

[MODEL_2]
FILE=4.kn5
POSITION=0,0,0
ROTATION=0,0,0

[MODEL_3]
[MODEL_4]
[...]

% ▲ A track can have as many models as necessary.

[DYNAMIC_OBJECT_0]
PROBABILITY=75
MULT=1,1
FILE=11.kn5
POS_MODE=RANDOM
RND_POS_CENTER=-320,260,1400
RND_POS_RANGE=1000,10,1000
VEL_MODE=RANDOM
RND_VEL_BASE=0,0,0
RND_VEL_RANGE=2,0,2

[DYNAMIC_OBJECT_1]
[DYNAMIC_OBJECT_2]
[...]

Keep in mind that if you use layouts, you must include the main model in this management script.
As you can see there are also other sections in the example provided, called [DYNAMIC_OBJECT_#]. We will come back to them later on.
In the meanwhile, for the game UI screens, it is mandatory to create inside the FIN\ui folder the respective ui\layout1, ui\layout2, ui\layout3, etc. paths, with
the correct .json and preview files (see Paragraph 1.2).
The Nordschleife uses 1.kn5, 2.kn5, etc. as names for the layouts. You can use anything you like, respecting the rules for filenames. So layout1_kerbs.kn5
will work, too. As long as the your_track_name/your_track_name.kn5 is present.
Each layout model can and should (only) include the specific cones, barriers and corner marker boards, along with the respective physics geometry, to make
sure people can't take shortcuts (Fig.). However, layouts can be used to store also miscellaneous objects, props and decorations (Fig.).

Fig. – Comparison of the two layouts for the Brands Hatch track by Kunos. (left) GP layout. (right) Indy.

576
Fig. – Objects on the side of the road or outside the circuit can be included in a separate model if necessary.

Pro tip: another use of track layouts/extra models is to add more pitboxes and positions on the grid for already existing tracks. You can simply create a model with the spawn
objects (see p.) at the right coordinates and add it to the list. It won’t generate online multiplayer mismatch with the original track, it will simply represent a different version. It’s
the easiest thing ever. It takes the “I have Spa with 30 pit boxes already, but it is not enough. I have to add more” to an entirely different level. Also, Fig..

Fig. – Self-explanatory response from Kunos.

Please note that in vanilla AC you can pack cars close together in pit lane ONLY FOR online MP (Multiplayer). In Single Player (SP) the AIs will run into each other as they
don't drive through each other like you can in MP. That is why Kunos is limited to having them in a straight line and a certain distance apart. If you actually skip practice and
qualify session and go directly racing - there will be no problem, all AI's will be on the grid and not on the pit lane, provided that there are enough spots on the grid.
One way you could deal with this is to have a set of config files for MP and SP for the track. The track model would be setup to hold say 32 pit boxes but in SP you can only
choose say 18 if that is all the track can do in the straight line. But in MP you can have a pit box anywhere in the pit lane without any issue.

The CSP mod overcomes this problem, allowing cars to be without collision in the SP pitlane. (unsure, in certain situations it happens)

As final advice, when adding pit spawn objects, most likely the pit line needs to be re-recorded. Otherwise, the AIs may teleport off the track into the pits.

577
CHAPTER 2 - MODELING
the road mesh can have up 64k tris, maximum length 1km

Pro tip: Very early in the project you can use a single low-poly road for both the visual mesh and physical mesh, just to get the track in-game and driveable.

wip
Visible join between the terrain meshes: blending the textures is no problem, but correcting the normals to smooth the lighting along the two edges can be
a pain. 3DsMax users can adopt this script: http://www.scriptspot.com/3ds-max/scripts/vertex-normals-stitcher; it effectively unifies the normals where two poly objects
meet, but without having to weld them. It is useful for example if the mis-matched normals come about from joining a mesh that started out as a lofted
object (verge) and a low poly terrain. Create a bridging mesh between the two and then correct all the normals afterwards. Blender users

2.1 –
2.1.2 - SPLINES
Using splines to model the road meshes is very useful, as any adjustments to the spline will be automatically updated. This means less work (edit in a non-
destructive manner), and less room for error, making everything automated. If you make a change to a corner, the roads, verges, fences, etc., all continue to
work together, seamlessly.
Regarding things like verges, wall, kerbs, create a lofted object using the same spline for the main track, along with its own cross-section shape, and then add
an Edit Poly modifier to edit the individual polys whilst still keeping the object tied to the spline. For kerbs, create a single long kerb that spans the entire
length of the track, then use the Edit Poly modifier to delete the polys in between the kerbs. You are then able to make changes to the spline without having
to remake the kerbs/walls etc. This maintains cohesion with the rest of the track objects until near the end of the project when you are then in the position of
collapsing everything to a mesh.
To ensure that the edges of you curbs align with the edges of the road, align the verts of each part's shape, or cross section, with each other. So, if the road
surface's cross section's outer edge vert is placed at X=6m, Y=0m, make sure that the first vert of the grass verge's cross section shape is also placed at
X=6m, Y=0m. That way, when the objects are lofted, the edge verts are all in exactly the right place, no gaps, no adjustments needed. As long as you use an
instance of the spline, and the same number of steps on each loft object, they'll be perfectly aligned.
Adding detail to a spline: in 3DsMax it is done by adding a Normalise Spline modifier, which takes the entire spline and creates new vertices, spaced at
whichever interval set.
Pro tip: be careful when using Normalize Spline, as sometimes it can change the geometry of the corner entry/exit, leaving a nasty little “kick” that looks very wrong.

For very old tracks a very small amount of noise can be added (on the Z axis) to all of the verts - only +/-15mm, to avoid making it feel like it has been made
to modern FIA standards. As this change to the spline is reflected immediately in the (low poly) physical mesh, export a new .FBX and test it in-game, to make
sure it hasn't been added too much.
Once happy with the overall randomness select only the verts where you want more noticeable bumps to be. If you selected all verts, the whole track would
be bumps and feel monotonous.
A quick note about random noise: even though it is all random, some works better at certain points on the track. 3Ds Max allows you to use a specific “seed”
or fingerprint for your noise. I use this, combined with exaggerating the scale, to see how the bumps will feel. Blender
Pro tip: make sure you test with as many types of cars as you can, to avoid obtaining a track that feels great in the Maserati 250F but like a ploughed field in a modern GT3.

This process gives bumps that run the entire width of the track, as you’re only adding noise to the spline. The next step is more destructive, requires to
remove the track surface from the spline, and to edit all of the verts in the mesh, to give a more realistic feel. This is the last stage you will go through, as
once the physical mesh is removed from the spline, any further changes to the spline will not be applied to the mesh.
Add the access roads only once you have finalised the main track, rather than making them dependent upon each other with splines.

2.1.3 – SPLITTING THE MAP

With the triangle count limited to 64,000, one can’t keep exporting a single mesh to test for very long. At some point it is either impossible to add any more
detail, or the map is too big to fit (e.g., epic monster Hillclimb track).
So the next step is more destructive, and more time consuming, and therefore when working with splines it is only done at the end of the process, once one
is happy with the track. Otherwise, if you know things will start huge from the beginning, splitting meshes will be your daily routine.
First step is to split the mesh into smaller sections.
To be able to add the kind of detail you want, the next thing you need to do is to dramatically increase the number of tris in each section.
Pro tip: here you don’t want to use a Subdivide modifier in 3DsMax for the physical mesh, because although it increases the number of tris (great), what it doesn't do is adjust
the transition from one poly to another accordingly (not so great). The road would still be faceted, as Subdivide doesn't reduce the angle from one face to another. On fairly flat
tracks with no great changes in elevation, the problem isn't very noticeable, but with tight, uphill hairpins, that becomes an issue. On sections of the track with large changes in
elevation you get a low-poly chatter (vibration) from the wheels. Once you switch to TurboSmooth that all goes away, and the road actually becomes too smooth, forcing the
increase of random noise, but that is not a problem, because noise can always be added, it’s difficult removing it.
For example, take a 2000 tris section, add a TurboSmooth modifier set to 3 iterations (each iteration multiplies the number of tris by a factor of 4). This gives a new total of just
over 120,000 tris, with a vertex every 20cm or so.

578
2.3 - MODELING RULES FOR AC TRACKS
JKLLM
2.3.1 – COORDINATE SYSTEM: THE TRACK IN THE 3D SPACE

2.4.2 - MODELING BUDGETS

The original Kunos pipeline 2.0 doesn’t say anything about track models. However, we know that they are on average around 200 MB in size. For huge
circuits like the Nordschleife, the number goes to more than 400 MB.

About materials: official AC tracks use no more than around 50-60 different materials (information confirmed by the devs) (quite old).

To check whether your model is performing well or not, you just have to test in a race session, because the scene is not visible all at once. There is the
rendering distance limit.

2.4.4 - SETTINGS AND TIPS TO EASE THE WORKFLOW IN BLENDER

(Move to ksEditor)
If you have missing textures after the export, as you can see in the attached screenshot below (Fig.), some of your meshes have the normals flipped. You
can easily see this by turning on "Face Orientation", going to the top-right of your viewport and click the arrow next to the two circles icon.

Fig. - It should all be blue when facing towards you, and red when facing away (=wrong direction if it's facing the camera). You can flip normals by selecting the faces, ALT+N > Flip.

2.4 – SET UP THE SCENE: COORDINATE SYSTEM

The nearer to 0,0,0 the better;

the problems at a far distance and 32 bit physics.

The CSP fix with 64 bit physics.

579
2.5 - ROAD: VISUAL AND PHYSICAL MESHES
In this paragraph we will discuss the difference between the visual road and the physical one.

First off, at least ten years ago in racing games there was no difference between the visual and physical road. The mesh you saw was what you were driving
onto.
This was fine back then, but with the advancement of the physics engines we needed more road detail to feel all the little bumps that every track has got. The
problem was that if you added too much detail to the visual road the framerate suffered. So software developers came up with an idea: separating the
physical road from the visual. This allowed a highly detailed and invisible, physical mesh to be hidden under the hood.

Just to show the difference, in Fig. is what they look like before the .kn5 export. Fig. instead shows the comparison after the export (thus with triangulation)
on the Imola track by Kunos.

Fig. – Comparison of road meshes from different tracks: on the left, the visual type, on the right physical.

The key here is the poly count needs to be just high enough so your turns looks smooth and not a bunch of straight lines. Notice the turn is of a higher
detail than the straight.

Do not be afraid of too high of a poly count on the physical. I have done tests between a 40k and 600k poly mesh and found ZERO loss in FPS. The only
thing I saw is it may add some time to your loading time. But be reasonable with your numbers. For example Kunos’s Monza is exactly 400k triangles and
the Nordschleife is around 730k triangles. The key is to make sure you set the IsRenderable setting in the editor to False. Also obviously the physical model
should be called 01ROAD and the visual can be anything else.

The reason this is important is if the physical layer is low count like the visual you get this "notchy" feel to your track (Fig.). If you have a hill instead of
driving smoothly over it you are essentially driving over one flat plane after another.
Pro tip: physical meshes should not be longer than 300 meters. This includes roads, walls, etc. The CPU usage will be too high if this rule is not followed.
Moreover, AC tires have a tendency to not like sharp edges, so when modeling kerbs / rumble strips, it’s a good practice to have a simpler mesh acting as the physical mesh
for a kerb.

580
Fig. – Official Imola track by Kunos. After the .kn5 export, all meshes are triangulated, including hidden ones. Top, visual, bottom, physical.

Then I just add a displacement modifier, moving each vert randomly in the z-axis by a maximum of +/-15mm. I have done lots of testing with different noise
patterns, experimenting with various types, amounts, sizes, and I now have a fair idea of what works well. For smooth sections of track I use a random Perlin
noise with 2 or 3 fractal levels. Fractals are to Perlin noise what harmonics are to a sine wave. They are kind of noise within noise, and the more fractal levels
you use, the more detailed the surface feels (to me). If you listen to a sine wave it is simple, dull... the same goes for Perlin noise, in my opinion. Once you
add harmonics to a sine wave you are able to give the sound characteristics, tone, colour. Same with noise - once you start adding fractal levels you create a
lot more detail in the mesh.
The only thing left to do is to optimise the mesh, reducing the number of polys. Use the Optimise modifier in 3DsMax - this identifies which faces are effectively
redundant (because they don't contain any detail) and merges them together. Aim to get each section down to around 25,000 tris. Any more than this and the
track surface feels too noisy, gritty - it almost send too much information to your wheel. If you optimise too much, you will lose all the lovely detail you just
added, so it is definitely a balancing act which requires a fair bit of testing and experimentation.
Obviously, if you make any changes to the visual mesh you will need to re-make that section of the physical mesh too.

581
2.2 – TRACK REFERENCE MATERIAL

Good websites to find references for real-world tracks are:

• http://theracingline.net/racingcircuits:
• https://jthatch.com/Terrain2STL: allows you to downloaded a low-resolution mesh of the terrain in the STL format. Useful for getting the basic landscape right (Fig.).

Fig. – (top) The Terrain2STL website, with the town of Asiago (Italy) selected. (bottom) The model imported in Blender. You will need to scale it to achieve the correct dimensions, as
you can see from the measurement.
You can make a spline for the path from a track schematic (digitising it in Adobe Illustrator or Inkscape) and drape it over the low-res terrain, loft it to form a driveable road,
and go for a test drive in AC. It’s probably the easiest way to get started with a track, but it’s not the most accurate one, as it has a resolution of around 90 metres, as specified
on the website. However it can be used to recreate the terrain further away from the track. Other methods can be employed for the terrain near the circuit.

• One thing you can try if you can't find any high-res data (for free), and you can't even view the road on Google Street View, is to use video footage of a race to work out the
track width at various points around the circuit. You have to know the “base” width of the track, usually on the straights. With one good, steady, clear video taken from inside
a car (little body roll compared to motorbike videos), place a ruler in front of your monitor to measure the width of the road. As you know the “standard” width, you can
scale from that measurement to work out how wide the road is at key points, like hairpin bends, or bridges. It takes a while but you sit with a piece of paper & a pencil and
write down around 100 measurements or more around the track, and while it may not be the most accurate data, it is some kind of data to work with.
You can also take notes about the camber around the track, and use the Twist deform tool (3DsMax) to twist the track by varying amounts to give your road camber.

582
Google Maps why not? - Google Earth may have historic variations – Topography

2.2.4 – LASER SCANS – LiDAR TECHNOLOGY

When complex or large environments need to be documented, laser scanners provide a practical and cost-effective solution.
Traditionally, the acquisition of large environments relied on instruments that produced single-point measurements, such as tape measures, harmonic wire,
plumb bobs, laser rangefinders, and total stations. Although these are familiar instruments, they are often time-consuming, often days, weeks or months
depending on the space. In addition, traditional instruments often produce inconsistencies in user-to-user measurements, and eventually data are often lost,
leading to potential cascading inaccuracies.
In contrast, laser scanners are non-contact devices that measure an object or space using a technology that produces detailed 3D images in minutes.
So how do they accomplish this so quickly?
The measuring technique is called LiDAR (Laser Imaging Detection and Ranging) in the scientific field and makes it possible to determine the distance to an
object or surface using a laser pulse.
The laser scanner emits a beam of infrared laser light onto a rotating mirror that effectively paints its surroundings with light. The scanner head rotates,
moving the laser over the object or area. Objects in the path of the laser reflect the beam back to a sensor inside the scanner (Fig.), which captures millions
of discrete 3D points, known as PCD (point cloud data), that can be interpreted into 3D geometry models.

Fig. - Electrically and optically packaged 512-element OPA (optical phased array) with an inline architecture. Due to the emerging need for solid-state LiDARs to increase durability while
reducing size and cost, there is significant interest in implementing OPA-based LiDAR.

583
In addition to distance, laser scanners also acquire displacement in the horizontal and vertical planes, providing a full range of measurement data.
A laser scanner generally acquires data through two types of systems:
• Time-of-flight systems: also known as pulse-measurement systems, it works by emitting a single pulse of laser light and determining the distance to the end point by
quantifying the time it takes for the light to be reflected back to a sensor on the scanner.
• Phase-shifting systems: similarly, this system also uses an emitted laser light, but in this system the light intensity is modulated with specific waveforms. The reflection of
the intensity patterns is shifted by the impact on the surface of the object, because it is also partially absorbed by the latter (Fig.). The displacement measurement between
the sent and received laser signal provides an accurate distance calculation. In general, laser scanners using phase-shifting systems are accurate, fast and provide high
resolution data.
Laser scanners are versatile, easy to use and move and accurate, making them an ideal tool for many applications and sectors:
• Law enforcement and fire safety: crime scene documentation, accident scene reconstruction, fire scene analysis, forensic investigation and more. Laser scanning saves
hours of documentation time and preserves a digital replica of locations that may be environmentally vulnerable.
• Insurance: to document the actual state of a piece of property at a given time, for establishing a baseline for value and obligation, as well as documenting losses with
damaged vehicles, property or products.
• Oil & gas: laser scanning is well equipped to assist in engineering, maintenance and planning on oil platforms and in refineries. They are also very useful for documenting
complex piping structures to avoid problems or installation errors.
• Public service: services that need information about huge networks distributed on a territory employ LiDAR to ascertain the actual state of the sites. An example is the railway
infrastructure, leveraging track geometric information models from airborne data. Rail infrastructure is a complex, safety-critical system (Wilson et al., 2007) that unfortunately
faces catastrophic risks such as derailments and collisions. European Railway Agency estimated that railway accidents' total costs at £3.4 billion in 2018 including derailments
and collisions (2020), even though these disastrous incidents are rare. Unplanned disruptions to railway operations are an example of improper maintenance of rail
infrastructure. The European railway industry could save between £1.4 billion and £6.1 billion (McKinsey & Company, 2021) by implementing preventive maintenance
measures. LiDAR technology is one of the most extensively used technologies for acquiring data in these types of environments since it enables capturing massive volumes
of data in a short period of time (Fig.).

Fig. – (top) LiDAR PCD of railway line segments. Notice the false positives at turnouts. (bottom) Rail point clusters are severely affected by the variations in incidence angle, resulting in
partial laser returns.

• Atmospheric measurements:
• Architecture and civil engineering, historical preservation: laser scanning can document the complex geometries of existing buildings to study, preserve or restore them.
• Formula 1 car scrutineering: since the start of the 2022 season, the FIA has outlined a new laser scanning scrutineering system to examine the legality of the racecars.
The teams share their CAD data on aerodynamic development with the FIA, and the laser scans are used to check if the physical car correlates with that data information 91.

In any application scenario, a laser scanner produces accurate results in less time and with fewer errors than more traditional methods.
To create the 3D models of the official tracks, the developers of AC scanned the real-world circuits as 3D point clouds, which provide the locations,
orientations, and dimensions of the road and the trackside objects.
This process requires to slowly drive onto the circuit with a vehicle, geolocated with GPS and equipped with the necessary special instruments and sensors
(Fig. ). The interesting part is that the more you get further from the spot where the laser beam starts, the more the dots start to become sparse, because
clearly the emission has a maximum distance where it can be detected. That’s what gives the PCDs their peculiar look.

91
At some point they’ll put the scanners up the driver’s bum.

584
Fig. – The setup used by Kunos to laser-scan Spa Francorchamps back in 2013.

Guided by the point clouds, the 3D artists model the polygonal meshes of the track surface, crash barriers, marker boards, trees, and buildings, and place
those objects in the virtual world. They also texture map them, to represent closely the real-world counterparts.

A lot of work and money goes into it, from renting the track, sending there a company which has the LiDAR system gear, doing the scan, cleaning the images.
Everything is still quite manual. The passage from laser scan to the finished product in-game is never automatic. There is no “give me the track” button. Only
the 3D modeler is always in control and knows where a certain number of polygons is needed, and where it isn’t.
But the gain is the time saved: there won’t be any discussion between the 3D artists and the directors, saying “you know what, I felt like that curve was going
a little bit more uphill”, or “oh, but I remember that there was a hole right there”, etc. There is little to no room for doubt.
As a simplistic reference illustration of the process, you can look at Fig. which shows in few steps the job done by Kunos with the official circuits. By the
way, did you know that when AC came out, it was the first time ever in a PC racing simulation that the legendary Nürburgring-Nordschleife circuit had been
reproduced using Laserscan Technology?

Fig. – Entry of the Tosa corner (Imola). (top left to bottom right) Photograph, laserscan point cloud, 3D model (solid), in-game (with textures). All images by Kunos.

585
Fig. – The same sequence of Fig. , with the Imola Tower this time. Come on, vanilla AC does look very good, it’s just that people got used to higher standards.

Note that even with laser scan technology things don’t always work as planned! See Fig. (railway) and Fig. below.

Fig. – Yep, that’s him, Marco Massarutto, the Assetto Corsa Project Manager. He accidentally became part of the scan while he was on the phone (isn’t that a bit dangerous?).

In the next pages we have a gallery of laser-scans and point cloud data collected by Kunos to make the official tracks.

586
Fig. – From the Nürburgring-Nordschleife laser-scans by Kunos, made with a two centimetre resolution (2014). This was the first time the track was scanned in history.
587
Fig. – Some laser-scans of Spa Francorchamps by Kunos, compared side by side with the 3D model. The bottom right image is the scan of the Eau Rouge corner.

588
Fig. – Laguna Seca PCDs by Kunos.

589
Fig. – The developers had fun laser-scanning every millimeter of the Monza circuit. Patriotism. (top) Sopraelevata section, for the official Monza 1966 layout. (middle) The main straight.
(bottom) The Serraglio bridge. These are strangely beautiful.

590
Fig. – Point cloud acquisition, Autodromo di Imola. My personal favourite. (top) Tamburello. (middle) (bottom) Variante Alta and Imola tower.

591
2.2.5 - FAITHFULNESS
At this point an underlying question makes its way to our foreground: why is the laserscan technology so important and fundamental to get an accurate
recreation of a racing circuit?

The answer lies not only on the road itself, which is the sacred path of the racecar on its mission to victory, but also on the landmarks, which constitute a
series of information essential to the driver. As he needs to understand where to brake and accelerate, in real life he starts noting in his brain a certain
number of reference points.

If these spots in the 3D model are in different locations than in reality, for a pilot there will be no purpose in training with the simulator, it will be wasted
time, absolutely useless, because when he goes on the real track he will have to find new reference points.

Employing laserscan then means being able to provide the driver with as many landmarks as possible, in the exact position where they should be.

With the fact that we can perfectly laser scan tracks, we can [also] accurately compare our lap times to the historic lap times. Once we successfully replicate all of the
variables of each track time and we can match the time digitally, we can be confident that we are as close as possible. (Aristotelis Vasilakos, 2016)

Fig. – This is what I call being true to real life. The track is Vallelunga. Example of sun position calculated in realtime, depending on the coordinates of the track and according to time
and date.

Problems with historic coherence on vintage tracks

You should include any and all tobacco-related advertising, as appropriate. Editing the history of motorsport so it conforms to the modern sensibilities is one
of the most foolish things imaginable... it wouldn’t be history anymore.

Not even Kunos tracks are completely faithful: see the missing chicane from Monza 1966.

592
593
2.5 - NAMING RULES FOR TRACKS
A track is not only made of concrete or tarmac, right? We have different surfaces and objects. Giving a different name to each one of them will make the
difference between driving on the Silk Road and throwing your car in the haybales of the nearest barn.

2.5.1 - NAMING RULES FOR SURFACES

The physics engine takes into account the naming of your meshes in order to give them physical properties. The syntax is: <ID#><label><optional_suffix>

Where:
1. ID# is a number; it must be > 0 (greater than 0, so 1, 2, 3, …) if you want the mesh to have some physical properties. It can be 0 or missing, and the object will be only a
graphical asset. You can also start from 01 instead of 1.
2. label is the name of your object/mesh, used as identifier for the surface type;
3. optional_suffix – as the name says, you can use it if you need, but has no impact on the object properties.
4. The separator between the label and the suffix can be anything, or missing.

The label parameter is very important and deserves some more explanation, as it will be used to define both the rolling surfaces and the collision meshes.

For rolling surfaces, there are pre-defined keywords that you can use as labels, being basic surface types already defined in surfaces.ini inside the folder
assettocorsa\system\data. They are:
1. ROAD (will make the chosen mesh driveable; acts like tarmac);
2. GRASS (offroad, grass areas out of the road boundaries, really bouncy and very slippery);
3. KERB
4. SAND (pretty obvious, the surface acts like the sanded areas in circuits, slowing down the car quite heavily; quite bouncy);
5. PIT (driveable, for the pitlane only)

Here are some examples, with basic and custom surfaces (see also Fig.):
01ROAD; 3SAND; 22PIT993; 58KERB_west; 33GRASS_green_darktone_325; 01TARMAC-IMA011; 17CONCRETE005

Fig. – This example uses basic surfaces (3D software used: Blender). You can manage any section of your track by giving a different name to each one of them.

If you want, you can adopt a custom surface name, for example 1CONCRETE or 05GRAVEL but you’ll have to define the characteristics of each label, like
friction, FFB behaviour, etc. in the dedicated surfaces.ini of your track (we’ll talk about it later).
Pro tip: in general, in AC, if an object name starts with number, it's used for auto collision, and it needs to be defined as surface.

594
For collision meshes instead, WALL is a mandatory label. There are no custom alternatives. The syntax is the following: <ID><WALL><optional_suffix>

Where:
1. ID# is a number; it must be > 0 (greater than 0, so 1, 2, 3, …) if you want the mesh to be collidable. It can be 0 or missing, and the object will be only a graphical asset
without collision detection. You can also start from 01 instead of 1.
2. WALL is the label used as identifier for the collision surfaces;
3. optional_suffix – as the name says, you can use it if you need, but has no impact on the object properties.
4. The separator between the label and the suffix can be anything, or missing.
Here are some examples:
1WALL_fence; 04WALL_building; 2WALL-pole; 15WALLprotection12; 67WALL23

- It is possible to quickly define an object as an obstacle (fence, building, pole, barrier, …) just by naming that object using the WALL label, but this is not
correct. Here's the right way: model and name your objects as you see fit, and then add an invisible and as-simple-as-possible mesh around them. Call this
mesh with the WALL label. This will assure the best behaviour.

Don't exaggerate with polycount with walls. Never call a complex object, like the armco barriers, guardrails or tire walls, as the actual WALL collision mesh.
Any physical object should be as simple as possible (Fig.), so draw a simple collision mesh and make it not renderable by setting Render to false in
ksEditor.

Fig. - As you can see here the barrier is simply visual. The actual WALL collision mesh is the highlighted box around it.

For WALLs you can technically use boxes, flat planes or polygons. The fewer faces the better, so you can remove top and bottom faces. (Fig.)

Fig. – These are valid examples of what you can use for track colliders. The colours indicate the front and back faces based on normals (Blender).

Try to keep parallel faces far away from each other: you can get stuck in them if the back face is too close to the front face and you hit the collider too hard
with your vehicle (Fig.).

In any case avoid using solid objects as much as possible, and employ flat planes/surfaces for the most, with the normal vector of the faces pointing to the
track. That’s what AC is checking, if the normal of a wall should point outside you collide, if the normal points inside, you can drive through (Fig.).
Pro tip: with conversions from games/other sources, if you just rename existing objects to #WALL, you will get mixed results; rFactor tracks for example tend to have weird
normals, and that’s what AC is checking; the normal of a wall should point outside, if the normal points inside, you can drive through; also if the geometry is complicated, you
get stuck, so the best way is to make new colliders around the track.

595
2.4.2 –RULES FOR SPAWN OBJECTS (CIRCUITS)
Spawn objects are special meshes which, given a correct name, determine various locations on the track where you’ll spawn at the beginning of a session,
for example in the pitlane, or at the starting line.
These meshes must be kept as simple as possible, and the shape must be cubic (a box, Fig.). They will not be rendered (invisible), so their position is the
most important thing; just remember to map them with a material (no need to create a unique material, just use any that you already have in the scene) in
your 3D editor of choice.
There's no need to make spawn cubes invisible (AC_PIT, AC_START – etc.), they will not be rendered automatically based on their name.
You can also use dummies (3DsMax) or empties (Blender) and in that case you no longer need to worry about materials. But it is easier with boxes.

Fig. – Example of spawn objects (3D software used: Blender). Many of the cubes you can see, once named correctly, will determine the positions of the cars in the pitlane.

In general, anything related to a position must follow this rule: the Y axis of the pivot point must point UP and the Z axis must point forward and will
determine the orientation of the car. This is very important for 3DsMax users, where usually Z axis is UP and Y axis is forward, beware.
All the spawn objects have to be above ground, as the car may clip through the ground otherwise.

The boxes that determine the positions of the pit-stop areas and of the spawn in the pitlane (for each car) must be named:
AC_PIT_# (# must be 0, 1, 2, 3, …, etc.). DO NOT add zeros before the numbers, for example AC_PIT_01 is incorrect (01 is different from 1).

The meshes in the starting grid positions must be named:

AC_START_#

The Hotlap start position must be named:

AC_HOTLAP_START_0

AC_PIT_0 must always be present. If you put only AC_START_0, the session will crash.
Pro tip: (for later, when you’ll be getting ready to get in-game with your track) the kn5 model file that contains pit/grid positions is mandatory. If that is missing, or spawn objects
are not present at all in your 3D map, AC will crash. This is very important in case you split your map into different files for either layouts (see p.) or optimization purposes.

596
2.4.3 – RULES FOR TIMING OBJECTS (CIRCUITS)
Timing objects are slightly different from spawn objects. They’re still cubes with a material applied, but they work as the extreme points of a segment, which
the cars cut, determining the lap time or the time with respect to a specific checkpoint. You can think of this like an invisible line (Fig.).

Fig. – Fictional representation of the timekeeper line. This track I made years ago went unnoticed, but in this-guise he will serve the teaching purposes as an old free-end.

These objects don't need the axis orientation like the spawn objects:
AC_TIME_0_L must be placed on the LEFT side of the start/finish
AC_TIME_0_R must be placed on the RIGHT side of the start/finish

To create an intermediate checkpoint, follow the same rule about left and right. Keep in mind that you can place only 2 intermediates.

The number 1 will be the first checkpoint. Use the number 2 for the second intermediate.
AC_TIME_1_L AC_TIME_2_L
AC_TIME_1_R AC_TIME_2_R

The trigger will be a line drawn from the center of the object to the other side (not visible obviously).
Timing objects do not need to be above ground, they can be touching the terrain. What matters is that the car must pass through them, not above nor
below.

Timing objects are the ones that determine the checkpoints in the Time Attack mode (Fig.).

Fig. – The Time Attack checkpoints in AC (Magione).

597
2.4.4 – NAMING RULES FOR POINT A TO POINT B TRACKS
What are point A to point B tracks? Most of the times they are roads, where you compete to be the fastest to reach point B, starting with your car from point
A. There are a lot of events, often rally ones, that take place on these types of tracks. Famous roads are part of this category too, like the Romanian
Transfagarasan, or Colorado’s Pikes Peak Hill Climb (Fig.). Both (and other maps of the same kind) have been recreated in AC if you want to enjoy them. An
example from the official content is the Trento-Bondone hillclimb course map, which Kunos brought directly from their old NetKar Pro simulator. Probably
only old school gamers will remember it.

Fig. – The Pikes Peak Hill Climb is really dangerous; you can definitely feel it in AC.

These are pretty challenging experiences, often the distance you have to travel is pretty long, and that’s part of the fun! You can also take them slowly and
enjoy the trip.

Keep the same naming rules for the pit spawn points as the circuits. Keep the same naming also for the hotlap start spawn point. There is no starting grid.

The starting line (point A) uses the following names for the objects (where L and R stand for left/right side of the road):
AC_AB_START_L
AC_AB_START_R

The finish line (point B) uses:

AC_AB_FINISH_L
AC_AB_FINISH_R

some free roam maps might not have time-gates, then you cant record ai line, it simply doesnt know where to start.
You can use layouts to overcome this problem and add in the timing object at the right coordinates.

598
2.4.6 – OTHER NAMING RULES
- If you'd like to have dynamic collidable objects in your scene (roadside cones, for example, see Fig.), use the following naming scheme for said items:

AC_POBJECT_suffix_00X

The AC_POBJECT is a simplified geometry for the collision, and underneath it, you will have the actual mesh that you want to be visible. That’s for
optimization purposes, as the actual full detail mesh might be too heavy for the physics (and potentially buggy).

Fig. – How to create cones for your track (3DsMax). The pyramid will be invisible and collidable.

In order to avoid unexpected issues, they work best when used on objects with simple geometry, and devs recommend not having too many (not more than
15 iirc). Even though you could get away with more.
There's nothing automatic, unlike spawn objects: you have to set the parent object (the collision mesh) as not renderable (IsRenderable=False in ksEditor,
see p.).
The center of mass should be the mesh pivot. Which decides how it can fall over.

- How to define the pitlane (with pitlane speed limitation):

You need to define a specific key suffix for the pit surface (within the track data file surfaces.ini, see pag.), and then use it to name the pit ground mesh(es)
accordingly. Example:
[SURFACE_1]
KEY=PITS-ZONE
FRICTION=1
DAMPING=0
WAV=
WAV_PITCH=0
FF_EFFECT=NULL
DIRT_ADDITIVE=0
IS_VALID_TRACK=1
BLACK_FLAG_TIME=0
SIN_HEIGHT=0
SIN_LENGTH=0
IS_PITLANE=1
VIBRATION_GAIN=0
VIBRATION_LENGTH=0

And then name the meshes composing the pitlane accordingly: 1PITS-ZONE, 2PITS-ZONE, and so on. The suffix can be anything, however you should stick
to these, for standardization purposes: -PITS, -PITS-ZONE, -PIT, -PITBOX.

599
2.5 - MODELLING GENERIC PARTS OF A TRACK: VEGETATION
The flora plays a huge role in giving a real-life look to your maps. Nowadays you can create photorealistic sceneries with some simple effects that we are
going to explain in the next paragraphs.

2.5.1 - VEGETATION TEXTURES, MATERIALS AND OBJECTS

If you already read PART 1: CAR MODDING of this manual, you will already be familiar with many of the following rules. This is an occasion to revise then.

First of all, as we already saw with cars, do not use .png or .jpg files for your textures.

PNG files are ok to use for testing as it can be a pain to assemble DDS files sometimes. But when it comes to finalizing and releasing the project, please be
sure ALL textures are in the DDS format. Just 1 PNG will cause stutters.

Second: keep your material list to a bare minimum. If you have multiple tree species on your track, consolidate them into 1 or 2 textures. If you have 8
different trees do not include 8 different textures. Remember it is always better to have fewer but larger textures than a bunch of tiny ones, because each one
has to be loaded separately. If your track has 500 different textures then you have too much. Try to keep it under 200 for the entire track.

For a lengthy explanation of the performance improvements that can be applied to tracks, see Paragraph 2.9.

In Fig. there are some examples of vegetation texture files displayed in Adobe Photoshop. They’re obviously transparent.

Fig. -

2.5.1 – TREES (WIP)

In Assetto Corsa you can have vegetation to decorate your landscape and make it feel more natural.

There is some confusion out there around how to setup trees for AC. Setting them up correctly not only helps you and makes your life easier, but also
improves the lighting and the performance. Therefore, it's highly recommended that you give this paragraph a read and follow it.

There are 2D and 3D trees. For now let’s focus on 2D trees.

What are 2D trees?

Best way (recommended by Kunos) is to use Y trees (remember, AC does not support double sided materials, so you must mirror faces). Make sure you
don't use X trees.

First off on my trees I have my pivot points all on the bottom of the object. If you didn't do this that is fine. but in the future I suggest you do that as it makes
it much easier to apply a random scale to your trees so they all aren't the same size.

600
Blablablabla (what? The page doesn’t write itself, you know?)

Fig. – REPLACE IMAGE (sorry LeBluem)

Don't merge anything regarding trees. Especially the vertices through the center.

wip

After triangulation you obtain trees with 12 triangles each. Can you make it work with less? Yes, see 6-tris Y-trees (nice tongue twister), Fig..

Fig. – 6-tris plants can fill up the environment where lighting isn't critical, so in the distant landscape. Halving the number of tris per tree can make a difference if you are adding 70-
80,000 unique pieces of vegetation.

601
Subdivisions are important for better tree lighting;

For all the trees next to the edge of the track use a 24-tri model which gives better lighting effect.

Pivot point/axis for each object has to be at the bottom. Also make sure vertices are all welded.

You can setup normals manually, but there is an easier way, if you respect 2 conditions. This will assure best look and best performance for your trees.

1) respect naming convention: KSTREE_GROUP_”anyname“_”number”

Example: KSTREE_GROUP_test_1. A group will be formed by all the objects that have the same name and continuous numbering: KSTREE_GROUP_test_2,
KSTREE_GROUP_test_3, KSTREE_GROUP_test_4, and so on. If you wish a second group, change the name of the group: KSTREE_GROUP_other_1, 2,
3,...

kstreegroups automatically merges all single tree meshes into chunks, it does that to minimize DIP and to automatically set normals

2) the pivot point of the single tree must be in the center of the geometry (or slightly moved on Z axis). This way, the ksEditor will set the normals
automatically when you import your FBX.

TREES:
It's not mandatory to be used, but there is a system to manage trees: model a tree, any shape you like. Make the front and back face, you can also weld
nearby vertices (don't think about normals). Place the pivot point on the center of the object.
Name it KSTREE_GROUP_"anyname"_"a number"
example: KSTREE_GROUP_A_1
Let's say you make 10 of them you'll call them
KSTREE_GROUP_A_1
KSTREE_GROUP_A_2
KSTREE_GROUP_A_3
...
KSTREE_GROUP_A_10

When you'll import the scene, the editor will point the normals of each tree in the opposite
direction of the pivot point (if it's in the center, the normals will be like a sphere)
AND will join all the trees of the same GROUP in a single object named "anyname" (A in the case of the example). This will let you the freedom to move
easily the trees in the cad, or change them or rotate them etc etc. but ingame they'll be much more optimized as drawcalls and reaction to light. (the
example above will create a single object named A containing 10 trees).
Doesnt matter how they come out of blender, the name tag overrides normals, and will "sphere" them out of, again, the pivot point of the object. So it has to
placed in the middle of the 3 planes, at the bottom. Trees shader is there for the "no self shadow" function.

The shader to use for Y trees is ksTree, with the BlendMode set to eAlphaTest (the latter is mandatory). Other shaders that support Alpha Test can be used
too (the ones with the AT in the name). Everything can be found in ksEditor.

Below are some examples of different trees and what they look like in Blender.

602
Fig. – Here are 4 basic trees and their object names. Two of them use the KSTREE naming scheme and two do not. The TREE on the far left has all normals set to vertical. For the
remaining trees, the normals are untouched from default. Also notice the vertical subdivisions present only on two meshes.

In Fig. they are displayed in ksEditor with sun overhead. All four trees are using the same shader settings. But it’s noticeable how they become very different.

Fig. - The far-left tree with vertical normals is fully lit, with no shading at all. Next, we see that using the KSTREE object name has altered the normals automatically. The issue is that the
entire center of the tree is dark and only the edges are lit up. On KSTREE_GROUP_B you can see the desired result, with good shading. The only difference between GROUP A and B is
the extra vertical subdivision shown previously. Then TREE2 is just a disaster, entirely in the shadow.

In Fig. we have the same plants, now at low light.

Fig. - As you can see TREE is still lit from top to bottom and completely unnatural. I believe this is what most Race Track Builder trees are doing. GROUP_A doesn't look bad but again
is too dark in the center. GROUP_B once more is the desired result. TREE2 still a disaster, with completely different lighting between the two surfaces.

One important thing about the tree objects is in order for the KSTREE auto normals to work properly the origin of the object MUST be at the bottom.

603
Now lets discuss the whole GROUP thing. It is worth mentioning that from within blender or 3DS you MUST keep the tree objects separate. DO NOT join
them together. The KSTREE naming scheme does that for you with the groups.

So here is a shot of Bridgehampton trees in blender. Selected below on the left is GROUP_A. Notice each tree is a separate object. Just to show on the right
is GROUP_B.

This trend goes around the whole track with GROUP_C. GROUP_D, etc.

You do not have to use A, B, C, D, etc. You can use anything like KSTREE_GROUP_PINE_, KSTREE_GROUP_MAPLE, etc. I find the letters the easiest.

This is what it will look like after you load it in the editor. there will be a section called "BLOCKTRANSFORM" and you will find the group names in there.
The KSTREE_GROUP part of the name will be stripped away.

604
Also know that just because you use the KSTREE_GROUP_x_ naming scheme DOES NOT mean you have to use the kstree shader. The entire point of the
KSTREE naming is to auto set the normals for you and join to single objects according to group name. You can also use KSTREE naming on 3D trees and it
will set the normals just like a Y tree. Just make sure the origin is always at the bottom and the normals will all be done for you on import to the editor.

Some final examples of trees in sim. Notice how the bottoms are all dark as they should be.

605
606
Ground shadows for 2D trees (wip)
This time we are working on 2D tree shadows, which by default look really bad. When the sun is at the zenith, around 12 noon, a shadow that breaks the
immersion appears 92. In order to avoid that you can create horizontal planes for the Y-trees, so that they have proper shadowing. In Fig. you have a
comparison of the trees before and after the fix, with the planes adequately set.

Fig. – (left) A normal set of trees at 12:00 PM. (right) The same trees with the horizontal plane in place.

In this case a single shadow texture was used for all of them, since they are not real close to the track. But if yours are right on the road edge you may want
to use 4 or so different shadow textures so they don't all look the same, like these do.
Let’s see how you do it (with Blender and Adobe Photoshop):
1. You need to make a texture. It is basically the same as a normal tree texture, except you set the opacity of the main layer to 1%. You will need Photoshop for this as the
DDS exporter for GIMP does not seem to make the texture properly. For reference, Fig. is what it the tex looks like at 100% opacity. Just set it to 1% (basically invisible)
and export to DDS DXT5.

Fig. – Tree texture at 100% opacity.

2. Now that you have the texture you must make the plane and then get that plane to be in place on each existing tree. What you do is select all the trees you want to have
the shadow and then duplicate them BUT DON'T MOVE THEM. Just duplicate them in place and hit the M key and select an empty layer in your Blender file. Now you
have the trees duplicated and sent over to a separate layer from your main trees.
3. In the new layer duplicate a single tree, move it away from the rest and single it out. Also make sure it is perfectly vertical and not tilted in any way (Fig. left).

Fig. - () The tree in Edit mode. (right) The plane with the origin, scale and transforms all corresponding to the tree’s.
Next, create a plane and position it over the tree you singled out (Fig. center). Now would be a good time to map your texture to it. The plane can be single sided but the
texture MUST FACE DOWN. After that, join the plane to the tree object (Fig. right). Once joined go into Edit mode and delete all the parts of the original tree. Now you’re left
with a plane that has the same pivot point of the original tree.

92
A "small" technical detail; this is with the Sun position at the Equator and during summer only. In Europe for example, the summer Sun angle is circa 43° (depending on the localization), not
90°. Then, if you did set correctly the Sun trajectory in the track’s lighting.ini (see pag.), you will NEVER see a shadow like that. In other words: if your track is not located at the Equator and
encounter the shadow issue, you should fix the Sun’s position. However, even with the correct sun angle, the technique explained in the continuation creates a much more realistic amount of
shade under the tree during the middle of the day, and it allows to achieve the correct darkness under a tree line.
607
4. Now comes the simple part. Select all your trees but make sure the plane is active, hit CTRL+L and choose "Object Data" and you will get this. Now your plane is in place
of the original trees with the correct scale and angle of the original tree.

5. Next part, the shader settings in SDK Editor. The only thing that matters is the ksalpharef. The rest doesn't make any difference.

You can play with the numbers a bit to make the shadow thicker or thinner.
And on another note I also did a similar process for a tree line. I made a long texture out of the same texture used on the individual trees.

This way inside the first tree row it is shaded. So it doesn't look like this:

I would like to clarify that this is really only needed when the trees don't “touch the ground”. If the leaves are very low and touch the ground, they hide the
trunk area better and there is very little need for the horizontal plane. Bushes can cover pretty well too and give an overgrown look (Fig.).

608
Fig. -

The horizontal plane method can be used in Blender to create an AO map that is added to the mask textures for the terrain. Given that the real time shadows
only draw so far you need the AO shadow to be there so at a distance it looks correct.

Working with huge amounts of trees

If you have a very big scenery, you will notice how the number of polygons necessary increases exponentially if you don’t use techniques that optimize your
map. One Y-tree is very low-poly by itself, but placing thousands of them like in Fig. will reduce the rendering performance, as object draw calls do require
CPU time. Not only that, it’s extremely inefficient as you have to do it manually.
609
Fig. – An example of what should be avoided: placing lots of plants as single objects. On this map 36000 low poly trees, all using a single 1024x512 texture were placed by hand.

Fig. - This track is huge, 21km to be exact.

The technique to learn here, regardless of software used, is to make grids of "treewalls" that criss-cross one another (Fig. top); looking from below it will
give the illusion of a dense forest (Fig. bottom). It’s a very low poly system and can cover massive surface areas that no one will ever be able to see from the
road.

610
Do not apply vertical subdivisions on the walls or else you defeat their purpose. Use four vertices per face. Moreover, usually you don't need shadows on
the walls, so CastShadow in ksEditor can be set to False.
For this particular application the ksGrass shader (see p.) is often preferred because it gives the option to use a variation texture, which reduces the
repetition look. In many areas the colors of trees will vary greatly from species to species. It would be really nice to have variation as an option on the ksTree
shader but we never got it. There has been work on Custom Shaders Patch so maybe we can get it that way.

Fig. – (top left) Walls of tree textures covering some hills in 3DsMax. (top right) The result in the simulator from another project. (bottom) A different track, adopting the same technique.

Accordion-style walls can be used too (Fig.). Sometimes with walls you can notice the straight line (Fig.). The accordion shape does a better job hiding that.

611
Fig. – Accordion-style walls properly set up.

Fig. – Comparison between straight tree walls (left) and accordion shaped walls (right), mixed with standard Y-trees in the foreground. On the left the line of the tree wall is highlighted.

If there are only small islands of trees however, just place a bunch of Y trees instead of walls. They will look better (Fig.).

612
Fig. – These aren’t nearly as many trees as you’d need for an entire forest, so you can avoid using tree walls.

Another note for tree lines/walls is that it is best on the first wall to point the normals vertical. This will darken the bottom to better match the Y trees.
Otherwise you will see the bright tree wall though the trees down by the trunks (?). And it is best to turn off shadows on them as they are not needed.

About foliage
If you want the trackside foliage to appear denser, really jungle-like, cut it up into a lot of pieces and LOD them heavily (using distance LODs rather than
LOD models). But to be honest, I've had a million+ tris on grass alone, always in view, and it did nothing to the performance. So you might get away with
simple LODs.
Pro tip: You can treat the under-tree foliage as "grass" (see par.) in that it does not make shadows and is combined into larger objects and performance should be good. You
should be able to have a large amount under there and not hurt performance much at all as long as they don't generate shadows.

613
Using Alpha test shaders different than ksTree for vegetation
Follows the example of a 2D tree created using the ksPerPixelMultiMap_AT_NMDetail shader (Fig.). The difference in lighting is noticeable.

Fig. - The Y-tree on the right has a standard ksTree shader (following the rules, hopefully). On the left however is a 2D plant using a normal map and specular map.

614
FAQ

QUESTION [1]: The 2D trees are half transparent (Fig.). Do I have to make the mesh double-sided or is there a shader setting I can change?

Fig. – This picture was taken from ksEditor. You can notice the trees, but look at the rendering quality: this modder doesn’t use editor Layouts properly. See paragraph

ANSWER [1]: AC doesn't support double-sided materials, so any object that needs to be visible from both sides needs to have faces on both sides.

QUESTION [2]: I’m using "Images as planes" in Blender for simple 2D trees, but in ksEditor the transparency isn’t correct (Fig.).

Fig. – With this shader you can’t distinguish the trees in the foreground from those in the background. The BlendMode set to eOpaque is another mistake. And again, bad graphics
mean that no editor Layout was correctly saved. This person is rambling, I feel sorry for that.

ANSWER [2]: For 2D trees you generally want to use the ksTree shader with BlendMode set to AlphaTest; you could also pick another shader that supports
Alpha Test (the ones with "AT" in the name). Otherwise, the graphics engine draws the objects in whatever order it feels like, and causes the depth issues
you see.

QUESTION [3]: In ksEditor I put a tree texture on a plane (like a billboard), but it is dark no matter what (Fig.). I tried to use ksPerPixel and ksPerPixelAT
shaders, but they are still dark.

615
Fig. – I have to admit it, I don’t know what’s going on here. The text, the names, the scene. Everything is weird. And the low-quality graphics.

ANSWER [3]: Either the sun is not hitting the normal side of the plane (and thus thinking it is in the shadow), or your material hasn't got a high enough
diffuse value, or the normals of that plane are “faulty”. Try adjusting the position of the sun in ksEditor first.

616
2.5.2 – BUILDINGS

You can create houses very easily with basic shapes (Fig.).

Fig. – Two examples of very basic vintage houses, along with how they look in-game (by @Fat-Alfie). The entire geometry consists of only 219 triangles. These buildings are mostly
diffuse texture, with no normal maps and very little detail in the mesh. It is possible to add recessed windows further down the line, but for now the texture seems to do a good enough
job of deceiving the eye. UV mapping and AO baking these kinds of objects is well worth the time, as well as softening the lines wherever necessary (like the slight droop along the roof
line). Anything to make it look a bit more natural and less clinical.

For some of the slower cars recessed windows might just add that tiny bit of additional depth to make it worth it. Then you have CSP which adds lights for
windows at night.

To add some chimney smoke to the houses, use a flag shader with an alpha blend mode, just to give it a slow, subtle movement.

FAQ
QUESTION [1]: In-game the light goes through the wall (Fig.), what should I do to fix this?

617
Fig. – The light bleeding from the ceiling and from the side wall of an interior.

ANSWER [1]: This happens because of how shadows work in vanilla AC’s graphics engine. If you add another inward-facing layer to the wall between inside
and outside, then you can prevent it from happening. If the wall is infinitely thin (only one polygon surface), then you will encounter that problem. Does CSP
fix this?

2.5.3 – GRASS (WIP)

For grass you have some options. Keep it to a simple ground texture or use 2D objects.

Vanilla 2D grass is a transparent texture on polygons, so not just a shader. Hand placed, or rather via randomised functions of the 3D modelling tools.

Since working with ground textures is fairly easy, the 2D grass will now be treated in more detail.

How to create 2D grass

Let's start by stating this is a how to for 3DSMax. Any other modeling programme that is capable of editing normals should be able to produce the same.

The basics. 2D grass is made out of flat planes of around 200 mm × 900 mm with the pivot point slightly above the bottom vertices (say, 20 mm). This is to
make up for any height difference from polygon to polygon. This plane should be physically double sided. So copied and flipped. Do not make the material
double sided: AC does not support this.

When UV mapping make sure your polygon does not touch the upper edge (or in this case any of the three "edges" at 33%V, 66%V and 100%V) to prevent
getting the dreaded horizontal lines above your grass.

It needs a texture and an example is given here:

618
3D grass is scattered around a surface with a specific amount per detail level. The following numbers are close approximations of what Kunos used for Spa.

60 clones per 100m² for KSLAYER3

90 clones per 100m² for KSLAYER4
240 clones per 100m² for KSLAYER5

These clones need a surface to be scattered across. This basically is the surface where you have a grass texture applied. Be aware that the grass object is
scattered around by its pivot point and can end up on the very edge of the reference surface. Please keep this in mind and bevel the surface inwards on
areas where this should not happen. For instance, right along the edge of the asphalt you want to prevent grass from pertruding the asphalt. Bevel inwards
by half the width of the grass object to prevent scattering too far out.

It's important to know 3DS Max can "only" do 65k clones at a time. If you need 240 clones per 100m², it means you cannot exceed ~27.000m²
(65.000/240/100 m²) per section.

Import both the ground layer and 3D grass object into 3DS Max. Cut the ground layer in (preferably equal size) pieces. Say your total grass area is
160.000m² you need 5,93 (160.000/27.000) pieces, so make it 6. With six roughly equal size ground layers (in this case 26.667m² each) you will now
require:

For KSLAYER3: 60/100 × 26.667 = 16000 clones per section;

For KSLAYER4: 90/100 × 26.667 = 24000 clones per section;
For KSLAYER5: 240/100 × 26.667 = 64000 clones per section.

Now the fun starts and you will actually see stuff happen!

Select the 3D grass object, go to the Create tab and pick Compound Objects from the drop down list. Now choose Scatter.

A bunch of options pop up.

Box 1: Pick the distrubution object on which you want the 3d grass to scatter.
Box 2: Hide a copy of the distrubution object.
Box 3: Select the amount of duplicates for this section (use the number as calculated per the above guides. In this case 64.000).
Box 4: Make sure it is scattered evenly by area.
Box 5: Add random rotation with 360 degree range of rotation along the vertical axis.

619
Once you've put in these numbers, you can save it as a preset for KSLAYER5. If your ground surface is cut up into roughly equal sizes you can easily load
up a preset and the amount of clones per m² will be the same.

Edit box 3 and save as KSLAYER3, edit it again and save as KSLAYER4.

Great, you've got 3D grass! But the AC Editor can only import 65k vertices per object. With 64k clones of 8 vertices (2 quads × 4 vertices if normal
smoothing is on), you have almost 8 times as many. You will need to cut the freshly grown grass into bite size pieces. The minimum is, ofcourse, 8 pieces
of each 64k vertices. You may want to cut it up into smaller bits.

Convert the 3D grass into Editably Poly and select a maximum of 16.000 polygons (the Selection tab will show you the amount of polygons selected). As
said, you can select chunks of 8.000 polygons for example if you want. Now Detach it from the mesh to create a new object.

Select your new mesh and add an Edit Normals modifier. You will now see a whole bunch of blue lines. These are vertex normals and they need to be
adjusted. Hit CTRL+A to select them all and be sure to have the Top view active. Then select Select and Move and type in 10000 inside the Z box to have all
normals point upwards. This way, the 3D grass will be lit as if it was a flat surface.

By default, the normals of the grass point upwards (z-axis in your modeling editor), whereas the normals of the terrain point 90° to the surface (Fig.). If the
ground surface is not too sloped you will not really see the difference. However if the slope is pronounced, it will lead to a discrepancy between the light that
falls on the ground and the light that falls on the grass. Which looks bad.

So you always need the grass normals to point perpendicular to the ground surface.

To do it, there is a script that takes the normals from one object (the terrain) and pastes them to another object (the grass). It’s called Normal Thief (you can
find it here: http://www.scriptspot.com/3ds-max/scripts/normal-thief). In Fig. can see few shots of it in action.

620
Fig. – (top left) Terrain mesh and 2D grass objects. (top right) Original normals of the grass. (bottom left) After the script has been applied, the normals of the grass are the same as the
ones of the terrain. (bottom right) Final result in AC.

Once you're done (and don't forget to name the object something like 3dgrass_001_KSLAYER5), export as FBX2012 and import it into the AC Editor. This
may take a while, depending on how much grass you have and how big your objects are.

Inside the AC Editor, assign the ksGrass material. Be sure to eliminate any specular values. Add an image to txVariation (this is obviously used to give it
some variation in colour. Can be any tiled image with darker, greener, brighter, browner, etc, patches) and play with the gain and scale of it. Be sure to
disable Cast Shadow. Open your base track, too. This will add a new hierarchy to the Editor. Edit the lighting via the Illumination tab to get a patch of grass
with shadow. Now, edit the Ambient value to match the ground surface in the shadow. Get to a sunny patch and edit the Diffuse value to match the ground
surface in the sun. Take note: even 0,01 change can be enough between too bright or just perfect.

621
Assign LOD distances to each detail layer of grass. For example: set KSLAYER3 LOD_out=350, KSLAYER4 LOD_out=170 and KSLAYER5 LOD_out=80. You
have to play with the numbers for your track but if done right you won't notice any pop in and you can gain a few FPS. Using each layer as a different LOD
distance creates a fairly smooth blending as you get closer.

Save the persistance file, restart the editor and reload your grass FBX. Then export it to .KN5.

This did affect filesize: De-activate the base track (Scene tab: click on the base track model and at the Object tab set IsActive to False.), save the persistance
file for future use and export it as 3dgrass.kn5 (or similar).

Via the multilayout system add the 3dgrass.kn5 to your base track.

Do not name your 3D grass objects something like 3dgrass_01_KSLAYER_3. AC will think it is a physical surface and this might cause serious problems.
Use grass3d_01_KSLAYER3 instead, or anything else with no number in front.

FAQ
QUESTION [1]: The ground texture looks washed out without Post Processing (PP) on (Fig.).

Fig. – Comparison. (left) with PP. (center) without PP. (right) The shader parameters used in this example.

ANSWER [1]: It is likely your shader Diffuse and Ambient values are just too high. PP filters can and will auto expose to make objects look dimmer than they
really are. The idea is to get the brightness correct without PP filters on and then when you turn them back on it should be fine.
Or maybe the Specular is set too high and the PP filter boosts those.
Keep in mind that CSP, in combination with SOL and Pure, changes the exposure and lighting behaviour.

QUESTION [2]: When I load into ksEditor I have some problems with 2D grass shadows (Fig.). It’s got dark spots, while I want everything to be like the rest.

Fig. – Comparison of the 2D grass under different lighting conditions. (left) In the shadow. (right) Under the sun.

ANSWER [2]: You probably forgot to point the normals upwards (or perpendicular to the ground surface, rather).

2.5.4 – TRACK MODELING FAQ

QUESTION [1]: Is it possible to create a track to drive upside down like in the movies?
ANSWER [1]: AC used to reset to the pits after 3 seconds if the car was upside down. There is an option in the .ini files that lets you turn that off.
AUTOFLIP_RECOVERY=0 in assettocorsa/system/cfg/options.ini

In the respect of aero, yes, there are loads of cars that produce more than their weight in downforce at certain speeds. But in terms of the driveable surfaces
working in AC at 180°? No.

AC does no ground collision above ~50° angles. There is half a loop on @Stereo’s Test Pad track, and you would just fall through it halfway up.
AC simply will not register a driving surface past that angle. You will never even get close to 90° no matter if it is a loop or a tunnel.

The CSP mod adds a replacement tire raycast method that can run on walls/ceilings (see p.), so as long as you're using a car that enables that, it works.
You can do barrel rolls on Stereo’s test track now.

622
There also is a problem with traction. Even if you have more (now inverse) downforce than weight, you would need to maintain a very high speed,
overcoming the air drag. You might not have enough tire contact to do so. Tiny bumps will also have something of a "moon effect", have you floating over
(now under) the surface much longer than normal. If during such time drag slows you down too much you drop. Underbody and rear diffuser downforce
would drop severely on bumps.

I've tried doing it on a barrel roll style track in another sim and the problem (with an F2004, so rwd) is that you need enough grip to overcome drag easily.
Otherwise the rear tires have high slip ratio and when your car goes up onto the vertical bank it starts to spin out. So just having more downforce than the
car's weight isn't close to enough, you need downforce to exceed weight + drag by a decent margin.

Doing a vertical loop has the obvious problem that the smaller it is the heavier vertical G's you get (and front/rear of the car dig into the surface) but the larger
it is the more you decelerate on the way up it. So ideally you want a car that hits “more downforce than its weight” at a speed where it's still accelerating easily.
I don't think any real-world cars get near that. Maybe boost turned up group C when they had full underbody tunnels allowed.
Probably the easiest way to do it in real life is to have the car riding upside down on a cart with its wheels against the ceiling and then have the cart drop away,
it skips trying to get it up there, problems with the engine running upside down, etc.
Late Group-C cars could probably do it. 850 kg with a driver and fuel, 8+ coefficient of lift, and 5-6:1 L/D ratio...the speed at which mass equals downforce is
quite low, so maintaining something a decent amount faster would be pretty manageable.

QUESTION [2]: Can I do anything interesting and with a broader perspective thanks to AC track mods?
ANSWER [2]: Yes, of course you can. For example, you can create a very basic wide cubic map with green walls/road textures for the purpose of making
chroma key videos. Did I get your attention?

2.6 - MODELLING GENERIC PARTS OF A TRACK: SKIDMARKS

Here's an introduction to grooves. I'll try to cover everything you'll need to know.

- What are grooves?

Grooves are dynamic layers on your track. Primarily they display a racing line and skidmarks. If your track surface is not set at Optimum, these layers will
build up over time depending on how many cars there are driving and how many laps there are driven (Fig.).

Fig. – Replace image

How do I create grooves?

While this depends on the 3D software you're using, the process is basically always the same. You start off by creating a ribbon of polygons along your
racing line (Fig.). Usually about 40-60% of your road width.

623
Fig. -

Use a tool to conform its shape to your road and kerbs. This is often called something like Heat Shrink, Shrinkwrap, Conform, etc.

Be sure to move the groove object a few mm upwards to prevent Z-fighting.

Name your groove object and material the same, for instance: groove_1 (you will notice in the screenshots below I have not done this as I do not experience
problems with it. But to be sure, please name them the same).

Apply a groove texture. This can be anything, but after careful studying of Mugello I found this groove has actually multiple appearances (Fig.).

Fig. - For straight lines, the groove is rather clean (middle). In braking zones, there's some skids off the ideal line (bottom), and in corners skidmarks are
added to the clean groove (top). (note: this is the alpha channel on a black texture).

These textures will usually be very widely spread out length wise. Left to right on the texture can be from corner entry to corner exit, for example.

On corner entries cars usually skid straight ahead. This can be simulated with a texture similar to this one, assigned to multiple polygons overlapping each
other.

624
Fig. - Something similar is also used in corners for extra skids on Mugello. So in corners, both the above and below texture are present. Edit the groove.ini
to have a look at the individual grooves. (note: this is the alpha channel on a black texture)

Inside the AC Editor

The AC Editor allows you to assign a nice material to it.

Here are the 'mandatory' settings in magenta:

The specular values are a thing of taste. I think these work nicely as a start.

You'll notice I have set the alpha to 1. This makes the groove visible inside the Editor. This value plays an important role in the next part. You can leave it at
1 and save the persistance file. This value will not influence anything if you're doing the next step.

How to control the grooves?

There is a data file that lets you control the visibility of the groove materials. It’s called groove.ini. See pag.

The same method can be used also with dirt and snow roads to show the brownish sludge you end up with, if you want add some details to example
junctions etc.

You can also use it in reverse to have sand/dirt on the track that gets less and less the more you drive.

625
2.7 - NULLs & SCENE STRUCTURE

2.9 – BAKING THE AMBIENT OCCLUSION

Baking the terrain AO, complete with all 40,000 trees (Fig.). If you choose this route you will need to remove all the real shadows from the terrain texture.

Fig. – Simplified models of the trees are made with basic shapes that will project their ambient occlusion on the ground surface. They are made just for this purpose.

626
2.10 - TRACK LODs
Do tracks have LODs? Yes and no.

Tracks do not behave entirely like cars. While on a vehicle the entire body is swapped (based on the distance from the camera) within a set of higher or
lower quality LOD models, maps actually use LOD objects, in two instances:

First, if there’s an object that can be turned off if distance allows, or if it’s hidden by trees or a behind a corner, etc., the LOD OUT distance parameter in
ksEditor (pag.) can be used to remove it entirely from the scene. For example, if three corners away from the car there is a tire wall that is not visible, set
LOD OUT to, say, 350 (meters) 93.

Second, if you do need to have that object in view, but it is quite far, you can do something equivalent to what happens with cars’ lods.ini: prepare one or
more lower detail versions and swap them using the LOD IN and LOD OUT values, again, available in the AC editor. For example: with a 20k tris tire wall, the
“LOD 1” will have LOD IN=0, LOD OUT=150, while “LOD 2” will have LOD IN = 140 and LOD OUT = 400.

- Keep in mind that the LOD distance switch value is calculated from the pivot point of the mesh, not from the mesh itself, but it is also influenced by the
Radius value for each object (see p.) and the LOD IN/OUT values are added to it, not with a 1:1 ratio, as it's also FOV related.
Let’s make an example: in Fig. left are five objects, four bigger cubes and one smaller cube, all with pivot point at 0,0,0 (global).

Fig. -

From within ksEditor we get radius values of 0,86 for the smaller and 63,94 for the bigger cube. Now, all the LodOUT values are set to 50. At 65 m, looking
at the camera coordinates, all objects are still visible (with FOV 60). At 70 m, the first (smaller radius object) disappears (Fig. right).

And at 85 m the bigger object disappears. That's only after the whole mesh
has been in view.

Now comes the fun part. If LodOUT is set at 75 m for both, they disappear at
the same time at a distance of 100 m. The turning point for LodOUT distance
for this behaviour is that 64 m, the radius of the larger object (Fig.).

There is probably a little calculation going on regarding FOV and angular

distance of the object related to the radius of that object. So if the angular
distance of the object matches the screen width (which is dependant of FOV),
the LodOUT value is used. If the angular distance is larger than the screen
width, the LodOUT value is ignored.

Something along those lines.

My point is, if you have, say, marshall huts along the track and you split them
up in objects of 4 huts, the LodOUT value is not directly related to the origin
of that object of 4 huts, but also related to the radius of those objects. So if
you experience weird behaviour, this might be the case.

Also, if the pivot (=origin) is not centred to the 0,0,0 coordinate of the object,
the LOD switch might not work as intended.
Fig. -

Typically outdoors decorations and props require only a couple LOD models for optimization purposes, since they already have to be made as low-poly as
possible. Below are some examples for various standard landscape elements (Fig.). Textures and materials can be removed to reduce the draw calls, as
usual.

93
The distance is always referenced from the position of the camera currently active. Switching to another camera will change which LODs you see on screen, depending on its position. Then,
when working with track LODs it’s best to choose one of the interior/exterior vehicle cameras.

627
Fig. -

There is a parameter called “World detail”, you can find it in the graphic options.

628
2.9.1 – OPTIMIZATION
How can you optimize as much as possible your track mod and get the most FPS (frames per second) out of it?
Keep the number of total objects to a bare minimum. If multiple objects share the same material, merge them into one or a couple objects. Combine multiple
object textures into one, and try to reuse it with as many objects as possible.
As already explained for car mods, do not use PNG or JPG formats for your texture work as they cause lots of stuttering. Use DDS only.
Turn off shadows for meshes that don't need them (set CastShadow to False in ksEditor).
If you have 2000 fence posts around your track merge them into fewer but larger objects. You still don't want one huge object around the entire track. It is
still best to break it up into say 4 or 5 different objects. No matter how you slice it, having 5 objects is better than having 2000 of them.
When dealing with smaller numbers however, like 20 or less objects, then there isn't a huge need to merge all of them together.
When you load up the Render Stats app keep an eye on the DIP number. Most official Kunos tracks stay under 1000-2000. To be concrete on this one, in
Fig. is an example. You’ll find an extensive description of the app at pag. .

Fig. – The official Ford Mustang on the Magione map (screenshot taken on a triple screen, hence the high TRI count).

Some mod tracks recently had as much as 5500 DIP which is way too high. This number is directly tied to the amount of materials and objects. This high
number causes excessive CPU usage and is also the reason AI is often a problem on mod tracks.
Keeping the number of materials down and consolidating objects will keep DIP values low, your GPU will thank you!
The biggest offenders are things like fence posts. When we are dealing with 100s or 1000s of copies of the same object is when the draw calls (DIP) go
through the roof.
Some could say "well, stop using a garbage computer and upgrade". While one might agree, the entire statement is flawed. The fact that the map performs
badly doesn't automatically mean that it is "next gen" and that you need the latest hardware to run it. Few simple rules need to be followed by track makers,
so that everyone is able to enjoy all their hard work. Remember, if a track is set up correctly at its core, it gives you the ability add all the details your heart
desires and still run well.
Since you will very likely adopt the LOD system previously explained in par. 2.9, you can follow these triangle counts as reference for the objects in your map
(keep in mind the LOD switch distance values written! Those are based on the official maps and can vary a lot from track to track, depending mostly on the
visibility of the object being considered):
• Vehicle, trackside (<25m): 5000-6000 tris LOD1 - OUT 150m 300-350 tris LOD2 - IN 140m / OUT 350m
• Vehicle, 40 metres from driveable road: 1300-1500 tris LOD1 - OUT 200m
• Vehicle, background (>80 metres): 150-180 tris LOD1 - OUT 400m
• 3D human: 900-1100 tris LOD1 200-300 tris LOD2
• House, background: 40 tris LOD1 - OUT 750m
• Small gazebo: 150 tris LOD1 - OUT 250m 40 tris LOD2 – IN 240m / OUT 600m
• Track flag (billboard):
• Track flag (country):
Some objects in the list do not have a LodIN value reported: in that case it can be left to zero (always visible).
629
2.10 - ABOUT RACE TRACK BUILDER (RTB)
This paragraph will try to explain why you should avoid using the software called Race Track Builder to create your tracks. You can still use it, but be aware
that can (and will) create some problems.

The track takes too long to load in the race session:

This is usually due to the fact that RTB duplicates texture files.

Fig. – A total of 359 textures, extracted from a track .kn5 model created with Race Track Builder. The marked files (~92 files, 119 MB) are unique, the rest are duplicates.

You are throwing away A LOT of memory space and performance here.

I assume RTB does the same with materials, meaning you have tons of duplicate materials all around the track, which may not be that bad for performance
but make it harder for you to maintain the track if every object needs to be modified on its own.

There is also the common "xpack" issue of 1024x1024 DXT5 textures of single colours:

630
CHAPTER 3 – SHOWROOMS (keep it here?)

A showroom is actually just a normal model (export as 'track' from the ksEditor), the panorama's just a regular texture mapped to whatever object makes
sense for it. (Kunos ones are basically a hemisphere above a flat plane, with some of the details visible in the panorama modeled in around the seam)

One unusual thing in the Kunos ones is that it uses a floating point dds format so the panorama's an HDR image with an all-real brightness scale.

You'll need at least 8000x4000 to get a decent in-game appearance, possibly larger.

Considering tracks have easily 3 million triangles in sight at any given time, you can go quite crazy with a modeled showroom.

Vanilla showroom requires additional dummies

CHAPTER 4 – THE FBX EXPORT

FAQ

QUESTION [1]: After I exported to fbx and opened it in the kunos editor, I see nothing. Could someone point me in the right direction?
ANSWER [1]: You may have some export settings wrong. Try these settings in Blender:

Also, a lot of your objects may have a scale applied to them. Reset their scale to 1 by applying the scale with CTRL+A > Scale. This will definitely help with
some lighting/shading issues.

QUESTION [2]: I have built a track with Blender, but when I load in-game my car keeps falling through the road and terrain.
ANSWER [2]: The top options are:

• Your objects have incorrect names (every mesh name has to start with a number in order to tell AC to assign collisions and there are also typical labels
you should use, see Paragraph 2.4);
• There are too many triangles in a single object instance (split the triangles into multiple meshes);
• You did not export the FBX model as a Track from the ksEditor export menu (don't know for sure about this one)
• The spawn dummy boxes have to be all above the ground.

631
CHAPTER 5 - TRACK DATA, CONFIGURATION FILES AND PHYSICS
You will definitely notice how things here will be much, much shorter with respect to vehicles. Circuits are just surfaces, nothing more, and we can easily
work with mean measurements and a statistic mathematical approach. Knowing the principles of static and dynamic friction is fundamental, so we will
elaborate on these later.

5.1 - HOW TO CREATE DATA FOR YOUR TRACK

5.2 – DATA FILES AND EXAMPLES (with ANALYSIS)

The following paragraph contains the list of all the data files for tracks; to make a basic track work you need none of them if you configured your 3D model
correctly (NULLs, object names, etc.). It’s very unlikely that without any of these files the track will not load and the game will crash, but many features may
(and will) not work. Tracks are probably one of the most reliable things in AC if you know how to make them.

This should not be necessary, but please note that if you’re using CSP you might encounter errors and crashes anyway.

5.2.1 - CONFIGURATION FILES (.ini) (page numberssss)

1. ai_hints.ini p.
2. audio_sources.ini p.
3. camera_facing.ini p.
4. cameras.ini p.
5. cameras_#.ini (cameras_1.ini, cameras_2.ini, etc.) p.
6. cameras_start.ini p.
7. crew.ini p.
8. drs_zones.ini p.
9. groove.ini p.
10. lighting.ini p.
11. map.ini p.
12. overlays.ini p.
13. sections.ini p.
14. semaphore.ini p.
15. startinglights.ini p.
16. surfaces.ini p.
17. EXTRA…

CSP files?

5.2.2 - OTHER FILES

AGFHSDH

down5m.csv
down10m.csv
ideal_line.ai
up10m.csv
monza file ray.opt 29mb. Not sure what it is for

632
5.2.3 - EXPLANATION AND ANALYSIS OF EACH .ini SCRIPT

This paragraph won’t be as long as its counterpart in the car modding section of the manual. There will be things almost as important however. Physics-
wise, surfaces can completely overhaul or destroy your racing experience. Which is the problem, your vehicle or the road you’re driving onto? We will learn
to distinguish between the two.

1. ai_hints.ini
This data file includes “hints” for the AI opponents, so it imposes over the Spline data the changes specified for their behaviour. Below you have a selection
of plausible hints (entirely fictional, do not reuse the values) for the Kunos Nordschleife Endurance.
; first chicane
[HINT_0] ; Throttle hint identifier. SYNTAX: [HINT_ID], ID starting from zero.
START=0.0240295 ; Where the hint starts on the AI spline.
END=0.03130058 ; Where the hint ends on the AI spline.
VALUE=0.69 ; Percentage of throttle for AI opponents (1=100%). Can exceed 1, up to 1.2 (120%).

% ▲ VALUE can go to 1,2 to compensate for a bad AI trajectory. It is a known advantage that the opponents can have over the player, whether it is set or
not. They have to be tuned to perfection.

; Dunlop Kurve
[HINT_1]
START=0.07420295
END=0.08058
VALUE=0.79

; Michael Schumacher S
[HINT_2]
START=0.09145193
END=0.1007502
VALUE=0.85

; Ring to Nordschleife section to Hatzenbach to Hocheichen

[HINT_3]
START=0.1700199
END=0.233634
VALUE=0.89

; Flugplatz
[HINT_4]
START=0.249958
END=0.258464
VALUE=0.50

[HINT_5]
[...]

% ▲ A track can have as many throttle hints as necessary.

; narrowing 1
[DANGER_0] ; Danger zone identifier. SYNTAX: [HINT_ID], ID starting from zero.
START=0.45
END=0.65
LEFT=0.5
RIGHT=0.5

[DANGER_1]
[...]

% ▲ A track can have as many danger zones as necessary.

; corner 7
[BRAKEHINT_0] ; Brake hint identifier. SYNTAX: [HINT_ID], ID starting from zero.
START=0.70
END=0.84
VALUE=0.92

[BRAKEHINT_1]
[...]

% ▲ A track can have as many brake hints as necessary.

LITTLE EXPLANATION
- I've come to understand that the START/END points in the hints file are simply the percentage of the AI fastlane spline length.

- For throttle hints, VALUE is the percentage of the original throttle resulting from the fastlane in that point.
For brake hints, VALUE specifies where the AI should brake. A number >1 makes the AI think it has amazing brakes and can brake later, a value <1 and they
will brake sooner. Note that if you put a brake hint value of 0.1 at the end of a straight just before a corner, the AIs will basically crawl to the turn.

- Danger zones are a way to move the Left/Right edges of the AI spline in or out without having to go into the editor.

- If you want to create a new ai_hints.ini script for any track, you will need to understand how to relate to the points of the AI spline on that track.

First, you have to create the new data in the CORRECT order and name the hints accordingly, this last bit for your convenience. For example, a track with
many corners will have the first corner after the starting line at the top of the list, and the last at the bottom:
; curve 1
; curve 2
; corner 3

If you open the AI app (this requires enabling dev apps, see p.), it will list "Normalized pos" in red on the top left corner of your screen, that's an easy way
to get the ranges of values for the START/END points. You can also use the DRS app to find them.

Then, by watching your replay, you can start playing around with the reference points where exactly the AI needs to behave slower/faster.
Test your data input to see if the ai behaves better and responds accurately. Based on this information, you should be able to create AI hints files for any
track.
633
2. audio_sources.ini
This script can be used to add special reverb zones to your track, for example if you have a tunnel, near a wall or under a bridge, but also in open areas.
You can use the Nordschleife as a template. You insert objects into the track at the respective tunnel and then fine-tune the reverberation.
[REVERB_0] ; Reverb entity identifier. SYNTAX: [REVERB_ID], ID starting from zero.
ENABLED=1 ; Boolean, effect enabled or not.
NODE=AC_PIT_0 ; Reference to the object which the effect is "attached to".

% ▲ The nodes can be dummies or meshes (uses object pivot/origin), but it’s more practical to use empties. The name can be anything you like, just use
uppercase text and underscore instead of spaces.

MINDISTANCE=175 ; Distance from the NODE for the reverb area where reverb will play at 100% effect. [m]

% ▲ If you are closer to the object than this you get the full effect intensity.

MAXDISTANCE=225 ; Distance from the NODE for the reverb area where reverb will cutoff. [m]

% ▲ This is the where you start to hear the effect from.

% ▲ MINDISTANCE and MAXDISTANCE are gradient values. Reverb works in a sphere, where the center (the NODE) is where your distance starts. You could use
spheres to visualize it. For example, if you use 5m as MINDISTANCE and 10m as MAXDISTANCE, from 5-10m the reverb effect will get weaker and at 10.01m it
will stop.

PRESET=CUSTOM ; FMOD sound engine preset. Available presets are listed below.

% ▲ Below is the list of all the presets that can be used (the FMOD_PRESET_ prefix shall be removed when input in the PRESET line):

FMOD_PRESET_OFF
FMOD_PRESET_GENERIC
FMOD_PRESET_PADDEDCELL
FMOD_PRESET_ROOM
FMOD_PRESET_BATHROOM
FMOD_PRESET_LIVINGROOM
FMOD_PRESET_STONEROOM
FMOD_PRESET_AUDITORIUM
FMOD_PRESET_CONCERTHALL
FMOD_PRESET_CAVE
FMOD_PRESET_ARENA
FMOD_PRESET_HANGAR
FMOD_PRESET_CARPETTEDHALLWAY
FMOD_PRESET_HALLWAY
FMOD_PRESET_STONECORRIDOR
FMOD_PRESET_ALLEY
FMOD_PRESET_FOREST
FMOD_PRESET_CITY
FMOD_PRESET_MOUNTAINS
FMOD_PRESET_QUARRY
FMOD_PRESET_PLAIN
FMOD_PRESET_PARKINGLOT
FMOD_PRESET_SEWERPIPE
FMOD_PRESET_UNDERWATER

Keep in mind you have to use FMOD 1.08.12.

DECAY_TIME=2750 ; Total reverberation time.

% ▲ Note that this differs a lot from RT60 (or even RT30) times that are listed for most rooms.

EARLY_DELAY=50 ; How long does the first reflection take to reach us.
LATE_DELAY=250 ; How long after the first reflection the room effect arrives.
HF_REFERENCE=4500 ; What is considered "high frequency", a high shelf center frequency. [Hz]
HF_DECAY_RATIO=75 ; Percentage of high frequency to mid frequency reverb.
DIFFUSION=100 ; Reverb diffusion percentage.
DENSITY=100 ; Modal density of the reverb.
LOW_SHELF_FREQUENCY=250 ; Low shelf center frequency.
LOW_SHELF_GAIN=0 ; Low frequency gain.
HIGH_CUT=850 ; Upper frequency for the reverb effect.
EARLY_LATE_MIX=80 ; Balance of early and late reflections in percentage.
WET_LEVEL=-16 ; Gain of the effect. [dB]

[REVERB_1]
[REVERB_2]
[...]

% ▲ A track can have as many reverb zones as necessary.

LITTLE EXPLANATION
How does the reverb effect work in AC?

- If you are setting up reverb zones against a wall you could use 1 or many reverb nodes, depending on how you need it set up (Fig.).

Fig. - If you have 2 lanes of traffic, yet you only want the lane closest to the wall to hear the reverb, you might need something like on the left, if you only have 1 lane or do not care
about the effects on the second lane you could create something like on the right.

- You could set the reverbs each with MINDISTANCE=MAXDISTANCE, but then there would be no sound build-up.

634
CURIOSITIES AND AMENITIES
In AC, before release 1.3, it used to be possible to add audio generators to a track. They were almost the same as the spawn objects, only that they emitted
audio. The naming was like this: AC_AUDIO_anyname
It used to work in conjuntion with the audio_sources.ini script in the track’s data folder:
[AC_AUDIO_amb1]
VOLUME_SCALE=7
VOLUME=1.0
FILENAME=content\tracks\brno_0.1\sfx\crowd1.wav

[AC_AUDIO_amb2]
VOLUME_SCALE=7
VOLUME=1.0
FILENAME=content\tracks\brno_0.1\sfx\crowd1.wav

[AC_AUDIO_amb3]
VOLUME_SCALE=7
VOLUME=1.0
FILENAME=content\tracks\brno_0.1\sfx\crowd1.wav

[AC_AUDIO_amb4]
VOLUME_SCALE=7
VOLUME=1.0
FILENAME=content\tracks\brno_0.1\sfx\crowd1.wav

These sections are deprecated and rare to find anywhere. For any object you had to specify a wave file (mono 44.1 kHz) to be played. It worked like a
speaker so the sound always had a direction (not really suitable for ambient sounds).

You could use it to place external audio sources at various positions on track. Example: sound of water near a river, sound of crowds near grand stands,
sound of birds near a forest...
After the release 1.3 the developers disabled this feature because it caused issues. Shared sounds are used as ambience (the ones under common in the
FMOD project, and you can’t change them, since they are hardcoded). However, some models of official tracks still have the AC_AUDIO objects, that’s why
explaining this is useful. Today, you can add ambience sounds to your tracks with CSP.

3. camera_facing.ini
This config file is dedicated to the creation of camera-facing crowds. They are 2D objects and thus the front face will automatically rotate to always look at
the camera (Fig.).

Fig. – Example from the Imola Autodrome modeled by Kunos. The further the objects are, the more the illusion breaks (you can see people sitting on nothing). It is not a big problem if
you look at them from the track instead.

This is a really old trick that generates seemingly populated sceneries without wasting many polygons, and the effect is really subtle when driving.
[CAMERA_FACING_0]
SURFACE=camerafacing_1_KSLAYER3 ; Object name of the distribution mesh.

% ▲ This mesh does not need UV coordinates and the shader can be set to "IsRenderable=False" in ksEditor.

ELEMENTS=2000 ; The amount of instances AC will place for you.

SIZE=0.8,1.4 ; The size of a slice of texture for a person (see TEXTURE_ROWS and TEXTURE_COLUMNS below).

% ▲ For a quick cross check, add a cube with human like dimensions to measure against. Then load AC and play with the size numbers until the 2D people
are about the same height. You could also do a quick cross check on your texture (if your texture is 512px high and the person in it is 450px high and
1,8m in real life, your size would need to be 512×1,8/450=2,05.

635
TEXTURE=content/texture/people_sit.dds ; Tells AC where to look for a texture with people on it.

% ▲ There are few standard tex under %root%\assettocorsa\content\texture, but you can also use your own.

TEXTURE_ROWS=3 ; How many rows of human figures are present in the tex.

% ▲▼ These two lines tell AC to slice your texture file in pieces. The standard tex people_stand.dds has 2 rows of people and 11 people (columns) per
row. In the same folder, crowd_sit.dds has 4 rows and 4 columns.

TEXTURE_COLUMNS=7 ; How many columns of human figures are present in the tex.
SHADED=1 ; If shadow will affect the crowd.
DIFFUSE=0.026,0.026,0.026 ; How bright the object will be under the sunlight.

% ▲▼ Here we have shader properties that might be necessary to tweak if people are standing underneath trees, rooftops, etc. You don't need to apply any
shaders while in ksEditor: the camera_facing.ini file will control ambient and diffuse lighting.

AMBIENT=0.09,0.09,0.09 ; How bright the object will be in the shadow.

[CAMERA_FACING_1]
SURFACE=camerafacing001_KSLAYER5
ELEMENTS=100
SIZE=0.7,1.9
TEXTURE=content/texture/people_stand.dds
TEXTURE_ROWS=2
TEXTURE_COLUMNS=11
SHADED=1
DIFFUSE=0.026,0.026,0.026
AMBIENT=0.09,0.09,0.09

[CAMERA_FACING_2]
[CAMERA_FACING_3]
[...]

% ▲ A track can have as many camera-facing crowds as necessary.

LITTLE EXPLANATION
- camera_facing.ini requires object names, not surface names.

- To create camera-facing crowd, you have to make a surface for them to stand on: you do not treat them like billboards. The surfaces can be anything and
can be invisible (or non renderable), people will appear anyway. An example is shown here:

Fig. – On the left, a billboard (the wrong way); in the middle, a flat/sloped surface; on the right a sloped one.

In Fig. below you can see the same grandstand as in Fig. , this time in Blender.

Fig. – The flat surfaces selected in the editor are where our 2D human figures from the textures will be “spawned”.

The human figures are placed vertically on the surface by AC, automatically, in a pseudo-random way.

636
- There are mainly two types of crowds that you can create: standing and sitting. In Fig. you can see examples of both.

Fig. – (left) This is people_stand.dds, one of the default images found under %root%\assettocorsa\content\texture. (right) People sitting, very useful for tribunes and grandstands.

You can have more than 2 rows/columns of people per image. Always be aware that the textures have to be transparent (there is an alpha channel). Use the
DDS format.

- It is possible to mix different textures on the same surface.

- You can also have the world detail slider affect the crowd. Simply add the _KSLAYER# (# being a number) suffix after the object name, just as you would
do for grass, marshalls, etc. Remember that # being 3 is low, 4 is medium and 5 is high. Don't forget to add the suffixes to your camera_facing.ini as well, if
you use them.

- If you’re looking for a better result, you can add low-poly 3D humans in places nearer to the track (i.e. the first line of seats), and place 2D crowds behind
them.

- Camera facing crowds are not visible in ksEditor.

- Do not use this configuration file and the related objects (2D crowds) for vegetation. Use it for animals in the landscape instead, for example with a mix of
cows, horses and sheep.
Pro tip: the camera_facing.ini file will make AC crash if it can't find the objects listed in the script, so you need to delete it in case you carelessly copied it from another track.

4. cameras.ini
To create cameras you have to make the AI line first. And if you change it, you'll have to reconfigure attack (in) and detach (out) points again.
[HEADER]
VERSION=3
CAMERA_COUNT=14
SET_NAME=Tv 1

[CAMERA_0]
NAME=1
POSITION=-177.531 ,54.7903 ,-791.639
FORWARD=-0.464872 ,-0.0699428 ,0.882612
UP=-0.0325944 ,0.997552 ,0.0618844
MIN_FOV=2
MAX_FOV=10
IN_POINT=0.83585
OUT_POINT=0.909733
SHADOW_SPLIT0=30
SHADOW_SPLIT1=90
SHADOW_SPLIT2=250
NEAR_PLANE=2
FAR_PLANE=35000
MIN_EXPOSURE=0.35
MAX_EXPOSURE=0.55
DOF_FACTOR=2.5
DOF_RANGE=250
DOF_FOCUS=0
DOF_MANUAL=0
SPLINE=
SPLINE_ROTATION=0
FOV_GAMMA=0.5
SPLINE_ANIMATION_LENGTH=10
IS_FIXED=0

[CAMERA_1]
NAME=3
POSITION=-80.5131 ,67.3688 ,-1045.9
FORWARD=-0.438474 ,-0.0599639 ,0.896744
UP=-0.0263401 ,0.9982 ,0.0538699
MIN_FOV=3
MAX_FOV=12
IN_POINT=0.909733
OUT_POINT=0.954706
SHADOW_SPLIT0=30
SHADOW_SPLIT1=90
SHADOW_SPLIT2=300
NEAR_PLANE=2
FAR_PLANE=35000
MIN_EXPOSURE=0.35
MAX_EXPOSURE=0.55
DOF_FACTOR=2.5
DOF_RANGE=250
DOF_FOCUS=0
DOF_MANUAL=0
SPLINE=

637
SPLINE_ROTATION=0
FOV_GAMMA=0.5
SPLINE_ANIMATION_LENGTH=10
IS_FIXED=0

[CAMERA_2]
NAME=4
POSITION=2.46151 ,65.1328 ,-849.565
FORWARD=-0.146259 ,-0.0200003 ,-0.989048
UP=-0.00292588 ,0.9998 ,-0.0197843
MIN_FOV=2
MAX_FOV=12
IN_POINT=0.954706
OUT_POINT=1
SHADOW_SPLIT0=30
SHADOW_SPLIT1=90
SHADOW_SPLIT2=300
NEAR_PLANE=2
FAR_PLANE=35000
MIN_EXPOSURE=0.35
MAX_EXPOSURE=0.55
DOF_FACTOR=2.5
DOF_RANGE=250
DOF_FOCUS=0
DOF_MANUAL=0
SPLINE=
SPLINE_ROTATION=0
FOV_GAMMA=0.5
SPLINE_ANIMATION_LENGTH=10
IS_FIXED=0

[CAMERA_3]
[...]

5. cameras_#.ini

[HEADER]
VERSION=3
CAMERA_COUNT=11
SET_NAME=Tv 2

6. cameras_start.ini

7. crew.ini
AFDGHJAG
[HEADER]
SIDE=-1 ; 1 = left, -1 = right

8. drs_zones.ini
[ZONE_0]
DETECTION=0.642
START=0.738
END=0.871

[ZONE_1]
DETECTION=0.925
START=0.979
END=0.096

9. groove.ini
This script is dedicated to the tire skidmarks that can accumulate (yes, they do!) on the road surface.
[HEADER]
GROOVES_NUMBER=12 ; Amount of groove materials/objects.

[GROOVE_0]
NAME=groovegp ; Name of the groove material (note: as shown inside ksEditor).
MIN=0.4 ; Minimum amount of alpha (the setting inside ksEditor) for the material.

% ▲ This amount of groove will always be visible, no matter which surface setting is your track at (during race session preparation: Dusty, Old, Green,
Slow, Fast, Optimum; see par. of the AC Manual, pag.). Use the AC Editor to find a nice value.

MAX=1.0 ; Maximum amount of alpha for the material.

% ▲ It determines the end state of the groove. If you set your track surface to Optimum in the race preparation options, this is the value used and the
skidmarks will not get darker than that. Again, use ksEditor to find a good compromise.

MULT=5 ; Controller for the fading transition.

% ▲ It determines how fast the groove goes from MIN to MAX. The higher the number, the higher the amount of laps/cars needed for it to become more
visible, so the slower it gets darker. It is related to grip levels, where some formula (like n_cars × n_laps × factor + grip_start = grip_%) determines
the grip. I can only guess the MULT is a multiplier so that MULT=5 takes five times the number of cars or laps to have the same effect as MULT=1.
For reference, the official Mugello circuit by Kunos uses MULT=1 for corner grooves, so they appear very rapidly.

[GROOVE_1]
NAME=groove_gp001
MIN=0.4
MAX=1.0
MULT=5

[GROOVE_2]
[GROOVE_3]
[...]

% ▲ A track can have as many tire grooves as necessary.

LITTLE EXPLANATION

638
- These MIN and MAX values are highly dependent of the alpha channel of your groove texture. You can play with the alpha value inside ksEditor to
determine which values you want.

10. lighting.ini
Vanilla AC just simulates a fixed sun trajectory, customizable for every track. lighting.ini defines this fixed trajectory.
[LIGHTING]
SUN_PITCH_ANGLE=25 ; Defines the highest zenith for the day. Values range from 0 to 90. [deg]

% ▲ A value equal to 0 means that the sun is at 90°, so straight above you. A value of 90 means it’s at the horizon. Pretty backwards logic here. (check)

SUN_HEADING_ANGLE=45 ; Calibrates the sun to the track with respects to the geographical north.

% ▲ Not every track is headed to the north, while it is created. This line lets you adjust that.

LITTLE EXPLANATION
- The sliders for the Sun position in the Illumination tab of ksEditor do nothing to the track’s model or data files, they’re just for preview purpose. lighting.ini
is the only place to define the daylight of your track, at least in vanilla.

CSP ADDITIONS
- Custom Shaders Patch adds a lot of configuration options to your map lighting. The old vanilla sun trajectory model can still be used, if you set "If no date
is set, use original sun trajectory" in the CSP/CM options. WeatherFX (what is it?) does that.
For more realism and with this option deactivated, WeatherFX generates the real sun trajectory via the tracks position, UTC time zone, date and time. Part of
this data comes from geotags in the ui_track.json file inside the your_track\ui folder. SUN_HEADING_ANGLE gets ignored. Therefore it’s no longer
possible to fake/set the sun position freely.
These new functions need to be set per track. You can see it in the CSP files, specifically inside extension\config\data_track_params.ini.

11. map.ini
[PARAMETERS]
WIDTH=600.604
HEIGHT=1565.46
MARGIN=20
SCALE_FACTOR=1.2
X_OFFSET=422.16
Z_OFFSET=1034.46
DRAWING_SIZE=10

12. overlays.ini
This file manages the position, offset, size and orientation of the Time Attack checkpoints (Fig.).
[MAIN]
OVERLAYS_COUNT=3 ; Number of checkpoints (StartFinish + Sector1 intermediate + Sector2 intermediate =3).

[CHECKPOINT_0]
WORLD_POSITION=-4.86199 ,63.9383 ,-760.247
OFFSET=-4.08257 ,3 ,0 ; Sets the distance between the world position and the object representing a checkpoint.
WIDTH=15 ; Width of the checkpoint graphical object.

% ▲ If you can't find the checkpoint on the track, set this to 100 or 200, this will make it easier.

HEIGHT=1.5 ; Height of the Checkpoint graphical object.

ORIENTATION=-0.0049426 ,0.00524384 ,-0.999974

[CHECKPOINT_1]
WORLD_POSITION=-11.4411 ,49.4285 ,77.5357
OFFSET=1.98687 ,3 ,0
WIDTH=15
HEIGHT=1.5
ORIENTATION=-0.485433 ,0.00904065 ,-0.874227

[CHECKPOINT_2]
WORLD_POSITION=-78.8248 ,48.7335 ,111.375
OFFSET=2.89969 ,3 ,0
WIDTH=15
HEIGHT=1.5
ORIENTATION=0.450846 ,-0.0157044 ,0.892464

13. sections.ini
This is the config file that contains the turn names. There is an app (Fig.) that visualizes them while you’re driving on the different sections of the circuit.
[SECTION_0]
IN=0.117
OUT=0.139
TEXT=Yokohama S

[SECTION_1]
IN=0.149
OUT=0.225
TEXT=Mercedes Arena

[SECTION_2]
IN=0.539
OUT=0.606
TEXT=Michael Schumacher S

[SECTION_3]
IN=0.691
OUT=0.729
TEXT=Bilstein Kurve

639
[SECTION_4]
IN=0.769
OUT=0.818
TEXT=Advan Bogen

[SECTION_5]
IN=0.872
OUT=0.902
TEXT=Veedol Chicane

14. semaphore.ini
This script its meant to be used for drag racing tree semaphore lights (Fig.). It will turn on the light with an EMISSIVE= the intensity value you've set, again,
and again.
In order for any lights to show up you have to create an object and name it AC_SEMAPHORE_RED, AC_SEMAPHORE_YELLOW or
AC_SEMAPHORE_GREEN (but any other name can do the job, as long as they correspond to what you specify in the NAME field).
If you wish to use this config with other lights/lamps you probably can, but they will be linked to the ready/start state (meaning they will be "red" in the ready
period and then switch to "green" state after race start).
[GROUPS]
DISQUALIFIED=1 ; DQ is the red light you get if you leave early.
READY=3
START=1

[COLOR]
INTENSITY=2.2

[OBJECT_0]
TYPE=1 ; Light type on the semaphore. Input can be 0, 1, 2.

% ▲ There are different light types: 0=DISQUALIFIED, 1=READY (usually yellow/red), is ON before the beginning of the race; 2=START (usually green light),
is on after the race started.

NAME=AC_SEMAPHORE_YELLOW_1
ORDER=0 ; it's the first of its set to be turned on

[OBJECT_1]
TYPE=1
NAME=AC_SEMAPHORE_YELLOW_4
ORDER=0

[OBJECT_2]
TYPE=1
NAME=AC_SEMAPHORE_YELLOW_5
ORDER=1

[OBJECT_3]
TYPE=1
NAME=AC_SEMAPHORE_YELLOW_2
ORDER=1

[OBJECT_4]
TYPE=1
NAME=AC_SEMAPHORE_YELLOW_6
ORDER=2

[OBJECT_5]
TYPE=1
NAME=AC_SEMAPHORE_YELLOW_3
ORDER=2

[OBJECT_6]
TYPE=2
NAME=AC_SEMAPHORE_GREEN_2
ORDER=0

[OBJECT_7]
TYPE=2
NAME=AC_SEMAPHORE_GREEN_1
ORDER=0
INTENSITY=2.2

[OBJECT_8]
TYPE=0
NAME=AC_SEMAPHORE_RED_2
ORDER=0

[OBJECT_9]
TYPE=0
NAME=AC_SEMAPHORE_RED_1
ORDER=0

15. startinglights.ini

The following lines are for the configuration of regular track semaphore lights at the beginning of the race (Fig.). They produce a different behaviour from
semaphore.ini, as are lit up the meshes with the naming KS_STARTLIGHT_# (where # is a number, starting from 0, 1, 2... etc). (section for track meshes)
[SETTINGS]
EMISSIVE=255,0,0,255
INTENSITY=2
DIFFUSE=0.3

640
16. surfaces.ini
With this script you can identify, physics-wise, the different surfaces of your track, and set their parameters for friction, vibration, damping, etc. Also, with the
CSP mod additions you can configure the altitude effects.
[SURFACE_0] ; Surface identifier
KEY=CONCRETE ; Custom surface type label.
FRICTION=0.96 ; Friction coefficient
DAMPING=0.01
WAV=grass.wav ; Surface sound, leave empty for no sound.
WAV_PITCH=0
FF_EFFECT=NULL ; Force-Feedback effect
DIRT_ADDITIVE=0 ; Multiplier applies dirt on vehicles.
IS_VALID_TRACK=1
BLACK_FLAG_TIME=15
SIN_HEIGHT=0.03
SIN_LENGTH=0.5
IS_PITLANE=0 ; If the surface has to be considered as pitlane. This activates the pit limiter.
VIBRATION_GAIN=0.05
VIBRATION_LENGTH=0.4

[SURFACE_1]
KEY=PITS-IMA
FRICTION=0.97
DAMPING=0
WAV=
WAV_PITCH=0
FF_EFFECT=NULL
DIRT_ADDITIVE=0
IS_VALID_TRACK=1
BLACK_FLAG_TIME=0
SIN_HEIGHT=0
SIN_LENGTH=0
IS_PITLANE=1
VIBRATION_GAIN=0
VIBRATION_LENGTH=0

[SURFACE_2]
[SURFACE_3]
[...]

% ▲ A track can have as many surfaces as necessary.

LITTLE EXPLANATION
- As you can see, the label of [SURFACE_1] on our config example is a weird naming scheme, but if set properly it works. Let’s take a look at the corresponding
meshes in the 3D model (Fig. below).

Fig. – On the right can be noticed the labels for the visual meshes of Imola circuit’s pitlane (Blender).

CURIOSITIES AND AMENITIES

CSP ADDITIONS
The Custom Shaders Patch mod adds altitude effects to the Assetto Corsa physics, that work only for cars using extended physics. There is a brand-new
section that can be added to surfaces.ini of tracks to input the elevation numbers:
[ALTITUDE] ; New section, not used by vanilla physics; enabling extended physics is required.
BASE=300 ; Altitude of the base point.

The code works by considering the BASE altitude point at the location of the first pit spawn object (AC_PIT_0). You can find the elevation by looking at
geolocalization data, for which even a quick search on Google can give you good results. The rest of the work is done internally, with the coordinates of the
3D map you drive onto, so there are no other parameters to configure.

641
You should be able to notice the effects (exclusively for engines and wings) on hillclimb roads. The elevation change on the Nordschleife is only about 300
m, so its influence on aerodynamics is negligible. At Pikes Peak the jump between start and finish is 1440 m, which means an air density change of 5% (and
the same change for realtime drag and lift coefficients). In any case, you can get immediate feedback in the telemetry (Fig.).

Fig. – Telemetry graph from a single lap at the circuit of Spa. Air density changes, temperature stays constant.

Pro tip: tracks that can start at different altitudes should have a different [ALTITUDE] entry in the surfaces.ini for each layout. Otherwise, on freeroam tracks with different pit
spawns only the first layout will be at the correct altitude.

The official tracks by Kunos are hardcoded in the mod, but if you add the section to the config file it gets overwritten.

642
CHAPTER 6 - LIVE ADJUSTMENTS DURING A SESSION
6.1 – HOW DOES AI WORK IN AC
Our opponent in single player is the machine, with virtual drivers coded to challenge us.

The yellow line gives the target for the steering wheel of the AI. The steering aid controls how far is the line.

For people working on mod cars, what you want to see by looking at the AI is: if the vehicle is going too much on the inside corners, basically the steering
LA is too high and you want to reduce it. If the car tends to oscillate too much then it means that the value is too low.

AI APP

The red line is the track boundary line and is defined by valid race track surfaces during recording. Look at official tracks with AI app open and study the
lines. Basically any surface inside the white lines should be valid. Anything outside should be invalid.

How do you edit these red lines?

They can be changed in the editor but it is a royal pain to do it that way. It is easiest to properly define the valid racing surface and record the line again.

The line is used to tell the AI where to go. When we make mod tracks and we want to record the AI line, we are basically just recording the racing line...
Whe do a lap of the track to record the path, but it also records what our pedals are doing.. If we are speeding up the line will be displayed green, if we
cruise at a set speed or just coast along it will be yellow and if we hit the brake pedal it will record red on the line. Which means if we are going along a big
straight recording our racing line and we hit the brake pedal Every other user who sees that racing line will also see a red " brake point" in the middle of a
long straight.. But you will clearly be able to see it's a long straight and you don't need to brake.. So REALLY the Racing line is nothing more than just a
visual recording of what the person did when they were actually recording the racing line..If the dev was a scaredy cat on the track and didn't drive to the
best of his potential then the racing line isn't even gonna be 100% accurate .. So hopefully you can now see why relying on the racing line so heavily is a
bad thing.. Use it to get familiar with the track and where the rough braking points are, but after that leave it well alone, you will learn the tracks much
quicker that way.

6.1.1 – TRACK LINE (fast_lane.ai)

Why don’t the AI track splines perfectly follow the ideal racing line of the circuits?
What you have to understand about the AI fast_lane trajectory is that there are cars which like to hit the kerbs, and others that really don’t. So Kunos
developers, working with many different types of vehicles, had to compromise, and made the cars follow a line that doesn’t allow the cars to take too much
of the kerbs surface, often as little as possible. That’s another reason why AC Competizione is better, having a small variety of racing classes (GT3 & GT4).

6.1.2 – PIT LINE (pit_lane.ai)

6.1.3 – IDEAL LINE (ideal_line.ai)
I guess ideal line is for that arcade ideal line app in game, without it it uses fastlane from ai folder. But I haven't tried yet.

6.1.4 - AI HINTS

6.2 - TRACK BOUNDARIES

These lines should be created / edited by the creator of the mod (who has the original project), otherwise you have to edit them with a text editor point by
point (and you don’t want to do that, trust me).

The track maker has only to produce 2 files called "side_l.csv" and "side_r.csv" (in track/data).
side_l for the left side, side_r for the right side, looking at driving direction.
As soon as the loading page of AC shows up (after pressing start on the launcher), just press SHIFT (and keep pressing it until the end of loading) and the 2
files will be added to fast_lane.ai
Lines will be rendered in yellow when using AI app.

643
the 2 csv files are simple XZY (watch out Max users) coordinate points (look at the example file provided). Coordinates are not interpolated so give a
reasonable number of points, there's no rule, these lines will be used by the sim to re-create track limits (red line of AI app)

shift must be pressed when loading the track you're doing the lines for... each time you want to change them. Once loaded, the lines are “baked” into
fast_lane.ai so they can be deleted from data.

in some quick testing I do not appear to need to hold the SHIFT key to load the CSV data into the AI line. It seems as long as the CSV file is in the data
folder it auto loads.

There is a system in place that compare dates on those files and updates if necessary but [we always found it a bit unreliable] so it's better to hold the shift
to be sure. [If the file timestamps match it won't load it. But the shift key forces it to regardless].

Just edit the main line and let the CSV file define the edges.

Also this method of edge line creation is really only for track creators/converters. You need to have the track inside a 3D program like Blender or 3DS max
to work with this.

About track limits

FAQ
QUESTION [1]: Some tracks, Spa for example, will disallow a lap for the smallest transgression. Others, Laguna Seca for example, allow you get away with
all sorts of off-track excursions. In the first case 40% of my laps may be no good while it is less than 10% in the latter, even though I feel it should be the
opposite. Does anybody know how the program makes those decisions?
ANSWER [1]: Road surfaces are set to valid or invalid according to their 3D model names. While the valid/invalid can be edited
(/tracks/trackname/surfaces.ini > IS_VALID=0/1), this will give you a checksum error for online racing.
The surface names instead are hardcoded into the 3D model and cannot be changed.

QUESTION [2]: Does editing the .CSV file of the track borders affect online multiplayer?
ANSWER [2]: All these files are only used by the single player AI, editing them will not cause a mismatch on online sessions in any way.

QUESTION [3]: Is partial track border replacement possible or I must create a full line?
ANSWER [3]: Before you had to remake the full line, but now you can use an app (man why don’t you… I know)

QUESTION [4]: What causes AI cars to weave down straights when I make the spline for my track? The spline is straight but the car weaves back and forth
full lock left and right.
ANSWER [4]: Sounds like the AI spline is broken. Just re-record it.

QUESTION [5]: I made an AI path but when the cars cross the start/finish line they weave uncontrollably and generally crash, even though the spline is straight.
ANSWER [5]: This is a slight variation of the issue from QUESTION [4].Irregular track boundaries, especially around the pitlane area, can cause this issue.
See Fig. for an example.

644
Fig. – The right-hand boundary should follow the edge of the track, and not jump across to the far right to follow the edge of the pit lane. Adjust that and see if it fixes your issue.

QUESTION [6]: Do left and right limits need the same number of points? Which density should they have?
ANSWER [6]: They don’t need to have the same number of vertices. It doesn’t matter how many they are in the .csv. AC will rebuild the AI line just based on
line and actual boundaries. However, a spacing from 30cm to 1m is pretty much fine.

QUESTION [7]: Is there a way to give the AI some kind of command/hint so that they don’t overtake at a certain corner of a track?
ANSWER [7]: You can change the AI boundary lines, making the path so small only one car can drive through that part at a time. with @Esotics AI-line
helper app

QUESTION [8]: Along the road there are two left-hand kinks which you can take flat. The AI drivers brake at these two points, completely spoiling the race.
ANSWER [8]: It is mostly the line causing the issue. It is probably not utilizing the entire track to straighten out the corners as much as possible. Therefore
to the AI the corner seems much tighter than it really is (Fig.).

645
Fig. – In purple is the current AI line and in yellow is more or less how it should look.

Then you should re-record the fast line, using the chase-cam to make sure you get right up to the edges of the track. Turn the two kinks into one long curve
(or a double apex curve).

646
CHAPTER 7 - SOUND
I recommend the reading of Chapter 8 of PART 2 - CAR MODDING to learn the creation process of a good sound. There are also all the
main principles of acoustics, if you don’t know or remember them.

Sound for tracks is for the most part related to ambience, attenuation and reverb:

• Ambience consists of background noise, and can be divided in two types: natural and artificial.
• Attenuation and reverb are physical phenomena: their existence is intrinsic with respect to the environment.

(wip)

7.2 – AMBIENCE SOUNDS

How to create a dark, mysterious, very filling ambience sound?

Assetto Corsa can become a completely different kind of experience, more inclined to exploration. So why not enhance it? Take a piece of music, open it
with an audio editor (e.g. Audacity) and slow it down to around 0.01-0.10x. In my opinion 0.03x works best. Add some echo if needed and put together the
parts you like; also, an equalization can be set to reduce low frequencies if they’re too intrusive. Depending on the genre of the song, you will get different
results. This works very well for a cave, and to generate a hominous, obscure feel in a futuristic science-fiction environment. I came up with this by myself,
but probably game developers use the same technique. Don't forget that less can be scarier sometimes. Did I just foresee the first horror map in AC?

7.3 - TRACK CAMERAS SOUNDS

A detailed mention is necessary when using track cameras (F3 view): the distance attenuation range of some exterior sounds is
multiplied by a value named DISTANCE_SCALE, expressed in meters, located in the following path:

Assetto Corsa/system/cfg/camera_track.ini
[CAMERA_SETTINGS]
DISTANCE_SCALE=7 ; PLEASE DON’T CHANGE IT
UPWARD_OFFSET=0
CAMERA_WOBBLING_SPEED=0.001
CAMERA_WOBBLING_STRENGTH=0.04 ; located

This is for gameplay purposes: imagine you're racing against 10 opponents with their own engine_ext playing. If the distance scale of
engine_ext is too short (e.g. from 1 to 20 meters), the sound will be not audible from the track cameras. If it's too large (e.g. from 1 to
750 meters), opponents will be audible from far away while you're racing against them.

With this "trick" you can find a good compromise about exterior sounds volume, in gameplay cases (driving among a pack of
opponents) and watching a replay with many cars involved.

The events that interact with the multiplier above are the following:

• engine_ext
• backfire_ext
• tractioncontrol_ext
• skid_ext
• limiter
• wheel
• wind

Note: the DISTANCE_SCALE multiplier is a global parameter, so its value is not configurable per car. The multiplier works only in track
cameras and free camera view (F3-F7) and only with the Events reported above. For any other exterior sound event, please use the
built-in distance scale and attenuation curves of the FMod deck.

This means that if you're using the car cameras (as said before, the F1 views and other "car attached" cameras), the multiplier is
switched off (technically, it's always set to 1 by code) and you can manage the distance scale and volume attenuation of the above
events using the original 3d panner (Fig.).

647
Fig. -

Back to the engine_ext and its 3d panner (picture above) of the example project, the maximum volume is reached at 6 meters and the
minimum is set at 350 meters, for gameplay cameras (F1 or F6).

Switching to track/free cameras (F3 or F7), those values are multiplied by the above DISTANCE_SCALE parameter, so the resulting
distance range is:

6 x 7 = 42

350 x 7 = 2450

This means that switching to track cameras view, the maximum volume is reached when the sound emitter (the car engine) is at 42
meters far (and below) from the sound listener (the camera position). Following the same reasoning, the volume goes to the minimum
(e.g. the event channel is released) when the car is 2450 meters far.

REVERB

In the new Fmod project we removed the “snapshot” reverb, because it led to episodes of bad implementation by some modders,
making the whole sound stage sounding like in a church using the track cameras. We reworked the whole code and when you drive
your car in a reverb zone, now the reverb is made by exterior sounds only (as expected in real life). Of course, skilled modders can add
snapshots to their own project if needed. Please refer to the Fmod official manual for further info.

7.5 - CUSTOM SHOWROOMS SOUNDTRACKS

The procedure is exactly the same of building a car bank. As reported in the first picture, remember to create an event folder named
"showrooms" and a new event with the same name of the showroom folder in the Assetto Corsa game folder. Put the soundtrack in
the timeline and set a region loop, then proceed to build the GUIDs and bank files.

Note: for showroom banks, please set the format to Vorbis.

648
CHAPTER 8 - TRACK MODS FROM THE COMMUNITY
You can find hundreds of track mods Assetto Corsa. Most of them are conversions, but they’re really fun nonetheless.

You can download them online from websites & forums; that’s the easy part, you still have to install them to be able to drive them in the simulator, and that’s
even easier! We can also talk about how you can edit mods from other authors, so there’s plenty of things you can learn here.

8.1 - HOW TO INSTALL TRACKS (copied from cars, modify)

If you read CHAPTER 8, you may be aware that mods are packed in a compressed archive, so you just have to extract the contents inside it with the tools
mentioned at the beginning of this manual.

Let’s look at the whole process then, working with 7-Zip (granted that you already installed this or a similar tool on your PC).

After you downloaded your car mod, you have different ways to install it:

A. FASTEST: Click on the file in the Downloads tab of your browser and the archive will open automatically in 7-Zip; select only the main car folder (you can recognize it
because it’s the FINAL folder, page), then drag and drop it in one of the following paths (which you will have to open in a File Explorer window), depending on the type
of AC installation you have:
- STEAM default: C:\Program Files (x86)\Steam\steamapps\common\assettocorsa\content\tracks
- STEAM default if you installed AC in a different (secondary) drive: [Drive letter]:\SteamLibrary\steamapps\common\assettocorsa\content\tracks.
- STEAM custom: You changed the path during the AC install process. To locate it use the method shown in par. 2.2 of the AC User Guide (pag.).
- Pirated version: Locate the respective assettocorsa main folder (may be named Assetto Corsa) and extract the mod under ~root\content\tracks; if you don’t remember
where it is, right click on the AC icon you should have on your desktop and select “Open file path”.
B. PRECISE: Click on the “Show in folder” menu/drop-down menu/icon next to the downloaded file in your browser. Your downloads folder will pop up and you will be
able to open the archive from there. Then in 7-Zip, click on the Extract button and change the destination folder to one of the paths in option A. Otherwise directly open
your downloads folder, and do the same.
If you enabled 7-Zip integration with MS-Windows drop-down menus, you can also right-click on the file and select 7-Zip > Extract the files… > choose the path.
Why is option B precise? Because dragging & dropping files can be glitchy and buggy, especially when rushing things. I know from personal experience. You may find
your files inside the wrong folders if you’re not careful.
C. SECURE: Same as B, but before opening or extracting the archive, scan it with your anti-virus software of choice.

Sometimes authors put in their package manuals and other kinds of stuff. Don’t copy those files in your AC assets, if you want to keep them just create a
special folder in your documents. In some case however, cars come with custom driver models, fonts and shaders, so you need to copy those (unless you
already have them). Be curious and look at what’s inside each folder. That’s the spirit.

Do not install mods automatically with Content Manager. It has an auto-install feature but it’s often buggy. You will avoid mistakes and errors with the
methods recommended here (A, B and C).

8.2 - HOW TO EDIT TRACKS

The basic principle around editing is that you aren’t the original creator of the mod. You want to obtain a custom or a better product for either yourself or the
community. Remember, always give credit to the authors of the assets you’re modifying.

You can use some tools to edit cars in either destructive or non-destructive ways.

649
 PART 5:

CODING
Software mods

650
CHANGING GENERIC AC SETTINGS:

List of all the configuration files under %root%\assettocorsa\system\cfg:

• assetto_corsa.ini
• audio_engine.ini
• camera_drivable.ini
• camera_free.ini
• camera_onboard_free.ini
• camera_start_mode.ini
• camera_track.ini
• chase_cam.ini
• chat.ini
• chat_app.ini
• colorCurves.ini
• damage_displayer.ini
• driver_performances.ini
• engine_smoke.ini
• fades.ini
• fanatec.ini
• ghost_car.ini
• graphics.ini
• hdr.ini
• ig_config.ini
• inireaderdocuments.ini
• lighting.ini
• map.ini
• messages.ini
• mouse_hider.ini
• name_displayer.ini
• options.ini
• physics.ini
• pitstop.ini
• proximity_indicator.ini
• random_camera.ini
• replay_steer_driver.ini
• scene_dimmer.ini
• session_info.ini
• skidmarks.ini
• sparks.ini (sparks_backup.ini)
• telemetry_presets.ini
• temp_blister.ini
• track_skins.ini
• tyre_pieces_grass.ini
• tyre_smoke.ini
• tyre_smoke_grass.ini
• tyres_app.ini
• vr.ini
• weather.ini
OH YEEEEAH NOW YOU’RE STARTING TO UNDERSTAND WHAT’S GOING ON HERE

Tire smoke (MOVE AWAY FROM HERE)

There are some settings to give the tire smoke a more natural color than the default one. You'll need to simply edit your tyre_smoke.ini, which can be found
under %root%\assettocorsa\system\cfg:
[SETTINGS]
EMISSIVE_BLEND=0.5
VELOCITY_BASE=0,0,0
VELOCITY_RANDOM=1,1,1
SIZE_BASE=1,1
SIZE_RANDOM=0.02,0.02
COLOR_BASE=0.70,0.72,0.8 ; RGB (red, green, blue) colour intensity.
COLOR_RANDOM=0.1,0.1,0.1
DRAG_BASE=0.1
DRAG_RANDOM=0.0

651
GRAVITY_BASE=0.1
GRAVITY_RANDOM=0.01
OPACITY_BASE=0.15
OPACITY_RANDOM=0.2
OPACITY_VELOCITY_BASE=-0.1
OPACITY_VELOCITY_RANDOM=0.005
SIZE_VELOCITY_BASE=0.3,0.3
SIZE_VELOCITY_RANDOM=0.1,0.1
VELOCITY_ROTATION_AXIS_RANDOM=0
FREQUENCY_HZ=30

[TRIGGERS]
SLIP_LEVEL=0.8

The most important lines are COLOR_BASE and COLOR_RANDOM. They allow you to create coloured smoke effects too (Fig.).

Fig. – Setting the red value to 10 in COLOR_BASE can get you this result. You can do pretty cool stuff. Imagine neon sci-fi cars in a futuristic environment.

You can use tyre_smoke_grass.ini in the same path to alter the dust effect when going offroad. It’s identical to tyre_smoke.ini, only the [TRIGGERS]
section is missing.
Keep in mind that these config files are for the vanilla effects, and if you enable CSP’s Particle FX, they will/may be overridden.
How to achieve this with CSP then?

Car damage display:

You can edit or replace the default car damage display graphics (Fig.) by changing the textures in %root%\assettocorsa\content\texture\damage.

Fig. – (left) Vanilla damage display. (right) Alternative Real Display Damage (https://www.racedepartment.com/downloads/alternative-real-display-damage-v1-0.26934) and Minimal Damage
Icon (https://www.assettocorsa.net/forum/index.php?threads/updated-minimal-damage-icon-ac-1-0-rc-and-up.12726).

It is only required to make the textures in white. AC will work by itself the colours, from cream to red (it’s hardcoded).
You can also make the original textures smaller; the original is a bit intrusive. A mod that does this is the smaller damage display / icon mod:
https://www.racedepartment.com/downloads/smaller-damage-display-icon.3858

A big question has always been: how can the display be moved on the screen? There are no settings in the vanilla launcher, but Kunos made it possible to
move the damage icon wherever you want with the damage_displayer.ini in the %root%\assettocorsa\system\cfg folder. Here is the script:
[MAIN]
TIME=8 ; Amount of time the display will stay active after the car takes damage. [s]

652
MAX_DAMAGE_KMH=60
POSITION_X=-1
DISTANCE_FROM_CENTER_Y=26
PRINT_VALUES=0 ; Boolean. Enable or disable damage values debug on screen.

To put the damage display completely to the left side of the monitor change the POSITION_X value to 0. To place it on the right side you have to test:
raise the value until its where you want it.
The DISTANCE_FROM_CENTER_Y value moves it up/down, and a negative number means up from the middle of the screen. Put a positive value there
and it will go downwards.
This file is exactly what the Content Manager launcher modifies in the menu of Fig..

Fig. – The Damage displayer tab under the Assetto Corsa settings menu of CM.

What CM doesn’t give you access to however is the PRINT_VALUES line, useful for debugging the damage levels of the car, which are showed on screen
whenever damage is taken (Fig.). When you are crash testing your mods, I would suggest to increase the TIME value so that the numbers on screen do not
disappear (set it to 3000, so it lasts 50 minutes).

Fig. – The car hit a wall on the front bumper, and the numbers show up accordingly on the left upper corner of the screen.

there are ways of "tricking" the server into going into weird values.

- set the server to increase in 1% track grip increments, have a session carry-over that results in a decimal, and boom! more than 100% track grip

- set temps to the "max" and then use the variation value and it has a chance of going higher

- set the server with a negative track grip change, and it can go below 0% grip

whether the game recognises any values "outside of bounds" I don't know

you can also configure cars with negative restrictor and ballast, and it will increase the performance of the cars (or make them fly)

but you can only do these with the acserver. you can't do them in single player

653
CHAPTER 1: Getting started with Assetto Corsa application development (WIP)
Starting with Assetto Corsa application development is not hard, but it is harder than it needs to be. The common wisdom seems to be to read the sample
applications that come with Assetto Corsa (in /apps/python/, there is a Chat and gMeter application), or to read the code behind some of the applications
being shared on the forums.

This certainly works, and is how I learned, but it takes more guess-and-test than should be necessary. For example, early on in reading the forum I heard of
something called py_log.txt, but it wasn't clear where to find it.

In this document, I pull back the curtain and explicitly show the basics. I assume you already know some Python. Other than a small note about Python's
treatment of global variables, I do not cover any Python.

I'm going to develop below an application called appName. You should, of course, name your application something more descriptive.

Preliminaries
Locations of interest
There are two folders you should be aware of:

• The Assetto Corsa installation directory. This is most likely to be found in your Steam directory. On Windows, this look like C:\Program Files
(x86)\Steam\steamapps\common\assettocorsa. You may have chosen to install AC elsewhere, and I trust you can find where that is.
• The Assetto Corsa documents directory. On Windows, this looks like C:\User\My Documents\Assetto Corsa\, where Useris replaced with your Windows account name.

Each of these contains at least one subfolder of interest:

• In the installation directory, the interesting subfolder is /apps/. This is where the application is placed.
• In the Documents directory, the subfolder of interest is /logs/. In this directory you will find both log.txt and py_log.txt.

log.txt is where AC logs everything about the execution of AC itself. Sometime this will contain relevant information about your application that AC logs
automatically.
py_log.txt is where AC places strings explicitly requested to be logged by running applications.

Basic workflow
The workflow of testing an application isn't the best. It can be slow going when you're making a lot of changes, especially if you make syntax or logical
mistakes. Try to be careful and ensure the code you're attempting to run is correct. You might want to look into something like pylint so you can find errors
in the code without having to run Assetto Corsa.

If something is wrong with your code, and error message might show up automatically in the in-game console or in py_log.txt. It will always show up in
log.txt. The best way to find an error in log.txt is by search for your application name, in this case appName, and reading the surrounding output.

I call an on-track event a session. I usually test in practise mode around a short track like silverstone-international, but it shouldn't matter what you choose.

Here is how I test my application:

• I edit the source code, then run AC and start a session.

• If there are no errors and the application was previously active on the screen, it will still be so. If something went wrong, it will have disappeared and
there will be a message somewhere as to why. If an error has occurred, I end the session. Otherwise, I continue.
• I do what I need to in order to test the application behaviour.
• When I find that I need to make changes, I end the session.

In either case - an error or a desired change - you don't have to exit Assetto Corsa. Instead, you can alt-tab out, change the code, and then start a new
session. This is faster than continuously starting and exiting the main Assetto Corsa application. It's still a bit of a drag having to exit and restart sessions, so
as I noted before try to be careful that at least the syntax of your code is correct before testing it. Otherwise, you wait around while starting a session only to
find out your application has failed to load.

It's a habit of mine to always check the console at the start of a session. If something in my application is wrong, there is likely to be a message in the
console about what went wrong. It's also often the case that the message in the console contains the line number in my application where the error was
found. If this is not the case, the error might instead be in py_log.txt orlog.txt. Again, you have a good change of finding a specific line number there, or at
worst a helpful error message.

Getting an application running

Create a folder in /apps/python/ with the name appname. Inside /apps/python/appname/, create a file appname.py. Open the file for editing.

A most basic application

First, note that a barebones application still needs a few imports. I won't keep embedding these in the code snippets below, so be aware that every
application should start off with the following imports:

import sys
import ac
import acsys

654
The most basic applications only takes a few lines of code. The AC plugin architecture will automatically execute certain functions in which it expects to find
your code. To begin an application, you must define a function as follows:

def acMain(ac_version):
...

The code for your application will go in place of the ellipses. For now, we'll insert the bare minimum code:

def acMain(ac_version):
appWindow = ac.newApp("appName")
ac.setSize(appWindow, 200, 200)
return "appName"

Actually, the bare minimum is probably just the return statement, but that application is not at all interesting.

If you run Assetto Corsa and start a session, you will find in the application sidebar an entry named appName. If you activate this, you will see a very basic
widget consisting of a 200x200 application window with the name appName at the top. Here is what you should see in the application sidebar:

ac.log and ac.console

The function ac.log writes to the file py_log.txt which I mentioned earlier.

The function ac.console writes to the Assetto Corsa console. To bring up the console, hit the Home key on your keyboard. Hit the key again to dismiss the
console.

The way you might use these functions is quite similar, so think of it this way:

• Use ac.log when you want the text to persist after the session has ended. This is helpful if you want to debug the application through lots of printed statements.
• Use ac.console when you might want to read the output during the session. By bringing up the in-game console you can immediately view the messages. Yes, you can
alt-tab out and view the py_log.txt while the session is still running, but it's not nearly as pleasant.

These functions are both good targets to dump information that you're not quite sure about. Use them to figure out exactly that a piece of code is doing.

Extending the basic application

Let's change the code to the following:

def acMain(ac_version):
appWindow = ac.newApp("appName")
ac.setSize(appWindow, 200, 200)

ac.log("Hello, Assetto Corsa application world!")

ac.console("Hello, Assetto Corsa console!")
return "appName"

Start a new session, and check that you see the text Hello, Assetto Corsa console! in the console when you hit the Homekey on your keyboard. Additionally,
ensure that Hello, Assetto Corsa application world! has shown up in the filepy_log.txt.

Unsurprisingly, both should be the case. There were no tricks here. One important thing to note is that your application does not have exclusive usage of
either the console or python log file. Other applications you have installed might also be sending text to the console or python log. You can either disable all
other application, or prefix all message with a unique string, e.g.*** Message from appName: so that you can quickly find the output from your application.

Adding labels to your application window

If you have an application window on your screen, you probably want to display some information within it. To do so, we can add labels to the window:

l_lapcount = ac.addLabel(appWindow, "Laps: 0");

ac.setPosition(l_lapcount, 3, 30)

655
Remember, your application windows is a 200x200 widget. Some of this space is taken up by the header, where the appNamelabel automatically appears.
This is why I set the label at position 30 vertically. I set it at 3 horizontally to offset it slightly from the border.

The code should now look like this:

def acMain(ac_version):
appWindow = ac.newApp("appName")
ac.setSize(appWindow, 200, 200)

ac.log("Hello, Assetto Corsa application world!")

ac.console("Hello, Assetto Corsa console!")

l_lapcount = ac.addLabel(appWindow, "Laps: 0");

ac.setPosition(l_lapcount, 3, 30)
return "appName"

and the application window should look like this:

Moving towards a more realistic application

So far, our application consists only of the application window and a static label. Let's add some dynamic behaviour.

The function acMain has setup our application window. To do something with it, we must use an additional functionacUpdate.

One important thing to note is that we're going to need to access the label l_lapcount from within acUpdate if we want to place dynamic information into it.
So far, the label has been a variable local to acMain. Since we're not the one callingacUpdate, we can't pass the label along to it as a parameter. Instead, we
must make l_lapcount a global variable. To do so, define it outside of acMain. Then, within acMain we must inform the function that l_lapcount is a global
variable. If we forget to do so, we'll create a local variable l_lapcount within acMain which will shadow the global variable, and any changes we make within
acMain will not be visible outside of it. Most importantly, if we forget to do this the actual label we placed in the application window in acUpdate would not
be available from acUpdate.

We'll also add a global variable lapcount which only needs to be accessible within acUpdate. The code should look like so:
l_lapcount=0
lapcount=0

def acMain(ac_version):
global l_lapcount

appWindow = ac.newApp("appName")
ac.setSize(appWindow, 200, 200)

ac.log("Hello, Assetto Corsa application world!")

ac.console("Hello, Assetto Corsa console!")

l_lapcount = ac.addLabel(appWindow, "Laps: 0");

ac.setPosition(l_lapcount, 3, 30)
return "appName"

def acUpdate(deltaT):
global l_lapcount, lapcount
laps = ac.getCarState(0, acsys.CS.LapCount)
if laps > lapcount:
lapcount = laps
ac.setText(l_lapcount, "Laps: {}".format(lapcount))

acUpdate takes a parameter that is ???(Guess: ?milli?seconds since it was called last).

Note that within acUpdate we make a call ac.getCarState(0, acsys.CS.LapCount). This might look confusing at first since I never explained anything about it,
but it's just another function made available through our import of ac and acsys. I don't want to duplicate the official documentation, so please look at the
resources section at the end of this guide for a link to the official documentation. Eventually, you should read it so that you know what has been made
available for application development by the Assetto Corsa developers, but it's not important at the moment. You can continue on with this guide.

Now, after completing a lap your application window will look like this:

656
and so on as you complete laps.

You could, of course, also log this information to the console or the python log:
ac.log("{} laps completed".format(lapcount))
ac.console("{} laps completed".format(lapcount))

Additional functions called by Assetto Corsa

One additional function to note is acShutdown, which is called when the session is ended.
def acShutdown():
# ...
return

You'll want to add within acShutdown any code that should be completed before your application exits. For example, if there are outstanding database
modifications, you want to make sure you commit them and safely close the connection to the database.

You can also register callbacks for certain events. Two that I am aware of are ac.addOnAppActivatedListener and ac.addOnAppDismissedListener. For
instance, you might define a function on_activation and register it by calling
ac.addOnAppActivatedListener(appWindow, on_activation)

It seems that acUpdate is always called, even when the application is dismissed. If this is not desirable, the idiom would be to check a flag within acUpdate
that is set in the callback registered with ac.addOnAppActivatedListener, so that you only run code when the application is activated.

Accessing Shared Memory

The Python API gives us access to some nice functions, which you can find in the next Chapter 2 along with their parameters, but there is a lot more that you
might need access to in order to make your app, that is, the functions on the C++ language side of Assetto Corsa. To get to this additional gateway, you must
access the shared memory structure made available by the simulator. This is done via ctypes, “a foreign function library for Python”, as stated on the official
Python documentation (here: https://docs.python.org/3/library/ctypes.html). It provides C compatible data types, and allows calling functions in DLLs or shared libraries.
It can be used to wrap these libraries in pure Python.
Here is a quick tutorial on doing so:
• Add a directory within /apps/python/appname/ with a name of your choice. I use third_party.
• Add into this directory _ctypes.pyd and sim_info.py.
See Shared memory for Python applications (sim_info.py) for AC v0.20 for where to obtain these files.
• Insert the third_party directory into the python environment before using the import statement:
sys.path.insert(len(sys.path), 'apps/python/appname/third_party').
• Import from sim_info.py using from sim_info import info.
After doing so, you can get to any of the shared memory information using e.g. info.physics.fuel.

Exercise: Add an additional label to the application window and fill it with the current fuel in the tank. Update the value dynamically throughout the session
with a period shorter than once-per-lap.

If you can complete this, you have understood everything I tried to communicate by writing this document.

Pro tip: for a better workflow with Assetto Corsa Python apps, you should install the following library for normal auto-complete for the “ac“ module in the
Python IDE: https://github.com/rikby/ac-stubs
This will solve the problem shown in Fig. below.

Enough, for now (nahhhh)

That should cover the basics, and get you started writing Assetto Corsa applications. There is still a lot that you'll need to learn to make a non-trivial
657
application, but a good starting point is always helpful.
Also, please note that this is just one way to do it. In programming, like in everything else there are many solutions to the same problem, so feel free to
experiment your own ideas once you get the hang of it. There is nothing you could break.

FAQ
Some of the basic questions and answers when dealing with apps. Let’s try to help coders.

QUESTION [1]: How do I install apps?

ANSWER [1]: It is a good practice to check the apps' archive first.
• If it contains a folder named "apps", then you just need to drop it under %root%\assettocorsa\
• If it contains a folder named as the app, then you need to drop it under %root%\assettocorsa\apps\python

QUESTION [2]: I've copied the app in the respective folder, but it's not showing in-game.
ANSWER [2]: Any app you install, must be first activated: go to Options > General, and check the box next to the app. The procedure is similar in CM.

QUESTION [3]: I want to activate the app in Options, but it doesn't show in the list.
ANSWER [3]: Check first the instructions (usually in the README.txt if present); you probably didn't copy the app in the right path.

658
CHAPTER 2: AC Python documentation
We’re decrypting info from the enemy. Everything is going as planned sir. Jokes aside, the documentation was in a pretty rough state when I
got my hands on it, many things aren’t clear. Also, the grammar doesn’t help, I know. But for now, enjoy.
import ac
The following functions become available when you import the “ac” module inside your python document. You can find the identifiers in the acsys.py file
under %root%\apps\python\system.
ac.getCarState(<CAR_IDENTIFIER>, <INFO_IDENTIFIER> , /*OPTIONAL*/<OPTIONAL_IDENTIFIER>)
This is the most important function. It returns the <INFO_IDENTIFIER> type of information associated to car <CAR_IDENTIFIER>. The optional identifier can be omitted, it is
used for special info where they require a specific tire, as described in the following section. The <OPTIONAL_IDENTIFIER> and it can be one of the following values:
On the left a synthetic description is given using blue color:
FL, Front Left
FR, Front Right
RL, Rear Left
RR, Rear Right

Using the following <INFO_IDENTIFIER>s ac.getCarState returns a scalar value:

SpeedMS, Current speed using Meters/Seconds [0, …]
SpeedMPH, Current speed using Miles/Hour [0, …]
SpeedKMH, Current speed using Kilometers/Hour [0, …]
Gas, Pression on the Gas pedal [0,1]
Brake, Pression on the Brake pedal [0,1]
Clutch, Pression on the Clutch pedal [0,1]
Gear, Current Gear [0,max gear]
BestLap, Best Lap in milliseconds [0, …]
CGHeight, Height of the center of gravity of the car from the ground [0, …]
DriftBestLap, Best Lap points in Drift mode [0, …]
DriftLastLap, Last Lap points in Drift mode [0, …]
DriftPoints, Current Lap points in Drift mode [0, …]
DriveTrainSpeed, Speed Delivered to the wheels [0, …]
RPM, Engine’s rotations per minute [0, …]
InstantDrift, Current drift points in Drift Mode [0, …]
IsDriftInvalid, Current Drift is valid/invalid in Drift Mode {0,1}
IsEngineLimiterOn, Engine Limiter On/Off {0,1}
LapCount, Current Session Lap count [0, …]
LapInvalidated, Is current Lap invalidated (by going out on the grass) {0, 1}
LapTime, Current LapTime in milliseconds [0, …]
LastFF, Last Force Feedback signal sent to the Wheel [0, …]
LastLap, Last Lap in milliseconds [0, …]
NormalizedSplinePosition, Position of the car on the track in normalized [0,1]
PerformanceMeter, Projection of how many seconds is the current time far from the current best lap [0, …]
Steer, Radians of steer rotation [2pi,2pi]
TurboBoost, Turbo gain on engine torque for specific vehicles [0,...]
Caster, Caster Angle in radians

Using the following <INFO_IDENTIFIER>s ac.getCarState returns a 3D vector (with x,y,z components):
AccG, Gravity acceleration on the vehicle’s GC x,y,z = [0, …]
LocalAngularVelocity, Get the angular velocity of the car, using the car as origin x,y,z = [0, …]
LocalVelocity, Get the velocity using the car as origin x,y,x = [0, …]
SpeedTotal, Get all the speed representation x= km/h, y = mph, z = m/s
Velocity, Current velocity vector x,y,z = [0, …]
WheelAngularSpeed, Current Wheel angular speed x,y,z = [0, …]
WorldPosition, Current Car Coordinates on map x,y,z = [0,...]

Using the following <INFO_IDENTIFIER>s ac.getCarState returns a 4D vector (with w,x,y,z components):
CamberRad, The camber angle in Radiants for each tyre
CamberDeg, The camber angle in Degree for each tyre
SlipAngle, Slip angle of the chosen tire in degrees. [0, 360]
SlipRatio, Slip Ration of the tyres x,y,z,w = [0,1]
Mz, Self-Aligning Torque x,y,z,w = [0, …]
Load, Current load on each tyre x,y,z,w = [0,...]
TyreRadius, Radius of any Tyre x,y,z,w = [0,...]
NdSlip,
TyreSlip,
DY, Lateral friction coefficient for each tyre
CurrentTyresCoreTemp, Current core temperature of the tyres °C x,y,z,w = [0,...]
ThermalState, Current temperature of the tyres °C x,y,z,w = [0,...]
DynamicPressure, Current pressure of the tyres psi x,y,z,w =[0, …]
TyreLoadedRadius, Radius of the tyre under load x,y,z,w =[0, …]
SuspensionTravel, Suspension vertical travel x,y,z,w =[0, …]
TyreDirtyLevel, Quantity of dirt on the tyres x,y,z,w =[0, 10)

Using the following <INFO_IDENTIFIER>s combined with the <OPTIONAL_IDENTIFIER> ac.getCarState returns a 3D vector (with x,y,z components) related to the
<OPTIONAL_IDENTIFIER> wheel:
TyreContactNormal, Normal vector to tyre’s contact point (z)
TyreContactPoint, Tyre contact point with the tarmac
TyreHeadingVector, Tyre Heading Vector (x)
TyreRightVector, Tyre Right Vector (y)

659
Using the following <INFO_IDENTIFIER>s combined with the <OPTIONAL_IDENTIFIER> ac.getCarState returns a scalar vector (with x,y,z components) related to the
<OPTIONAL_IDENTIFIER> index O:
Aero, o=0 drag Coefficient
Aero, o=1 lift Coefficient front
Aero, o=2 lift Coefficient rear

Example : ac.getCarState(0,TyreContactPoint,FR). On failure ac.getCarState returns 0.

UNDOCUMENTED identifiers
SpeedTotal,
SlipAngleContactPatch
TyreSurfaceDef
TyreVelocity
LastTyresTemp
RideHeight
ToeInDeg
KersCharge
KersInput
DrsAvailable
DrsEnabled
EngineBrake
ERSRecovery
ERSDelivery
ERSHeatCharging
ERSCurrentKJ
ERSMaxJ
RaceFinished
P2PStatus
P2PActivations

GENERAL INFO:
ac.getDriverName(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car returns as a string the driver’s name of the <CAR_ID> car. This function returns the car name on success, 1 otherwise.
ac.getTrackName(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car returns as a string the track’s name where <CAR_ID> is running. This function returns the track’s name on success, 1
otherwise.
ac.getTrackConfiguration(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car returns as a string the track’s configuration where <CAR_ID> is running. This function returns the track’s name on
success, 1 otherwise.
ac.getCarName(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car returns as a string the car’s name of the <CAR_ID> car. This function returns the car name on success, 1 otherwise.
ac.getLastSplits(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car returns as a Python List the car’s last splits of the <CAR_ID> car. This function returns the Python list with the splits on
success, 1 otherwise.
ac.isCarInPitline(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car. This function returns 1 if the car is currently in the Pitline. (-lane?)
ac.isCarInPit(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car. This function returns 1 if the car is currently in the Pitbox.
ac.isConnected(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car. This function returns 1 if the car is currently connected.
ac.getCarBallast(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car. This function returns the ballast value of the car.

660
ac.getCarMinHeight(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car. This function returns the minimum height of the car.
ac.getServerName()
This function returns the name of the joined server.
ac.getServerIP()
This function returns the IP of the joined server.
ac.getServerHttpPort()
This function returns the Http port of the joined server.
ac.getServerSlotsCount()
This function returns the total number of occupied slots in the server.
ac.getCarsCount()
This function returns the session’s max number of cars.
ac.getCarLeaderboardPosition(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car. This function returns the position of the car on the Leaderboard.
ac.getCarRealTimeLeaderboardPosition(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car. This function returns the position of the car on realtime.
ac.getCarFFB()
This function returns the FFB Gain value for the player current car.
ac.setCarFFB(<VALUE>)
<VALUE>is the value that will be added to the current FFB gain. This function sets the FFB Gain value for the player current car.

CAMERA MANAGEMENT
ac.setCameraMode(<INFO_IDENTIFIER>)
<INFO_IDENTIFIER> can be (Camera Mode): Cockpit, Car, Drivable, Track, Helicopter, OnBoardFree, Free, Random, ImageGeneratorCamera, Start

ac.getCameraMode()
This function returns a <INFO_IDENTIFIER> above
ac.isCameraOnBoard(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car. This function returns 1 on success, 1 otherwise.
ac.setCameraCar(<CAMERA_ID>,<CAR_ID>)
<CAMERA_ID> must be the F6 camera index. <CAR_ID> must be the car ID, 0 for the player’s car. This function returns 1 on success, 1 otherwise.
ac.getCameraCarCount(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car. This function returns the number of F6 cameras, 1 otherwise.
ac.focusCar(<CAR_ID>)
<CAR_ID> must be the car ID, 0 for the player’s car. This method get switch the actor to the selected car. This function returns 1 on success, 1 otherwise.
ac.getFocusedCar()
This method get the selected car index.

DEBUG
ac.log(<VALUE>)
<VALUE> must be a string. Use ac.log if you want to send some text to the AC log.txt file. The function returns 1 on success.
ac.console(<VALUE>)
<VALUE> must be a string. Use ac.console to send a string to the AC console. The function returns 1 on success.

GENERAL APP MANAGEMENT:

ac.newApp(<VALUE>)
<VALUE> must be a string. Creates a new app and returns the corresponding Identifier. Returns the App ID on success, 1 otherwise.
ac.setTitle(<CONTROL_IDENTIFIER>,<TITLE>)
<TITLE> must be a string, <CONTROL_IDENTIFIER> must be a form. This function will set the title of the specified App by <CONTROL_IDENTIFIER>. The function returns 1
on success, 1 otherwise.
ac.setSize(<CONTROL_IDENTIFIER>,<WIDTH>,<HEIGHT>)
<WIDTH>,<HEIGHT> must be floating point numbers. This function will set the size of a control specified by <CONTROL_IDENTIFIER>. The function returns 1 on success, 1
otherwise.
ac.addLabel(<CONTROL_IDENTIFIER>,<VALUE>)
<VALUE> must be a string. It is possible to add a label to a Window, we need to pass the Window to ac.addLabel and the label name. The function returns 1 on success, 1
otherwise.
ac.setPosition(<CONTROL_IDENTIFIER>,<X>,<Y>)
<X>,<Y> must be a floating point numbers. Use ac.setPosition to set the control's position specified by <CONTROL_IDENTIFIER> in the app. The function returns 1 on
success, 1 otherwise.

661
ac.setIconPosition(<CONTROL_IDENTIFIER>,<X>,<Y>)
<X>,<Y> must be a floating point numbers, <CONTROL_IDENTIFIER> must be a form. Use ac.setPosition to set the new icon’s position instead of the default one. The
function returns 1 on success, 1 otherwise
ac.setTitlePosition(<CONTROL_IDENTIFIER>,<X>,<Y>)
<X>,<Y> must be a floating point numbers, <CONTROL_IDENTIFIER> must be a form. Use ac.setPosition to set the new title’s position inside the app. The function returns 1
on success, 1 otherwise
ac.getPosition(<CONTROL_IDENTIFIER>)
<CONTROL_IDENTIFIER> is the identifier of a control. Use ac.getPosition to get the control's position in the parent window, this function returns a python tuple width,height.
The function returns the position as a tuple x,y on success, 1 otherwise.
ac.setText(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a string, <CONTROL_IDENTIFIER> is the control that we want to set the text to. Set the text of the control specified by <CONTROL_IDENTIFIER>, with the
<VALUE> text passed as an argument. The function returns 1 on success, 1 otherwise
ac.getText(<CONTROL_IDENTIFIER>)
<CONTROL_IDENTIFIER> is the control that we want to get the text from. Use ac.getText to get the control's text. This function returns the coordinates x,y of the control on
success, 1 otherwise.
ac.setBackgroundOpacity(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a floating point value between 0 and 1. Use ac.setBackgroundOpacity to change the alpha channel of the desired control. The function returns 1 on
success, 1 otherwise.
ac.drawBackground(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be 0 or 1. Use ac.drawBackground to set the background visible (1)(DEFAULT) or transparent (0). The function returns 1 on success, 1 otherwise.
ac.drawBorder(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be 0 or 1. Use ac.drawBorder to draw the border of the desired control (1) (DEFAULT) or not (0). The function returns 1 on success, 1 otherwise.
ac.setBackgroundTexture(<CONTROL_IDENTIFIER>, <PATH>)
<PATH> starts from Assetto Corsa root folder, <CONTROL_IDENTIFIER> must be a control identifier. Use ac.setBackgroundTexture to draw a specified texture stored in the
path specified by <PATH> as background image for the control specified by <CONTROL_IDENTIFIER>. The function returns 1 on success, 1 otherwise.
ac.setFontAlignment(<CONTROL_IDENTIFIER>, <ALIGNMENT>)
<ALIGNMENT> is one of the following strings: “left“, “right” or “center”. Use ac.setFontAlignment to set the font alignment of the control text as specified by the
<ALIGNMENT> string. The function returns 1 on success, 1 otherwise.
ac.setBackgroundColor(<CONTROL_IDENTIFIER>, <R>,<G>,<B>)
<PATH> starts from Assetto Corsa root folder. Use ac.setBackgroundColor to set the background color of the window as specified by the R,G,B values. The function returns 1
on success, 1 otherwise
ac.setVisible(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be 0 or 1. It is possible to hide the object using the function ac.setVisible with VALUE set to 1. The function returns 1 on success, 1 otherwise.
ac.addOnAppActivatedListener(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined inside the Python script, <CONTROL_IDENTIFIER> must be an app. This method set the <VALUE> function as callback function
for the event of app selection on the task bar. The function returns 1 on success, 1 otherwise.
ac.addOnAppDismissedListener(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined inside the Python script, CONTROL_IDENTIFIER> must be an app. This method set the <VALUE> function as callback function for
the event of app deselection on the task bar. The function returns 1 on success, 1 otherwise.
ac.addRenderCallback(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined inside the Python script. This method set the <VALUE> function as callback function for the finished rendering event. The function
returns 1 on success, 1 otherwise
ac.setFontColor(<CONTROL_IDENTIFIER>,<R>,<G>,<B>,<A>)
<CONTROL_IDENTIFIER> must be a Controlidentifier, <R>,<G>,<B>,<A> are the color value scaled from 0 to 1. This function returns 1 on success, 1 otherwise
ac.setFontSize(<CONTROL_IDENTIFIER>, <VALUE>)
This method set <VALUE> as new new size of the control’s font. The function returns 1 on success, 1 otherwise.
ac.initFont(0, <FONTNAME>, <ITALIC>, <BOLD>)
This method loads the font in memory (stored as font+italic+bold). Should be used at the initialization of the application. The font needs to be saved in the “content/fonts”
folder.
<FONTNAME> must be the name of the base font (real name, not filename, so it can be “Arial”) <ITALIC> must be a 0 for nonitalic font, 1 for italic font (instance will be “Arial
Italic”) <BOLD> must be a 0 for nonbold font, 1 for bold font (instance will be “Arial Bold” or “Arial Italic Bold” is also italic).
The function returns 1 on success, 1 otherwise
ac.setCustomFont(<CONTROL_IDENTIFIER>, <FONTNAME>, <ITALIC>, <BOLD>)
This method create or replace the font of a control. Should not be done without calling “iniFont”. The font needs to be saved in the “content/fonts” folder.
<CONTROL_IDENTIFIER> is the control owner of the font <FONTNAME> must be the name of the base font (real name, not filename, so it can be “Arial”) <ITALIC> must be a
0 for nonitalic font, 1 for italic font (instance will be “Arial Italic”) <BOLD> must be a 0 for nonbold font, 1 for bold font (instance will be “Arial Bold” or “Arial Italic Bold” is also
italic)
The function returns 1 on success, 1 otherwise

SPECIFIC CONTROL MANAGEMENT:

662
Button:
ac.addButton(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a string, <CONTROL_IDENTIFIER> must be a form. The function adds a Button to the window specified by <CONTROL_IDENTIFIER>. The function returns
the Button ID on success, 1 otherwise
ac.addOnClickedListener(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined in this file. It is possible to associate the button with an event to trigger when it is clicked using this function. The function returns
1 on success, 1 otherwise

Graph:
ac.addGraph(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a string. The function adds a Graph to the window specified in <CONTROL_IDENTIFIER>. The function returns the Graph ID on success, 1 otherwise.
ac.addSerieToGraph(<CONTROL_IDENTIFIER>, <R>,<G>,<B>)
<R>,<G>,<B> must be floating point numbers between 0 and 1. To plot some data it is necessary to add a Serie. A serie is a succession of points to plot on the graph.
When adding a serie you must specify the color of the serie as argument. The function returns 1 on success, 1 otherwise
ac.addValueToGraph(<CONTROL_IDENTIFIER,<SERIE_INDEX>,<VALUE>)
<SERIE_INDEX> is the Serie ID in the graph that where <VALUE> will be added. The function returns 1 on success, 1 otherwise.

ac.setRange(<CONTROL_IDENTIFIER>,<MIN_VALUE>,<MAX_VALUE>,<MAX_POINTS>)
<MIN_VALUE>,<MAX_VALUE>,<MAX_POINTS> must be floating point numbers. In order to plot the data inside the Graph it is necessary to specify the amplitude of the
ordinates and the maximum number of points to store in memory. The function returns 1 on success, 1 otherwise.

Spinner:
ac.addSpinner(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a string. It is possible to add a Spinner using the function. The function returns the Spinner ID on success, 1 otherwise.

ac.setRange(<CONTROL_IDENTIFIER>, <MIN_VALUE>,<MAX_VALUE>)
<MIN_VALUE>,<MAX_VALUE> must be floating point numbers. It is possible to set the min and max values of the Control:
The function returns 1 on success, 1 otherwise
ac.setValue(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be floating point number. This function set the "value" parameter of the specific Control if this is an available parameter. This function affects controls like
Spinner, Progress Bar or Check Box. The function returns 1 on success, 1 otherwise.
ac.getValue(<CONTROL_IDENTIFIER>)
<VALUE> must be floating point number. This function returns the "value" parameter of the specific Control if this is an available parameter. The function returns the value on
success, 1 otherwise.
ac.setStep(<CONTROL_IDENTIFIER>,<VALUE)
<CONTROL_IDENTIFIER> must be a Spinner ID <VALUE> must be floating point number. Set the value added or subtracted when the + or button is pressed in a Spinner
controller. The function returns 1 on success, 1 otherwise.
ac.addOnValueChangeListener(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined inside the Python script. It is now possible to associate the spinner with an event to trigger when one of the two buttons is
pressed. The function returns 1 on success, 1 otherwise.

Progress Bar:
ac.addProgressBar(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a string. It is possible to add a Progress Bar using the function. The function returns the Progress Bar ID on success, 1 otherwise.

Input Text:
ac.addTextInput(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a string. It is possible to add an Input Text Field using the function. The function returns the Input Text ID on success, 1 otherwise.
ac.setFocus(<CONTROL_IDENTIFIER>, <FOCUS>)
<CONTROL_IDENTIFIER> must be an Input Text, <FOCUS> must be 0 or 1. If FOCUS is 1, this function sets the Input Text as first responder. The function returns 1 on
success, 1 otherwise
ac.addOnValidateListener(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined inside the Python script. It is possible to associate the <CONTROL_IDENTIFIER> with an event to trigger when the enter key is
pressed. The function returns 1 on success, 1 otherwise.

List Box:
ac.addListBox(<CONTROL_IDENTIFIER>,<NAME>)
<CONTROL_IDENTIFIER> must be a window identifier. This method adds a List Box to the window specified by CONTROL_IDENTIFIER. The function returns the ListBox ID
on success, 1 otherwise.
ac.addItem(<CONTROL_IDENTIFIER>,<NAME>)
<CONTROL_IDENTIFIER> must be a ListBox identifier. This method adds a List Box item to the List Box specified. The item's label is specified by the Name string.
This function returns the ListBox Item ID on success, 1 otherwise.

663
ac.removeItem(<CONTROL_IDENTIFIER>,<ID>)
<CONTROL_IDENTIFIER> must be a ListBox identifier. This method removes from the List Box the item with ID as identifier. This function returns the size of the List Box on
success, 1 otherwise.
ac.getItemCount(<CONTROL_IDENTIFIER>)
<CONTROL_IDENTIFIER> must be a ListBox identifier. This function returns the size of the List Box on success, 1 otherwise.
ac.setItemNumberPerPage(<CONTROL_IDENTIFIER>,<NUMBER>)
<CONTROL_IDENTIFIER> must be a ListBox identifier, <NUMBER> is the number of element to be displayed desired for each page. This function sets the number of
elements displayed for each page in a List Box. This function returns 1 on success, 1 otherwise
ac.highlightListBoxItem(<CONTROL_IDENTIFIER>,<ID>)
<CONTROL_IDENTIFIER> must be a ListBox identifier, <ID> is the element to be selected. This function sets the list box item with <ID> as identifier as selected. This function
returns 1 on success, 1 otherwise
ac.addOnListBoxSelectionListener(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined inside the Python script. Control identifier must be a List Box controller otherwise the function does nothing and returns 0.
This method set the <VALUE> function as callback function for the event of item SELECTION inside a ListBox. The callback function receives as input parameters the Item's
NAME and its ID (his position inside the listbox). The function returns 1 on success, 1 otherwise
ac.addOnListBoxDeselectionListener(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined inside the Python script. Control identifier must be a List Box controller otherwise the function does nothing and returns 0.
This method set the <VALUE> function as callback function for the event of item DESELECTION inside a ListBox. The callback function receives as input parameters the Item's
NAME and its ID (his position inside the listbox). The function returns 1 on success, 1 otherwise
ac.setAllowDeselection(<CONTROL_IDENTIFIER>,<ALLOW_DESELECTION>)
<CONTROL_IDENTIFIER> must be a ListBox identifier, <ALLOW_DESELECTION> must be 0 or 1. Passing true as a parameter, when the user clicks on a selected item the
item is deselected. In this way there could be 0 or 1 selected item at a given time. If also ac.setAllowMultiSelection is set as true there can be more than 1 selected items at a
given time. This function returns 1 on success, -1 otherwise
ac.setAllowMultiSelection(<CONTROL_IDENTIFIER>,<ALLOW_MULTI_SELECTION>)
<CONTROL_IDENTIFIER> must be a ListBox identifier, <ALLOW_MULTI_SELECTION> must be 0 or 1. Passing true as a parameter, when the user clicks on a different item
the item is added to the selected item list. In this way there could me more than one selected items at a given time. This function returns 1 on success, 1 otherwise.
ac.getSelectedItems(<CONTROL_IDENTIFIER>)
<CONTROL_IDENTIFIER> must be a ListBox identifier. This method returns the list of the selected items at a given time. This function returns a Python list of Long on
success, 1 otherwise.

Check Box:
ac.addCheckBox(<CONTROL_IDENTIFIER>,<VALUE>)
<CONTROL_IDENTIFIER> must be a form ,<VALUE> must be the form’s name. This function adds a checkbox to the current form passed as <CONTROL_IDENTIFIER>.
The function returns the checkbox created on success, 1 otherwise.
ac.addOnCheckBoxChanged(<CONTROL_IDENTIFIER>, <VALUE>)
<VALUE> must be a function name defined inside the Python script. Control identifier must be a Check Box controller otherwise the function does nothing and returns 0.
This method set the <VALUE> function as callback function for the event of checkbox SELECTION or DESELECTION inside a ListBox. The callback function receives as input
parameters the CheckBox's NAME and its value, 1 if selected, 1 otherwise. The function returns 1 on success, 1 otherwise.

Text Box:
ac.addTextBox(<CONTROL_IDENTIFIER>,<NAME>)
<CONTROL_IDENTIFIER> form identifier, <NAME> text box name. This method adds a text box (scrollable if the text is longer than the textbox, to the current form.
THIS CONTROL IS NOT CURRENTLY WORKING YET, so no set text has been exposed

GRAPHICS AND RENDERING:

ac.newTexture(<PATH>)
<PATH> must be a string, the path is considered from AC installation directory. This method loads in memory the texture specified by path. This method returns the texture
identifier on success, 1 otherwise.
ac.glBegin(<PRIMITIVE_ID>)
<PRIMITIVE_ID> must be an int corresponding to the following ints:
0 : Draw lines
1 : Draw lines Strip
2 : Draw triangles
3 : Draw quads.
Begin a rendering of the specified type. This function returns 1 on success, 1 otherwise
ac.glEnd(void)
Finishes the render of a previous specified primitive. This function returns 1 on success.
ac.glVertex2f(<X>,<Y>)
<X>,<Y> must be floating point numbers. Adds a 2d point to the rendering queue. This function returns 1 on success, 1 otherwise.
ac.glColor3f(<R>,<G>,<B>)
<R>,<G>,<B> rgb coordinates scaled from 0 to 1, must be floating point numbers set the current rendering color to <R>,<G>,<B> color. This function returns 1 on success, 1
otherwise.

664
ac.glColor4f(<R>,<G>,<B>,<A>)
<R>,<G>,<B> rgb coordinates scaled from 0 to 1, <A> alpha component from 0 to 1, all the values must be a floating point numbers set the current rendering color to
<R>,<G>,<B> color, with <A> as transparency. This function returns 1 on success, 1 otherwise.
ac.glQuad(<X>,<Y>,<WIDTH>,<HEIGHT>)
<X>,<Y>,<WIDTH>,<HEIGHT> must be a floating point numbers draw a quad quickly without using glBegin, … , glEnd This function returns 1 on success, 1 otherwise
ac.glQuadTextured(<X>,<Y>,<WIDTH>,<HEIGHT>,<TEXTURE_ID>)
<X>,<Y>,<WIDTH>,<HEIGHT> must be a floating point numbers, <TEXTURE_ID> is the id of the texture previously loaded. draw a quad quickly without using glBegin, … ,
glEnd This function returns 1 on success, 1 otherwise

new in this document as of 2020:

ac.isAcLive() as bool
ac.restart()
ac.isCarInPitlane() as bool # same as ac.isCarInPitline()
ac.getCarSkin(carID) as string
ac.getDriverNationCode(carID) as string
ac.getCurrentSplits(carID) as List
ac.getTrackLength(carID) as float
ac.getWindSpeed() as float
ac.getWindDirection() as float
ac.isAIControlled() as bool
ac.getCarEngineBrakeCount() as int
ac.getCarPowerControllerCount() as int
ac.freeCameraSetClearColor(r, g, b, alpha)
ac.freeCameraMoveForward(float)
ac.freeCameraMoveRight(float)
ac.freeCameraMoveUpWorld(float)
ac.freeCameraRotatePitch(float)
ac.freeCameraRotateHeading(float)
ac.freeCameraRotateRoll(float)
ac.sendChatMessage(string_msg)
ac.addOnChatMessageListener(ac_WindowID, callBackFunction)

ac.getCarRestrictor

ac.getCarTyreCompound

ac.getSize

ac.setAppTitle

ac.setFont

ac.shutdown

CustomShadersPatch adds more python funtions, see https://github.com/ac-custom-shaders-patch/acc-extension-

config/wiki/Python-Apps-%E2%80%93-New-functions

665
AC Shared Memory Documentation (another piece of the puzzle is here ;-D)
SPageFileStatic
The following members are initialized when the instance starts and never changes until the instance is closed.
wchar_t smVersion[15] ; Version of the Shared Memory structure
wchar_t acVersion[15] ; Version of Assetto Corsa
int numberOfSessions = 0 ; Number of sessions in this instance
int numCars = 0 ; Max number of possible cars on track
wchar_t carModel[33] ; Name of the player’s car
wchar_t track[33] ; Name of the track
wchar_t playerName[33] ; Name of the player
wchar_t playerSurname[33] ; Surname of the player
wchar_t playerNick[33] ; Nickname of the player
int sectorCount = 0 ; Number of track sectors
float maxTorque = 0 ; Max torque value of the player’s car
float maxPower = 0 ; Max power value of the player’s car
int maxRpm = 0 ; Max rpm value of the player’s car
float maxFuel = 0 ; Max fuel value of the player’s car
float suspensionMaxTravel[4] ; Max travel distance of each tyre [Front Left, Front Right, Rear Left, Rear Right]
float tyreRadius[4] ; Radius of each tyre [Front Left, Front Right, Rear Left, Rear Right]
float maxTurboBoost = 0 ; Max turbo boost value of the player’s car
float deprecated_1 ; Do not use it
float deprecated_2 ; Do not use it
int penaltiesEnabled = 0 ; Cut penalties enabled: 1 (true) or 0 (false)
float aidFuelRate = 0 ; Fuel consumption rate: 0 (no cons), 1 (normal), 2 (double cons) etc.
float aidTireRate = 0 ; Tire wear rate: 0 (no wear), 1 (normal), 2 (double wear) etc.
float aidMechanicalDamage = 0 ; Damage rate: 0 (no damage) to 1 (normal)
int aidAllowTyreBlankets = 0 ; Player starts with hot (optimal temp) tyres: 1 (true) or 0 (false)
float aidStability = 0 ; Stability aid: 0 (no aid) to 1 (full aid)
int aidAutoClutch = 0 ; If player’s car has the “auto clutch” feature enabled : 0 or 1
int aidAutoBlip = 0 ; If player’s car has the “auto blip” feature enabled : 0 or 1
int hasDRS = 0 ; If player’s car has the “DRS” system: 0 or 1
int hasERS = 0 ; If player’s car has the “ERS” system: 0 or 1
int hasKERS = 0 ; If player’s car has the “KERS” system: 0 or 1
float kersMaxJ = 0 ; Max KERS Joule value of the player’s car
int engineBrakeSettingsCount = 0 ; Count of possible engine brake settings of the player’s car
int ersPowerControllerCount = 0 ; Count of the possible power controllers of the player’s car
float trackSPlineLength = 0 ; Length of the spline of the selected track
wchar_t trackConfiguration[33] ; Name of the track’s layout (only multi-layout tracks)
float ersMaxJ = 0 ; Max ERS Joule value of the player’s car
int isTimedRace = 0 ; 1 if the race is a timed one
int hasExtraLap = 0 ; 1 if the timed race is set with an extra lap
wchar_t carSkin[33] ; Name of the used skin
int reversedGridPositions ; How many positions are going to be swapped in the second race
int PitWindowStart ; Pit window is open on Lap/Minute
int PitWindowEnd ; Pit window is closed on Lap/Minute

SPageFilePhysics
The following members change at each graphic step. They all refer to the player’s car.
int packetId = 0 ; Index of the shared memory’s current step
float gas = 0 ; Value of gas pedal: 0 to 1 (fully pressed)
float brake = 0 ; Value of brake pedal: 0 to 1 (fully pressed)
float fuel = 0 ; Liters of fuel in the car
int gear = 0 ; Selected gear (0 is reverse, 1 is neutral, 2 is first gear)
int rpms = 0 ; Value of rpm
float steerAngle = 0 ; Angle of steer
float speedKmh = 0 ; Speed in Km/h
float velocity[3] ; Velocity for each axis (world related) [x, y, z]
float accG[3] ; G-force for each axis (local related) [x, y, z]
float wheelSlip[4] ; Spin speed of each tyre [Front Left, Front Right, Rear Left, Rear Right]
float wheelLoad[4] ; Load on each tyre (in N) [Front Left, Front Right, Rear Left, Rear Right]
float wheelsPressure[4] ; Pressure of each tyre [Front Left, Front Right, Rear Left, Rear Right]
float wheelAngularSpeed[4] ; Angular speed of each tyre [Front Left, Front Right, Rear Left, Rear Right]
float tyreWear[4] ; Current wear of each tyre [Front Left, Front Right, Rear Left, Rear Right]
float tyreDirtyLevel[4] ; Dirt level on each tyre [Front Left, Front Right, Rear Left, Rear Right]
float tyreCoreTemperature[4] ; Core temperature of each tyre [Front Left, Front Right, Rear Left, Rear Right]
float camberRAD[4] ; Camber of each tyre in Radian [Front Left, Front Right, Rear Left, Rear Right]
float suspensionTravel[4] ; Suspension travel for each tyre [Front Left, Front Right, Rear Left, Rear Right]
float drs = 0 ; If DRS is present and enabled: 0 (false) or 1 (true)
float tc = 0 ; Slip ratio limit for the traction control (if enabled)
float heading = 0 ; Heading of the car on world coordinates
float pitch = 0 ; Pitch of the car on world coordinates
float roll = 0 ; Roll of the car on world coordinates
float cgHeight ; Height of Center of Gravity
float carDamage[5] ; Level of damage for each car section (only first 4 are valid)
int numberOfTyresOut = 0 ; How many tyres are allowed to stay out of the track to not receive a penalty
int pitLimiterOn = 0 ; If pit limiter is enabled: 0 (false) or 1 (true)
float abs = 0 ; Slip ratio limit for the ABS (if enabled)
float kersCharge = 0 ; KERS/ERS battery charge: 0 to 1
float kersInput = 0 ; KERS/ERS input to engine: 0 to 1
int autoShifterOn = 0 ; If auto shifter is enabled: 0 (false) or 1 (true)
float rideHeight[2] ; Right heights: front and rear
float turboBoost = 0 ; Turbo boost
float ballast = 0 ; Kilograms of ballast added to the car (only in multiplayer)
float airDensity = 0 ; Air density
float airTemp = 0 ; Ambient temperature
float roadTemp = 0 ; Road temperature
float localAngularVel[3] ; Angular velocity of the car [x, y, z]
float finalFF = 0 ; Current Force Feedback value;
float performanceMeter = 0 ; Performance meter compared to the best lap
int engineBrake = 0 ; Engine brake setting
int ersRecoveryLevel = 0 ; ERS recovery level

666
int ersPowerLevel = 0
int ersHeatCharging = 0
int ersIsCharging = 0
float kersCurrentKJ = 0
int drsAvailable = 0
int drsEnabled = 0
float brakeTemp[4]
float clutch = 0
float tyreTempI[4]
float tyreTempM[4]
float tyreTempO[4]
int isAIControlled
float tyreContactPoint[4][3]
float tyreContactNormal[4][3]
float tyreContactHeading[4][3]
float brakeBias
float localVelocity[3]
struct SPageFileGraphic
The following members change at each graphical step. They all refer to the player’s car.
int packetId = 0
AC_STATUS status = AC_OFF
AC_SESSION_TYPEsession =AC_PRACTICE
AC_TIME_ATTACK 4; AC_DRIFT 5; AC_DRAG 6
wchar_t currentTime[15]
wchar_t lastTime[15]
wchar_t bestTime[15]
wchar_t split[15]
int completedLaps = 0
int position = 0
int iCurrentTime = 0
int iLastTime = 0
int iBestTime = 0
float sessionTimeLeft = 0
float distanceTraveled = 0
int isInPit = 0
int currentSectorIndex = 0
int lastSectorTime = 0
int numberOfLaps = 0
wchar_t tyreCompound[33]
float replayTimeMultiplier = 0
float normalizedCarPosition = 0
float carCoordinates[3]
float penaltyTime = 0
AC_FLAG_TYPEflag =AC_NO_FLAG
3; AC_WHITE_FLAG 4; AC_CHECKERED_FLAG 5; AC_PENALTY_FLAG 6
int idealLineOn = 0
int isInPitLane = 0
float surfaceGrip = 0
int mandatoryPitDone = 0
float windSpeed = 0
float windDirection = 0
SHARED MEMORY NAMES
physics : acpmf_physics
graphics : acpmf_graphics
static : acpmf_static
SHARED MEMORY EXAMPLE in attachment
; ERS selected power controller
; ERS changing: 0 (Motor) or 1 (Battery)
; If ERS battery is recharging: 0 (false) or 1 (true)
; KERS/ERS KiloJoule spent during the lap
; If DRS is available (DRS zone): 0 (false) or 1 (true)
; If DRS is enabled: 0 (false) or 1 (true)
; Brake temp for each tire [Front Left, Front Right, Rear Left, Rear Right]
; Value of clutch pedal: 0 to 1 (fully pressed)
; Inner temperature of each tyre [Front Left, Front Right, Rear Left, Rear Right]
; Middle temperature of each tyre [FL, FR, RL, RR]
; Outer temperature of each tyre [FL, FR, RL, RR]
; AI controlled car: 0 (human) or 1 (AI)
; Vector for contact point of each tyre [FL, FR, RL, RR][x, y, z]
; Vector for contact normal of each tyre [FL, FR, RL, RR][x, y, z]
; Vector for contact heading of each tyre [FL, FR, RL, RR][x, y, z]
; Brake bias from 0 (rear) to 1 (front)
; Vector for local velocity
; Index of the shared memory’s current step
; Status of the instance: AC_OFF 0; AC_REPLAY 1; AC_LIVE 2; AC_PAUSE 3
; Session type: AC_UNKNOWN -1; AC_PRACTICE 0¸AC_QUALIFY 1; AC_RACE 2; AC_HOTLAP 3;
; Current lap time
; Last lap time
; Best lap time
; Time in sector
; Number of completed laps by the player
; Current player position (standings)
; Current lap time
; Last lap time
; Best lap time
; Time left until session is closed
; Distance traveled during the instance
; If player’s car is stopped in the pit: 0 (false) or 1 (true)
; Current sector index
; Last sector time
; Number of laps needed to close the session
; Current tyre compound
; Replay multiplier
; Car position on the track’s spline
; Car position on world coordinates [x, y, z]
; Time of penalty
; Type of flag being shown: AC_NO_FLAG 0; AC_BLUE_FLAG 1; AC_YELLOW_FLAG 2; AC_BLACK_FLAG
; If ideal line is enabled: 0 (false) or 1 (true)
; If player’s car is in the pitlane: 0 (false) or 1 (true)
; Current grip of the track’s surface
; Set to 1 if the player has done the mandatory pit
; Speed of the wind on the current session
; Direction of the wind (0-359 degrees) on the current session
667
AC UDP Remote Telemetry Documentation
AC supports remote telemetry via UDP (User Datagram Protocol) socket. It is possible to make your application read real time telemetry data from AC
following this document.
All the code samples follow the C++ syntax and can be made with Visual Studio Editor. The PC running Assetto Corsa will be referred as the ACServer, and
the Remote Telemetry Server will be referred to as RTS. The data types are the following:
• int are 32-bit little endian integers
• float are 32-bit floating point numbers
• bool are 8-bit boolean values

1.0 - Connect to AC via UDP for Remote Telemetry: Handshake

1.1 - Client to AC RTS communication procedure
The handshake process to connect and receive Remote Telemetry data from Assetto Corsa via UDP works as follows: your app first must create an UDP socket
and connect to a PC address running Assetto Corsa (ACServer). The connection port number is 9996.
Your application must send a structured data using the following format:
structhandshaker{
intidentifier;
intversion;
intoperationId;
};

where:
• intidentifier: not used in the current Remote Telemetry version by AC. In future versions it will identify the platform type of the client. This will be used to adjust a
specific behaviour for each platform:
eIPhoneDevice =0
eIPadDevice =1
eAndroidPhone =2
eAndroidTablet =3
• intversion: not used in the current Remote Telemetry version by AC. In future version this field will identify the AC Remote Telemetry version that the device expects
to speak with.
• intoperationId: this is the type of operation required by the client.

The following operations are now available:

• HANDSHAKE = 0; this operation identifier must be set when the client wants to start the communication
• SUBSCRIBE_UPDATE = 1; this operation identifier must be set when the client wants to be updated from the specific ACServer
• SUBSCRIBE_SPOT = 2; this operation identifier must be set when the client wants to be updated from the specific ACServer just for SPOT Events (e.g.: the end of a lap)
• DISMISS = 3; this operation identifier must be set when the client wants to leave the communication with ACServer

In summary, for the first handshaking phase your application will need to send the following structured data to ACServer:
structhandshaker;
handshaker.identifier = 1 ;
handshaker.version = 1 ;
handshaker.operationId= 0 ;

1.2 - AC RTS responds to the client

After sending the structured data in paragraph 1.1, your application will receive the following struct as response:
structhandshackerResponse{
charcarName[50];
chardriverName[50];
intidentifier;
intversion;
chartrackName[50];
chartrackConfig[50];
};

where:
• charcarName[50]: is the name of the car that the player is driving on the AC Server
• chardriverName[50]: is the name of the driver running on the AC Server
• intidentifier: for now is just 4242, this code will identify different status, as “NOT AVAILABLE” for connection
• intversion: for now is set to 1, this will identify the version running on the AC Server
• chartrackName[50]: is the name of the track on the AC Server
• chartrackConfig[50]: is the track configuration

Your application will need to parse this structured data in order to get the information. This step is necessary to understand which driver we’re connecting to.

1.3 - AC Client confirms connection

Again the client must send the following structured data, the same from paragraph 1.1:
structhandshaker{
intidentifier;
intversion;
intoperationId;
};

668
Now, operationId must be one of the following options: SUBSCRIBE_UPDATE = 1 or SUBSCRIBE_SPOT = 2 (see paragraph 1.1).
After this phase the Client is added as a listener to AC Remote Telemetry listeners.

2.0 - ACServer updating clients

For each physics step, ACServer will call the update function to all the listeners. If the client subscribed himself with SUBSCRIBE_UPDATE identifier, it will
receive the following structured data:
structRTCarInfo
{
charidentifier;
int size;
floatspeed_Kmh;
floatspeed_Mph;
floatspeed_Ms;
boolisAbsEnabled;
boolisAbsInAction;
boolisTcInAction;
boolisTcEnabled;
boolisInPit;
boolisEngineLimiterOn;
floataccG_vertical;
floataccG_horizontal;
floataccG_frontal;
int lapTime;
int lastLap;
int bestLap;
int lapCount;
floatgas;
floatbrake;
floatclutch;
floatengineRPM;
floatsteer;
intgear;
floatcgHeight;
floatwheelAngularSpeed[4];
floatslipAngle[4];
floatslipAngle_ContactPatch[4];
floatslipRatio[4];
floattyreSlip[4];
floatndSlip[4];
floatload[4];
floatDy[4];
floatMz[4];
floattyreDirtyLevel[4];
floatcamberRAD[4];
floattyreRadius[4];
floattyreLoadedRadius[4];
floatsuspensionHeight[4];
floatcarPositionNormalized;
floatcarSlope;
floatcarCoordinates[3];
} ;

• charidentifier: is set to char “ a ” , it is used to understand that the structured data is the data that the client app wants
• int size: the size of the structured data in Bytes.

If the client subscribed himself with SUBSCRIBE_SPOT identifier, it will receive the following structured data whenever a spot event is triggered (for example for the end of a
lap).
Differently from SUBSCRIBE_UPDATE, this event will interest all the cars in the AC session:
structRTLap
{
intcarIdentifierNumber;
intlap;
chardriverName[50];
charcarName[50];
inttime;
};

Your application will need to parse locally the structured data sent by ACServer.

3.0 - Dismissing an AC Client

A client to dismiss itself it must send the following package (the same from paragraph 1.1):
structhandshaker{
intidentifier;
intversion;
intoperationId;
};

with DISMISS = 3 as operationId.

The client will be removed from the listeners, ACServer will forget about him and no more updates will be sent to it.
To connect again, do again the steps from paragraph 1.1 or 1.2.

669
670
 ENDING
Let’s go back to a simpler time.

This is the conclusion, I believe. Am I right?

The truth? None of us are experienced enough at modding Assetto Corsa. That being said, it's not rocket science.

Modding is just like any other hobby, only you are trying to finish something. You can have passions like karate, mountain biking, scale models, beer drinking
or bowling just for fun without any goals and you never need to finish anything. There is no end product. In modding you want to create something. Starting
things is easy. Finishing things is difficult.

Like with all hobbies, as time goes by, you can lose interest. Maybe you get into a situation where it is less fun and more work and you just don't feel like
doing it anymore. Or you continue "later", that becomes “never”. Your life schedule changes and you have less time and/or energy to keep learning complex
software. Maybe you just found something else that is more fun. I don't really see anything mysterious about it. How many times did you start something and
never finished it?

I think a huge part is about problem solving. The documentation and the tools are never perfect and with some games they are downright appalling. To
conclude something, you need to learn how specific game wants things and how its features work, what different parameters mean and what works, what is
deprecated or disabled and the different ways to get a result.

That’s why this book details what’s important. All the info you need is at your fingertips.

But even with good documentation and tools, there are steps along the way where complexity ramps up. I think they are:

• Problems that just seem like they can’t be solved. Maybe the car won't load into the game, some feature just doesn't work and you can’t find any information about it. You
keep trying and get more and more desperate and negative as you go. Eventually it feels like waste of time. It is not necessarily a problem that stops all work but it puts a
big barrier on your willingness to keep going. In the end it is not fun anymore.
• When you figure out something you need to do, and notice it is long hours of tedious work, you may just lose interest. This could be things like splitting your mesh into
different materials and UV maps. Doing this first time is difficult because you don't really know how to do it. You really need to get through the process at least once from
beginning to end so you know how it works and comes together. This can be a huge problem if you want to work so that you are 100% finished with one thing before
moving to the next thing. Especially if you are not experienced you need to go back and forth constantly, sometimes doing some things multiple times to get it right.
• Having to learn new software. If you want to make a car you need your 3D modeler and some kind of texture painting software. You need to learn how different DDS files
work and their settings. You have some smaller tools you may use for normal mapping, font creation. If you make a track from Lidar you need to learn to use software that
handles the point cloud data. Even inside the 3D software there are many different sections that are almost like separate programs. For physics you need to find some kind
of suspension program and learn to use spreadsheet program.
• If you are beginner at everything you need lots of time and will power to learn all of that from scratch. You need to learn how to search for textures and references. Good
quality reference takes time to find. A 400x320 pixel blurry picture of a car going around a corner is not reference. And every time you need to find one image of something
you need to have the persistence of mind to go to internet and find just that image and then get back to work instead of going to relax on forums writing long posts or
watching cat videos on YouTube.

I don't think any car or track mod project gets abandoned because the scaling is wrong or pivots are wrong. Any person who has that low level of modding
pain tolerance never had the passion to keep working on it. It is the smaller and bigger things that from outside are almost invisible.

You want a deeper truth? Watching video tutorials on the internet will not make you learn anything. In an attempt to try and show an “idiot” a method to
solve a problem under ten minutes, they take the shortest possible route to give a solution, with shortcuts that sometimes do not turn out to be such, and
they do not give a reason for what they do, but remain at the level of a parrot who only knows how to repeat the same procedure over and over again. While
this may actually work for an ”idiot” as long as he doesn’t forget it, the one who wants to evolve to produce something useful and satisfying for himself and
others will always fall behind. It would take hours to prepare a comprehensive and non-redundant speech, but even if it were redundant, a speech that can
teach. Revealing how much and how one can go wrong is more difficult.

Having the desire is not enough. Life is hard. So, experiment away, expect it to go wrong loads of times, and eventually you will know what works for you
the way you do it. This will make you far more powerful as a modder.

Travel, sail, fly. And fight! Be filled with Determination.

I am truly, deeply happy, because I can say that I made the very first manual for AC. Being the first, it’s also the best out there! And I am the last one to
laugh. Those few who participated to the story of this project will know what I mean.

You’ll probably still have an army of questions. You’re not alone, there are many others. But I can’t answer now.

This is Farewell.

671
672
 APPENDIX 1:

CAR LIST

673
674
 Follows the list of all the official cars present in Assetto Corsa 1.16.4 Ultimate Edition. For those who didn’t buy the full package, the DLCs are mentioned where present 94.

ABARTH
595 SS 595 SS Step 1 595 SS Step 2

Year: 1964 Year: 1964 Year: 1964

Power: 32 hp / Power: 32 hp / Power: 65 hp /
Torque: 38 Nm/3500 RPM Torque: 40 Nm/5000 RPM Torque: 70 Nm/5500 RPM
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
500 EsseEsse 500 EsseEsse Step 1 500 Assetto Corse

Year: 2008 Year: 2008 Year: 2009

Power: 160 hp / Power: 175 hp / Power: 195 hp /
Torque: 230 Nm/ Torque: 245 Nm/ Torque: 302 Nm/3000 RPM
Max speed: 211 km/h Max speed: Max speed: 225 km/h
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):h

ALFA ROMEO
Giulia Sprint GTA 33 Stradale Scaglione Prototipo 4C

Year: 1965 Year: 1967 Year: 2013

Power: 170 hp / Power: 230 hp / Power: 240 hp /
Torque: Torque: 206 Nm Torque: 350 Nm
Max speed: Max speed: 260 km/h Max speed: 245 km/h
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
MiTo Quadrifoglio Verde Giulietta QV Giulietta QV Launch Edition

Year: 2012 Year: 2014 Year: 2014

Power: 168 hp / Power: 235 hp / Power: 240 hp /
Torque: 250 Nm Torque: 349 Nm Torque:
Max speed: 219 km/h Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

94
Although most data here is taken from the in-game vehicle specifications, some values have been corrected and added where needed. Car info is often incomplete or wrong in Assetto Corsa!

675
 Giulia QV 155 V6 Ti

Year: 2016 Year: 1993

Power: 510 hp / Power: 420 hp /
Torque: 600 Nm Torque: 294 Nm
Max speed: 307 km/h Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h):

AUDI
R8 V10 Plus R8 LMS ULTRA 2014 R8 LMS 2016

Year: 2007 Year: 2009 Year: 2016

Power: 550 hp / Power: 570 hp / Power: 500 hp /
Torque: 540 Nm Torque: Torque:
Max speed: 317 km/h Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
Sport Quattro Sport Quattro S1 Sport quattro S1 Evo 2 Group B

Year: 1983 Year: 1984 Year: 1985

Power: 306 hp / Power: 373 hp / Power: 540 hp /
Torque: 350 Nm Torque: 425 Nm Torque:
Max speed: 250 km/h Max speed: 272 km/h Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
TT RS (VLN) TT Cup S1 quattro

Year: 2015 Year: 2016 Year: 2015

Power: 390 hp / Power: 310 hp / Power: 231 hp /
Torque: Torque: Torque: 370 Nm
Max speed: Max speed: Max speed: 241 km/h
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

676
 R18 E-Tron Quattro RP4 2014

Year: 2014
Power:
Torque:
Max speed:
Acceleration (0-100 km/h):

BMW
1 Series M Coupé (E82) 1 Series M Coupé (E82) Step 3 M235i Racing GT4

Year: 2004 Year: 2004 Year: 2014

Power: 340 hp / Power: 400 hp / Power: 333 hp /
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
M4 Coupé M4 Coupé Akrapovič Edition M3 GT2

Year: 2015 Year: 2015 Year: 2009

Power: 431 hp / Power: 445 hp / Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
M3 E30 M3 E30 Drift M3 E30 Step 1

Year: 1986 Year: 1986 Year: 1986

Power: 238 hp / Power: 343 hp / Power: 238 hp /
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

677
 M3 E30 Group A M3 E30 Group A DTM M3 E92

Year: 1986 Year: 1992 Year: 2015

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
M3 E92 Drift M3 E92 Step 1 Z4 E89 35is

Year: 2015 Year: 2015 Year: 2009

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
Z4 E89 35is Drift Z4 E89 35is Step 1 Z4 GT3

Year: 2009 Year: 2009 Year: 2010

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

CHEVROLET
Corvette C7 Stingray Z51 Corvette C7.R GTE

Year: 2014 Year: 2015

Power: Power:
Torque: Torque:
Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h):

678
CLASSIC TEAM LOTUS
Type 25 Type 49 72D

Year: 1962 Year: 1967 Year: 1970

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
98T

Year: 1986
Power:
Torque:
Max speed:
Acceleration (0-100 km/h):

FERRARI
250 GTO 330 P4 312/67

Year: 1962 Year: 1967 Year: 1967

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
F312T 288 GTO F40

Year: 1975 Year: 1984 Year: 1987

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

679
 F40 S3 F2004 458 Italia

Year: 1987 Year: 2004 Year: 2011

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
458 Italia S3 458 GT2 488 GTB

Year: 2011 Year: 2011 Year: 2015

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
488 GT3 599XX EVO 812 Superfast

Year: 2011 Year: 2012 Year: 2017

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
F138 SF15-T SF70H

Year: 2013 Year: 2015 Year: 2017

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

680
 LaFerrari FXX K

Year: 2015 Year: 2015

Power: Power:
Torque: Torque:
Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h):

FORD
GT40 MK I Escort RS 1600 Mustang GT

Year: 1966 Year: 1973 Year: 2015

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

KTM
X-Bow R

Year: 2008
Power:
Torque:
Max speed:
Acceleration (0-100 km/h):

681
LAMBORGHINI
Miura P400 SV Countach 5000 QuattroValvole Countach Step 1

Year: 1966 Year: 1983 Year: 1983

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
Huracan LP 640-2 Super Trofeo Huracan LP 640-4 Performante Huracan GT3

Year: 2014 Year: 2014 Year: 2015

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
Gallardo LP 570-4 SuperLeggera Gallardo LP 570-4 SL Step 3 Aventador LP 750-4 Super Veloce

Year: 2007 Year: 2007 Year: 2015

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
Sesto elemento

Year: 2011
Power:
Torque:
Max speed:
Acceleration (0-100 km/h):

682
LOTUS
Evora GTE Evora GTE Carbon Evora GX

Year: 2014 Year: 2014 Year: 2014

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

Evora GTC Evora S Evora S Stage 2

Year: 2014 Year: 2014 Year: 2014

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
Elise SC Elise SC Step 1 Elise SC Step 2

Year: 2008 Year: 2008 Year: 2008

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
Exige S Exige S Roadster Exige Scura

Year: 2012 Year: 2013 Year: 2009

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

683
 Exige 240R Exige 240R Stage 3 Exige V6 CUP

Year: 2008 Year: 2008 Year: 2013

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
2-Eleven 2-Eleven GT4 Supersport 3-Eleven

Year: 2007 Year: 2007 Year: 2015

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
Exos T125 Exos T125 S1

Year: 2010 Year: 2010

Power: Power:
Torque: Torque:
Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h):

MASERATI
250F 6C 250F T2 12C Levante S

Year: 1954 Year: 1957 Year: 2016

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

684
 Granturismo MC GT4 Quattroporte GTS Alfieri Concept

Year: 2016 Year: 2013 Year: 2014

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
MC12 GT1

Year: 2004
Power:
Torque:
Max speed:
Acceleration (0-100 km/h):

MAZDA
Miata MX-5 NA MX5 ND MX5 ND Cup

Year: 1990 Year: 2015 Year: 2016

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
RX-7 FD Spirit R Type A RX-7 FD Spirit R Type A Tuned 787B

Year: 2002 Year: 2002 Year: 1990

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

685
McLAREN
F1 GTR MP4 – 12C MP4 – 12C GT3

Year: 1995 Year: 2011 Year: 2011

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
P1 P1 GTR 570S

Year: 2013 Year: 2015 Year: 2015

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
650S GT3

Year: 2014
Power:
Torque:
Max speed:
Acceleration (0-100 km/h):

MERCEDES-BENZ
190E 2.5-16 EVO II Sauber C9 LM SLS AMG

Year: 1990 Year: 1989 Year: 2009

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

686
 SLS AMG GT3 AMG GT3

Year: 2009 Year: 2015

Power: Power:
Torque: Torque:
Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h):

NISSAN
Skyline GT-R R34 V-Spec GT-R NISMO (R35) GT-R NISMO GT3 (R35)

Year: 1997 Year: 2015 Year: 2014

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
Z34 370Z NISMO

Year: 2016
Power:
Torque:
Max speed:
Acceleration (0-100 km/h):

PAGANI
Huayra Huayra BC Zonda R

Year: 2012 Year: 2016 Year: 2009

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

687
PORSCHE
718 RS 60 Spyder 908/01 Coupé Langheck 917 K

Year: 1960 Year: 1968 Year: 1970

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
917/30 Spyder 911 Carrera RSR 3.0 935/78 “Moby Dick”

Year: 1973 Year: 1974 Year: 1978

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
962C Short Tail 962C Long Tail 911 GT1-98

Year: 1984 Year: 1987 Year: 1998

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
911 Carrera S 911 R 911 Turbo S

Year: 2015 Year: 2016 Year: 2015

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

688
 911 GT3 RS 911 GT3 R 911 GT3 Cup

Year: 2015 Year: 2016 Year: 2017

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
911 GT3 RSR 718 Boxster S (manual) 718 Boxster S PDK (semiautomatic)

Year: 2017 Year: 2016 Year: 2016

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
718 Cayman S Cayman GT4 Cayman GT4 Clubsport

Year: 2016 Year: 2015 Year: 2015

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):
918 Spyder (Weissach Package) Panamera Turbo Macan Turbo

Year: 2014 Year: 2016 Year: 2014

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

689
 Cayenne Turbo S 919 Hybrid 2015 919 Hybrid 2016

Year: 2015 Year: 2015 Year: 2016

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

PRAGA
R1

Year: 2012
Power:
Torque:
Max speed:
Acceleration (0-100 km/h):

RUF
CTR Yellowbird RT 12R RWD RT 12 R AWD

Year: 1987 Year: 2011 Year: 2011

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

SCUDERIA GLICKENHAUS
P4/5 Competizione SCG 003C

Year: 2011 Year: 2015

Power: Power:
Torque: Torque:
Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h):

690
SHELBY
Cobra 427 S/C

Year: 1966
Power:
Torque:
Max speed:
Acceleration (0-100 km/h):

TATUUS
FA01 (Formula Abarth)

Year: 2010
Power:
Torque:
Max speed:
Acceleration (0-100 km/h):

TOYOTA
AE-86 TRUENO AE-86 Drift AE-86 Tuned

Year: 1983 Year: 1983 Year: 1983

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

JZA80 Supra MKIV JZA80 Supra MKIV Drift JZA80 Supra Time Attack

Year: 1993 Year: 1993 Year: 1993

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

691
 GT-86 Celica GT-Four WRC (ST 185) 4WD Turbo TS 040 Hybrid

Year: 2015 Year: 1992 Year: 2014

Power: Power: Power:
Torque: Torque: Torque:
Max speed: Max speed: Max speed:
Acceleration (0-100 km/h): Acceleration (0-100 km/h): Acceleration (0-100 km/h):

692
 APPENDIX II

All the images of this appendix come from AC, not from real life.

Autodromo dell’Umbria – Magione (BASEGAME)

Autodromo Internazionale Enzo e Dino Ferrari – Imola (BASEGAME)

Autodromo Internazionale del Mugello (BASEGAME)

Autodromo Nazionale di Monza (four layouts, including three historic 1966 configurations) (BASEGAME)

Autodromo Piero Taruffi – Vallelunga (three layouts) (BASEGAME)

Black Cat County (three layouts) (BASEGAME)

Brands Hatch (two layouts) (DREAM PACK 3 DLC)

Circuit de Barcelona-Catalunya – Barcelona (two layouts) (DREAM PACK 2 DLC)

Circuit de Spa-Francorchamps (BASEGAME)

Circuit Park Zandvoort (BASEGAME)

Drag Strip (five layouts) (BASEGAME)

Drift (BASEGAME)

693
Highlands (four layouts) (BASEGAME)

HIGHLANDS

694
Laguna Seca (BASEGAME)

695
Nürburgring (four layouts) (BASEGAME)

Nürburgring Nordschleife (four layouts) (DREAM PACK 1 DLC)

Red Bull Ring (two circuits) (RED PACK DLC)

Silverstone Circuit (four layouts, including one historic 1967 configuration) (BASEGAME)

Trento-Bondone Hill Climb (BASEGAME)

696
CREDITS

697
Author, writer, editor, designer and producer of this manual:
A.M. (aka brotto marco on RaceDepartment; known as A_M on GtPlanet) - community member, modder and mechanical engineering undergraduate
(I have to at least take some credit for my work, yeah, let’s make it bigger, bigger, bigger! The Moon is almost rising…)

From Kunos Simulazioni SRL, developers of AC, authors of various posts in the official forums and creators of the Kunos AC Pipeline 2.0:
Stefano Casillo (@stefanoCasillo) - creator of AC and founder of Kunos Simulazioni SRL
Aristotelis Vasilakos (@aris) - lead physics modeling
Gergő Panker (@pankykapus) - supervising 3D vehicle artist, vehicle production management
Gianluca Miragoli (@yashugan) - lead 3D artist, lead modeller and animator, technical lead
Manuel Darin (@6S.Manu) - staff programmer, beta testing management
Marc Orphanos (@the_meco) - external 3D artist, driver rig

- Greetings to Simone Trevisiol (@Si3v - lead 3D artist, tracks creation) for his old tutorial on the SDK editor: https://www.youtube.com/watch?v=qj3z_yzdwbs
- Acknowledgement to Aristotelis Vasilakos for his explanations around ACC and for his old tutorial on the AC car modding: https://www.youtube.com/watch?v=jz5Y5ylGD4c
- Also, special thanks to Giovanni Romagnoli (game core programmer) for the many details about the AC coding (shared memory), for the old AC Python documentation:
https://docs.google.com/document/d/13trBp6K1TjWbToUQs_nfFsB291-zVJzRZCNaTYt4Dzc/pub and to fughettaboutit aka leBluem for his corrections on that source.

Forum references:
Keep in mind that the sources listed may have inaccuracies, errors and discrepancies, between them and with respect to the contents of this book. It is a consequence of the philologist’s work.

Threads from www.assettocorsa.net, the official AC forums by Kunos:

• AC system requirements: https://www.assettocorsa.net/forum/index.php?faq/assetto-corsa-minimum-requirements.1
• AC keyboard shortcuts: https://www.assettocorsa.net/forum/index.php?faq/keyboard-shortcuts.18
• AC tire model v10: https://www.assettocorsa.net/forum/index.php?threads/tyre-model-v10-specs.36686
• Car materials/shaders: https://www.assettocorsa.net/forum/index.php?threads/car-materials-shaders-modelling-stuff-add-your-knowledge-here.19704
• Track materials/shaders: https://www.assettocorsa.net/forum/index.php?threads/track-materials-shaders.10174
• Analog/digital instruments and lights: https://www.assettocorsa.net/forum/index.php?threads/analog-digital-instruments-lights-q-a-request-official-support-here-check-first-post.12249
• Techniques for track making: https://www.assettocorsa.net/forum/index.php?threads/proper-technique-in-track-making-plus-tips.27180
• “AI_default setup?”: https://www.assettocorsa.net/forum/index.php?threads/ai_default-setup.35214
• “Pit tactics post-1.7 in SP”: https://www.assettocorsa.net/forum/index.php?threads/pit-tactics-post-1-7-in-sp.34352
• “Custom AI doesn't seem to work”: https://www.assettocorsa.net/forum/index.php?threads/custom-ai-doesnt-seem-to-work.38208
• “AI Inconsistencies (Fuel)”: https://www.assettocorsa.net/forum/index.php?threads/ai-inconsistencies-fuel.45654
• “Chassis flex”: https://www.assettocorsa.net/forum/index.php?threads/chassis-flex.61594
• “CPU OCCUPANCY > 99% warnings after v1.12 update”: https://www.assettocorsa.net/forum/index.php?threads/cpu-occupancy-99-warnings-after-v1-12-update-eng-ita.43172
• “Camera-facing crowd - how to”: https://www.assettocorsa.net/forum/index.php?threads/camera-facing-crowd-how-to.27910
• “Shared Memory Reference [25-05-2017]”: https://www.assettocorsa.net/forum/index.php?threads/shared-memory-reference-25-05-2017.3352
• “AC UDP Remote Telemetry [UPDATE 31-03-2016]”: https://www.assettocorsa.net/forum/index.php?threads/ac-udp-remote-telemetry-update-31-03-2016.222
• “Python DOC [UPDATE 25-05-2017]”: https://www.assettocorsa.net/forum/index.php?threads/python-doc-update-25-05-2017.517
• “Groove.ini: racing line and skidmarks | how-to”: https://www.assettocorsa.net/forum/index.php?threads/groove-ini-racing-line-and-skidmarks-how-to.26460
• “Glass texture issue or wrong settings?”: https://www.assettocorsa.net/forum/index.php?threads/glass-texture-issue-or-wrong-settings.17584
• “Ac gear ratio editor”: https://www.assettocorsa.net/forum/index.php?threads/ac-gear-ratio-editor.11506
• “Bone Animation Rig (Blender)”: https://www.assettocorsa.net/forum/index.php?threads/bone-animation-rig-blender.34594
• “Custom steering animation rig 1.7”: https://www.assettocorsa.net/forum/index.php?threads/custom-steering-animation-rig-1-7.18201
• “Wings app for dummies”: https://www.assettocorsa.net/forum/index.php?threads/wings-app-for-dummies.43463
• “wings physics app explained?”: https://www.assettocorsa.net/forum/index.php?threads/wings-physics-app-explained.30071
• “Kunos tracks with extra pit boxes 1.7”: https://www.assettocorsa.net/forum/index.php?threads/kunos-tracks-with-extra-pit-boxes-1-7.28132
• “Updated! minimal damage icon ac 1.0 rc and up”: https://www.assettocorsa.net/forum/index.php?threads/updated-minimal-damage-icon-ac-1-0-rc-and-up.12726
• ò

Threads from www.racedepartment.com (RD):

• “Assetto Corsa - FAQ & Game Description”: https://www.racedepartment.com/threads/assetto-corsa-faq-game-description.91105
• “AC: Stuttering reduction”: https://www.racedepartment.com/threads/ac-stuttering-reduction.88597
• “Making new and correct colliders is easy - PDF tutorial”: https://www.racedepartment.com/threads/making-new-and-correct-colliders-is-easy-pdf-tutorial.208067
• “How to MOD! (Links & ref)”: https://www.racedepartment.com/threads/how-to-mod-links-ref.141062
• “Explanation of values in tyres.ini”: https://www.racedepartment.com/threads/explanation-of-values-in-tyres-ini.167883
• “Change a car Mod‘s aero drag”: https://www.racedepartment.com/threads/change-a-car-mod%E2%80%98s-aero-drag.200328
• “Any Aero.ini, LUT experts? building wings from scratch”: https://www.racedepartment.com/threads/any-aero-ini-lut-experts-building-wings-from-scratch.191889
• “Skin "Priority"…what is that priority value for ??”: https://www.racedepartment.com/threads/skin-priority-what-is-that-priority-value-for.127910
• “Trying to get first skin into Assetto Corsa”: https://www.racedepartment.com/threads/help-needed-trying-to-get-first-skin-into-assetto-corsa.143892
• “Converting skins?”: https://www.racedepartment.com/threads/converting-skins.144476
• “Which modeling program should I choose?”: https://www.racedepartment.com/threads/beginners-dillema-which-modeling-program-should-i-choose-to-create-a-racing-track.163571
• “How to install Mods”: https://www.racedepartment.com/threads/how-to-install-mods.130867
• “Gear ratio fractions explanations”: https://www.racedepartment.com/threads/gear-ratio-fractions-explanations.219133
• “Help! Replacing the driver”: https://www.racedepartment.com/threads/help-replacing-the-driver.210337
• “Correct usage of GUIDs.txt”: https://www.racedepartment.com/threads/correct-usage-of-guids-txt.126690
• “Help with engines”: https://www.racedepartment.com/threads/help-with-engines.192138
• “Analog Gauges, How to?”: https://www.racedepartment.com/threads/analog-gauges-how-to.189911
• “Regarding suspension_graphics.ini”: https://www.racedepartment.com/threads/regarding-suspension_graphics-ini.204560
• “Track Building.”: https://www.racedepartment.com/threads/track-building.208211
• “Car falling through the ground”: https://www.racedepartment.com/threads/car-falling-through-the-ground.231275
• “Light inside a building”: https://www.racedepartment.com/threads/light-inside-a-building.253373

698
• “AI Hints”: https://www.racedepartment.com/threads/ai-hints.146259
• “Matching a real life tire to AC tire”: https://www.racedepartment.com/threads/matching-a-real-life-tire-to-ac-tire.150256
• “Parts of my tire are missing”: https://www.racedepartment.com/threads/parts-of-my-tire-are-missing-when-opening-in-kseditor-only-on-the-passenger-side.216065
• “First time making a track, trees are half transparent”: https://www.racedepartment.com/threads/first-time-making-a-track-trees-are-half-transparent.239234
• “How do I make simple trees transparent”: https://www.racedepartment.com/threads/how-do-i-make-simple-trees-transparent.236569
• “Dark tree”: https://www.racedepartment.com/threads/dark-tree.210578
• “More Adjustable Suspension Options”: https://www.racedepartment.com/threads/more-adjustable-suspension-options.134549
• “Help with Mirrors”: https://www.racedepartment.com/threads/help-with-mirrors.133971
• “Grass washed out without Post Processing”: https://www.racedepartment.com/threads/grass-washed-out-without-post-processing.128542
• “Thomson Road Grand Prix – Singapore”: https://www.racedepartment.com/threads/thomson-road-grand-prix-singapore.127582
• “How did a F2002 mod from AC end up in F1 2017???”: https://www.racedepartment.com/threads/how-did-a-f2002-mod-from-ac-end-up-in-f1-2017.142884
• “Suspensions problem”: https://www.racedepartment.com/threads/suspensions-problem.147820
• “Help my track mod doesn’t load in AC”: https://www.racedepartment.com/threads/help-my-track-mod-doesnt-load-in-ac.155862
• “Problem with colliders”: https://www.racedepartment.com/threads/problem-with-colliders.161018
• “Shifting Animations”: https://www.racedepartment.com/threads/shifting-animations.162299
• “AI Drift .ini Manipulation”: https://www.racedepartment.com/threads/ai-drift-ini-manipulation.182358
• “Blender ksanim/knh exporter”: https://www.racedepartment.com/downloads/blender-ksanim-knh-exporter.30388
• “Help with A.I paths Please”: https://www.racedepartment.com/threads/help-with-a-i-paths-please.180735
• “Ford P68 (F3L) W.I.P.”: https://www.racedepartment.com/threads/ford-p68-f3l-w-i-p.126974
• “Unwanted numbers on a custom paintjob”: https://www.racedepartment.com/threads/unwanted-numbers-on-a-custom-paintjob.139783
• “Williams - BMW FW24”: https://www.racedepartment.com/threads/williams-bmw-fw24.135627
• “models.ini: create separate files”: https://www.racedepartment.com/threads/models-ini-create-separate-files.141401
• “How to calculate fuel consumption”: https://www.racedepartment.com/threads/how-to-calculate-fuel-consumption.140114
• “Do I start building tracks??”: https://www.racedepartment.com/threads/do-i-start-building-tracks.138115
• “I'm having issues making a very simple track”: https://www.racedepartment.com/threads/im-having-issues-making-a-very-simple-track.139457
• “Updating mods”: https://www.racedepartment.com/threads/updating-mods.141155
• “Upside down track”: https://www.racedepartment.com/threads/upside-down-track.146345
• “Tracks modding, physical objects”: https://www.racedepartment.com/threads/tracks-modding-physical-objects.147861
• “Mercedes 190”: https://www.racedepartment.com/threads/mercedes-190.156996
• “I need help about merging two cars in one”: https://www.racedepartment.com/threads/i-need-help-about-merging-two-cars-in-one.251609
• “Basics of Getting your mod car in game?”: https://www.racedepartment.com/threads/basics-of-getting-your-mod-car-in-game.158568
• “Talent files for AI drivers?”: https://www.racedepartment.com/threads/talent-files-for-ai-drivers.138187
• “PITS Zone not working”: https://www.racedepartment.com/threads/pits-zone-not-working.163190
• “Tips and Tricks to get more FPS out of your tracks”: https://www.racedepartment.com/threads/tips-and-tricks-to-get-more-fps-out-of-your-tracks.158405
• “Deutschlandring”: https://www.racedepartment.com/threads/deutschlandring.132099
• “Door animation and car wipers”: https://www.racedepartment.com/threads/door-animation-and-car-wipers.176619
• k

- The following users will be mentioned due to the useful posts and info they provided: Georg Siebert, AccAkut, LilSki, NightEye87, kubaa, alekabul, mantasisg, garyjpaterson,
Ben O’Bro, Stereo, mclarenf1papa, Brownninja97, Ryno917, Sven Hielscher, DanTDBV, peterboese, Fat-Alfie, A3DR, piereligio
- Also, special thanks to Navigator for letting me know of the existence of the Fmod Bank Tools.
- Greetings to Ben O’ Bro (aka Benoit Aubry) for the original idea of a vehicle list, here: http://benobro.org/ac/cars.php
Threads from www.assettocorsamods.net:
• “Basic Guide - Your FIRST car in Assetto Corsa”: https://assettocorsamods.net/threads/your-first-car-in-assetto-corsa-basic-guide.1019
• “Loading track in game”: https://assettocorsamods.net/threads/loading-track-in-game.881/#post-4102
• “KS Grass // Ks Tree”: https://assettocorsamods.net/threads/ks-grass-ks-tree.765
• “Apps – FAQ”: https://assettocorsamods.net/threads/faq-apps-faq.715
• “BIG PROBLEM WITH WALLS”: https://assettocorsamods.net/threads/big-problem-with-walls.2061
• “App for Current Grip level of a track”: https://assettocorsamods.net/threads/app-for-current-grip-level-of-a-track.713

- Huge thanks to all these users for their lengthy and comprehensive posts: LilSki, luchian, Johnr777, fughettaboutit,
Other sources:
- Various details about NetKar & NetKar Pro: https://www.drivingitalia.net/forums/topic/24201-caro-diario
- AC system requirements: https://www.assettocorsa.it/system-requirements
- Stefano Casillo never uses the launcher: https://youtu.be/xBjXYHNUiis?t=401
- Interview stating that the AC user experience should be fun and easy: “Assetto Corsa: intervista a Kunos Simulazioni”: https://www.youtube.com/watch?v=JG98CRyOgIw
- About the Assetto Corsa product strategy and track laserscan: “Assetto Corsa: il talk di Kunos alla GGJ 2013”: https://www.youtube.com/watch?v=ijvih-97-IA
- About the AC 1.16.4 update:
https://steamcommunity.com/app/244210/discussions/0/2794999575659541610/?ctp=4#c2794999575672291339
https://steamcommunity.com/app/244210/discussions/0/2794999575672538035
- Various definitions and articles:
https://en.wikipedia.org/wiki/Modding
https://en.wikipedia.org/wiki/Central_processing_unit
https://en.wikipedia.org/wiki/Graphics_processing_unit
https://web.archive.org/web/20060324123541/http://management.silicon.com/government/0%2C39024677%2C39117891%2C00.htm
https://en.wikipedia.org/wiki/Software_bug
https://en.wikipedia.org/wiki/Graphical_user_interface
https://en.wikipedia.org/wiki/HUD_(video_gaming)
https://en.wikipedia.org/wiki/Texture_mapping
https://en.wikipedia.org/wiki/Virtual_reality
https://en.wikipedia.org/wiki/Video_post-processing

699
https://en.wikipedia.org/wiki/API
https://en.wikipedia.org/wiki/DirectX
https://en.wikipedia.org/wiki/Head-up_display
https://en.wikipedia.org/wiki/Frame_rate
https://en.wikipedia.org/wiki/Computer_graphics
https://en.wikipedia.org/wiki/Virtual_private_network
https://en.wikipedia.org/wiki/Downloadable_content
https://en.wikipedia.org/wiki/Assetto_Corsa
https://www.gamersnexus.net/dictionary/7-game-graphics-settings/41-v-sync

- About mesh topology/optimization:

https://sites.stat.washington.edu/wxs/Siggraph-93/siggraph93.pdf
https://blenderbasecamp.com/home/what-is-mesh-topology-in-3d-modeling/
https://www.avalab.org/shoequest-ii-box-model/
- All credits for text and illustrations of paragraph “4.7 - Driving techniques” of PART 1 belong to Rick Haslam, Nick Stokes and Sarah Warburton, authors of the Grand Prix 2 user manual – a game
by Geoff Crammond. All rights © 1995 MicroProse
- About the making of 3D colliders with 3DsMax: tutorial “How to make car collider | Assetto Corsa” by M9mentum (YouTube): https://www.youtube.com/watch?v=Wo7ncL_MYzg
- Screenshot of the LOD structure of ACC vehicles: Inside the game @Kunos Simulazioni - "Road To" Powered by Mercedes-Benz - Chapter 4: https://www.youtube.com/watch?v=j0FlgFYKhDA
- Additional Python app creation guide: https://github.com/ckendell/ACAppTutorial/blob/master/ACAppTutorial.md, shared under Creative Commons BY-NC 4.0
- Additional physics information: Girellu, repository about Assetto Corsa by archibaldmilton: https://github.com/archibaldmilton/Girellu

- A lot of info from the official AC Custom Shaders Discord server. The following users will be mentioned due to the very useful info they provided: JPG_18, Stereo,
Johnr777, abbo90, Tuttertep, peterboese
- “Sound Modelling Tutorial #1 - Honing Your Attention to Detail Pt.1” by SHR Modding – Link of his tutorial: https://www.youtube.com/watch?v=tS-H-CGn--
s&list=PLVycee5B29McufS3nLwfHsgbbulVVgQFb

Sound: Citations
World Health Organization, WHO-ITU global standard for safe listening devices and systems, 2019. Retrieved from https://www.who.int/deafness/make-listening-
safe/standard-for-safe-listening/en/.

U.S. Environmental Protection Agency, Office of Noise Abatement and Control. (1974, March). Information on levels of environmental noise requisite to protect public
health and welfare with an adequate margin of safety. Retrieved from https://nepis.epa.gov/Exe/ZyPDF.cgi/2000L3LN.PDF?Dockey=2000L3LN.PDF [PDF].

Bibliographic / article publications references:

- Zwa, Amen. “Going Nowhere Fast In Assetto Corsa (17ed, 2020-10-20): Race Driving On A Simulator.” sOnit, Inc.
- Bhadri Rajasai, Ravi Tej, Sindhu Srinath, “Aerodynamic effects of dimples on aircraft wings”, IJAMAE [ISSN : 2372-4153], 19/10/2015
- Shabir Grover, B.B.Arora, Vaibhav Khanna, Tushar Kaushik, Akhilesh Arora, “Analysis on Drag Reduction of Bluff Body using Dimples”, IJAPIE-SI-IDCM 602 (2017) 04–11

Photos and illustrations:

Front cover:
- Alfa Romeo 33 Stradale, official content by Kunos Simulazioni SRL, on the Shutoko Revival Project track by Soyo; image shot by A.M.
- Audi Sport Quattro S1 E2, official content by Kunos Simulazioni SRL, on Black Cat County track by Kunos; image shot by A.M.
- Ferrari SF15-T, official content by Kunos Simulazioni SRL, on the Drag 2000m track by Kunos; image shot by A.M.
Back cover:
- Auto Union Type C, mod by Gary Paterson (garyjpaterson on RaceDepartment) on the Test Pad track mod by Stereo; image shot by A.M.
Title covers:
- “Garden of Books”, AI-generated image, created by A.M. with Dream.ai – Wombo
- “Forgotten Nature”, AI-generated image shown in the titles of PART 1, created by A.M. with Dream.ai – Wombo
- Alfa Romeo P2 Biposto, mod by A.M., shown in the titles of PART 2, on the Industrial showroom by Kunos; image shot by A.M., mod currently WIP, not publicly released
- Lamborghini Miura P400 SVR, mod by Velo, shown in the titles of PART 3, on the Nurburgring 1967 track mod by WilliamRiker (aka WilliamTRiker); image shot by A.M.
- “The Arc of Decay”, AI-generated image shown in the titles of CREDITS, created by A.M. with Dream.ai - Wombo
Illustrations:
- Safety Car mod shown in Fig. 0.3 (top left) by Gary Paterson (on RaceDepartment); image shot by A.M.
- Lego Hot-Rod #2 mod shown in Fig. 0.3 (top right) by PenguinActually (on RaceDepartment); image shot by A.M.
- Ape Proto "Terrorcarro" mod shown in Fig. 0.3 (bottom left) by Pessio (on RaceDepartment); image shot by A.M.
- Test Plane mod shown in Fig. 0.3 (bottom right) by the_meco (on RaceDepartment); image shot by A.M.
- Ferrari 250 GTO Series II mod shown in Fig. 1.2 by Legion & AC Legends; image shot by A.M.
- Abarth 500 EsseEsse shown in Fig. 1.4 & 2.10 by Kunos
- Delage 2LCV 1923 mod shown in Fig. 1.7 & 1.8 by Liam aka Nicecuppatea (on RaceDepartment); image shot by A.M.

A special thanks goes to these people for their support and participation to this project:
Ben O’ Bro (RD) Navigator (RD) Graham Botha (RD) Sven Hielscher (RD)

700
 “I will achieve my goals, even if some people don’t believe in me because they’re too self-centred to try and do it. I will be the last one to laugh, and I
definitely won’t hear the echo of my voice. Never mess with Italians!”

“I’m only licenced to die, like us all”

A.M.

Disclaimer. Safety & Copyright Notice

Included within the resources of this manual may be copyrighted material, the use of which has not always been specifically authorized by the copyright owner(s). The author believes this
constitutes a ‘fair-use’ of any copyrighted material as provided for in section 107 of the US Copyright Law. In accordance with Title 17 U.S.C. Section 107, the contents of this manual are
distributed without profit to those who have expressed a prior interest in receiving the included information for research and educational purposes. If you wish to use copyrighted material from this
manual for purposes of your own that go beyond ‘fair use’, you must obtain permission from the copyright owner(s). Any copyright logo, watermark or reference in this manual, unless belonging to
the respective owners mentioned in the CREDITS, is not registered, and its purpose is to act only as a deterrent against copy.

The material and information contained on this manual is for general information purposes only. You should not rely upon the material or information on the manual as a basis for making any
business, legal or any other decisions. Whilst the author endeavours to ensure that accurate information is disseminated through this medium and to keep said information up to date and correct,
he makes no representations or warranties of any kind, express or implied about the completeness, accuracy, reliability, suitability or availability with respect to the manual or the information,
products, services or related graphics contained on the manual for any purpose.

The user assumes all responsibility and risk for the use of this manual. The author accepts no liability or responsibility to any person as a consequence of any reliance upon the information
contained in this manual. Under no circumstances, including negligence, shall anyone involved in creating or maintaining this manual be liable for any direct, indirect, incidental, special or
consequential damages, or loss profits that result from the use or inability to use the manual and/or any website linked to this manual. Nor shall they be liable for any such damages including, but
not limited to, reliance by a reader on any information obtained via the manual; or that result from mistakes, omissions, interruptions, deletion of files, viruses, errors, defects, or failure of
performance, communication failure, theft, destruction or unauthorised access. States or Countries which do not allow some or all of the above limitations of liability, liability shall be limited to the
greatest extent allowed by law.

If you use this book for commercial purposes without giving credit to any of the people who contributed directly or indirectly to its creation, you truly have no respect.

701
“Happiness is when you win a race against yourself. If you follow another you’re always behind.”

© 2023 A.M. All rights reserved.

702