Anda di halaman 1dari 64




Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham



This project report describes in detail an attempt within a seven month time period to develop a realistic vehicle simulation application. A project such as this represents a significant learning commitment as the prerequisites of this project involved a great deal of research into the fields of vehicle dynamics, computing, mathematics and physics. The project has been name the “Vehicle Dynamics Engine” with the acronym ‘VDE’ and is executable in real-time on consumer level computer systems. Typical vehicle simulations of this nature may be found in software and computer entertainment applications. In the latter case however, the physics models are optimised for enjoyment and playability rather than for realism.


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham



Marco Monster for making available an advanced introduction to car physics modelling for games on which most of the application’s physics is based. Kenneth J. MacLeod for the inspiration needed to undertake this project. Discreet for their 3D Studio max 3D modelling package used to create the 3D models. Adobe for their Photoshop 2D painting package used to create the 2D textures. Dr. Abhir Bhalerao for his valuable assistance in a supervisory role. The final acknowledgement I dedicate to family and friends.


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham



All important nomenclatures used in the report are listed below in order of appearance:



rear wheel traction force (N)



car heading unit vector



aerodynamic drag force (N)



aerodynamic drag coefficient



car velocity vector



car speed (m sֿ¹)



car wheel rolling resistance (N)



rolling resistance coefficient



longitudinal force (N)



car acceleration vector



car acceleration (m sֿ²)



car mass (Kg)



car weight (N)



simulation engine loop time (milliseconds, ms)



car position vector



car position from origin (m)



friction coefficient



car frontal area (m²)



air density, rho (Kg mֿ³)



car braking force (N)



car braking constant



maximum force on car wheel (N)



friction coefficient of the tyre, mu



acceleration due to gravity (m sֿ²)



weight of car on front wheels (N)



weight of car on rear wheels (N)



position vector of the centre of gravity



distance from CG to the rear axle (m)



distance from CG to the front axle (m)



height of CG above wheelbase (m)


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham




wheelbase (m)



car horsepower (hp)



car engine revolutions per minute



car engine drive force (N)



car engine torque at a given rpm (N)



car gear ratio



car differential ratio



transmission efficiency (%)



car wheel radius (m)



first gear ratio



second gear ratio



third gear ratio



fourth gear ratio



fifth gear ratio



sixth gear ratio



reverse gear ratio



car engine drive torque (N)



ratio of a circle circumference to its diameter, pi



slip ratio



car wheel angular velocity (rad sֿ¹)



longitudinal velocity (m sֿ¹)



lateral velocity (m sֿ¹)

Fn, long


normalized longitudinal force for a given slip ratio (N)

Fn, lat


normalized lateral force for a given slip ratio (N)



load on the tyre (N)



traction constant



total inertia (kg m²)



turning angle made by front and rear wheels, delta (deg)



radius of curvature (m)



car angular velocity (rad sֿ¹)



angle different between car heading and velocity direction vectors, beta (deg)


car body heading direction vector, omega



car tyre lateral or cornering force (N)



cornering stiffness



slip angle, alpha


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham




car front tyre lateral speed (m sֿ¹)



car front tyre longitudinal speed (m sֿ¹)



car front wheel slip angle (deg)



car rear wheel slip angle (deg)



cornering or centripetal force (N)

Flat, rear


car rear lateral force (N)

Flat, front


car front lateral force (N)



car angular acceleration (rad sֿ²)

Notations and Conventions Vectors are 3-Dimensional and are shown in bold. So for example the vector notation a = -b would translate to the following code snippet:

a.x = -b.x a.y = -b.y a.z = -b.z


The main assumptions made in this project report are that the car physics theory presented only applies for common modern-day four wheel cars and the rear wheels of these cars provide all the drive for the entire

vehicle. In other words, the theory behind the vehicle dynamics engine is based on common two wheel drive cars and not four wheel drive cars.

Units and Conversions

Mainly S.I. (meters, kilograms, Newton’s, etc) units will be used in this report. Below are some unit

conversions to S.I. units:

Force Power Torque Speed Angular velocity Acceleration Mass Distance 1 mile

N (Newton) W (watt) N.m (Newton meter) m/s rad/s m/s² kg m 1.6093 km

6² N.m/s = J/s = m²kg/s³ - - - - - - -

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


  • 1 ft (foot)

0.3048 m


  • 1 in (inch)

0.0254 m

2.54 cm

  • 1 km/h

0.2778 m/s

  • 1 mph

1.609 km/h

- 0.447 m/s

  • 1 rpm (revolution per minute)

0.105 rad/s


  • 1 G

9.8 m/s²

32.1 lb/s²

  • 1 lb (pound)

4.45 N


  • 1 lb (pound)

0.4536 kg

1 lb/1 G

  • 1 lb.ft (foot pounds)

1.356 N.m


  • 1 lb.ft/s (foot pounds per second)

1.356 W


  • 1 hp (horsepower)


745.7 W

  • 1 metric hp

0.986 hp

735.5 kW


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham



Abstract ..



Acknowledgments …………………………………………………………………………………………



Nomenclature ………………………………………………………………………………………………. 4

Chapter 1 - Introduction ……………………………………………

………………………………… ...


  • 1.1 The Problem …

……………………………………… ..




  • 1.2 Objectives ….…….……………………………………………





  • 1.3 Motivations ………

………………………………………………………… ..




  • 1.4 Document Overview ……………………………………………………………………



Chapter 2 - Self Assessment of the Project ...

………………… ………………





…… ..


  • 2.1 Technical Contribution of the Project


  • 2.2 Relevancies to Computer Systems Engineering ……………………



  • 2.3 Making use of the Project Work ……………….……………………………………………




  • 2.4 Project Achievement Considerations …………………




  • 2.5 Weaknesses of the Project …………….……………………………




Chapter 3 – Background Research ……………………………………………………………



  • 3.1 Introduction ………………………………………………………………………



  • 3.2 Vehicle Dynamics Research ……………………………………………………



  • 3.2.1 Comparable Vehicle Simulations ………………………………………





  • 3.2.2 Engine and Drive Train Simulation ……………………………………



  • 3.2.3 Suspension, Traction and Steering ………………………………………



  • 3.2.4 Uneven Grounds and Gravitational Effects ………………………….……



  • 3.3 Computer Implementation Research …………………………………………………



  • 3.3.1 Software Development Kits and Libraries ………………………………



  • 3.3.2 Program Development Cycle and structure ………………………………



  • 3.4 Methods and Conclusions …………………………………………………………



Chapter 4 - The Simulation Engine …………………

…………………………………… ...




  • 4.1 Introduction ………………………………………………………………………



  • 4.2 Hardware Technology Specifications …




  • 4.3 Software Technology Specifications …

…………………………………………… ...





Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


  • 4.4 Application Framework Design and Architecture ....








  • 4.5 Application Framework Implementation …………………………………………





  • 4.5.1 Engine Files ……………………………………………………………



  • Level 0: API Library ……






  • Level 1: Low Level Functions ..

………….……….………… …………… ...


  • Level 2: High Level Functions ……




  • Level 3: The Application Core……………………………



  • Resource Manager …





  • 4.5.2 Program Files …………………………………………………………



  • 4.5 Engine Testing and Evaluation


Chapter 5 - The Vehicle Dynamics Engine ……………………………….…







  • 5.1 Introduction ………………………………………………………………………



  • 5.2 Vehicle Class Design and Architecture …………………………………………




  • 5.3 Vehicle Class Implementation ……………………………………………………




  • 5.3.1 Vehicle Physics Theory …………………………………………………



  • Linear Physics …………………………………………………



  • Turning Physics …………………………………………………




  • Uneven Terrain …………………………………………………



  • Suspension System ………………………………………………



  • 5.3.2 Input System ……………………………………………………………




  • 5.3.3 3D Mesh Control …………………………………………………………



  • 5.3.4 Sound Control ………………………………………………………………



  • 5.3.5 Heads-Up Display Control ……………………………………………………



  • 5.3.6 Vehicle Data Control …………………………………………………………



Chapter 6 - Final Testing and Results ……………………………………………………………



  • 6.1 Creating the Simulation Environment …………………………………………………





  • 6.2 Vehicle Setup and Test Procedure …………………………………………………………


  • 6.3 Vehicle Dynamics Engine Results ………………………………………………………



Chapter 7 - Conclusion and Evaluation …………………………………………….……………



  • 7.1 Summary: Goals Criticism, Achievements, Difficulties and Learnt Lessons ……………




  • 7.2 Further Work ………………………………………………………………………



  • 7.2.1 High Speed Physics ………………………………………………………




Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


  • 7.2.2 Alternate Input Methods



  • 7.2.3 Jumping Physics ……………………………………………………………




  • 7.2.4 Realistic Suspension System …………………………………………………





  • 7.2.5 Rigid Body Mechanics …………………………………………………

………… ...


Chapter 8 - Appendix ……….……………………





  • 8.1 Using the Application ………





  • 8.2 References …………………………………………………………



Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham




  • 1.1 The Problem

Due to an increase in the expectations of customers concerning video game content, developers must

strive to ensure their games contain certain features previously overlooked by customers; such features

include realistic vehicle physics for realistic games in which vehicles are being controlled. Developing these

features from scratch could prove very costly, resource hungry and time consuming.

Alternatively many developers resort to seeking out 3 rd party or middleware technology to integrate

into their games. A popular industrial 3 rd party development kit is the Havok game dynamics SDK, a

development kit allowing developers integrate character, vehicle and environmental dynamics into their

existing games and software. Havok was born in the computer science department of Trinity College,

Dublin and is now the chief supplier of dynamics technology to major game and software development

companies around the world. This kit however doesn’t come cheap and very few low-cost or free

alternatives exist on the market today.

This poses a problem for budget and hobbyist game developers who require these features in their

games but lack the resources to purchase them and the time or expertise to develop these features for their

selves. Due to the “free” or “cheap” nature of this kit it is not expected to be as high-quality as Havok or

similar in its price range. On the other hand, its advantages can lie elsewhere like in its simplicity, ease of

use, understanding and integration into an existing game or software with little to no support from the

developer as you shouldn’t expect much support from a free product.

  • 1.2 Objectives

The objectives of this project would be to develop a cheap, simple, efficient and modular vehicle

physics engine that can be easily integrated into an existing game or software program providing it with a

fully immersive driving experience using either a keyboard or force feedback driving wheel for navigation.

With the increasing complexity of modern day computer games, the need to modularise code grows more

crucial. Therefore this engine will be made to be standalone in the form of a source file add-on, library or

dynamic link library (DLL).

The vehicle physics engine will be based on rigid body mechanics, dynamics and mathematics and

will be designed to allow various types of vehicle behaviours to be simulated effectively. The engine will


Modular encapsulation for easy integration into an existing game or software.

Core vehicle physics for games and software.


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


Parameters for engine, game play, aerodynamics and steering modification amongst others.

Simple deformation for post-crash scenarios.

Support for multiple vehicle types including realistic racing cars and cartoon cars.

Support for multiple input methods including keyboard and force feedback driving wheel.

The vehicle physics engine will be built with a virtual 3D simulation of a landscape to navigate

around and showcase its functionality. The landscape should feature:

Even and uneven grounds with hills and cliffs.

Obstacles such as trees, rocks, buildings etc.

Other vehicles.

  • 1.3 Motivations

Being a hobbyist game developer and an occasional game player I have witnessed the little

development in the games and software industry concerning creating realistic vehicle physics simulators for

budget and hobbyist game developers. Most of the budget level vehicle physics middleware solutions are

either part of a larger more complex physics system or not suitable for serious games and developers. This is

one of my motivations for creating this vehicle dynamics engine so it could help hobbyist developers like

me to easily integrate vehicle physics into their applications. Another motivation of mine is a personal

interest in cars and their representation in computer games with the advent of the modern day desktop


  • 1.4 Document Overview

This report now proceeds into chapter two by first self assessing the entire project and answering

important questions based on the technical contribution of the project, it’s relevancies to computer systems

engineering, potential current and future uses of the project work, project achievements and weaknesses.

Chapter three takes a look at the prerequisite background research performed in order to design and

develop the vehicle dynamics engine. This chapter also presents research into a number of issues in vehicle

dynamics, computing, topics such as user input logging and processing and finally an analysis of

comparable vehicle simulations.

Chapter four takes an in-depth look at the design, development and testing of the simulation engine

responsible for supporting the vehicle dynamics engine.

Chapter five documents the design and development of the vehicle dynamics engine which covers

topics ranging from the input methods, vehicle processing methods and final output methods.


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


Chapter six describes the final integration testing of the vehicle dynamics engine combined with the

simulation engine. This section describes in detail how a simple simulation environment was created and

used to test a vehicle using real-world technical data.

Chapter seven provides a conclusion and evaluation to the finished vehicle dynamics engine. The

specifications of the final simulation are compared to those originally proposed. Moving on from this

evaluation the potential future work and enhancements are discussed.

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham




  • 2.1 Technical Contribution of the Project

The vehicle dynamics engine contains practical applications of scientific, engineering, mathematical

and software design principles. The project would not have been possible without some of these principles.

Some of the technical contributions made by the project include the complexity of the vehicle physics as the

reader shall see in later sections, the structure and modularisation of the software code in order to allow

certain techniques to be employed and other 3D techniques such as mathematical collision detection and

matrix manipulation etc.

  • 2.2 Relevancies to Computer Systems Engineering

Computer Systems Engineering is a specialised discipline that combines electrical engineering with

computer science. From a computer science perspective, a computer engineer is a software architect with a

focus on the interaction between software programs and the underlying hardware components. This project

is direct towards the computer science aspect of computer systems engineering, it’s a software based project

that seeks to create software capable of performing sophisticated numerical simulations of vehicles on a

modern day desktop or laptop computer keeping in mind the advantages, disadvantages and restrictions of

the underlying hardware regardless of what system it’s being executed on.

  • 2.3 Making use of the Project Work

This project work has several potential uses such as in education, development and leisure.

Educational uses include teaching or learning about cars and their behaviour, mechanics, physics through

studying the vehicle dynamics code and running the simulations. Development uses include using the

vehicle dynamics engine as a middleware solution to power vehicle physics in an existing software

application or game. For example the vehicle dynamics engine is included in the simulation engine as a

standalone source file and can hence be easily used to compliment a game create using the simulation

engine. Finally Leisure uses simple means creating your own worlds and landscapes, creating your own

cars, setting the car’s up with real-world technical data and observing the cars behaviour in the simulation

environment as part of your own pleasure.

  • 2.4 Project Achievement Considerations

I feel the project has achieved a lot over the course of it seven month development period, keeping in

mind a project of this category can never be fully completed but instead can be continually enhanced

indefinitely. In general, the vehicle dynamics engine boasts the preliminary stages of an engine capable of


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


accurately or convincingly simulating any type of car simply by feeding it the right technical information

from its real-life counterpart. So for example, by setting up a vehicle in the vehicle dynamics engine with

the technical information of say a Chevrolet corvette C5, the vehicle physics engine should be able to

convincingly simulate the virtual version of the car like its real-life counterpart.

2.5 Weaknesses of the Project

Time restriction was the main weakness of the project, you can only develop the vehicle physics as

much as time would allow and in this case that was seven months. Although in a stable state the vehicle

dynamics engine lacks some higher capabilities such as high speed driving, jumping, rolling, a sophisticated

suspension system etc. There are also a few minor bugs and software errors within the current build but they

do not retract the project from the goals the author set out to achieve.

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham




  • 3.1 Introduction

The background research for the vehicle dynamics engine spans several topics in vehicle dynamics,

mathematics, mechanics, physics and computing. With such a broad range of required knowledge much

time was devoted to performing this research. This chapter provides a narrative survey of the background

research for the vehicle dynamics engine. The important research findings are presented here, and their

implications discussed. Background research matter including books, articles, source code, executable

programs, existing games, internet resources, etc to name a few where all used for this project. This portion

of the report will be presented in two main sections. Vehicle dynamics research discusses all the research

carried out concerning cars, their behaviour in real-life and how this can be represented in a computer

simulation. Computer implementation research discusses the research made that focuses on how this

simulation can be implemented in a computer program and how to cater for input, processing and display.

Finally, section 3.4 provides a conclusion on all the research undertaken.

  • 3.2 Vehicle Dynamics Research

Many areas of vehicle dynamics relevant to this project have been documented by many people with

contrasting academic backgrounds. These people would include racing enthusiasts, mechanical engineers

and computer programmers. Because of the varied background of these authors in this field it proved

straightforward to find useful information that was pitched at an adequate and yet not excessively technical

level. As the author had no prior experience of vehicle physics theory it would not be possible to build the

simulation from only elaborate engineering texts. The information reviewed here is of relevance to

computer simulation rather than a detailed study of vehicle dynamics. As well as restricting the technical

scope, background research has been limited to the study of normal four wheel cars. This is the only type of

vehicle required by this project. The term normal used here means that the vehicle dynamics engine project

is not concerned with unusual or experimental car concepts. Examples of vehicle types that are excluded

from this project include:

Cars with four-wheeled steering systems.

Hybrid multi-fuel cars.

Electric cars.

Accounting for such cars would have proved too extensive for the seven month time period available

for designing and developing this project. Research into vehicle dynamics is presented in the four following


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


subsections. Section 3.2.1 begins by looking at similar vehicle simulation programs. Section 3.2.2 takes a

look at straight line physics involving drive train simulation, traction, and suspension etc. Section 3.2.3

examines turning physics involving steering. Finally section 3.2.4 focuses on uneven grounds and the

resulting gravitational effects on the vehicle.

3.2.1 Comparable Vehicle Simulations

The most common use of graphical vehicle simulation is in entertainment programs such as driving

games. Car accelerations, highest speeds and cornering abilities are typically much more enhanced,

optimised and tweaked compared to in reality. Two example driving games where this is the case is

Electronic Arts’ Need for Speed: Underground series and the Microsoft’s Mid Town Madness series. The

reason for using such distorted physics is to increase the game enjoyment and playability. It is financially

better for a commercial game developer to produce an entertaining simulation application as opposed to a

highly accurate and boring one. An unrealistic yet highly entertaining driving game simulation will reach a

greater audience.

Below is a review of two high-quality attempts to write realistic motorcar simulations. As previously

mentioned such driving simulations are generally not commercially viable therefore both simulations where

created by hobbyist programmers. The two simulations are called Racer and TORCS; the source code for

both of these driving simulations is publicly available.

A Review of Racer by Kenneth J. MacLeod

“This is a highly ambitious project written by Ruud van Gaal. The aim is to create a platform

independent racing simulation with an emphasis on accurate physics. Although Racer is less than fifty

percent complete it has many features. Cars may be driven under user control around a race circuit all within

a 3D environment. Cars accelerate and brake realistically, and steering and traction forces are calculated

allowing convincing turning and skidding. In addition to this Racer also features variable height terrain.

This enables banked turns as well as the ability to get cars airborne over steep crests when travelling at high

speeds. Graphics for the cars and tracks have been imported from 3D Studio Max. This has allowed the use

of highly detailed 3D models.

Racer is not without some flaws. Most significant are the issues with the spring physics. While

driving around it is quite possible through extreme weight shifts to start ever increasing oscillations in a

car’s suspension system. After landing from a jump, or as a result of rapid slalom style turns the suspension

can begin to bounce out of control. It would appear that the suspension system is somehow creating energy

instead of dissipating it. Racer’s suspension system is based upon a full rigid body simulation. This aims to

capture the true movements and interactions of the suspension joints and suspended car body.


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


The transmission system also has some problems. When the car is in gear and stationary, the engine

is still running but with zero revolutions per minute (RPM). Obviously an engine cannot be running if it is

not turning. As well as this Racer features only a digital clutch system, the clutch is either engaged or not.

These features are far from realistic.

Racer does feature sound, but although van Gaal claims to have completed the audio system some

bugs are apparent. Audio output can be intermittent and distorted.

Despite these flaws Racer is still very impressive. Features required in the vehicle dynamics engine

are demonstrated such as convincing acceleration and breaking effects.”

The Racer driving simulator provided a useful benchmarking application against which to test

features common with the vehicle dynamics engine. Also, careful study of how Racer has been structured

from a programmer’s point of view also proved useful. Discussions on the program structure of Racer are

presented in chapter 4.

A Review of TORCS by Kenneth J. MacLeod

“TORCS is an open source racing simulator project that is currently in the late stages of

development. The goal of TORCS is somewhat different to that of Racer. According to the project mission

statement “the goal is to have programmed robot drivers racing against each other”. Joystick support is

however included to allow cars to be taken under user control. TORCS is more ambitious in the field of

artificial intelligence than vehicle dynamics. In spite of this the physics system is still well specified.

The current version of TORCS implements a 3D world comprising of a race track and a number of

different cars. Terrain in the simulation can of variable height in a similar way to that of Racer. Cars

accelerate and brake convincingly, and yet the physics engine behind this s much simpler that that or Racer.

Skidding effects are implemented and include handbrake support.

The suspension effects of this simulation are modelled in a simple yet effective way. Suspension

springs are coupled to dampers and work on simple principles well documented in A-levels standard physics

texts. This is in contrast to Racer’s much more sophisticated yet bugged suspension physics (although Racer

is much less complete than TORCS).

From a graphical point of view, TORCS lacks the sophistication of Racer. All 3D models have been

constructed from very few polygons. This graphical simplicity does however all high frame rates and

realistically smooth movements of the cars.

There are currently some flaws with TORCS. Most notably it is very difficult to keep traction.

Wheels spin easily and it is only with great difficulty that a car can be navigated around a complete lap

without sliding off the road.


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


Another problem is that as in Racer, it is possible to have the engine running at Zero RPM with the

car stationary and in gear.

It has not been possible to evaluate the audio output in TORCS as this has only been implemented

for Linux systems. The system TORCS was reviewed on was running Microsoft Windows. This lack of

sound is not a true flaw, but merely a feature that has not yet been implemented for windows users.”

The TORCS driving simulator also provided a useful benchmarking program against which to test

the common features with the vehicle dynamics engine. A careful study of the structure of TORCS has also

been made and discussions on this structure are presented in later chapters.

3.2.2 Engine and Drive Train Simulation

Vehicle engines are extremely complex engineering systems and have to be greatly simplified in

order to make their simulation practical, even possible in the vehicle dynamics engine. It would be very

unreasonable to model arbitrary vehicle components such as the cylinder, valve, cam shaft etc. Opportunely

there are well documented methods available over various mediums that can be used to create a convincing

engine model in a simple way.

A vehicle engine can be treated as a solid body of uniform flywheel upon which a torque is applied

to. The torque applied to this flywheel is determined by the characteristics of the engine performance as well

as the throttle’s current settings. Gillespie’s Fundamentals of Vehicle Dynamics shows how “the

performance characteristics of engines may be characterised by their torque and power curves as a function

of speed” [Gillespie 1992, p.21]. The torque force exerted by the engine varies with the speed of the engine.

This variation of this engine torque with engine speed can be plotted against one another to produce what is

known as a ‘torque curve’. It is important to note however that the torque curves assume the engine is at full


Engine acceleration is influenced by internal braking inertia and torque. The inertia on the flywheel

may be quickly and easily calculated from its diameter and mass [Amsterdam]. Engine braking arises

because of compression effects and friction in the wheel cylinders and the magnitude the force increases

linearly with the speed of the engine. The engine braking force can be modelled by a suitable coefficient

multiplied by engine speed [Gaal 2001b].

Transfer of engine torque force to the ground through the drive trains is covered in part three of

Brian Beckman’s articles on the physics of racing. These articles provide a look at several important areas

of vehicle dynamics but are generally biased towards producing a computer-based motorcar simulation. The

drive train of a typical vehicle comprises of the engine, clutch, transmission (gearbox), and differential.

The drive train contains gears that give the engine extra leverage, i.e. the gears of the drive train

magnify the engine torque force output as well as user selectable gear ratios in the transmission (typically


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


within gear 1 to gear 6 included for an average car). There is a fixed differential gear called the final drive

gear. The differential is the final drive train module that divides output torque force amongst the drive

wheels (rear wheels in this case). Total gearing ratio is the transmission gear multiplied by the final drive

gear [Beckman 1991a].

Gillespie provides a procedure for calculating the inertia of the entire transmission system. This

inertia is the total inertia of all of the main moving parts taking into account the effects of the gear ratios.

Inertia is amplified by gearing in the same way as the torque force.

Marco Monster’s article Car Physics for Games [Monster 2001] features a good discussion on how

drive train output torque force is used to accelerate a vehicle. This article covers key issues but doesn’t go

into complex detailed discussions of vehicle physics. Monster talks about how the acceleration of a car is

due to a traction force from the road. Whenever there is a difference in the linear speeds of the tyre and road

a friction force is generated that opposes the difference. This friction force is known as ‘traction’. The

magnitude of this force depends on the slip ratio between the ground surface and the tyre surfaces, as well as

the characteristics of the two surfaces themselves. For example, a loose gravel surface will always provide

less traction that a tarmac surface.

Ted Zuvich has published a more in depth article on car simulation titled Vehicle Dynamics for

Racing Games [Zuvich 2000]. This covers a wide variety of issues and cites many respected works in

vehicle dynamics including Gillespie’s book [Gillespie 1992]. Zuvich also talks about the environmental

factors acting upon a moving car such as air resistance and rolling resistance from the tyres interacting with

the road surface and within the tyre system. Much of Zuvich’s discussions are regarding environmental

factors cited from Gillespie however, Zuvich’s text is more useful as his discussions are in a more readable


With a typical passenger car, below 60MPH rolling resistance is the main opposing force, at 60MPH

air resistance is approximately equal to rolling resistance and from then on becomes the dominant opposing

force. Rolling resistance and air resistance are the major factors limiting a vehicles acceleration and final top

speed. If the density of the surrounding air is known, the drag or air resistive force acting upon a car can be

calculated from its speed, frontal area and drag coefficient. The coefficient of drag is determined from wind

tunnel tests and is unique to the shape of each individual car. The air resistance force on the car increases

with the square of the car’s velocity. The equation Zuvich provides for air resistance force is cited from

Gillespie’s text and is used in this project.

The rolling resistance increases linearly with car’s velocity. The rate of rolling resistance force gain

is represented by a constant coefficient; this coefficient is determined by the unique combination of the tyre

and road surface. The rolling resistance values are not easily calculated and are normally found through

practical experimentation. The rolling resistance of a vehicle’s tyre also varies depending on the direction in

which the steering wheels (front wheels) are headed. You would expect a greater rolling resistance if a


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


vehicle was travelling at high speeds and a quick turn was made on the steering wheel. The equation Zuvich

cites from Gillespie formed the basis of the rolling resistance calculations at the wheels that where used in

this project.

3.2.3 Suspension, Traction and Steering

More research was carried out on suspension than initially planed due to the fact that it wasn’t

possible to find an existing physics library to handle the mechanics of spring and damper systems. Tom

Duncan’s A-Level Physics textbook [Duncan 1988] describes how vehicle spring-dampers are an example of

critically damped harmonic oscillators (CDHO). A spring system with no damping effects is known as a

simple harmonic oscillator (SHO). A mass attached to a SHO, once released tends to oscillate infinitely in a

sinusoidal pattern, in real life however energy is dissipated through heat and other forms and the mass will

slowly but finally come to rest. Here the mass is the fraction of the total vehicle weight supported by the

suspension spring in question. In contrast a mass in a CDHO comes quickly to rest as the damper removes

energy from the system. There is little to no sinusoidal motion depending on the abilities of the damper.


Vehicle Body Wheel
Vehicle Body


Figure 3.1: Simplified vehicle suspension system.

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ vehicle was travelling at
Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ vehicle was travelling at

Figure 3.2: Simple harmonic oscillator. Figure 3.3: Critically damped harmonic oscillator.

Figure 3.1 shows a simple vehicle suspension system modelled as the vehicle body resting on the

wheels via a spring and damper system. The application of a single spring-damper system and wheel is used

to further simplify the situation rather than four separate spring-damper and wheel systems. Ignoring the


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


damper and energy losses from oscillation, if the mass if released from a positive or negative height (as

would be the case when traversing rough terrain), the mass would oscillate indefinitely as show in Figure

3.2. However including the damper into the equation would absorb all the energy from the oscillations and

restore the mass to its original position of rest. The properties of such a damper would determine the time

taken for the mass to return to its original position or in other words, how bumpy the ride will be when

traversing rough terrain.

Traction and steering are of particular importance to one another and hence will be discussed

collectively. A tyre has far from infinite ability to grip the road and there are several variables determining

the tyre’s performance, there are however some methods that can be used to determine a reasonable

approximation of a tyre’s performance. The maximum acceleration (measured in G’s) that a tyre-surface

combination can create is independent of tyre load [Beckman 1991b]. By multiplying the G limit and tyre

load the maximum traction force can be determined. For example, new tyres on a tarmac road will

obviously have greater maximum traction than worn out tyres on a gravel track. So traction therefore

depends upon the adhesion between the tyre surface and the ground surface. The limits of this adhesion give

the maximum vehicle acceleration achievable. Refer to figure 3.4 below.

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ damper and energy losses

Figure 3.4: Example tyre traction budget. Image from [Beckman 1991b].

Both longitudinal and lateral accelerations have to be produced within the traction limit of the tyre so

it is possible to reach this limit while accelerating hard and turning rapidly. In this situation, the tyre will

begin sliding rather than rolling in its intended direction. This sliding can cause the car to skid outwards of a

circular turn rather the following the turn around.

As the tyres encounter the rolling and sliding motion, the friction force with the road surface cannot

be represented by a single coefficient because rolling tyres experience what is known as static friction while

sliding tyres experience kinetic friction. Static friction applies only between objects in contact (like the tyre


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


and ground surfaces) but not in motion with respect to each another and Kinetic friction applies between

objects in contact and moving with respect to each other. The magnitude of the Kinetic friction is always

less than that of the Static friction so it takes more force to set an object in motion that it does to keep it in

motion. A tyre simply exists in either a rolling or sliding state depending on its motion with respect to the

ground surface and there is a gradual transition between the two states.

Both Zuvich and Monster talk about a good method to calculate the friction coefficient for a given

ratio of slip between the road and tyre surfaces. A 2D curve can be made of how the friction coefficient of a

surface varies with the slip ratio; this is known as a traction curve. The nature of friction force variance is

unique to the tyre/surface combination although trends do apply. With slip ratios below 20% the tyre is

experiencing basically static friction, above this kinetic friction becomes the main force. Traction curves

provide an approximation of tyre performance, Figure 3.5 below provides an example curve for a standard

passenger car tyre on a tarmac surface road.

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ and ground surfaces) but

Figure 3.5: Example traction curve for tarmac road surface.

This slip ratio tyre performance approximation is ideal for the Vehicle Dynamics Engine project,

however for industrial quality tyre simulation the “Pacejka Magic Formula” is normally used [Gaal 2002].

This magic formula incorporates many tyre factors like load and pressure into a complete model then by

using a series of complicated equations and about 25 constants the Pacejka formula can be used to

accurately describe all longitudinal and lateral tyre forces experienced within a tyre.

As mention before, tyre forces must provide lateral components to handle steering. Wheel steering

orientation often differs from their actual direction of travel and the difference between the wheel heading

direction and the wheel travel direction is known as the slip angle. Gillespie describes the calculation of slip

angle and how it generates lateral forces [Gillespie 1992, pp. 198-215]. Turning is normally started by drive

steering inputs; this creates slip angles at the front wheels. The friction force acting against the front tyre

sides produces a vertical axis rotation or yawing torque force on the entire vehicle body. As the vehicle

body begins to turn around, the rear wheels also develop slip angles. The rear wheels add to the torque on

the vehicle body, helping the yawing procedure of the vehicle. A constant has been defined that represents

the lateral force at the tyre per radian of slip angle and is knows as the “cornering stiffness”. The cornering


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


stiffness provides a method of approximating the turning characteristics of a tyre. The pacejka magic

formula on the other hand dynamically calculates cornering stiffness based upon the current tyre state but

because of its reputation it is beyond the scope of this project.

3.2.4 Uneven Grounds and Gravitational Effects

On even ground you can assume that gravity has no resulting effect on the vehicle since the vehicle

will always be in contact with the ground via its four wheels. The weight of the vehicle (body, tyres and

passengers etc) is exerted on the ground surface via its four wheels so equal and opposite normal forces

must be exerted on the vehicle also via its four wheels to maintain equilibrium. In theory this is so the

vehicle doesn’t float off into the air or sink into the ground.

On uneven ground however it’s a different situation. Several A-level mathematics, mechanics and

even physics text books provide solutions for there situations, one such text book is Pearson’s A-level study

guide for Physics which describe how the resultant force acting on a mass can be calculated [Pearson 2000,

p.16]. Refer to figure 3.6.

-N N F Figure 3.6: Gravitational effects on a vehicle on sloping ground.
Figure 3.6: Gravitational effects on a vehicle on sloping ground.

In this case the ground is slanting at a specific angle and the normal force provided by the ground

surface only balances out a portion of the weight force exerted by the mass. The remaining component acts

along the plane causing the mass to move down. Bear in mind, this is in 2-Dimensional space; this becomes

more complex when performed in 3-Dimensional space.

Uneven ground also affects the weight distribution on a vehicle. If the vehicle is on level ground,

stationary (ignoring weight distribution caused by acceleration and inertia for the moment), the centre of

gravity of the vehicle is exactly in its mid-point, and the tyres are of equal distance from this centre of

gravity position then all the tyres get an equal share of the weight of the vehicle body. In the case of uneven

ground as shown in figure 3.6, it’s obvious that now the two back tyres will have to bear more weight than

the two front tyres. This is because the downward projected position of the vehicle’s centre of gravity lies

closer to the rear wheels ground surface contact point than the front wheels ground surface contact point.

A vehicle always has a constant mass regardless of its position or orientation but its weight can

differ based on the orientation of the ground surface or position on the earth’s surface. On even ground there

is an equilibrium of two forces the weight of the vehicle and the opposite normal force exerted by the


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


surface on the vehicle. On uneven ground the weight force exerted by the vehicle reduces as a component of

the initial weight is now being used to cause motion down the plane. This also affects the suspension system

of the vehicle.

Finally the stability of the vehicle is in question when traversing uneven ground. Picture a rectangle

formed on the surface of the ground with its four points represented by the contact positions between the

vehicles four tyres and the ground surface. Now project the vehicle’s centre of gravity vector position

directly downwards until it intersects the ground surface at a certain point. If this intersection point lies

within the aforementioned rectangle the vehicle is said to be stable. If it lies on the boundaries of the

rectangle then the vehicle is said to be marginally stable or on the brink of capsizing (a small nudge could

topple the vehicle). If it lies outside the boundaries of the rectangle the vehicle is unstable and should

already be toppling if it hasn’t already.

3.3 Computer Implementation Research

The background research for the computing aspect of this project involved two main sections. The

first section involves the use of third party software, middleware and libraries. It would be ideal to make use

of existing libraries to shorten or quicken development time, providing the project with special expertise and

features such as sound output, joystick device input, driving wheel input and rigid body physics simulation.

The second section involved how best to structure the VDE project from a programmer’s point of view.

3.3.1 Software Development Kits and Libraries

One possible method of employing some of the required physics would have involved using a

software solution such as the MathEngine’s Karma library [MathEngine 2001]. Such sophisticated software

would have allowed the easy modelling of complicated springs, dampers and joint mechanics. It would have

made possible more accurate simulations of the vehicle’s suspension system in particular. Unfortunately

MathEngine provide trial versions of the Karma library to only established software developers that have

the intention to buy the program in the long run. A sub division of MathEngine known as Critical Mass Labs

provides a similar physics library named Vortex which is basically a watered down version of the Karma

library and made specially for academic use. However Vortex is limited to a 30 day trial version [Critical

2001] which isn’t reliable for a project such as this.

Other freeware alternatives included Russell Smith’s Open Dynamics Engine (ODE), a free physics

library used for simulating rigid body dynamics such as ground vehicles [Smith R. 2001]. Unfortunately the

software is currently at an early beta testing stage of development and is poorly documented. Several demo

programs built with the ODE are provided on the website and in the library. Two example demos included

are a tricycle game which involved driving over ramps and a collection or random convex shapes falling

from the sky and stacking upon each another. These demos were impressive but showed faults within the


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


ODE, faults like random crashing. ODE could therefore not be used as a result of its unreliability and lack

of documentation.

There are several application programming interfaces (API’s) that could be used to handle graphics

processing and display in the vehicle dynamics engine. Two of the well known API’s include Microsoft’s

Direct3D and OpenGL. Direct3D was chosen over OpenGL based on experience with the latter and the

project time window would not permit learning another API from scratch. Direct3D is a well documented

library which masks the compatibility issues and contrasting architectures of the modern day graphics cards

and computer hardware from the software programmer.

For handling program input, DirectInput library from the Microsoft’s DirectX suite seemed a logical

choice. This library is freely available software that allows any compatible input device to be programmed

via a single generic interface. Keyboard, joystick and mouse devices are supported. DirectInput is a part of

the DirectX suite of libraries currently at version 9.0c. The DirectInput library is mature, reliable, easy to

use and well documented.

Audio output is one of the project requirement, to this end research into the use of Microsoft’s

DirectSound library was performed. However unlike DirectInput, DirectSound is less well documented and

would require a lot of work to integrate into the project.

File manipulation techniques and procedures would also be required in this project to retrieve data

such as car specification information from external files and directories. There are functions within

Microsoft’s DirectX API and other standard source files that could help implemented these functions.

3.3.2 Program Development Cycle and structure

Vehicles, in this case car’s are complex machines but it is possible to break them down into a series

of simplified modules. Example simplified modules might be steering system, wheels and suspension

systems etc. Both Racer and TORCS reviewed previously in the report use an object oriented approach to

designing and implementing their cars model systems. There are many approaches that can be taken to

decompose a motorcar into modular forms, however finding the more appropriate method depended on the

scope of the simulation. For extreme accuracy and realism, modules could be broken down to levels as low

as individual pistons and gears, or even lower. Of course this is too extreme for this project; a more realistic

situation would be decomposing the car’s drive train system into smaller modules for the engine, clutch,

transmission and differential etc. Equilibrium between good organisation and a reasonable number of

modules must be made. Too many modules could mean large exchange of data which could complicate

programming and degrade program performance.

The structure and organisation of the vehicle modules for both the Racer and TORCS examples

reviewed previously have been examined and evaluated. For the purposes of comparison, two diagrams are

provided that show how each vehicle simulator decomposed its car model into simpler modules. The


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


modules are programmed in the form of C++ classes in both cases. Figure 3.7 shows Racer’s car model

structure. Parents in the hierarchy store their children, e.g. in Racer the engine object is stored inside the car

body object and the engine object contains the differential object. The names of certain modules are plural;

this means that there may be more than one instance of that version of the module. For example, the module

“wheels” means that there may be more than one instance of wheel; it does not mean that there is a single

module named wheels.

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ modules are programmed in

Figure 3.7: Module structure in the Racer car model.

The diagram above is a simple and efficient solution to the problem. As most modules are at the

same level, communication is straight forward. Although Racer is more ambitious in terms of realism than

TORCS, it has a much simpler car structure. Figure 3.8 below shows the approach taken by TORCS. The

car model structure of both Racer and TORCS are quite similar and work well in practise. Both served as

inspiration for the car structure employed in the vehicle dynamics engine.

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ modules are programmed in

Figure 3.8: Module structure in the TORCS car model.

3.4 Methods and Conclusions

The background research was required to be wide ranging and multi-disciplinary given the nature of

this project and as such has it been carried out. Looking into the physics of how car simulations can be

implemented was challenging. An appreciable amount of reading around mechanical physics was a


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


prerequisite to understanding much of the background research but it would have been impractical to

present all of this background reading here. As well as providing the required knowledge for building a car

simulation, research also provided a source of encouragement and inspiration. The works of Ruud Van Gaal

was particularly encouraging as he is the sole developer of Racer. This shows even complicated projects do

not always require a large development team.

A brief compilation of key points relating to the final methods that will be used in the design and

development of the vehicle dynamics engine are presented below:

The entire project will be implemented using the C++ programming language and will be powered by

the Microsoft DirectX API.

I have chosen the Microsoft’s DirectX API over the OpenGL graphics library because of my familiarity

with the DirectX API in the past. DirectX also provides tools to deal with components such as

multimedia (sound, music, video etc) and input which might be used in this project. Rather than use

OpenGL for the graphics and DirectX for multimedia and input I decided to stick with DirectX.

I have chosen C++ over Java because C++ is faster than Java and hence better suited for real-time

application development. Such is the case for this project. It is said that learning 100% of one is like

learning 80% of the other so the transition from Java to C++ should be fairly straight forward.

The vehicle physics will be implemented based on research sources and theories covered previously in

the report.

Tutorials on how to use 2D painting and 3D modelling programs can be found on the internet or within

the programs them selves. These programs will be used to create the virtual 3D simulated worlds in

which the vehicle physics engine will be showcased.

Tutorials and sample code regarding using the force feedback Driving Wheel as an alternate input

source can be found on the web and probably within the package.

The engine will be accessed through a function call, this function call will be fed parameters such as car

body object, car wheel objects, input method (keyboard or driving wheel), landscape object, colliding

obstacles, car properties (aerodynamic factors, engine specifications, weight etc). The function might return

information like if collisions occur, what objects collided etc.

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham




  • 4.1 Introduction

Suitable middleware technologies with which to build the vehicle dynamics engine had to be found

before design of the application officially began. These technologies were briefly introduced in previous

chapters and are discussed further here in more depth; these technologies span from hardware to software.

With the choice of middleware technologies decided, the design of the vehicle dynamics engine

application framework could commence. This framework provides an essential background functionality

foundation upon which to construct the remainder of the simulation. Examples of what this includes are

timing, user input handling and 3D model rendering etc. This chapter provides a discussion of both the

architecture and implementation of this application framework.

  • 4.2 Hardware Technology Specifications

The vehicle dynamics engine was intended from the beginning to be executable on an average

modern day desktop or laptop personal computer. At the time of writing even average desktop and laptop

PC’s are more than adequately specified. Current desktop and laptop PC’s typically operate in excess of

1.00GHz; offer hardware accelerated graphics and provide stereo 3D sound output. Such is ideal providing

that the graphics drivers are at least DirectX 8.1 compliant, which is the same DirectX version used to

develop this application.

In terms of hardware requirements it is necessary to duplicate the main controls of a typical car. The

best input solution is unquestionably a racing package such as the Canadian joystick manufacturers ACT

LABS which includes a steering wheel, three pedals and a gear shift level, however due to budget and time

requirements the only suitable alternative had to be employed, the standard desktop PC keyboard. The

keyboard is based on two-state logic; contact and no contact while a racing package’s wheel could have

several states depending on its orientation or a racing package’s pedals could have different states

depending on its position; released, fully compressed or different positions in-between. As a result, specific

measures will have to be taken within software to compensate for this drawback. The standard keyboard

keys used for racing games include the W, A, S, D, Up and Down keys and how they are used to

compensate for a fully functional racing package will be discussed in later sections.

  • 4.3 Software Technology Specifications

Decisions on which software technologies would be used were made at the time of the provisional

proposal. Programming language and development environment, as well as graphics, sound and user input


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


API’s were all selected. These decisions where based upon the author’s previous experience as well as

background research.

The vehicle dynamics engine is written in C++ using Microsoft’s Visual C++ 6.0 Integrated

Development Environment, IDE. For graphics output the Microsoft’s Direct3D API is used. Significant

previous prior experience with both Visual C++ and DirectX was the main factor in these decisions.

However no prior experience was possessed with regards to audio output and user input. C++ was chosen

over alternatives like Java and Basic because of its suitability in handling real-time applications, as is the

nature of the vehicle dynamics engine. On compilation C++ code is converted into machine code which runs

a lot faster than the Java and Basic alternatives. C++ is also an industrial standard for building applications

such as this.

DirectX also comes with a suite of sub libraries such as Direct3D, DirectAudio and DirectInput

which can be used to cater for all programming needs concerning graphics, music, sound and input handling

from various input devices.

4.4 Application Framework Design and Architecture

Appreciable time was given to determining how best to structure the simulation engine. Ideally

source code should be logically organized as a series of distinct components. This allows differing areas of

the program to be built in isolation and reduces the chances of introducing bugs that are duplicated in the

whole application. Taking extra time to design a solid framework at the outset no doubt prevented serious

difficulties later in the development of the project.

The framework has two main components, the program component and the engine component.

Figure 4.1 shows an overview of the proposed application framework hierarchy.

Simulation Engine Program Engine Component Component Level 3: Resource Core Manager Level 2: High Level Functions
Level 3:
Level 2:
High Level
Level 1:
Low Level
Level 0:
API Library

Figure 4.1: Application framework hierarchy.


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


The program component will contain all the code that makes use of the simulation engine wrapper

functions for the DirectX application programming interface to create the required simulation environment,

i.e. the code within this component will be responsible for creating the application window, initializing

DirectX, setting up the simulation environment (setup objects, sounds, lights, textures etc) and proceeding

into the application execution loop.

The engine component comprises of several levels of functionality. Level 0 contains all the DirectX

API libraries and files needed to support the application. However, the interface to these functions is bloated

and requires several steps or lines of code to get certain tasks accomplished. Inserting all this code within

the program component would not be advisable and hence a set of wrapper functions had to be created in

order to provide easy access in the form of few lines of code to accomplish these tasks. All these wrapper

functions are embedded in Level 1.

Level 1 of the engine component contains wrapper functions for graphics, audio, input and file

manipulation. They contain simple functions for example to initialize Direct3D, DirectAudio and

DirectInput for keyboard and mouse devices. This layer also contains class definitions for graphic-related

objects such as images, objects, terrain, cameras, lights, sprites and 3D lines, audio-related objects such as

sound and music and input-related objects such as keyboards and mice that can be created and manipulated

by the programmer within the program component.

Level 2 of the engine contains higher level functions that utilises the lower level to perform more

sophisticated processes. Examples of functions that could reside in this layer include collision detection and

response (utilising level 1 objects, terrains etc), Artificial Intelligence routines, etc but in the scope of this

project this is where the vehicle dynamics engine will reside and utilise level 1 objects (vehicle mesh)

terrain (ground surface), sounds (vehicle noises), sprites (heads-up display) and keyboard (user-controlled

input method) etc.

Level 3 of the engine contains the application core, a structure that links all the other levels together.

This structure contains the application entry point as well as miscellaneous functions that handle the engine

window, console, timing, basic maths, etc.

The engine component also contains resources which are basically miscellaneous entities such as

icons and cursors required by the application and a resource manager to handle loading and using these


4.5 Application Framework Implementation

Although limited in functionality, building the simulation engine is not a trivial task. Some

knowledge of the complicated Win32 API is required. Fortunately the Microsoft DirectX 8.1 SDK comes

with some descent examples on how to setup and create the basic application window as well as handle

windows messages but that’s as far as it goes, it contained no information on programming structures. There


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


wasn’t sufficient time to learn all the advanced C++ programming techniques initially in the simulation

engine’s development so it had to be learnt during which often involved constantly updating the simulation

engine’s code. However because of the structure initially conceived during the design phase it was a

relatively straight-forward procedure and didn’t require a lot of code re-writing and deleting.

4.5.1 Engine Files

As explained initially, the design and development of the simulation engine was finalised after

several refined attempts. This section represents the final implementation of the simulation engine. The

simulation engine is very similar to a computer game engine as it wraps up the underlying complexities of

hardware compatibility, rendering, 3D mathematics etc in simple to use interfaces and functions so the

application programmers can do their jobs a lot more easily and efficiently. An example, taken directly from

the simulation engine is the simple function ‘hexCore.setupEngine. From the application

programmers perspective this is the only line of code they have to use in order to use the simulation engine

core object to setup the window icon and cursor, create and register a windows class, create and setup an

application window, initialise Direct3D, initialise DirectAudio, initialise DirectInput, and enter the program

loop. However from the engine programmer’s perspective this single high level line of code is equivalent to

about 50 lines of low level code to actually perform the tasks. Keep in mind that even the 50 low level lines

of code are based upon the API library functions that could even contain more. The point is to make the

simulation engine as modular as possible so the vehicle dynamics engine could be inserted and used or

removed as efficiently as possible. Level 0: API Library

This level contains the numerous libraries and source files from Microsoft’s DirectX API that are

required to support the simulation engine. API’s like this are designed so you can use them but don’t have to

worry about how they work just that they do what they are supposed to do. The libraries used include;

DSound.lib, dxguid.lib, dxerr8.lib, dinput8.lib, d3dx8.lib, d3d8.lib, winmm.lib, kernel32.lib, user32.lib,

gdi32.lib, winspool.lib, comdlg32.lib, advapi32.lib, shell32.lib, ole32.lib, oleaut32.lib, uuid.lib, odbc32.lib

and odbccp32.lib, some of which are windows libraries and other DirectX libraries. As mentioned before,

how each and every library works is not known but the help documents provide you with the important

functions and interfaces need for application development. Level 1: Low Level Functions

The low level structures and functions act as wrappers from the API library interfaces and functions.

These low level functions are divided into four main categories; graphics, audio, input and files. Each

function within this level has to be encapsulated within a structure like a class because leaving the functions


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


global would impose problems on the application programmers like keeping to strict function names that

don’t collide with engine functions. Each category has a base file that contains all structures and definitions

required and a class file that contains all the classes for the category.


The graphics base file contains constants, functions and structures used by the graphics classes.

Constants in this context refer to text that represents constant numbers to make the application

programmer’s job easier. Functions refer to graphics-related mathematical functions that are constantly used

through-out the application. Structures include vertex structures for meshes for example that contain

position, normal, colour, specular and texture coordinate information.

The graphics class file contains the actual class definitions of several graphics entities including the


Graphics Class: Manages all other graphics classes, handles printing text to screen and controls the

graphics device responsible for what is visible on screen. Examples of what this device can do include

displaying fog, displaying lights, setting object shade modes and changing the view-port. The graphics

also contains a crucial ‘sync’ function that whenever called updates everything on screen with initial


Image Class: Responsible for creating, loading and manipulating images. Examples of what this class

can do include blurring images, loading images from file and taking screen shots.

Objects Class: Responsible for creating, loading and manipulating 3D mesh objects. Examples of what

this class can do include loading objects from file, translating, rotating and scaling the object.

Eland Class: Responsible for creating, loading and manipulating 3D tile terrain objects. Examples of

what this class can do include creating a terrain from a height map, colouring a terrain and determining

point on the terrain so objects can traverse on its surface.

Camera Class: Responsible for creating and manipulating the viewing camera in 3D space. Examples

of what this class can do include focussing at a point in 3D space or freely moving about, rotating and


Light Class: Responsible for creating and manipulating 3D lights. Examples of what this class can do

include setting light colours, types (spot, directional or point), position in 3D space and range.

Sprite Class: Responsible for creating and manipulating 2D sprites. Examples of what this class can do

includes assign images to sprites, position sprites and rotate sprites.

Line Class: Responsible for creating and manipulating 3D line objects. Examples of what this class can

do include colouring lines, positioning lines and rotating lines.


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham



This component is responsible for everything heard out of the speakers while the application is

running. The base file contains structures to be used to load sound and music files from external sources and

the class file contains the definitions of the audio class, the sound class and the music class, all described


Audio Class: Responsible for managing the audio device that makes audio possible, used by both the

sound and music classes. Set’s up application audio.

Music Class: Responsible for creating, loading and manipulating music. Examples of what this class

can do includes playing music, stopping music, looping music, positioning 3D music and changing the

music tempo.

Sound Class: Responsible for creating, loading and manipulating sounds. Examples of what this class

can do include playing sounds, stopping sounds, looping sounds, positioning 3D sounds and changing

the sound frequency.


This component is responsible for interaction between the user and the application while the

application is running. The base file contains macro’s to make easier the process of input data collection and

processing. The class file contains the class definitions of the input class, the keyboard class and the mouse

class, all described below:

Input Class: This manages the input device required to retrieve input from the keyboard and mouse

hardware. It also initializes input detection when the program is run.

Keyboard Class: Only one instance of this class is required as the user only uses one keyboard.

Examples of what this class can do includes detect keyboard states concerning specific keys and relay

them to the querying function.

Mouse Class: Only one instance of this class is requires as the user only uses one mouse. Examples of

what this class can do include detect mouse states when mouse buttons are being pressed or the mouse

wheel is being moved.


This component is responsible for file manipulation, i.e. loading, creating and manipulating files.

The base file contains constants used by the class and the class file contains a single file class definition of

which only one instance is made. Examples of what this class can do include opening files, making files,

reading from files, writing to files and opening files to append to.


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


Level 2: High Level Functions

This section is reserved for the vehicle dynamics engine and other high level functions such as

collision detection and artificial intelligence that could be implemented later but are beyond the scope of the

project. The vehicle dynamics engine will be described in the next chapter.

Level 3: The Application Core

The core is linked to all the layers and is responsible for everything else needed by the application

but not covered by the lower layers. The core provides the following functions:

Miscellaneous mathematics and mechanical functions.

Debug error message processing and handling and displaying.

Window registering and setup.

Engine timing (required for the vehicle dynamics engine) and screen refresh rate calculations.

Debug console setup and control (changes engine properties while application is running).

Displaying debug information on the screen.

Windows handling, refreshing, updating etc.

Set’s up the entire engine.

Resource Manager

Resources in the context of the simulation refer to files that are embedded within the executable files

once it’s been compiled and created. The visual C++ 6.0 IDE provides the manager. Examples of the

resources used in the simulation engine include the executable icon, the application cursor and the

application console image.

4.5.2 Program Files

Files contained within this component make use of the simulation engine files to create applications

like the simulation environment used for the vehicle simulations. Below is an example code written as a

program and uses the simulation engine to create an environment.


This line of code will instruct the core to tell the graphics object to setup Direct3D and the graphics

device with a 1024 by 768 resolution, a 32 bit colour depth and in windowed mode signified by a 2.


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


light sun;





These five lines of code would create a light object called ‘sun’, set all it’s properties and attributes

(specular, diffusion etc) to values that make the light simulate a sun source and finally update these values

with the graphics object.

image dune("media/2D/Eland/dune.jpg");

image hmap("media/2D/Eland/hmap.jpg");

These two lines of code load two images from the hard disk, ‘dune.jpg’ and ‘hmap.jpg’ respectively

and assign them to image objects of similar names. Figures 4.2 and 4.3 represent the dune and hmap images.

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ light sun; sun.makeSun(); sun.setAmbient(0.5f,0.5f,0.5f,0.5f);

Figure 4.2: The dune.jpg image.

eland land;





Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ light sun; sun.makeSun(); sun.setAmbient(0.5f,0.5f,0.5f,0.5f);

Figure 4.3: The hmap.jpg image.

Eland is short for electronic land and basically represents tiled terrains in the simulation engine.

These five lines of code create and eland object called land, textures the land object with the dune image

previously created and finally uses the hmap image to create a terrain height map. This is when an image is

composed of two colour like white and black where for example white represents up and black down, both

by a magnitude of 1 unit and the different shades of grey are all in-between. The extra attribute 20.0 refers

to a multiplication of the magnitude 1 unit by a factor of 20.0. The colorise function basically sets the colour


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


of individual vertices based on their height from the 0 unit y axis level and finally the normalize function

recalculates the eland’s vertices normal as they need to be updated since the mesh structure was changed.



The camera object as already been pre-instanced once the application is run and the instance name is

called ‘cam’. These two lines of code sets the position in 3D space and point position in 3D space of the

camera object.





This code segment represents the application loop which continually renders the graphic objects to screen

via the sync command.

4.5 Engine Testing and Evaluation

The simulation engine has a lot of functionality and therefore it would not be appropriate to discuss

all of the test procedures and results as it would be too extensive for the project report size limit and it

would diverge from the main focus of the project. The simulation engine was developed to compliment the

vehicle dynamics engine so the real test comes when the vehicle dynamics engine uses the simulation

engine to perform the simulations. The tests and results for this case will be summarised in later sections.

Some of the tests and results carried out on the simulation engine include:

Running above code which successfully compiled and the figure 4.4 below shows the error-free result.

Audio functionality was tested and confirmed by loading and playing sounds and music.

Graphical functionality was tested and confirmed by loading 3D meshes with and without textures.

Input functionality was tested and confirmed by creating a program to display mouse and keyboard input

on the screen.

File functionality was tested and confirmed by manipulating external files (open, close, append, delete).

Other graphical functions where tested and confirmed such as using 3D lines, changing the graphics

device properties and observing the effects on screen (e.g. fog effects), using lights, sprites and elands

where also confirmed to be working.


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ Figure 4.4: The example

Figure 4.4: The example program code output.

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham




  • 5.1 Introduction

Every simulated vehicle is contained within a vehicle base class. The vehicle base provides a virtual

chassis in which to mount the drive train, wheel and suspension systems. The vehicle base also aids

interaction between the systems. For example drive train torque accelerates the drive wheels and therefore

the vehicle. Acceleration then causes movement of the suspension. This chapter describes the architecture

and implementation of the vehicle base class.

The vehicle dynamics engine cannot be tested alone, it must be tested with the simulation engine and

hence this chapter contains to testing and evaluation section. However the next chapter provides the testing

and evaluation of the entire simulation engine and vehicle dynamics engine system.

  • 5.2 Vehicle Class Design and Architecture

Every variable, structure and function related to the vehicle dynamics engine will have to be

encapsulated within a class for the sake of modularity and help resolve application programming-side

conflictions. The vehicle class is composed of the following entities:

Physics-related variables: Stores results from the vehicle physics calculations.

Physics-related functions: Perform the necessary vehicle physics calculations.

Vehicle properties structure: Stores the properties of the loaded vehicle.

Object class instances: Contains the 3D mesh data for the vehicle body and wheels.

Line class instances: Debug illustration lines to show specific direction vectors.

Sound class instances: Stores the vehicle engine, brakes and horn sounds.

Eland class instances: Stores the terrain on which the vehicle traverses.

Image class instances: Stores the heads-up display image.

Sprite class instances: Displays the heads-up image on the screen.

The simulation engine handles rendering so all the vehicle dynamics engine has to do is manipulate

the entities positions, rotations, scales, etc and the simulation engine does the rest. All the vehicle physics

theory will be implemented in functions sub-divided into unique components. These functions when called

will perform the necessary physics calculations based on the vehicle physics theory as well as using the

chosen vehicle properties and store the results in the physics variables. Other functions will control updating

the objects, lines, sounds and sprite instances based on the result of the calculations.


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


5.3 Vehicle Class Implementation

This section seeks to explain how the vehicle class was implemented and how the physics theory

was applied to create the vehicle dynamics engine.

5.3.1 Vehicle Physics Theory

The vehicle physics theory is the foundation of the vehicle dynamics engine. All functions and

calculations made within the engine were based on this theory. Explanation within this section will begin

with linear or straight line physics and take into account acceleration, resistance forces, braking, weight

transfer, the drive train etc. The section will then move on to turning physics explaining steering and the

forces that result on the vehicle body and wheels. Uneven terrain is then discussed and it’s implication in

contrast to even terrain and finally a brief look at a simple suspension system implemented for the vehicle.

Rather than constantly explain what each and every symbol is, the nomenclature section at the

beginning of the report contains a description of what each and every symbol and variable represents.

A lot of the physics explained in this section is based on the car physics theory by Marco Monster

[Monster 2001]. Some of the explanations have been adapted to fit into the context of this project and makes

use of other theories accumulated from other background research sources. The Marco Monster theory is

based on a 2D simulation of car physics and hence a lot of work had to be done to convert and make the

theory applicable to 3D scenarios. Linear Physics

Moving in a Straight Lines

A car driving in a straight line has several forces acting on it; these include the tractive force, i.e. the

force delivered by the engine via the rear wheels, the air resistance, i.e. the aerodynamic drag on the car and

the rolling resistance, i.e. the frictional force caused between the road and wheel surfaces and the axle

friction etc. All these forces can be expressed by the equations below:

F traction = u * Engineforce

F drag = - C drag * v * |v|

F rr = - C rr * v

At low speeds the rolling resistance is the main resistance force, at high speeds the aerodynamic drag

force takes over in magnitude. At approximately 100 km/h (60 mph, 30m/s) they are equal according to

[Zuvich]. This means that C rr must be approximately 30 times the value of C drag .


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


The air resistance coefficient or constant C drag is approximated by the following formula from Fluid

Mechanics by Landau and Lifshitz, [Beckham] chapter 6, [Zuvich]:

F drag =

0.5 * C d * A * rho * v


Using the values of air density as 1.29 kg/m 3 and for a Chevrolet Corvette C5 frontal area is

approximately 2.2 m 2 and C d as 0.30 which depends on the car shape determined via wind tunnel tests, the

drag coefficient is about 0.4257.We’ve already found that C rr should be approximately 30 times C drag so this

a rolling resistance constant value of 12.8.

The total longitudinal force is therefore the vector sum of these three forces.

F long =

F traction + F drag

+ F rr

Keep in mind that the air resistance force and rolling resistance force are in opposite directions of the

traction force when moving in a straight line. So if the longitudinal force is positive the vehicle is

accelerating, if negative the vehicle is decelerating and if zero then the vehicle is moving at a constant

velocity. The acceleration of the car is determined by the net force of the car and the car’s mass using

Newton’s second law:

a = F / M

The car’s velocity is determined by integrating the acceleration over time using the Euler method for

numerical integration which involves summing the car’s velocity by the multiplication of its acceleration

and a time increment in seconds between subsequent calls of the simulation engine. The same procedure is

done for the car’s position and both processes are represented by the equations below:

v = v + dt * a

p = p + dt * v

With these three forces you can simulate car acceleration fairly accurately. Together they also

determine the top speed of the car for a given engine power.


When braking, the traction force is replaced by a braking force which is oriented in the opposite

direction. The total longitudinal force is then the vector sum of these three forces.


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


F long =

F braking + F drag

+ F rr

F braking = -u * C braking

In this simple model of braking, the braking force is constant.

Weight Transfer

An important effect when accelerating or breaking is the effect of dynamic weight transfer. When

braking hard the car will nosedive and during accelerating, the car leans back. The effect of this is that the

weight on the rear wheels increases during acceleration and the weight on the front wheels increases during

braking. Weight transfer effects are important in simulations as they add realism as well as dramatically

affect the maximum traction force per wheel. This is because there is a friction limit for a wheel that is

proportional to the load on the wheel.

F max = mu * W

For a stationary vehicle the total weight of the car is distributed over the front and rear wheels according to

the distance of the rear and front axle to the centre of mass.

W f = (c/L)*W

W r = (b/L)*W

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ F long = F

Figure 5.1: Vehicle weight transfer specifications.

If the car is accelerating or decelerating at rate a, the weight on front (W f ) and rear axle (W r ) can be

calculated as follows:


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


W f = (c/L)*W - (h/L)*M*a

W r = (b/L)*W + (h/L)*M*a

Engine Force

The engine is responsible for delivering a specific amount of torque to the rear wheels. This torque

depends on the speed at which the engine is turning or its revolutions per minute, rpm. The torque vs. rpm

relationship is not linear but is usually provided as a curve known as the torque curve whose exact shape

and height is specific for each engine type and is determined by engine tests on a dynamometer. Figure 5.2

shows an example torque curve of a 5.7 litre V8 engine found in Chevrolet Corvettes from 1997 to 2000.

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ W = (c/L)*W -

Figure 5.2: 5.7 Litre V8 engine torque curve.

Torque curves are only defined within a specific range which represents the operating range of the

engine, in this particular case from about 1000 to 6000 rpm. Any lower than 1000 and then engine will stall,

any higher than 6000 (the engine redline) and you’ll damage the engine. The curve shows the maximum

torque the engine can deliver at a given rpm, the actual torque depends on the throttle position and is a

fraction between 0 (fully up) and 1 (fully down) of this maximum. Although both torque and power curves

are represented, the torque curve is the most important in the scope of this project.

The torque from the engine (i.e. at the crankshaft) is converted via the gear and differential before

it’s applied to the rear wheels. The gearing multiplies the torque from the engine by a factor depending on

the gear ratios. Some energy is lost however, as much as 30% in the form of heat and this gives a

transmission efficiency of about 70%. The torque on the rear axle can be converted to a force of the wheel

on the road surface by dividing the wheel radius. The equation below is used to get from engine torque to

drive force, i.e. the longitudinal force that the two rear wheels exert on the road surface:

F drive = u * T engine * x g * x d * n / R w


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


Gear Ratios

As mentioned previously, gear act like torque multipliers on the crankshaft to the torque on the rear

wheels. Most cars have five to six gears, a reverse gear and a differential ratio. Below are typical gear ratios

that apply to a Chevrolet Corvette C5 hardtop [Corvette C5 Specifications].

First gear



Second gear



Third gear



Fourth gear



Fifth gear



Sixth gear






Differential ratio

x d


In low gears the gear ratio is high, so you get lots of torque but not so much speed. In high gears,

you get more speed but less torque. You can put this in a graph as a set of curves, one for each gear as in

Figure 5.3

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ Gear Ratios As mentioned

Figure 5.3: Torque curve per gear for a Chevrolet Corvette C5.

These curves however assume 100% efficient gearing. The engine torque curve is shown as well for

reference. The other curves show the torque on the rear axle for a given rpm of the axle, rather than engine.

The rotation rate of the wheels can be related to the car speed (disregarding wheel slip) if we know the

wheel radius. This means 1000 rpm of the rear axle is 36 m/s or 128 km/h car speed (80 mph).

Drive Wheel Acceleration


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


The torque from the torque curves for a given rpm is the maximum torque at that rpm. How much

torque is actually applied to the drive wheels depends on the throttle position. This position determined by

user input (the accelerator pedal) and varies from 0 to 100% of this maximum torque. To implement this, a

function is created to retrieve the maximum torque and this value is multiplied by the throttle position to get

the engine torque. The function will comprise of six torque/rpm value pairs and linear interpolation will be

used to get results in-between. This torque is delivered to the drive wheels via the gearbox and results in a

drive torque:

T drive =

T engine * x g * x d * n

where F drive = T drive / R w

The gearbox increases the torque, but reduces the rate of rotation, especially in low gears.

Engine RPM

The engine rpm is required to calculate the engine’s max torque and from there the engine’s actual

applied torque. This can be done by calculating back from the drive wheel rotation speed. If the engine is

not declutched, the crankshaft and the drive wheels are physically connected through a set of gears. If you

know the rpm, you can calculate the rotation speed of the drive wheels and vice versa.

rpm = wheel rotation rate * gear ratio * differential ratio * 60 / 2 pi

The 60 / 2 pi is a conversion factor to get from rad/s to revolutions per minute. Because the torque

curve isn’t defined below a certain rpm, a limit will have to be imposed on the result. This is needed to get

the car in motion from a standstill. The wheels aren’t turning so the rpm calculation would return a zero. A

zero rpm, the engine torque is either undefined or zero. That would mean you’d never be able to get the car

moving. In real life, you’d be using the clutch in this case, gently declutching while the car starts moving.

So the wheel rotation and engine rpm are more or less decoupled in this situation. The wheel rotation rate

can be calculated from the car speed and the wheel radius.

Slip Ratio and Traction Force

On certain situations when the car is moving at a constant speed, the rear wheels will be rotating

slightly faster than the front wheels. The front wheels are rolling and therefore have zero slip but the rear

wheels however are rotating fast and that means the surface of the tyre is slipping with regard to the road

surface. This slip causes a friction force in the direction opposing the slip. The friction force will therefore

be pointing to the font of the car. This friction force is known as traction or as the longitudinal force. The


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


traction depends on the amount of slip. The standardised way of expressing the amount of slips is called the

slip ratio which is expressed by the equation:

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ traction depends on the

The slip ratio is zero for a free rolling wheel. For a car braking with locked wheels the slip ratio is -

1, and a car accelerating forward has a positive slip ratio. It can even be larger than 1 if there’s a lot of slip.

The relationship between longitudinal (forward) force and slip ratio can be described by a curve shown in

Figure 5.4.

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ traction depends on the

Figure 5.4: A typical slip ratio curve for a 5KN load.

The exact curve shape may vary per tyre, per road surface, per temperature etc. Note how the force

is zero if the wheel rolls (0 slip ratio) and the force is at peek for a slip ratio of approximately 6% where the

longitudinal force slightly exceeds the wheel load. That means a wheel grips best with a little bit of slip.

Beyond that optimum, the grid decreases. The longitudinal force has a linear dependency on load so this

curve can be applied for all tyre types through normalisation using the formulas:

F long = F n, long * F z

F long = C t * slip ratio

Torque on the Drive Wheels

Figure 5.5 illustrates the torque on the drive wheels for an accelerating car. The engine torque is

magnified by the gear ratio and provides torque on the rear wheels. The angular velocity of the wheel is high

enough that it causes slip between the tyre surface and road, which can be expressed as a positive slip ratio.

This results in a reactive friction force, known as the traction force, which is what pushed the car forward.

The traction force also results in a traction torque on the rear wheels which opposes the drive torque. In this


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


case the net torque is still positive and will result in an acceleration of the rear wheel rotation rate. This will

increase the rpm and increase the slip ratio.

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ case the net torque

Figure 5.5: Torque on the drive wheel of an accelerating car.

The net torque on the rear axle is the sum of the following torques:

total torque = drive torque + traction torques from both wheels + brake torque

This torque will cause an angular acceleration of the drive wheels, just like a force applied on a mass

will cause it to accelerate:

angular acceleration = total torque / rear wheel inertia.

inertia of a cylinder = Mass * radius 2 / 2

The inertia of a solid cylinder around its axis can be calculated using the equation above. A positive

angular acceleration will increase the angular velocity of the rear wheels over time. As for the car velocity

which depends on the linear acceleration, you can simulate this by doing one step numerical integration

each time you go through the physics calculations:

rear wheel angular velocity += rear wheel angular acceleration * time step

Where the time step is the amount of simulated time between two call’s of this functions. This way you can

determine how fast the drive wheels are turning and therefore the engine’s rpm. Turning Physics

All the information presented in earlier sections where for the scenario in which the vehicle is

moving in a straight line. This section describes the physics involved when a vehicle turns. Simulating the

physics of turning at low speed is different from turning at high speed. At low speeds, the wheels pretty

much roll in the direction they’re pointed at. To simulate this, geometry and kinetics is required.


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


At higher speeds, it becomes noticeable that the wheels can be heading in one direction while their

movement is still in another direction. In other words, the wheels can sometimes have a velocity that is not

aligned with the wheel orientation. This means there is a velocity component that is at right angle to the

wheel. This of course causes a lot of friction. In high speed turns, wheels are being pushed sideways and all

these forces need to be taken into account.

In the situation of low speed turning you can assume that the wheels are moving in the direction

they’re pointing. The wheels are rolling, but not slipping sideways. If the front wheels are turned at an angle

delta and the car is moving at a constant speed, then the car will describe a circular path. If lines are

projected from the centre of the hubcaps of the front and rear wheel at the inside of the curves, where these

two lines cross would be the centre of the circle.

Refer to figure 5.6 the radius of the circle can be determined via geometry. The distance between the

front and rear axle is known as the wheel base and denoted as L. The radius of the circle that the car

describes is called R. The figure shows a triangle with one vertex in the circle centre and one at the centre of

each wheel.

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ At higher speeds, it

Figure 5.6: Vehicle radius of curvature while turning.

The angle at the rear wheel is 90 degrees per definition. The angle at the front wheel is 90 degrees

minus delta. This means the angle at the circle centre is also delta. The sine of this angle is the wheel base

divided by the circle radius, therefore:

Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ At higher speeds, it

If the steering angle is zero, then the circle radius is infinite, i.e. we’re driving in a straight line. The

next step would be to calculate the angular velocity or the rate at which the car turns. Angular velocity is

usually represented by the Greek letter omega, and is expressed in radians per second. It is fairly simple to



Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham _______________________________________________________________________________________ By using these last

By using these last two equations, you can determine how fast the car must turn for a given steering

angle at a specific speed. For low speed cornering, that’s all the information that is needed. The steering

angle is determined via user input. The car speed is determined as for the straight line cases. From this you

can calculate the circle radius and the angular velocity. The angular velocity is used to change the car

orientation at a specific rate. The car’s speed is unaffected by the turn, the velocity vector just rotates to

match the car’s orientation.

As stated previously, there wasn’t sufficient time to update the vehicle dynamics engine further and

one of the physics features that couldn’t be implemented was high speed turning.

  • Uneven Terrain When the vehicle traverses uneven grounds then there are other forces that come into the equations

such as gravitational forces and effects on the vehicles weight. Uneven terrain also affects the vehicles

orientation and positioning. Calculating the components of the vehicles weight when traversing uneven

ground is A-level mechanics standard and Figure 3.6 in earlier sections shows a pictorial representation of

the problem.

On level ground the weight, W of the vehicle balances out the normal force, N from the terrain

surface but while on uneven or slanting ground at a particular angle, θ the normal force required to keep the

vehicle in equilibrium is simply Wcosθ. The remainder weight component is therefore Wsinθ which causes

the vehicle to roll down the uneven terrain. This weight force is added to the total longitudinal force


F long =

F braking + F drag

F long =

F traction + F drag

+ F rr + Wsinθ

+ F rr + Wsinθ

This weight force affects the total longitudinal force of the vehicle regardless of if the vehicle is in motion

or stationary. It does not affect the lateral force of the vehicle because the vehicles wheels don’t move or roll

in this direction and hence the weight force would have to be of a considerable magnitude or the vehicle

tyres would have to be worn out for the weight force to have an effect.

  • Suspension System Due to time restrictions a simple suspension system model was implemented into the project rather

than none at all. The suspension system model was based on spring theory involving stress, stain, Hooke’s

laws and simple harmonic motion. The entire vehicle is treated as a vehicle body mass resting on the


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


underlying tyres (modelled as a single tyre) through a suspension system composed of a spring and damper

parallel arrangement. The vehicles body mass causes a negative extension in the length of the spring from

its original length, this is represented in the equation below:

F = -kx

Where F is the weight force applied to the spring, x is the extension made and k is the spring constant

[Pearson]. The minus sign shows that the force acts in the opposite direction to the extension. The spring

continuously oscillates every time the net force displaces it and is brought to rest by means of the energy

consuming damper using a linear damping mechanism. Assuming the spring is only functional within its

elastic limits, the spring has maximum and minimum extension amplitude as extreme stretching or

compression would change its elastic properties. The equations below are used to calculate the

displacement, velocity and acceleration respectively of the oscillation process against time.

  • x = Asin(ωt)

  • v = Aωcos(ωt)

a = -Aω²sin(ωt)

Where A is the oscillation amplitude, ω is the angular velocity and t is the time. Damping complicates

matters by effectively reducing the amplitude A over time. The spring extension is calculated by dividing

the vehicle weight by the spring constant. The oscillation original amplitude is a factor of the difference

between the spring’s previous length and its new length. A sine function is used to simulate the simple

harmonic oscillation of the spring and a variable is used to monitor the increasing effect of the damper on

the spring’s oscillation via the amplitude.

5.3.2 Input System

As explained previously, the keyboard has slight disadvantages with simulating vehicles as it is a 2

state device. These disadvantages where overcome within the software by maintaining variables that

simulated the varying positions of a real-car input system. For example, a car’s acceleration pedal could

have a 0 state (not being pressed), a 1 state (fully pressed) and states in between like 0.1, 0.5 etc. To emulate

this in software, if the user hits the keyboard equivalent of the accelerator pedal or the ‘W’ key a variable is

incremented starting from 0 to 1 by a factor of say 0.01. When this variable exceeds 1 it is locked on this

value. Same goes when the user releases the ‘W’ key, the variable is decremented by the factor 0.01 till it

exceeds 0 and is then locked.


Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation

Dienye S. Boham


The same emulation is done for the break key ‘S’ and the steering keys ‘A’ and ‘D’. The up and

down keys are used to change the gears from gear 1 to the maximum gear the vehicle has. Gear 0 is reserved

for the revered gear. The input component and all the variables they directly affect are all encapsulated

within a input control function within the vehicle dynamics engine.

  • 5.3.3 3D Mesh Control

The vehicle has 5 main 3D meshes, the vehicle body or chassis, the front left wheel, the front right

wheel, the back left wheel and the back right wheel. After all the calculations are made simulating the

vehicle in the virtual physics environment, the results are then used to correctly position these 3D meshes in

the simulation environment which represents what is actually visible on screen while the simulation is


  • 5.3.4 Sound Control

While the physics calculations are being performed, the results are being monitored and used to

determine when specific sounds are to be played like the braking sound and the car engine sound. The car

engine sound is directly related to the engine revolutions per minute. The engine rpm has a higher and upper

limit and so does the engine sound frequency. A simple conversion routine is used to convert the rpm into a

frequency and using the sound class’s functions the particular engine sound is played using this frequency.