VDE-Vehicle dynamics engine

8/7/2019 VDE-Vehicle dynamics engine

1/64

| 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.


2/64

Vehicle Dynamics Engine (VDE) Vehicle Physics Simulation Dienye S. Boham

_______________________________________________________________________________________

2

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.


3/64


_______________________________________________________________________________________

3

ACKNOWLEDGEMENTS

Marco Monster for making available an advanced introduction to car physics modelling for games on

which most of the applications 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.


4/64


_______________________________________________________________________________________

4

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 ofCG above wheelbase (m)


5/64


_______________________________________________________________________________________

5

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 ratiow = 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


6/64


_______________________________________________________________________________________

6

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 entirevehicle. 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, Newtons, 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 = mkg/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 -


7/64


_______________________________________________________________________________________

7

1 ft (foot) 0.3048 m -

1 in (inch) 0.0254 m 2.54 cm

1 km/h 0.2778 m/s -

1 mph 1.609 km/h 0.447 m/s

1 rpm (revolution per minute) 0.105 rad/s -

1 G 9.8 m/s 32.1 lb/s

1 lb (pound) 4.45 N -

1 lb (pound) 0.4536 kg 1 lb/1 G

1 lb.ft (foot pounds) 1.356 N.m -

1 lb.ft/s (foot pounds per second) 1.356 W -

1 hp (horsepower) 550 ft.lb/s 745.7 W

1 metric hp 0.986 hp 735.5 kW


8/64


_______________________________________________________________________________________

8

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


9/64


10/64


_______________________________________________________________________________________

10

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


11/64


_______________________________________________________________________________________

11

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 doesnt 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 shouldnt 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.


12/64


_______________________________________________________________________________________

12

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, its 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 coverstopics ranging from the input methods, vehicle processing methods and final output methods.


13/64


_______________________________________________________________________________________

13

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.


14/64


_______________________________________________________________________________________

14

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, its 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 its 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 astandalone 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 cars 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


15/64


_______________________________________________________________________________________

15

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.


16/64


_______________________________________________________________________________________

16

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 projectis 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


17/64


_______________________________________________________________________________________

17

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 Microsofts 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

cars 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. Racers 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.


18/64


_______________________________________________________________________________________

18

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 programmers 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 ofartificial 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 Racers 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.


19/64


_______________________________________________________________________________________

19

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 throttles current settings. Gillespies Fundamentals of Vehicle Dynamics shows how theperformance 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 Beckmans 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


20/64


_______________________________________________________________________________________

20

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 Monsters 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 doesnt 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 Gillespies 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 withthe road surface and within the tyre system. Much of Zuvichs discussions are regarding environmental

factors cited from Gillespie however, Zuvichs 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 cars velocity. The equation Zuvich provides for air resistance force is cited from

Gillespies text and is used in this project.

The rolling resistance increases linearly with cars 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 vehicles 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


21/64


_______________________________________________________________________________________

21

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 wasnt

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

Duncans 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.

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 thewheels via a spring and damper system. The application of a single spring-damper system and wheel is used

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

Vehicle Bod

Wheel

Dam erS rin


22/64


_______________________________________________________________________________________

22

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 tyres performance, there are however some methods that can be used to determine a reasonable

approximation of a tyres performance. The maximum acceleration (measured in Gs) 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


23/64


_______________________________________________________________________________________

23

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


24/64


_______________________________________________________________________________________

24

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 doesnt float off into the air or sink into the ground.

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

even physics text books provide solutions for there situations, one such text book is Pearsons 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.

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, its 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 vehicles 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 earths surface. On even ground there

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

N

-N

F


25/64


_______________________________________________________________________________________

25

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 vehicles 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 hasnt 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 programmers 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 MathEngines 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 vehicles 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 isnt reliable for a project such as this.

Other freeware alternatives included Russell Smiths 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


26/64


_______________________________________________________________________________________

26

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 (APIs) that could be used to handle graphics

processing and display in the vehicle dynamics engine. Two of the well known APIs include Microsofts

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 Microsofts 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 Microsofts

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

Microsofts 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 cars 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 cars 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


27/64


_______________________________________________________________________________________

27

modules are programmed in the form of C++ classes in both cases. Figure 3.7 shows Racers 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


28/64


_______________________________________________________________________________________

28

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 bythe Microsoft DirectX API.

I have chosen the Microsofts DirectX API over the OpenGL graphics library because of my familiaritywith 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-timeapplication 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 inthe report.

Tutorials on how to use 2D painting and 3D modelling programs can be found on the internet or withinthe 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 inputsource 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.


29/64


_______________________________________________________________________________________

29

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

PCs are more than adequately specified. Current desktop and laptop PCs 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 packages wheel could have

several states depending on its orientation or a racing packages pedals could have different statesdepending 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


30/64


_______________________________________________________________________________________

30

APIs were all selected. These decisions where based upon the authors previous experience as well as

background research.

The vehicle dynamics engine is written in C++ using Microsofts Visual C++ 6.0 Integrated

Development Environment, IDE. For graphics output the Microsofts 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 seriousdifficulties 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.

Figure 4.1:Application framework hierarchy.

SimulationEn ine

ProgramCom onent

EngineCom onent

ResourceMana er

Level 3:Core

Level 2:High LevelFunctions

Level 1:Low LevelFunctions

Level 0:API Library


31/64


_______________________________________________________________________________________

31

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 andresponse (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 thats as far as it goes, it contained no information on programming structures. There


32/64


_______________________________________________________________________________________

32

wasnt sufficient time to learn all the advanced C++ programming techniques initially in the simulation

engines development so it had to be learnt during which often involved constantly updating the simulation

engines code. However because of the structure initially conceived during the design phase it was a

relatively straight-forward procedure and didnt 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 programmers 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 Microsofts DirectX API that are

required to support the simulation engine. APIs like this are designed so you can use them but dont 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


33/64


_______________________________________________________________________________________

33

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

dont 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

programmers 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 thegraphics 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 classcan 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 whatthis 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 ofwhat 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. Examplesof 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 doinclude 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 doincludes assign images to sprites, position sprites and rotate sprites.

Line Class: Responsible for creating and manipulating 3D line objects. Examples of what this class cando include colouring lines, positioning lines and rotating lines.


34/64


_______________________________________________________________________________________

34

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 thesound and music classes. Sets up application audio.

Music Class: Responsible for creating, loading and manipulating music. Examples of what this classcan 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 classcan 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 macros 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 mousehardware. 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 ofwhat 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 ofwhich 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.


35/64


_______________________________________________________________________________________

35

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. Sets 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 its 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 graphicsdevice with a 1024 by 768 resolution, a 32 bit colour depth and in windowed mode signified by a 2.


36/64


_______________________________________________________________________________________

36

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 its 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


37/64


38/64


39/64


_______________________________________________________________________________________

39

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.


40/64


41/64


_______________________________________________________________________________________

41

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.Weve already found that Crrshould 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 cars mass using

Newtons second law:

a = F / M

The cars velocity is determined by integrating the acceleration over time using the Euler method for

numerical integration which involves summing the cars 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 cars 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.


42/64


_______________________________________________________________________________________

42

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:


43/64


_______________________________________________________________________________________

43

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

VDE-Vehicle dynamics engine

Documents