VDE-Vehicle Dynamics Engine

| VEHICLE DYNAMICS ENGINE (VDE) |
AUTHOR: TAMUNO-DIENYE S. BOHAM.

NUMBER OF WORDS: 18,000 approx.
COURSE: COMPUTER SYSTEMS ENGINEERING.
YEAR OF STUDY: 2002 - 2006.
SUPERVISOR: DR. ABHIR BHALERAO.
REPORT COPY: 1
PROJECT KEYWORDS: Vehicles, Physics, Software, Games, DirectX, C++, Driving, Cars.
Vehicle Dynamics Engine (VDE) – Vehicle Physics Simulation Dienye S. Boham
_______________________________________________________________________________________
PROJECT ABSTRACT
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.
2
_______________________________________________________________________________________
ACKNOWLEDGEMENTS
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.
3
_______________________________________________________________________________________
NOMENCLATURE
All important nomenclatures used in the report are listed below in order of appearance:
Ftraction = rear wheel traction force (N)

u = car heading unit vector
Fdrag = aerodynamic drag force (N)
Cdrag = aerodynamic drag coefficient
v = car velocity vector
s = car speed (m sֿ¹)
Frr = car wheel rolling resistance (N)
Crr = rolling resistance coefficient
Flong = longitudinal force (N)
a = car acceleration vector
a = car acceleration (m sֿ²)
M = car mass (Kg)
W = car weight (N)
dt = simulation engine loop time (milliseconds, ms)
p = car position vector
p = car position from origin (m)
Cd = friction coefficient
A = car frontal area (m²)
Ρ = air density, rho (Kg mֿ³)
Fbraking = car braking force (N)
Cbraking = car braking constant
Fmax = maximum force on car wheel (N)
Μ = friction coefficient of the tyre, mu
g = acceleration due to gravity (m sֿ²)
Wf = weight of car on front wheels (N)
Wr = weight of car on rear wheels (N)
CG = position vector of the centre of gravity
c = distance from CG to the rear axle (m)
b = distance from CG to the front axle (m)
h = height of CG above wheelbase (m)
4
_______________________________________________________________________________________
L = wheelbase (m)
hp = car horsepower (hp)
rpm = car engine revolutions per minute
Fdrive = car engine drive force (N)
Tengine = car engine torque at a given rpm (N)
Xg = car gear ratio
Xd = car differential ratio
n = transmission efficiency (%)
Rw = car wheel radius (m)
g1 = first gear ratio
g2 = second gear ratio
g3 = third gear ratio
g4 = fourth gear ratio
g5 = fifth gear ratio
g6 = sixth gear ratio
gR = reverse gear ratio
Tdrive = car engine drive torque (N)
Π = ratio of a circle circumference to its diameter, pi
σ = slip ratio
ωw = car wheel angular velocity (rad sֿ¹)
Vlong = longitudinal velocity (m sֿ¹)
Vlat = 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)
Fz = load on the tyre (N)
Ct = traction constant
I = total inertia (kg m²)
δ = turning angle made by front and rear wheels, delta (deg)
R = 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
Flateral = car tyre lateral or cornering force (N)
Ca = cornering stiffness
α = slip angle, alpha
5
_______________________________________________________________________________________
Vx = car front tyre lateral speed (m sֿ¹)
Vy = car front tyre longitudinal speed (m sֿ¹)
αfront = car front wheel slip angle (deg)
αrear = car rear wheel slip angle (deg)
Fcornering = cornering or centripetal force (N)
Flat, rear = car rear lateral force (N)
Flat, front = car front lateral force (N)
ωa = 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
Assumptions
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 N (Newton) m.kg/s²

Power W (watt) N.m/s = J/s = m²kg/s³
Torque N.m (Newton meter) -
Speed m/s -
Angular velocity rad/s -
Acceleration m/s² -
Mass kg -
Distance m -
1 mile 1.6093 km -
6
_______________________________________________________________________________________
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 -
1G 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) 550 ft.lb/s 745.7 W
1 metric hp 0.986 hp 735.5 kW
7
_______________________________________________________________________________________
TABLE OF CONTENTS
Abstract ..……………………………………………………………………………………………………. 2
Acknowledgments ………………………………………………………………………………………….. 3
Nomenclature ………………………………………………………………………………………………. 4
Chapter 1 - Introduction ……………………………………………..…………………………………... 11
1.1 The Problem …....………………………………………..…….……………………………….. 11
1.2 Objectives ….…….……………………………………………..………………………...……. 11
1.3 Motivations ………..…………………………………………………………..……………..… 12
1.4 Document Overview ……………………………………………………………………...……. 12
Chapter 2 - Self Assessment of the Project ...…………………..………………..………………...…….. 14

2.1 Technical Contribution of the Project ………………………..……………………………...…. 14
2.2 Relevancies to Computer Systems Engineering ……………………..………………..........….. 14
2.3 Making use of the Project Work ……………….……………………………………………..... 14
2.4 Project Achievement Considerations …………………..………………….………………...…. 14
2.5 Weaknesses of the Project …………….……………………………...…………………...…… 15
Chapter 3 – Background Research ……………………………………………………………...………. 16

3.1 Introduction ………………………………………………………………………...…………... 16
3.2 Vehicle Dynamics Research ……………………………………………………...……………. 16
3.2.1 Comparable Vehicle Simulations ………………………………………...………….. 17
3.2.2 Engine and Drive Train Simulation ……………………………………...…………... 19
3.2.3 Suspension, Traction and Steering ………………………………………...…………. 20
3.2.4 Uneven Grounds and Gravitational Effects ………………………….……...……….. 24
3.3 Computer Implementation Research …………………………………………………...………. 25
3.3.1 Software Development Kits and Libraries ………………………………...…………. 25
3.3.2 Program Development Cycle and structure ………………………………...………... 26
3.4 Methods and Conclusions …………………………………………………………...…………. 27
Chapter 4 - The Simulation Engine …………………..……………………………………...…………... 29

4.1 Introduction ………………………………………………………………………...…………... 29
4.2 Hardware Technology Specifications …...………………………………………...…………… 29
4.3 Software Technology Specifications …..……………………………………………...……….. 29
8
_______________________________________________________________________________________
4.4 Application Framework Design and Architecture ....……...……….......…………….……........ 30
4.5 Application Framework Implementation …………………………………………...………….. 31
4.5.1 Engine Files ……………………………………………………………...…………... 32
4.5.1.1 Level 0: API Library ……...………………………………......……………. 23
4.5.1.2 Level 1: Low Level Functions ..………….……….…………...…………… 23
4.5.1.3 Level 2: High Level Functions …….......…………………...……………… 35
4.5.1.4 Level 3: The Application Core……………………………...……………… 35
4.5.1.5 Resource Manager …..………………………………………...…………… 35
4.5.2 Program Files …………………………………………………………...……………. 35
4.5 Engine Testing and Evaluation ……………………………………………...…………………. 37
Chapter 5 - The Vehicle Dynamics Engine ……………………………….…..….………..…………….. 39

5.1 Introduction ………………………………………………………………………...…………... 39
5.2 Vehicle Class Design and Architecture …………………………………………...…………… 39
5.3 Vehicle Class Implementation ……………………………………………………...………….. 40
5.3.1 Vehicle Physics Theory …………………………………………………...…………. 40
5.3.1.1 Linear Physics …………………………………………………...…………. 40
5.3.1.2 Turning Physics …………………………………………………...……….. 47
5.3.1.3 Uneven Terrain …………………………………………………...………... 49
5.3.1.4 Suspension System ………………………………………………...………. 49
5.3.2 Input System ……………………………………………………………...………….. 50
5.3.3 3D Mesh Control …………………………………………………………...………… 51
5.3.4 Sound Control ………………………………………………………………...……… 51
5.3.5 Heads-Up Display Control ……………………………………………………...……. 51
5.3.6 Vehicle Data Control …………………………………………………………...……. 51
Chapter 6 - Final Testing and Results ……………………………………………………………...…… 53

6.1 Creating the Simulation Environment …………………………………………………...…….. 53
6.2 Vehicle Setup and Test Procedure …………………………………………………………...… 55
6.3 Vehicle Dynamics Engine Results ………………………………………………………...…… 56
Chapter 7 - Conclusion and Evaluation …………………………………………….……………...……. 63

7.1 Summary: Goals Criticism, Achievements, Difficulties and Learnt Lessons ……………...….. 63
7.2 Further Work ………………………………………………………………………...…………. 63
7.2.1 High Speed Physics ………………………………………………………...………… 63
9
_______________________________________________________________________________________
7.2.2 Alternate Input Methods ………………………………………………………...…… 63
7.2.3 Jumping Physics ……………………………………………………………...……… 63
7.2.4 Realistic Suspension System …………………………………………………...…….. 64
7.2.5 Rigid Body Mechanics …………………………………………………...…………... 64
Chapter 8 - Appendix ……….……………………..…………………………………………...………… 65

8.1 Using the Application ………...…………………………………………………...…………… 65
8.2 References …………………………………………………………...…………………………. 65
10
_______________________________________________________________________________________
CHAPTER 1 - INTRODUCTION
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 3rd party or middleware technology to integrate
into their games. A popular industrial 3rd 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
feature:
• Modular encapsulation for easy integration into an existing game or software.

• Core vehicle physics for games and software.
11
_______________________________________________________________________________________
• 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
computers.
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.
12
_______________________________________________________________________________________
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.
13
_______________________________________________________________________________________
CHAPTER 2 - SELF ASSESSMENT OF THE PROJECT
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
14
_______________________________________________________________________________________
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.
15
_______________________________________________________________________________________
CHAPTER 3 - BACKGROUND RESEARCH
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
16
_______________________________________________________________________________________
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.
17
_______________________________________________________________________________________
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.
18
_______________________________________________________________________________________
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
throttle.
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
19
_______________________________________________________________________________________
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
format.
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
20
_______________________________________________________________________________________
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
Spring Damper
Wheel
Figure 3.1: Simplified vehicle suspension system.
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
21
_______________________________________________________________________________________
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.
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
22
_______________________________________________________________________________________
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.
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
23
_______________________________________________________________________________________
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
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
24
_______________________________________________________________________________________
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
25
_______________________________________________________________________________________
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
26
_______________________________________________________________________________________
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.
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.
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
27
_______________________________________________________________________________________
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.
28
_______________________________________________________________________________________
CHAPTER 4 - THE SIMULATION ENGINE
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
29
_______________________________________________________________________________________
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 1:
Low Level
Functions
Level 0:
API Library
Figure 4.1: Application framework hierarchy.
30
_______________________________________________________________________________________
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
resources.
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
31
_______________________________________________________________________________________
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.
4.5.1.1 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.
4.5.1.2 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
32
_______________________________________________________________________________________
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.
Graphics
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
following:
• 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
values.
• 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
translating.
• 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.
33
_______________________________________________________________________________________
Audio
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
below:
• 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.
Input
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.
Files
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.
34
_______________________________________________________________________________________
4.5.1.3 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.
4.5.1.4 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.
4.5.1.5 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.
hexCore.setupGame(2,1024,768,32)
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.
35
_______________________________________________________________________________________
light sun;
sun.makeSun();
sun.setAmbient(0.5f,0.5f,0.5f,0.5f);
sun.setPosition(250.0f,100.0f,250.0f);
sun.update();
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.
Figure 4.2: The dune.jpg image. Figure 4.3: The hmap.jpg image.
eland land;
land.setTexture(dune);
land.heightMap(hmap,20.0f);
land.colorize(20.0f,2);
land.normalizeEland();
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
36
_______________________________________________________________________________________
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.
cam.setPosition(10.0f,10.0f,10.0f);
cam.setPoint(10.0f,0.0f,50.0f);
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.
while(1==1)
{
graphicsSystem.sync()
};
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.
37
_______________________________________________________________________________________
Figure 4.4: The example program code output.
38
_______________________________________________________________________________________
CHAPTER 5 - THE VEHICLE DYNAMICS ENGINE
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.
39
_______________________________________________________________________________________
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.
5.3.1.1 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:
Ftraction = u * Engineforce
Fdrag = - Cdrag * v * |v|
Frr = - Crr * 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 Crr must be approximately 30 times the value of Cdrag.
40
_______________________________________________________________________________________
The air resistance coefficient or constant Cdrag is approximated by the following formula from Fluid
Mechanics by Landau and Lifshitz, [Beckham] chapter 6, [Zuvich]:
Fdrag = 0.5 * Cd * A * rho * v2
Using the values of air density as 1.29 kg/m3 and for a Chevrolet Corvette C5 frontal area is
approximately 2.2 m2 and Cd 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 Crr should be approximately 30 times Cdrag so this
a rolling resistance constant value of 12.8.
The total longitudinal force is therefore the vector sum of these three forces.
Flong = Ftraction + Fdrag + Frr
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.
Braking
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.
41
_______________________________________________________________________________________
Flong = Fbraking + Fdrag + Frr

Fbraking = -u * Cbraking
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.
Fmax = 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.
Wf = (c/L)*W
Wr = (b/L)*W
Figure 5.1: Vehicle weight transfer specifications.

If the car is accelerating or decelerating at rate a, the weight on front (Wf) and rear axle (Wr) can be
calculated as follows:
42
_______________________________________________________________________________________
Wf = (c/L)*W - (h/L)*M*a
Wr = (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.
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:
Fdrive = u * Tengine * xg * xd * n / Rw
43
_______________________________________________________________________________________
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 g1 2.66

Second gear g2 1.78
Third gear g3 1.30
Fourth gear g4 1.0
Fifth gear g5 0.74
Sixth gear g6 0.50
Reverse gR 2.90
Differential ratio xd 3.42
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
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
44
_______________________________________________________________________________________
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:
Tdrive = Tengine * xg * xd * n
where Fdrive = Tdrive / Rw
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
45
_______________________________________________________________________________________
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:
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.
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:
Flong = Fn, long * Fz

Flong = Ct * 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
46
_______________________________________________________________________________________
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.
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 * radius2 / 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.
5.3.1.2 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.
47
_______________________________________________________________________________________
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.
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:
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
determine:
48
_______________________________________________________________________________________
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.
5.3.1.3 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
equation:
Flong = Fbraking + Fdrag + Frr + Wsinθ

Flong = Ftraction + Fdrag + Frr + 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.
5.3.1.4 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
49
_______________________________________________________________________________________
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.
50
_______________________________________________________________________________________
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
running.
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.
5.3.5 Heads-Up Display Control

Each vehicle instance of the vehicle dynamics engine has their own Heads-up display which shows
the important vehicle data such as speed and gear. Sprites and images are used to handle this aspect of the
vehicle dynamics engine. For the speed metre, an indicator sprite is used to point towards the specific speed
at which the vehicle is moving at. So in this case the speed of the vehicle is converted to an angle for the
sprite to rotate at to point to the right speed on the speed metre.
Performing this calculation as is would provide rough movements of the indicator as the speed of the
vehicle could change abruptly. In this case a simple curve value or linear interpolation routine was created,
also for angles that could interpolate between two values at a certain speed and still being dependent on the
engine time. This was used to quickly but smoothly move the indicator from one speed to another no matter
how abrupt the change was.
5.3.6 Vehicle Data Control

Vehicle-specific information was stored in external VDP (vehicle dynamics plug-in) files. These
files contained as much information on the vehicles as possible, below is a list of all the vehicle information
stored and uniquely used to identify and simulate individual types of vehicles:
51
_______________________________________________________________________________________
• Vehicle name
• Brake torque
• Vehicle body mass
• Vehicle wheel mass
• Drag coefficient
• Frontal area
• Vehicle body length
• Vehicle body width
• Vehicle body height
• Centre of gravity position vector
• Vehicle wheel radius
• Suspension spring original length
• Suspension spring constant
• Gear information
• Wheel position information
• Engine torque/rpm curve values
• Vehicle mesh, images and sound file names and paths
This data is retrieved from the file once the vehicle instance object is created. The path of the .vdp file is
actually an attribute of the vehicle class constructor and has to be specified for a vehicle object to be created.
The vehicle dynamics engine currently has .vdp files on the Chevrolet Corvette C5, the Audi TT and the
Mini Cooper.
52
_______________________________________________________________________________________
CHAPTER 6 - FINAL TESTING AND RESULTS
6.1 Creating the Simulation Environment

The simulation environment used for the final testing of the vehicle dynamics engine comprises
simply of a terrain with both even and uneven surfaces created using a height map and the eland classes
height map functions. The chosen vehicles with real-world specifications are:
• Figure 6.1: Audi TT [Audi TT specifications].
• Figure 6.2: Chevrolet Corvette C5 [Corvette C5 specifications].
• Figure 6.3: Mini Cooper [Mini Cooper specifications].
53
_______________________________________________________________________________________
The specifications for these vehicles can be found on websites referenced in the later sections of the
report. Below is the exact program file code used to setup and run the simulation environment, the program
code uses the simulation engine to perform all the necessary tasks.
#include "coreMain.h" // engine core
HRESULT runEngine() // program entry function

{
hexCore.setupGame(2,1024,768,32); // setup program
// create light
light sun;
sun.makeSun();
sun.setAmbient(0.5f,0.5f,0.5f,0.5f);
sun.setPosition(250.0f,100.0f,250.0f);
sun.update();
// create terrain
image dune("media/2D/Eland/dune.jpg"); // dune texture
image hmap("media/2D/Eland/hmap.jpg"); // hmap texture
eland land;
land.setFillType(1);
land.setTexture(dune);
land.heightMap(hmap,20.0f);
land.colorize(20.0f,2);
54
_______________________________________________________________________________________
land.normalizeEland();
vehicle car("media/cars/TT/TT.vdp",land); // create vehicle
while(1==1) // loop forever

{
car.controlVehicle(); // controls the vehicle
graphicsSystem.sync(); // updates the graphics system
}
return S_OK;
}
As you can see, the program code required to make the entire simulation engine is very small, about
20 lines of code. However, behind each class and function are several lines of code all wrapped up and
placed within the main simulation engine. The interface to the vehicle dynamics engine is also made very
easy, the programmer only has to create a vehicle instance, in this case called ‘car’ and provide the directory
of the car’s technical information as well as the terrain on which it traverses, in this case the eland instance
‘land’. Once this is done another simple function call is made by the vehicle instance to its own vehicle
control method within the main program loop. Within the function call, everything from the physics
calculations, vehicle mesh position and orientation updates, user input logging and processing, heads-up
display control, sound control etc are all controlled.
6.2 Vehicle Setup and Test Procedure

The vehicle dynamics engine was tested on two computer systems of contrasting specifications. The
Desktop has the specifications of a high end computer system and the Laptop has the specifications of a low
end computer system. The vehicle dynamics engine in theory should run at approximately the same speed
on both systems although movement on the high end computer system will be a lot smoother that on the low
end computer system. The specifications of both the Desktop and the Laptop are as follows:
Desktop Specifications
Make: Custom.
Operating System: Microsoft Windows XP Professional Edition.
Processor: Intel Pentium 4 CPU 3.00GHz.
Memory: 512MB RAM.
55
_______________________________________________________________________________________
DirectX Version: 9.0c.
Graphics Card: RADEON X300 series, ATI Technologies Inc.
Graphics Card Memory: 256MB.
Laptop Specifications
Make: Dell Computer Corporation.
Operating System: Microsoft Windows XP Home Edition.
Processor: Intel Pentium 4 Mobile CPU 1.70GHz.
Memory: 254MB RAM.
DirectX Version: 9.0c.
Graphics Card: GeForce2 Go, NVIDIA.
Graphics Card Memory: 16.0MB.
The procedure for testing the vehicle dynamics engine was simply selecting each car in turn and
driving around the simulation environment over even and uneven terrain while performing turns, brakes,
accelerations, free rolls etc. While driving around the environment, at the same time the vehicle behaviour
was being monitored and reactions of the vehicle like weight transfer, performance, and speed of the vehicle
where closely watched. The procedure was repeated on both the high specification Desktop computer and
the low specification Laptop computer.
6.3 Vehicle Dynamics Engine Results

The completed vehicle dynamics engine allows users to explore the capabilities of three very
different cars. The first car is the Chevrolet Corvette C5, typical of the American ‘muscle car’ style and it
features a large V8 engine. In contrast the second car is a 2000 Audi TT. Much lighter that then Corvette C5
and features a smaller engine size. The final vehicle is the Mini Cooper, the smallest vehicle of the three and
the lightest. After setting up the vehicles technical specifications, meshes, textures and sounds it is ready to
be test driven in the simulation environment.
Users interact with the vehicles through the keyboard and by using the Function keys F1 to F12 can
change camera angles and vehicle mesh properties while driving. Users can view the current vehicle state at
a glance through the HUD system. The HUD features information such as vehicle speed and gear. The
vehicle dynamics engine also provides audio output which includes variable pitch engine sounds as well as
braking sounds.
The project was a success, the different cars all performed differently and convincingly. The graphic
scenes where rendered correctly and the audio output was in sync with vehicle performance. Figures 6.4 to
6.9 show pictures of the completed vehicle dynamics engine simulations:
56
_______________________________________________________________________________________
Figure 6.4: The Chevrolet Corvette C5 turning.
57
_______________________________________________________________________________________
Figure 6.5: The Chevrolet Corvette C5 climbing a hill.
58
_______________________________________________________________________________________
Figure 6.6: The Audi TT curving.
59
_______________________________________________________________________________________
Figure 6.7: The Audi TT turning.
60
_______________________________________________________________________________________
Figure 6.8: The Mini Cooper free rolling downhill.
61
_______________________________________________________________________________________
Figure 6.9: The Mini Cooper stationary on top a hill.
62
_______________________________________________________________________________________
CHAPTER 7 - CONCLUSION AND EVALUATION
7.1 Summary: Goals Criticism, Achievements, Difficulties and Learnt Lessons

Driving the three available cars around the simulation environment clearly shows their different
performance characteristics. The vehicle dynamics engine’s physics model provides a consistent and
realistic driving experience for what it’s worth and despite the fact that it’s still incomplete and has a simple
suspension system model. Audio-visual aspects of the vehicle dynamics engine are also of a good quality.
The 3D models are detailed and yet frame rate performance is still very acceptable. Performance is at 70
FPS on the Desktop computer system and about 30 FPS on the Laptop computer system at a resolution of
1024x768 with 32-bit colour depth. Unfortunately lighting effects are not very apparent. The sound output
of the vehicle dynamics engine works well to increase the user’s sense of immersion in the simulation.
7.2 Further Work

This section of the report seeks to introduce some areas of potential improvement and further work
on the vehicle dynamics engine and the simulation. The engine in itself is incomplete as some features
haven’t been implemented yet and some still use simple physics models.
7.2.1 High Speed Physics

The physics theory and information required to implement high speed physics into the vehicle
dynamics engine is available and was initially gathered during the planning and design phase of the project.
This was however not implemented as there wasn’t enough time so instead is included in the further work
section. The vehicle dynamics engine could be improved in the future by taking high speed physics into
account so vehicles could act more realistically at higher speeds like simulating high speed wheel slips,
vehicle drifting, wheel skids and all other actions that normal cars can perform when driving at higher
speeds.
7.2.2 Alternate Input Methods

The vehicle dynamics engine currently uses the keyboard as the main and only source of user input.
However future work could take the form of programming and integrating other forms of user input such as
racing packages which include the driving or steering wheel, acceleration pedals, brake pedals, the clutch
and even hand break.
7.2.3 Jumping Physics
63
_______________________________________________________________________________________
The current vehicle physics is under the assumption that the vehicle stays firmly on the ground at all
times but this is not the case in real life. Jumping physics is an essential part of all vehicle physics engines
and allow the vehicle to actually leave the ground when going over a curve or speeding off a cliff, the
vehicle dynamics engine currently doesn’t support this so it could be implemented in the future.
7.2.4 Realistic Suspension System

As mentioned previously, the suspension system for the vehicle dynamics engine was a last minute
addition so it’s not as sophisticated. Improving on this suspension system could be the basis of future work
on the vehicle dynamics engine and in this case all wheels would be modelled independently with separate
suspension systems so complex reactions such as a single wheel traversing on a rock or boulder could be
simulated making the vehicle dynamics engine more realistic.
7.2.5 Rigid Body Mechanics

Another feature that could be implemented is full rigid body mechanics. In this case this refers to the
vehicle being able to topple over provided the chance is available. At this stage the vehicle remains upright
at all times and even when traversing terrain at nearly ninety degrees inclination would still remain fixed on
the terrain surface. The vehicle dynamics engine could be improved to support the vehicle toppling over if
this should happen and other effects the vehicle dynamics engine could support could include driving at
high seeds and turning sharply on a vehicle with a high centre of gravity (like a bus), causing it to fall over
on it’s side, or even jumping off a platform an tumbling on reaching the ground.
64

VDE-Vehicle Dynamics Engine

Uploaded by

Document Information

Original Description:

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

VDE-Vehicle Dynamics Engine

Uploaded by

Copyright:

Available Formats

| VEHICLE DYNAMICS ENGINE (VDE) |

AUTHOR: TAMUNO-DIENYE S. BOHAM.

Ftraction = rear wheel traction force (N)

Notations and Conventions

Units and Conversions

Force N (Newton) m.kg/s²

Chapter 2 - Self Assessment of the Project ...…………………..………………..………………...…….. 14

Chapter 3 – Background Research ……………………………………………………………...………. 16

Chapter 4 - The Simulation Engine …………………..……………………………………...…………... 29

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

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

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

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

1.1 The Problem

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

• Even and uneven grounds with hills and cliffs.

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.2 Vehicle Dynamics Research

• Cars with four-wheeled steering systems.

3.2.1 Comparable Vehicle Simulations

A Review of Racer by Kenneth J. MacLeod

A Review of TORCS by Kenneth J. MacLeod

3.2.2 Engine and Drive Train Simulation

3.2.3 Suspension, Traction and Steering

Figure 3.1: Simplified vehicle suspension system.

Figure 3.5: Example traction curve for tarmac road surface.

3.2.4 Uneven Grounds and Gravitational Effects

Figure 3.6: Gravitational effects on a vehicle on sloping ground.

3.3 Computer Implementation Research

3.3.1 Software Development Kits and Libraries

3.3.2 Program Development Cycle and structure

Figure 3.7: Module structure in the Racer car model.

Figure 3.8: Module structure in the TORCS car model.

3.4 Methods and Conclusions

CHAPTER 4 - THE SIMULATION ENGINE

4.2 Hardware Technology Specifications

4.3 Software Technology Specifications

4.4 Application Framework Design and Architecture

Figure 4.1: Application framework hierarchy.

4.5 Application Framework Implementation

4.5.1 Engine Files

4.5.1.1 Level 0: API Library

4.5.1.2 Level 1: Low Level Functions

4.5.1.3 Level 2: High Level Functions

4.5.1.4 Level 3: The Application Core

• Miscellaneous mathematics and mechanical functions.

4.5.1.5 Resource Manager

4.5.2 Program Files

4.5 Engine Testing and Evaluation

Figure 4.4: The example program code output.

CHAPTER 5 - THE VEHICLE DYNAMICS ENGINE

5.2 Vehicle Class Design and Architecture

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

5.3 Vehicle Class Implementation

5.3.1 Vehicle Physics Theory