1. Grigor Todorov
1102166 1
Grigor Todorov
1102166
Evaluation of Physics Engines for Games
BSc (Hons) Computer Games Development
Undergraduate Thesis Report
Department of Computer Science & Technology
University of Bedfordshire
Supervisor: Rob Manton
2013 – 2014

2. Grigor Todorov
1102166 2
Abstract
This project evaluates three of the most popular physics engines for games. The
artefact provides a system that is capable of simulating multiple physics engines in
one application as well as measuring the performance. The thesis uses the data
captured from the artefact to provide an evaluation of multiple characteristics of the
engines such as the performance, simulation quality and accuracy, the amount of
features available as well as the overall ease of use of the engines.
There have been numerous attempts in the past that successfully evaluate physics
engines, but the engines are evolving constantly and some of these studies are very
old. The artefact of this project features an environment that makes the
implementation of multiple physics engines an easy and straight forward process.
Even when the evaluation of this thesis becomes outdated the reader will be capable
of creating their own evaluation applications using the information as well as the
artefact provided by this project.
This thesis concludes that each project has different needs and one of the physics
engines may be superior at fulfilling that needs. After reading this thesis the reader
should be able to select the physics engine that is most suitable for their project.

3. Grigor Todorov
1102166 3
Acknowledgements
Rob Manton – Supervisor
Bogdan Predescu – Tester
Vladimir Sinapov – Tester
Jeffery Asante - Tester
Dedications
I would like to dedicate this thesis to my sisters Stanislava and Biljana, my parents
Todor and Pavleta, as well as Vanya, Milen and all the people who have helped me
through my studies.
Keywords
Physics, Engine, Evaluation, PhysX, Havok, Bullet

4. Grigor Todorov
1102166 4
Table of Contents
Abstract.................................................................................................................................... 2
Acknowledgements.................................................................................................................. 3
Dedications .............................................................................................................................. 3
Keywords................................................................................................................................. 3
Table of Contents..................................................................................................................... 4
1. Introduction.......................................................................................................................... 7
1.1 Aims and Objectives...................................................................................................... 8
1.2 Structure of the Thesis ................................................................................................... 9
1.3 Additional Clarifications.............................................................................................. 10
2. Contextual Review and Market Research.......................................................................... 10
2.1 Contextual Review....................................................................................................... 10
2.2 Market research............................................................................................................ 12
2.2.1 Available Physics Engines.................................................................................... 12
2.2.2 Physics engine constraints .................................................................................... 14
2.2.3 Collision geometries ............................................................................................. 15
3. Artefact Design, Development and Testing....................................................................... 17
3.1 Requirements ............................................................................................................... 17
3.1.1 Changes from the original scope and specifications............................................. 18
3.2 Development methodology.......................................................................................... 19
3.3 Design of the Artefact.................................................................................................. 20
3.3.1 Paper Prototype..................................................................................................... 20
3.3.2 Prototype............................................................................................................... 21
3.3.3 Final artefact ......................................................................................................... 22
3.4 Use of the artefact ........................................................................................................ 23
3.5 Code Design and Implementation................................................................................ 24
3.5.1 UML design .......................................................................................................... 24
3.6 Physics Engines Implementation ................................................................................. 28
3.6.1 Setting up the project ............................................................................................ 28
3.6.2 PhysX Implementation.......................................................................................... 29
3.6.3 Bullet Engine Implementation .............................................................................. 31
3.6.4 Havok Implementation.......................................................................................... 32
3.7 FreeGlut implementation ............................................................................................. 34
3.7.1 FreeGlut base implementation .............................................................................. 34
3.7.2 FreeGlut objects drawing...................................................................................... 35

5. Grigor Todorov
1102166 5
3.7.3 FreeGlut grid drawing........................................................................................... 37
3.8 UI implementation ....................................................................................................... 37
3.9 Encountered problems ................................................................................................. 38
3.10 Testing........................................................................................................................ 38
3.10.1 White-box testing................................................................................................ 38
3.10.2 Black-box testing ................................................................................................ 38
3.10.3 Focus group testing............................................................................................. 39
3.10.4 Evaluation of the Artefact................................................................................... 40
4. Evaluation of Physics Engines........................................................................................... 40
4.1 Implementation Evaluation.......................................................................................... 40
4.2 License Requirement Evaluation ................................................................................. 41
4.3 Features Evaluation...................................................................................................... 42
4.3.1 Collision shapes .................................................................................................... 42
4.3.2 Available Constraints............................................................................................ 42
4.3.3 Vehicle specific features ....................................................................................... 43
4.4 GPU Acceleration Evaluation...................................................................................... 43
4.5 Ease of use and help provided...................................................................................... 45
4.6 Performance Evaluation............................................................................................... 45
5. Conclusion and further work.............................................................................................. 52
5.1 Conclusion ................................................................................................................... 52
5.2 Further work................................................................................................................. 52
References.............................................................................................................................. 53
Appendices............................................................................................................................. 56
List of Tables
Table 1. Available Physics Engines....................................................................................... 12
Table 2. Name Acronyms ...................................................................................................... 13
Table 3. Collision Comparison .............................................................................................. 42
Table 4. Constraints comparison............................................................................................ 43
Table 5. Download size.......................................................................................................... 45
Table 6. CPU Usage............................................................................................................... 51

6. Grigor Todorov
1102166 6
List of Figures
Figure 1. Different Types of Physics Constraints.................................................................. 14
Figure 2. Car Wheel Constraints............................................................................................ 14
Figure 3. Different Collision Objects..................................................................................... 16
Figure 4. Flow Diagram......................................................................................................... 23
Figure 5. UML Diagram for the Physics Engines.................................................................. 25
Figure 6. UML Diagram of the Collision Objects ................................................................. 27
Figure 7. Cube creation chart................................................................................................. 47
Figure 8. Sphere creation chart .............................................................................................. 48
Figure 9. Capsule creation chart ............................................................................................ 49
Figure 10. Mesh Creation Chart............................................................................................. 50
List of Screenshots
Screenshot 1. Paper Prototype ............................................................................................... 20
Screenshot 2. The Second Iteration of the Artefact ............................................................... 21
Screenshot 3. The Final Iteration of the Artefact................................................................... 22
Screenshot 4. Bullet GPU and PhysX Flex............................................................................ 44
Screenshot 5. Rendering GUI ................................................................................................ 45
List of Code Snippets
Code Snippet 1. Physics Engine Definition in Main.cpp....................................................... 26
Code Snippet 2. Multiple instances of the same engine......................................................... 26
Code Snippet 3. PhysX Include Libraries.............................................................................. 29
Code Snippet 4. PhysX Implementation................................................................................ 30
Code Snippet 5. PhysX Instance Release............................................................................... 30
Code Snippet 6. PhysX Step Simulation................................................................................ 30
Code Snippet 7. Objects Drawing Call.................................................................................. 31
Code Snippet 8. Bullet Include Libraries............................................................................... 31
Code Snippet 9. Bullet Initialization...................................................................................... 32
Code Snippet 10. Bullet Step Simulation............................................................................... 32
Code Snippet 11. Havok Initialization................................................................................... 33
Code Snippet 12. Havok Step Simulation.............................................................................. 34
Code Snippet 13. FreeGlut Base Implementation.................................................................. 34
Code Snippet 14. FreeGlut Object Rendering ...................................................................... 35
Code Snippet 15. FreeGlut Capsule Rendering ..................................................................... 36
Code Snippet 16. FreeGlut Mesh Rendering ......................................................................... 36
Code Snippet 17. FreeGlut Grid Drawing ............................................................................ 37

7. Grigor Todorov
1102166 7
1. Introduction
From the early days of video games some type of physics are an integral part of the
game systems. Even before the implementation of life like physics systems the
developers were always trying to fake physics into their games. In fact, some of the
earliest video games are based on physics principles. A simplistic physics simulation
can be found as a base of the gameplay in some of the first games available for a
wide audience: “Pong” and “Asteroids”. Nowadays there are numerous different
physics engines available. Newer versions emerge so fast that it is a challenge to
keep up with the changes. The seemingly simple task of choosing the most suitable
physics engine for a game can become quire overwhelming.
This project aims to help developers that are struggling in choosing the right project
for the game they are developing. It provides a simple to use application that is
capable of measuring the performance of multiple physics engines and it is relatively
easy to add additional physics engines to the application. The thesis evaluates the
current state of the physics engines using the measurements conducted with the
artefact. It also gives more information on how developers can do customized
evaluations when selecting a physics engine for their own projects.

8. Grigor Todorov
1102166 8
1.1 Aims and Objectives
The artefact changed its aims and objectives as well as its scope multiple times. The
original design will be discussed further into this thesis. These are the current aims
and objectives of the artefact and the thesis.
Artefact:
 Robust Object Oriented Application
 Implementation of PhysX, Bullet and Havok
 OpenGL rendering using FreeGlut
 GUI using AntTweakBar
 Ability to change between physics engines at run time
 Ability to create multiple collision objects
o Cube
o Sphere
o Capsule
o Mesh
 Ability to choose between different collision materials
o Concrete
o Rubber
 Ability to change simulation options at run time
o Gravity
o Time step
 Ability to measure and save performance data
Thesis:
 Use graphs, tables and screenshots to convey the workings of the physics
engines and the artefact.
 Use the data gathered from the artefact as well as additional research data to
critically evaluate the physics engines.
 Conclude with recommendations regarding the strengths and weaknesses of
the physics engines.

9. Grigor Todorov
1102166 9
1.2 Structure of the Thesis
This section will clarify the overall structure of the report. The subsections will not
be explained here.
Section 1. Introduction
This section provides an introduction to the Thesis Report and outlines the Aims and
Objectives of the project.
Section 2. Contextual Review and Market Research
This section accumulates more information regarding the physics engines, both
academic and commercial. The first part discusses similar academic projects. The
second part lists all the available physics engines and gives more information about
the workings of a physics engine.
Section 3. Artefact Design, Development and Testing
This section follows the development process of the artefact from the early stages of
paper prototyping to the final stages of testing.
Section 4. Evaluation of Physics Engines
This section features the evaluation of the physics engines. It measures the
performance and other features of PhysX, Bullet and Havok.
Section 5. Conclusion and Further Work
This section provides a conclusion and suggests a list of additional features that
could improve the artefact.

10. Grigor Todorov
1102166 10
1.3 Additional Clarifications
When referring to “the project” the author refers to both the artefact and the thesis.
The evaluation of physics engines is performed in the thesis and the artefact is only
used for data gathering.
Some physics engines have long names and the use of acronyms can be difficult for
the reader to follow. This is the reason why when referring to some physics engines a
shorter name is used. For example, instead of using NGD for the “Newton Game
Dynamics”, the author is referring to that engine as “Newton”.
2. Contextual Review and Market Research
2.1 Contextual Review
There are a small number of academic papers that analyse and evaluate the available
physics engines. Some publications, such as (Boeing, 2007) and (Seugling, 2006) are
outdated, because newer versions of some of the engines are now available. The
hardware increases its capabilities and features such as GPU accelerated physics
enable the developers to dedicate more resources for physics than ever before
(Zogrim, physxinfo.com, 2013).
(Hummel, 2012), on the other hand is relatively new, but it only compares the
physics engine implementation in Virtual Reality Assembly Simulations.
The conclusions of most of these papers are similar. There isn’t one engine that is
best suited for all types of operations.
Each physics engine has its own strengths and weaknesses. One engine that can
perform very well at realism of simulations can lack the performance needed for
some games.

11. Grigor Todorov
1102166 11
All the conclusions in these papers can be summarized as:
 PhysX is the most stable.
 Havok has optimized speed.
 Bullet is good with constraints as well as simulating collision and friction
 Newton is very accurate.
 ODE is unpredictable if stressed too much.
As (Wilcox-Netepczuk, 2013) does not fail to convey, player immersion is facilitated
from both graphics and physics and the two are inevitably interconnected. Using the
right physics tool can be crucial for the overall performance and stability of a game.
The most straight forward way of evaluating multiple physics engines is to use a
wrapper library. Unfortunately, although there are some wrapper libraries available,
none of them prove to be useful. Physics Abstraction Layer (PAL, 2009) is the most
promising, but fails to deliver to the expectations. CMake have to be used to build
the library, but it cannot detect the latest versions of the physics engines. The
development of other similar projects, such as GangstaWrapper (Geeknet, 2009) and
OPAL (Fischer, 2005) has been put into a halt as well.

12. Grigor Todorov
1102166 12
2.2 Market research
2.2.1 Available Physics Engines
There are numerous physics engines available, some are open sourced and some
require license (gamedev forum, 2012).
(Table 1. Available Physics Engines) provides information on some of the available
physics engines. Its goal is to reduce the number of engines that are going to be
evaluated in the artefact by proving why most of the engines should not be used.
Table 1. Available Physics Engines
Engine Developer License
(22.12.2013)
Last release
(22.12.2013)
Notes
AGX Algoryx Proprietary 01.04.2011 – 1.11
Box2D Erin Catto zlib 3.11.2013 - 2.3.0.7 2D
Bullet Erwin Coumans zlib 24.10.2013 - 2.82
Chipmunk Scott Lembcke MIT 15.10.2013 - 6.2.1 2D
Chrono Project Chrono BSD3 No date - 1.7.0
DMM* Pixelux Ent. Proprietary 01.05.2010 - 1.0
Havok Havok Proprietary No date - 2013.1.0
JigLib D. Chapman zlib 9.11.2007 - 0.84
NGD* J. Jerez & A.Suero zlib 11.10.2013 - 3.11
ODE* Russell Smith GNU 28.05.2012 - 0.12
PAL* A. Boeing BSD 06.02.2013 benchmark
PhysX NVIDIA Proprietary 01.12.2013 - 3.3.0
SOFA* Sofa-frameworks LGPL 13.12.2011 - 1.0
SPE* Phyar Studio Proprietary 6.8-2009 - 3.3
Tokamak David Lam BSD 17.05.2004
True Axis True Axis Proprietary 01.11.2006 - 1.2.0.3
Vortex CMLabs Proprietary 01.09.2011 – 5.0.4
Some engine names are too long to fit into (Table 1. Available Physics Engines) and
acronyms were used. The full names of those engines can be found in (Table 2. Name
Acronyms).

13. Grigor Todorov
1102166 13
Table 2. Name Acronyms
This project requires an engine that is capable of simulating physics in 3D and
therefore some engines such as Box2D and Chipmunk cannot be used. The engine
should also be available. Engines such as DMM and Vortex that require a license and
have no available trial version cannot be used. There are plenty of engines that are
outdated, and with so many options that are current, they won’t be considered as
well. Only the three most prominent engines with the newest releases will be
evaluated in the artefact.
The engines that will be evaluated are:
 Bullet
 Havok
 PhysX
Engines that won’t be evaluated, but should be included for a future evaluation in the
further work section include:
 ODE
 Chrono
 Newton
Physics Abstraction Layer is not a physics engine in itself, but it can be used to
integrate many engines in one application. Unfortunately PAL failed to work with
the newest versions of the physics engines and is therefore not used in this project.
Full Name
DMM Digital Molecular Matter
ODE Open Dynamics Engine
PAL Physics Abstraction Layer
SOFA Simulation Open Framework Architecture
SPE Simple Physics Engine
NGD Newton Game Dynamics

14. Grigor Todorov
1102166 14
2.2.2 Physics engine constraints
In order to simulate realistic behaviour a physics engine must provide a wide variety
of constraints and tools. These constraints are sometimes called “joints”. There are
different types of joints and each physics engine calls them differently, but there is a
set of physics constraints (Figure 1. Different Types of Physics Constraints) that every
physics engine has.
Figure 1. Different Types of Physics Constraints
Point-to-Point Hinge Slider
Piston Distance D6
D6 offers a freedom in all
axes and is capable of
representing most real world
connections.
Some real world connections cannot
be represented with only one of these
joints. In such cases a new joint type is
created by combining them. For
example, a slider connection can be
combined with a hinge joint to create a
wheel absorber. Adding another hinge
joint in between the first hinge and the
slider can be used for additional
camber angle (Figure 2. Car Wheel Constraints) feature of the tire. This example is
Figure 2. Car Wheel Constraints

15. Grigor Todorov
1102166 15
simplified and the camber angle in real world is achieved in a completely different
way. Its only goal is to demonstrate the use of multiple joint types in the creation of a
complex connection. If the set up from the example is used in an actual simulation it
won’t lead to realistic results.
Each physics engine has different naming for the constraints.
Point-to-point is sometimes called a spherical joint or a ball socket joint.
Hinge joint is sometimes called a revolute joint.
Sider joint is sometimes called a prismatic joint.
Distance joint is sometimes called a spring joint, but not every distance joint is a
spring joint.
D6 is sometimes called a 6 DoF joint. DoF stands for Degrees of Freedom.
There is another type of a joint which is standard for every physics engine: the fixed
joint. It represents two objects jointed together. Sometimes this joint can be adjusted
to break when a predefined amount force is applied to it.
2.2.3 Collision geometries
Each physics engine has its own set of supported collision shapes. Any shape can be
used with most engines that support collision meshes, convex meshes or concave
meshes. If an engine has a specific shape that is implemented and can be used
without the need of a mesh, it is better to use that instead of a custom mesh. The
physics engines use optimizations that can increase the performance. Excessive use
of dynamic collision meshes can lead to bad performance. More physics geometries
implemented in a physics engine usually lead to better optimizations. Some of the
most used geometry shapes can be seen in (Figure 3. Different Collision Objects).

16. Grigor Todorov
1102166 16
Figure 3. Different Collision Objects
Box Sphere Capsule
Cylinder Cone Plane
Convex Triangle Mesh Height Field
Most of the collision geometries in (Figure 3. Different Collision Objects) are straight
forward. The actual collision mesh can be seen in the renders as thin blue lines.
Usually the sphere colliders are optimized most, since the collision calculation
consists of measuring the distance between the centres of each sphere to the other. If
the distance is greater than the combined radiuses of the spheres there isn’t collision
between them. Other collision geometries, such as Convex have more complicated
collision detection, but are still faster than triangle mesh. Triangle meshes used for
collision are the least appropriate method, since they are not optimized in any way.
In most cases a model can be broken into different segments, each of which can use a
primitive collider.
The Height Fields in most engines are static and their performance is greater than a
triangle mesh collider.

17. Grigor Todorov
1102166 17
3. Artefact Design, Development and Testing
3.1 Requirements
A set of requirements for the artefact was defined early in the project design stage
and each sprint aimed on bringing a fulfilment of at least one of those requirements.
As the project progressed the requirements changed as well. The initial requirements
consisted of four engines implemented. After a short development and testing of one
of the engine it was decided that there is no need for the implementation of that
engine due to it being inferior to the other engines being evaluated.
Functional requirements of the Evaluation Application:
1. PhysX is working
2. Havok is working
3. Bullet is working
4. AntTweakbar UI system is implemented and working
5. OpenGL is used for rendering
6. It is possible to create different objects:
a. Cube
b. Sphere
c. Capsule
d. Mesh
e. Ragdoll
7. It is possible to measure the performance of the simulation
8. It is possible to save the measurement in a text file
9. It is possible to rotate and zoom the camera
Non-functional requirements of the Evaluation Application:
1. Both the application window and the user interface are responsive
2. There are tooltips with additional information that appear
3. The application does not crash
4. The code is reusable and the application is object oriented

18. Grigor Todorov
1102166 18
Most of the requirements were successfully fulfilled by the Evaluation Application.
The Ragdoll creation was not implemented and therefore no joint functions are being
evaluated by the artefact. This is a major omission and the evaluation of the joint
functionality of the engines would be based on third party information.
There are multiple features that were added to the artefact, even though they were
never mentioned in the project requirements.
One such feature is the ability to change gravity and to choose between two different
materials for the simulated objects.
A toggle that makes it possible to disable the rendering of objects, but keeping the
simulation was added. It will prove to be useful in the performance measurement.
The aim of this evaluation is not to measure the performance of OpenGL and the
ability to partially stop it is important.
The Evaluation Application fulfils the non-functional requirements with the
exception of the non-functional requirement 4. The part of the application that
achieves the physics simulation is object oriented and can be easily extended or
reused, but the part that renders the scene is not object oriented and it is very hard to
follow and understand.
3.1.1 Changes from the original scope and specifications
The artefact was originally planned to consist of two applications. An Evaluation
Application, which is the current artefact, and a second application. The second
application was planned to be a vehicle simulation game with multiple physics
properties simulated. When the first iteration of the Evaluation Application was
created the scope of the project shifted from creating the second application towards
the refining of the Evaluation Application. The current artefact is a result of multiple
iterations of the original Evaluation Application.

19. Grigor Todorov
1102166 19
3.2 Development methodology
Rapid prototyping (Rassweiler, 2012 ) was used for the development of the
prototype. Most of the code from the initial iteration was not used in the final
version. The goal of the rapid prototyping was to experiment with the physics
engines and the other libraries that are going to be used for the final artefact. The
development of the prototype focused to quantity over quality.
For the development of the artefact, or the second integration of the application, a
more structured approach was used. Quality of code was of a top priority. The
overall structure of the application should be object oriented and easy to reuse and
change. The implementation of additional features and physics engines should not
break the application and should be relatively easy.
The Agile software development methodology (Cunningham, 2001), and most
specifically the sprints from Scrum (Mountaingoatsoftware, 2012), were used for the
development. Each new feature was implemented in a different sprint. After every
sprint there is a period of testing. Most features took one week to implement, but
some of the features were harder and required more time. One such feature was the
mesh collision. The mesh collision implementation for both Havok and Bullet
Engine was straight forward and one week sprint was enough, but the PhysX mesh
collision took another week.
In some sprints multiple features were implemented at the same time. This was the
case of the performance measurement and the capsule creation features. Even though
these are two fairly distinctive features, they were not complex enough to be split
into two different sprints. One sprint was enough for both of them. Instead of
splitting the week into two sprints both features were implemented and the testing
was performed at the end of the week.
Version Control was not used for the development of the artefact. Most files were
regularly saved both in a flash drive and in cloud storage for back up. The
“Externals” that has all the engines was not saved, since it was 7,68GB.

20. Grigor Todorov
1102166 20
3.3 Design of the Artefact
3.3.1 Paper Prototype
The initial “paper” prototype of the artefact (Screenshot 1. Paper Prototype) is very
different from the final version. The main goal of the paper prototype was to
highlight the overall layout of the menus and test the look and feel of the application.
Initially there were four engines that were considered to be evaluated. Halfway
through the project ODE was removed from the evaluation due to its lack of newer
versions and support.
Screenshot 1. Paper Prototype
The Ragdoll feature was also removed from the evaluation application. The final
version is capable of creating capsules instead.

21. Grigor Todorov
1102166 21
3.3.2 Prototype
The prototype (Screenshot 2. The Second Iteration of the Artefact) was created early in
the development process. It was crude, lacking most features that are characteristic
for the final artefact. It had only 2 physics engines available: PhysX and Bullet. Each
engine could only create 2 types of objects: boxes and spheres. A new system for
object creation was developed through experimentation. The user can specify the
number of objects to be created in height, length and depth.
Screenshot 2. The Second Iteration of the Artefact
In this early version of the Evaluation Application features such as camera
movement and zoom are missing. Its only goal is to test whether the creation of the
application is possible and how long it would take. This prototype proved to be very
useful because it uncovered a major problem in the initial plan, the time dedicated for
development was not enough and the scope was too large. Some major changes had
to be made to keep the project on track, such as reducing the amount of engines that
are going to be evaluated from four to three.

22. Grigor Todorov
1102166 22
The initial plan was to evaluate the physics engines and use the engine with best
results for a vehicle game. This plan proved to be unrealistic and the second part of it
was not executed.
3.3.3 Final artefact
Screenshot 3. The Final Iteration of the Artefact
The final version of the Evaluation Application (Screenshot 3. The Final Iteration of the
Artefact) features PhysX, Havok and Bullet implementations.
The UI consists of three tabs.
The first tab is called “Settings” and is responsible for:
 Creating objects
 Cleaning the scene
 Changing the physics engine that is being used
 Specifying how many objects to create in X,Y and Z
 Receiving feedback on how many objects are currently simulated
 Changing the material of the objects that are going to be created
 Changing the time step of the simulation

23. Grigor Todorov
1102166 23
The second tab is called “World Settings” and is responsible for:
 Choosing a gravity from multiple gravity options
 Choosing a custom gravity vector
The third tab is called “Rendering” and is responsible for:
 Enabling/Disabling the rendering of objects
 Receiving the FPS and milliseconds the last frame took to render.
 Enabling/Disabling of saving of the performance in a text file.
 Changing the measurement frequency
 Clearing the text file
3.4 Use of the artefact
When the Evaluation Application is opened
the user can decide which engine to use in the
simulation. The default physics engine will be
PhysX, so the user is able to start creating
physics objects even if no physics engine is
selected. The user will be able to create
different types of physics objects in each
physics engine. The objects will be rendered
on screen. The user will receive feedback how
many objects are created and what is the
performance of the simulation.
Figure 4. Flow Diagram

24. Grigor Todorov
1102166 24
3.5 Code Design and Implementation
3.5.1 UML design
The UML diagram of the artefact went through numerous different stages. As the
evaluation application was initially designed as a small testing application the
implementation of the code was very simple and without the use of software design
patterns. The first iteration of the evaluation application works well, but the code was
hard to understand and build on. The second iteration featured an OOP structure with
interfaces for both the physics engines and the objects.
The following UML diagrams demonstrate the final structure of the evaluation
application. A free online application draw.io (jgraph, 2014) was used to create the
diagrams.
Physics Engines:
The initial implementation of the physics engines did not use any of the object
oriented programming that is characteristic for the final artefact. As the development
is an iterative process, some of the code was rewritten and some was rendered
useless after additional features were implemented. The main goal of the final
artefact implementation is to make the code reusable and enable the user to add and
remove physics engines from the application, without the need to rewrite any other
code. OOP Interface (Jim, unknown) was used. The “PhysicsBase” interface class
holds all the virtual functions that are used by every physics engine class
implemented. The class is abstract (IBM, unknown) since it does not consist of any
implementations of the functions. There is no need for a cpp file for a pure virtual
class and therefore the “PhysicsBase” base class consists only of the header file.

25. Grigor Todorov
1102166 25
Figure 5. UML Diagram for the Physics Engines
Each physics engine class has unique implementation of the virtual functions from
the base class. The use of a pure virtual class makes it possible to create a std::vector
that holds elements with a “PhysicsBase” type. The vector holds all the physics
engines implemented and can be increased, adding more engines, even in runtime. It
is also possible to add the same engine twice, creating more than one independent
simulations of the same physics engine. This makes the artefact a very powerful
evaluation and comparison tool. Even if there is a problem with one of the engines,
the other engines should function as expected.
In order to add physics engines to the vector the “DefineAllEngines” function in the
Main.cpp is called (Code Snippet 1. Physics Engine Definition in Main.cpp).

26. Grigor Todorov
1102166 26
Code Snippet 1. Physics Engine Definition in Main.cpp
void DefineAllEngines()
{
allEngines.push_back(new CPhysXInit ());
allEngines.push_back(new CBulletInit ());
allEngines.push_back(new CHavokInit ());
}
The creation of more than one instance of an engine is as simple as adding that
engine again (Code Snippet 2. Multiple instances of the same engine)
Code Snippet 2. Multiple instances of the same engine
void DefineAllEngines()
{
allEngines.push_back(new CPhysXInit ());
allEngines.push_back(new CPhysXInit ());
allEngines.push_back(new CBulletInit ());
allEngines.push_back(new CBulletInit ());
}
Although such feature is not implemented, it is possible to add more physics engine
instances at runtime. In order for such feature to be implemented there is a need of
small changes in in the way the UI works.
The use of a pure virtual base class can have negative impact in some occasions.
Since every virtual function from the base should have an implementation in the
child class, but not every child class need an implementation, there might be a need
to create an empty function in that child class. The artefact needs implementations
for every class and even provides overloading for some functions.
Objects:
The physics objects do not always have different implementations. For example, all
objects share the same “ChangeDrawingColor” function (Figure 6. UML Diagram of
the Collision Objects), therefore its implementation is in the “ObjectBase” class. All
the objects inherit from that class. “DrawSelf” is a virtual function because each
object has unique rendering implementation.
The “SetDrawingRot” function is currently used only by the Capsule Objects, but it
might be useful for objects that will be added in the future.

27. Grigor Todorov
1102166 27
Figure 6. UML Diagram of the Collision Objects
Main.cpp:
After three unsuccessful attempts to convert the freeglut and the anttweakbar
implementation into an object oriented one the final version of the artrfact uses one
large main.cpp file. It consists of the whole rendering and GUI implementations. As
putting it into different classes proved to be very difficult, the current solution works,
but is not the smartest one possible. Since this application is physics centric and not
rendering or GUI centric it should not be a problem, it would just make the reading
and understanding of the main file very hard.

28. Grigor Todorov
1102166 28
3.6 Physics Engines Implementation
3.6.1 Setting up the project
Setting up PhysX:
PhysX has a very well written documentation (Nvidia Documentation, 2013) that can
be of a great help when the actual development start, but it is not as user friendly as
one would expect. For example, there are gaps, such as the lack of information on
how to use custom baked convex meshes.
In order to gain access to PhysX one needs to sign up for the Nvidia Developer
Program, which is free of charge, but can take up to one week to receive an approval.
Once approved, the developer has access to multiple versions of PhysX as well as a
very useful visual debugger/profiler tool.
One very useful tutorial (Chalikias, 2013) was followed to do the initial linking and
set up of the engine.
Setting up Bullet:
Bullet Engine is open sourced and accessing it is free and does not require any
registration. The latest version can be found hosted on the Google Code Repository
page of the project (bullet physics download, 2013).
When downloaded from the repository Bullet lacks some important libraries. The
developer has to build the libraries using a program called CMake (Hoffman, 2014)
A tutorial (bulletphysics, 2012) was used to set up the engine.
Unfortunately Bullet does not have a visual debugging tool.

29. Grigor Todorov
1102166 29
Setting up Havok:
Havok is proprietary physics engine and downloading it required filling a form.
Unfortunately there isn’t an account system, such as the platform used by PhysX, and
the download form has to be filled up every time before a download. The
downloaded file, when extracted and installed, is relatively big compared to the other
engines, which is due to the fact that Havoc features a large amount of
demonstrations and sample applications. Visual debugging tool is available.
To do the initial implementation and linking of the libraries an online tutorial
(marcoarena, 2011) was followed. The linking works, but unfortunately the “Hello
World” code provided in the tutorial is outdated. In order to test the initial
initialization the code from one of the provided demos was used:
HavokDirhk[version]DemoStandAloneDemosStepByStepMemoryUtilInit
3.6.2 PhysX Implementation
PhysX is implemented in the class “PhysXInit”. It inherits from the interface
“PhysicsBase” and consists of the complete PhysX implementation.
Code Snippet 3. PhysX Include Libraries
#pragma comment(lib, "PhysX3DEBUG_x86.lib")
#pragma comment(lib, "PhysX3CommonDEBUG_x86.lib")
#pragma comment(lib, "PhysX3CookingDEBUG_x86.lib")
#else
#pragma comment(lib, "PhysX3_x86.lib")
#pragma comment(lib, "PhysX3Common_x86.lib")
#pragma comment(lib, "PhysX3Cooking_x86.lib")
#endif
#include <PxPhysicsAPI.h>
#include <PxDefaultErrorCallback.h>
#include <PxDefaultAllocator.h>
#include <PxDefaultCpuDispatcher.h>
PhysX requires different libraries (Code Snippet 3. PhysX Include Libraries) for its
Debug and Release versions and there are multiple header files that need to be
included. “PxPhysicsAPI” is the core of the engine. The other headers are used to
initialize different PhysX components explained in (Code Snippet 4. PhysX
Implementation).

30. Grigor Todorov
1102166 30
Code Snippet 4. PhysX Implementation
In header:
physx::PxScene* myScene;
physx::PxPhysics* myPhysicsSDK;
physx::PxFoundation* myFoundation;
physx::PxSimulationFilterShader myDefaultFilterShader;
physx::PxDefaultErrorCallback myDefaultErrorCallback;
physx::PxDefaultAllocator myDefaultAllocatorCallback;
physx::PxDefaultCpuDispatcher* myCpuDispatcher;
In cpp Initialize() called in the constructor:
myDefaultFilterShader=PxDefaultSimulationFilterShader;
myFoundation = PxCreateFoundation(PX_PHYSICS_VERSION, myDefaultAllocatorCallback,
myDefaultErrorCallback);
myPhysicsSDK = PxCreatePhysics(PX_PHYSICS_VERSION, *myFoundation, PxTolerancesScale());
PxSceneDesc tempSceneDesc(myPhysicsSDK->getTolerancesScale());
tempSceneDesc.gravity=PxVec3(0.0f, -9.81f, 0.0f);
tempSceneDesc.cpuDispatcher = PxDefaultCpuDispatcherCreate(1);
tempSceneDesc.filterShader = myDefaultFilterShader;
myScene = myPhysicsSDK->createScene(tempSceneDesc);
PhysX requires multiple specific PhysX objects to be created. The code that can be
seen in (Code Snippet 4. PhysX Implementation) is the simplified version of the PhysX
initialization.
All of the pointers are released in the destructor (Code Snippet 5. PhysX Instance
Release).
Code Snippet 5. PhysX Instance Release
DeleteAllObjects();//delete all the physX objects
myCpuDispatcher->release();//release all the physX blocks
myPhysicsSDK->release();
myScene->release();
myFoundation->release();
After a successful initialization of PhysX the application can start calling the
simulate function of “myScene” every frame. After each “simulate” call all the
matrices ( float[16] ) of the objects must be updated.
Code Snippet 6. PhysX Step Simulation
myScene->simulate(1.0f/(_timeStep));
while(!myScene->fetchResults() ) {
for (int i = 0; i < physXObjects.size(); i++ ) {
SetMatrix(PxMat33(physXObjects[i]->getGlobalPose().q), PxVec3
(physXObjects[i]->getGlobalPose().p), allObjects[i]->myMatrix);

31. Grigor Todorov
1102166 31
OpenGL uses column-major notation for its matrices while PhysX uses row-major
and a custom convertor from row to column-major is used. The function that does the
conversion is called “SetMatrix”.
Since every object inherits from the “ObjectBase” class to draw each object the
“DrawSelf” function is called (Code Snippet 7. Objects Drawing Call).
Code Snippet 7. Objects Drawing Call
for(int i=0;i<allObjects.size();i++)
{
allObjects[i]->DrawSelf();
}
Since all the objects classes inherit from the same base class “ObjectBase” they can
populate the same std::vector that is created in the physics class.
3.6.3 Bullet Engine Implementation
Bullet Engine is implemented in the class “BulletInit”. It inherits from the interface
“PhysicsBase” and consists of the complete Bullet Engine implementation.
For Bullet to function there is only one header file that needs to be included to the
application (Code Snippet 8. Bullet Include Libraries)
Code Snippet 8. Bullet Include Libraries
#include <btBulletDynamicsCommon.h>
The implementation of Bullet Engine has similarities to the implementation of
PhysX. Both engines need pointers to cpu dispatchers to function.

32. Grigor Todorov
1102166 32
Code Snippet 9. Bullet Initialization
In header:
btBroadphaseInterface* broadphase;
btDefaultCollisionConfiguration* collisionConfiguration;
btCollisionDispatcher* dispatcher;
btSequentialImpulseConstraintSolver* solver;
btDiscreteDynamicsWorld* dynamicsWorld;
btCollisionShape* groundShape;
btRigidBody* groundRigidBody;
In the cpp file Initialize() called in the constructor:
broadphase = new btDbvtBroadphase();
collisionConfiguration = new btDefaultCollisionConfiguration();
dispatcher = new btCollisionDispatcher(collisionConfiguration);
solver = new btSequentialImpulseConstraintSolver;
dynamicsWorld = new btDiscreteDynamicsWorld(dispatcher,broadphase,solver,
collisionConfiguration);
dynamicsWorld->setGravity(btVector3(0,-9.81,0));
Bullet Engine works in row-major, similar to PhysX and Havok, but it does not
require a custom converter of matrices. Each btRigidBody already has a function that
does the conversion. The code (Code Snippet 10. Bullet Step Simulation) demonstrates
the workings of the “StepSim” function of the Bullet Engine implementation. It is
called every frame from the “OnRender” function in the “Main.cpp” file.
Code Snippet 10. Bullet Step Simulation
dynamicsWorld->stepSimulation(1.0f/_timeStep,1);
for (int i = 0; i < allObjects.size(); i++ ) {
bulletObjects[i]->getWorldTransform().
getOpenGLMatrix(allObjects[i]->myMatrix);
}
3.6.4 Havok Implementation
Havok has the most cumbersome implementation of all the engines that are
evaluated. There are multiple header files that need to be included and multiple
features that need to be excluded. The header files need to be included in the cpp file
of the implementation while all the exclusions need to be in the header file of the
implementation. Havok is the engine that took most time to implement and therefore
“falls behind” in the “ease of use” category.

33. Grigor Todorov
1102166 33
Another difference between Havok and the other engines is the need of a special
error report function that is usually used to print error messages in the console.
Without such function the base of the engine cannot be created and the engine cannot
be initialized.
As seen in (Code Snippet 11. Havok Initialization) Havok requires allocation of
available memory. When the physics simulation reaches the limits of the allocated
memory the simulation stops. In the Evaluation Application this can be achieved by
creating a large amount of objects. Since by the time the limit of 4096*4096
allocated memory is reached the simulation is very slow and not useable in an actual
game, more memory does not need to be allocated.
Code Snippet 11. Havok Initialization
In header:
hkMemoryRouter* memoryRouter;
hkpWorld* physicsWorld;
hkReal timestep ;
hkpBoxShape* groundShape;
In cpp Initialize() called in the constructor:
hkMemorySystem::FrameInfo finfo(4096 * 4096);
memoryRouter = hkMemoryInitUtil::initDefault(hkMallocAllocator::m_defaultMallocAllocator,
finfo);
hkBaseSystem::init( memoryRouter, errorReport );
hkpWorldCinfo worldInfo;
worldInfo.setupSolverInfo(hkpWorldCinfo::SOLVER_TYPE_2ITERS_HARD);
worldInfo.m_gravity = hkVector4(0.0f, -9.8f, 0.0f);
worldInfo.m_broadPhaseBorderBehaviour = hkpWorldCinfo::BROADPHASE_BORDER_FIX_ENTITY;
worldInfo.setBroadPhaseWorldSize(1000.0f);
physicsWorld = new hkpWorld(worldInfo);
hkpAgentRegisterUtil::registerAllAgents( physicsWorld->getCollisionDispatcher() );
Havok, similarly to the other physics engines evaluated in this thesis, uses row-major
matrices that require conversion to be used in the OpenGL rendering pipeline. Havok
does not provide a conversion of the matrixes and a custom made slow and
cumbersome conversion function had to be used. It took a fair amount of time to
create the function which demonstrates that Havok clearly lacks behind Bullet in this
regard. The matrix transformations are not discussed in this dissertation because they
are not required in the functioning of a physics engine and are only used for the
graphical representation of objects. The step simulation function can be seen in (Code
Snippet 12. Havok Step Simulation). It is similar to the step simulation functions of
PhysX and Bullet.

34. Grigor Todorov
1102166 34
Code Snippet 12. Havok Step Simulation
physicsWorld->stepDeltaTime(1.0f/time_step);
for (int i = 0; i < allObjects.size(); i++ )
{
if(havokObjects[i]->isActive())SetProperMatrix(i);
}
3.7 FreeGlut implementation
3.7.1 FreeGlut base implementation
FreeGlut shares the same implementation with glut (Code Snippet 13. FreeGlut Base
Implementation).
Code Snippet 13. FreeGlut Base Implementation
In the main function:
glutInit(&argc, argv); // Initialize the glut (freeglut) library
glutInitDisplayMode(GLUT_DOUBLE | GLUT_RGBA | GLUT_DEPTH);
glutInitWindowSize(winWidth, winHeight); //screen and height
glutCreateWindow("Physics Engine Evaluation"); //creates a new glut window
glutDisplayFunc(OnRender); // the display function is OnRender
glutIdleFunc(OnIdle); //the idle function is OnIdle
glutReshapeFunc(OnReshape); //the reshape function is OnReshape
glutMouseFunc(Mouse);
glutMouseWheelFunc(MouseWheel);
glutMotionFunc(Motion);
glutKeyboardFunc(Keyboard);
InitGL(); //call the freeglut initialization method
glutMainLoop(); //start/enter the freeglut loop
void InitGL() {
glEnable(GL_DEPTH_TEST);
glEnable(GL_CULL_FACE);
glEnable(GL_LIGHTING);
glEnable(GL_LIGHT0);
GLfloat ambient[4]={0.25f,0.25f,0.25f,0.25f};
GLfloat diffuse[4]={1,1,1,1};
GLfloat mat_diffuse[4]={0.5f,0.5,0.5,0.5};
glLightfv(GL_LIGHT0, GL_AMBIENT, ambient);
glLightfv(GL_LIGHT0, GL_DIFFUSE, diffuse);
glMaterialfv(GL_FRONT, GL_AMBIENT_AND_DIFFUSE, mat_diffuse);
glDisable(GL_LIGHTING);
}
The event functions, such as “OnIdle”, “Mouse”and “Keyboard” are triggered by an event,
when the freeglut main event loop is entered.

35. Grigor Todorov
1102166 35
3.7.2 FreeGlut objects drawing
The artefact is capable of rendering cubes, spheres, capsules and convex meshes.
(Code Snippet 14. FreeGlut Object Rendering) demonstrate how the cubes and spheres are
drawn.
Code Snippet 14. FreeGlut Object Rendering
Cube rendering:
glPushMatrix();
glEnable(GL_COLOR_MATERIAL);
ChangeDrawingColor(); //Change according to the material of object
glMultMatrixf(myMatrix); //A new matrix is sent every frame
glutSolidCube(1.0f);
glColor3f(0.0f,0.0f,0.0f); //Black colour for the wireframe
glutWireCube(1.01f); //Every object has a black wireframe around itself
glPopMatrix();
Sphere rendering:
glPushMatrix();
glEnable(GL_COLOR_MATERIAL);
ChangeDrawingColor();
glMultMatrixf(myMatrix);
glutSolidSphere(0.5f,10,10);
glColor3f(0.0f,0.0f,0.0f);
glutWireSphere(0.501f,10,10);
glPopMatrix();
Since there are multiple materials for physics objects, each material has a different
colour. The “ChangeDrawingColor” function is called before the rendering of the
object.
Each object has a thin wireframe around itself, to make it easier for the user to
differentiate it from its surroundings. This wireframe is black and is created by
rendering the same object again, with its size of it being bigger.

36. Grigor Todorov
1102166 36
Code Snippet 15. FreeGlut Capsule Rendering
Capsule rendering:
glPushMatrix();
glEnable(GL_COLOR_MATERIAL);
glMultMatrixf(myMatrix);
glRotatef(xRot,1,0,0);
glRotatef(yRot,0,1,0);
glRotatef(zRot,0,0,1);
ChangeDrawingColor();
glutSolidCylinder(length,height,10,3);
glColor3f(0.0f,0.0f,0.0f);
glutWireCylinder(length+0.01,height+0.01,10,3);
ChangeDrawingColor();
glutSolidSphere(length, 10, 10);
glColor3f(0.0f,0.0f,0.0f);
glutWireSphere(length+0.01, 10, 10);
glTranslatef(0,0,height);
ChangeDrawingColor();
glutSolidSphere(length, 10, 10);
glColor3f(0.0f,0.0f,0.0f);
glutWireSphere(length+0.01, 10, 10);
glPopMatrix();
FreeGlut does not have a “glutSolidCapsule” function implemented and another
approach was used for the capsule rendering (Code Snippet 15. FreeGlut Capsule
Rendering). Capsules consist of a cylinder in the middle, with spheres on both sides.
After a short experimentation period the set up seen in (Code Snippet 15. FreeGlut
Capsule Rendering) proved to work best.
Every physics engine has a different default rotation for the capsule object, so
“glRotatef” is used to set up the rendering of the sphere to the physics object
rotation.
The mesh rendering is a more advanced topic and therefore some time was saved
with an already created and freely available class (Code Snippet 16. FreeGlut Mesh
Rendering).
Code Snippet 16. FreeGlut Mesh Rendering
Mesh rendering:
glPushMatrix();
glEnable(GL_COLOR_MATERIAL);
ChangeDrawingColor();
glMultMatrixf(myMatrix);
glmDraw(modelMesh, GLM_SMOOTH);// | GLM_MATERIAL);
glPopMatrix();

37. Grigor Todorov
1102166 37
“GLM” (UMN, 2014) was used to load and render a mesh. The mesh that was used
is a low polygon version of the Stanford Bunny (johnny6, 2013).
3.7.3 FreeGlut grid drawing
Code Snippet 17. FreeGlut Grid Drawing
void DrawGrid(int _gridSize)
{
glBegin(GL_LINES);
glColor3f(0.8f, 0.8f, 0.8f);
for(int i=-_gridSize;i<=_gridSize;i++) {
glVertex3f((float)i,0,(float)-_gridSize);
glVertex3f((float)i,0,(float)_gridSize);
glVertex3f((float)-_gridSize,0,(float)i);
glVertex3f((float)_gridSize,0,(float)i);
}
glEnd();
}
The rendering of the grid is standard and can be seen in numerous demonstrations
and implementations through the Internet. The grid is used instead of a ground plane.
With a grid the user is able to observe the simulated objects from any viewing angle
imaginable.
3.8 UI implementation
The User Interface of the artefact is created using a free class called AntTweakBar
(Anttweakbar, 2013). As with the mesh rendering, creating a custom user interface is
a large project by itself and cannot contribute in any way to the evaluation of physics
engines. The AntTweakBar fulfilled the project requirements and its implementation
was relatively easy.

38. Grigor Todorov
1102166 38
3.9 Encountered problems
Numerous problems were encountered through the implementation of the physics
engines. Some of the most persistent ones include:
 Lack of ability to control the GUI and the freeGlut camera at the same
window
 The use of std::vector pointers in Bullet Engine and Havok is not possible
Both problems are solved for the final version of the artefact. The first problem’s
solution was found in the documentation (Anttweakbar , 2013) of the graphics user
interface library used. The solution of the second problem was in the use of a built in
data type of vectors. Both Havok and Bullet have such types built in.
3.10 Testing
3.10.1 White-box testing
White-box testing was mostly used through the development stage. Each new
iteration was more or less the result of white-box testing. In order to achieve a good
quality of optimization debugging features had to be used regularly. Breaking points
and “std::cout” were used through the project in a regular basis to gain additional
feedback of the functioning of the application. Each library and header file was
excluded from the application to see if the application needs that part of the physics
engine. The visual debuggers of PhysX and Havok were used for more feedback on
the workings of the physics engines.
3.10.2 Black-box testing
Black-box testing was used regularly through the development of the artefact. After
the implementation of a feature the whole application was tested according to a set of
“bullet points”:

39. Grigor Todorov
1102166 39
 Are there any error listings in the console?
 Is the freeGlut functioning correctly
o Is the cpu usage normal?
o How long does it take to load the application?
o Is the camera controllable by the mouse and the scroll?
o Is the window resizable?
o Is the window minimizable?
o Is the window movable?
o Is the name of the window the right one?
 The UI
o Can the user control both the UI and the freeGlut window?
o Is the UI colour the usual one? (could mean an anttweakbar crash)
 Physics
o Are the physics engines initialized appropriately?
o Are all the buttons working?
o Is the gravity change working?
o Is the “Object Deletion” button working?
o Is the objects behaviour usual?
o Are the two physics materials working?
o Can the time step be changed?
These lists have helped to find the problems early. Bugs that are founded later
through development are usually harder to fix.
3.10.3 Focus group testing
There have been two focus group tastings for the project. The first one was half-way
through the project and the second one was at the very end. Both proved to be
invaluable for the projects development.
It was very important to separate each individual from the group and ask him to talk
while playing with the application. If the feedback is given at the end of the testing
most of it will be forgotten. A mobile phone was used to record what the testers say
while testing the artefact.

40. Grigor Todorov
1102166 40
A number of bugs were detected through the focus group testing:
 Havok capsules are not behaving properly.
 Havok matrices rotation conversion is broken.
 Changing the physics engine does not change the gravity as chosen in the UI,
because each physics engine starts with Earth gravity and even if other
gravity is specified in the UI, it is not taken into account.
The first two bugs were not repaired for the current version of the artefact. The third
bug with the gravity was repaired.
3.10.4 Evaluation of the Artefact
The artefact meets most of the aims and objectives and fulfils the artefact
requirements. There are some minor problems discussed in the previous chapter, but
they are mostly unnoticeable and do not interfere to the actual workings of the
artefact. The artefact is fully capable of performing multiple performance tests and
saving the information into a text file, which was its purpose from the start.
4. Evaluation of Physics Engines
4.1 Implementation Evaluation
The implementation of a physics engine needs to be as easy as possible. The least
cumbersome implementation has the biggest disadvantage. Some developer might
prefer to be able to implement an engine with a medium performance fast than
implementing the fastest physics engine, but through a slow and timewasting process
of implementation. Therefore the time it takes to a developer to implement a physics
engine is an important characteristics of that physics engine and needs to be
evaluated in this thesis.

41. Grigor Todorov
1102166 41
As seen earlier Havok Engine has the most cumbersome implementation from all the
evaluated engines. There are multiple header files that need to be included and the
engine does not provide a reliable conversion of matrices, which is something that is
required for a proper OpenGL rendering.
PhysX provides a system that converts matrices, but it did not work as expected and
a custom system had to be created. The creation of the system was easy and PhysX
has to be given credit for that.
Bullet does not require a custom matrices conversion function, because it has one
implemented by default. It works well and makes it very easy for a beginner
developer to convert the simulation matrix of each object from row-based major used
in Bullet to the column-based major used by OpenGL.
4.2 License Requirement Evaluation
Havok and PhysX are both governed by proprietary licenses and the user has no
access to the source code. This is not a problem for most titles since the engines are
always up to date and support teams are available. Bullet, on the other hand, is open
sourced and governed by the “zlib” license. Lack of dedicated teams for support of
Bullet Engine is not a problem because there are numerous forums and web sites
dedicated for Bullet Engine developers.
As Bullet Engine is completely free and open sourced it is the engine with the best
license.

42. Grigor Todorov
1102166 42
4.3 Features Evaluation
4.3.1 Collision shapes
As seen in the (Table 3. Collision
Comparison) all of the evaluated physics
engines support most of the usual
physics shapes. PhysX does not support
optimized cylinders, so a custom
cylinder mesh must be used for cylinder
collision with PhysX. That is the case
with cone collision for both Havok and
PhysX. Bullet Engine is the only physics
engine that supports all of the collision
shapes.
Table 3. Collision Comparison
PhysX Bullet Havok
Box   
Sphere   
Capsule   
Cylinder   
Cone   
Plane   
Convex   
Height Field   
Triangle mesh   
4.3.2 Available Constraints
This section of the thesis assesses the available constraints in each engine. As seen in
an earlier chapter in (Figure 1. Different Types of Physics Constraints) there are
different physical constraints that are available. Each physics engine has its own set
of constraints already implemented.
PhysX supports fixed, distance, spherical, revolute, prismatic and D6 constraints
(Nvidia, 2013).
Bullet supports ball socket, hinge, Slider, Cone Twist and 6 DoF constraints (Bullet,
2013)
Havok supports point-to-point, hinge, D6 and Spring constraints (Havok, 2002)

43. Grigor Todorov
1102166 43
Table 4. Constraints comparison
PhysX Bullet Havok
Fixed   
Distance   
Point-to-point   
Hindge   
Slider   
D6   
Some physics engines use synonyms of the same constraint type in the provided
documentation. Spherical joint can also be referred as Ball Socket or Point-to-point
joint. Hinge joint is also referred as Revolute joint. Prismatic joint is a synonym of
Slider joint.
4.3.3 Vehicle specific features
Both PhysX and Havok have advanced physics systems for vehicle simulations
already implemented. Although Bullet attempts to provide such system as well it
fails to catch up to its two competitors. This is most likely due to the fact that PhysX
and Havok are proprietary and both Nvidia and Intel can indulge on developing an
expensive solution for vehicles.
4.4 GPU Acceleration Evaluation
There is a universal transfer of all the simulations from the CPU to the GPU.
Currently the GPU is usually responsible for cloth and particle simulation with all the
rigid body simulations running on the CPU. It is very hard to create realistic
interactions between physics actors simulated on the CPU and the ones that use the
parallelism of the GPU.

44. Grigor Todorov
1102166 44
With the new Nvidia Flex technology that will be available with PhysX 3.4.x, and
the new version of the Bullet Physics Engine, available and under development in
Bullet 3.x, all the simulations will be transferred to the GPU. This would speed up
the simulation and make more realistic simulations of water, soft bodies and Voronoi
shattering possible.
Screenshot 4. Bullet GPU and PhysX Flex
Bullet Physics 3.x – GPU rigid bodies
(Coumans, 2013)
Nvidia Flex – collision between GPU rigid
bodies and particles (Nvidia, 2013)
It is unknown how many objects are simulated in the first image in (Screenshot 4.
Bullet GPU and PhysX Flex), but a demonstration video for the Havok GPU
acceleration features over one million objects (IGN, 2013) running on a modern
video card. This is very impressive when compared to my evaluation application that
starts slowing down with merely 8000 simultaneous CPU rigid bodies. Unfortunately
the currently available Bullet Physics Engine 3.x does not run as fast as it is seen to
run in the demonstration.

45. Grigor Todorov
1102166 45
4.5 Ease of use and help provided
Both PhysX and Bullet have moderately sized folders when downloaded. Havok
features a large amount of sample demonstrations and additional applications which
clearly results in a bigger folder as seen in (Table 5. Download size).
Table 5. Download size
PhysX Bullet Havok
Size 990MB 1,06GB 5,21GB
The “externals” folder of the evaluation application ended up being over 7,60GB but
after cleaning up some files that are not needed for the compilation of the application
the current size can fit into a standard DVD. Most of the examples and samples from
all the engines are removed.
Although Havok is relatively hard to integrate in an application it offers the largest
amount of samples from all the engines evaluated.
4.6 Performance Evaluation
In order to measure the performance of the
artefact an additional feature had to be
implemented. The current version of the
evaluation application has the function to
save a text file with information. The user
can save a log file of the performance
through the tests and use that information for
a later use. The “Measure performance” button starts the saving to the log file. The
measure frequency specifies the frequency of the data gathered. With a frequency of
one every frame will be added to the log file, while with the frequency of sixty this
would happen roughly once a second.
Screenshot 5. Rendering GUI

46. Grigor Todorov
1102166 46
The data that is saved consists of:
 An identifier of the engine that is being used.
 The current frame of the performance measurement.
 The number of physics objects that were created
 The current FPS
 How many milliseconds the last frame took
With the data collected multiple comparison tables were created. The exact steps
followed through the measurements are as follows:
 Start the evaluation application
 Change the “Measure frequency” property to 30.
 Chose a physics engine.
 Set up the total objects to be created to be 100 (the default is 125).
 Clean the log with the “Clean Log” button.
 Disable the “Render Objects” option, because rendering of objects slows
down the system and interferes to the performance measurement.
 Enable the “Measure performance” tick.
 Start creating objects until the total number of objects created reaches 5000.

47. Grigor Todorov
1102166 47
Cube Creation Evaluation:
The first thing that was measured is the performance of physics engines while
creating cubes. (Figure 7. Cube creation chart) demonstrates the performance of the
engines while constantly creating new cubes. The chart demonstrates how the
amount of objects created (the numbers at the bottom) affects the application frame
rate (the number to the left).
Figure 7. Cube creation chart
As seen in (Figure 7. Cube creation chart) Bullet Engine performs worst. PhysX is very
stable and behaves well for the first 1800 boxes. It also scales well and has a gradual
performance decrease line. Havok performs best and has an advantage of almost ten
frames per second in every occasion.
0
10
20
30
40
50
60
70
80
0 1000 2000 3000 4000
Bullet
Havok
PhysX

48. Grigor Todorov
1102166 48
Sphere Creation Evaluation:
The results when measuring the performance of creation of spheres was similar for
PhysX and Bullet. Havok is capable of optimizing its performance better than the
other engines. When the majority of box start moving slower and does not have
many contact points with other boxes the performance increases. As seen in (Figure 8.
Sphere creation chart) both PhysX and Bullet lack such feature by default. Their
results are very similar.
Figure 8. Sphere creation chart
Since sphere collision is the easiest collision to be determined mathematically wise it
is not a surprise that this is the test with best performance for all physics engines.
0
10
20
30
40
50
60
70
0 1000 2000 3000 4000
Bullet
Havok
PhysX

49. Grigor Todorov
1102166 49
Capsule Creation Evaluation:
The capsule performance for both PhysX and Havok are very similar. As seen in
(Figure 9. Capsule creation chart) only Bullet lacks behind. Havok has a slight
advantage over PhysX when the amount of capsules created becomes more than
three thousand.
Figure 9. Capsule creation chart
This test differs from the other tests mainly because of PhysX. Usually PhysX can
support sixty frames per second until the amount of created boxes or spheres reaches
one thousand five hundred. It is surprizing that it manages to support the same
performance up until reaching two thousand capsules. One would imagine that
capsule collision is more complex than sphere collision. The results PhysX provides
might be due to the fact that capsules are created in such fashion that when multiple
capsules are created at the same time they collide with each other and fly away from
the centre of the world. This might have positive impact of the performance
measurement since broad phase collision does not happen for some capsules and
therefore PhysX does not check for narrow phase collisions, which has a higher
performance intensity.
0
10
20
30
40
50
60
70
0 1000 2000 3000 4000
Bullet
Havok
PhysX

50. Grigor Todorov
1102166 50
Mesh Creation Evaluation:
The mesh collision test tested the physics engines to their limits. As (Figure 10. Mesh
Creation Chart) demonstrates the user should avoid using mesh collision for an actual
game. The usually gradual reduction of PhysX performance is not observable any
more. PhysX has a slight advantage over Havok in most of the test. Bullet, once
again, lacks behind the other two engines.
Figure 10. Mesh Creation Chart
The mesh collision results from (Figure 10. Mesh Creation Chart) are not surprizing.
The Stanford Bunny (Stanford, 2013) used for this test has 168 vertices and the
physics engines use mesh collision instead of the optimized convex collision.
0
10
20
30
40
50
60
70
0 1000 2000 3000 4000
Bullet
Havok
PhysX

51. Grigor Todorov
1102166 51
Another thing that was measured while performing the tests was the CPU usage.
(Table 6. CPU Usage) is a result of measuring the CPU. The CPU was measured while
the application was off and while there were four thousand objects of different types
simulated.
Table 6. CPU Usage
App off PhysX Bullet Havok
CPU usage (%) 5% 25 12 13
Ram usage 2,48GB 2,63GB 2,66GB 2,64GB
Core usage 4 - low 5 - high 4- med 4 - med
Bullet and Havok offer a slight reduction in CPU usage while PhysX uses more CPU
cores.
The machine used for the performance measurement has the following
characteristics:
 64-bit Windows 7 with Service Pack 1
 Intel i7-2630QM with 2.00Ghz and 4(8) cores
 6 GB ram
 Graphics card is not important since neither of the engines offers GPU
acceleration for rigid bodies.
As seen in the above tests PhysX offers the greatest scalability with gradual
performance reduction. Havok supports a large amount of objects, while keeping the
performance high, but it also provides inferior simulation quality over PhysX.
Bullet’s main strength is that it is open-sourced and can be good for some smaller
games without the need of a lot of physics objects.

52. Grigor Todorov
1102166 52
5. Conclusion and further work
5.1 Conclusion
As described in the contextual review physics engines evolve with newer versions
available regularly and this thesis cannot provide an evaluation that can stay true for
a long time in the future. The main goal of this project is to provide an application
and information how the user can evaluate different physics engine versions, both
from the past and the future.
As seen in the tests from Section 4 Havok is capable of simulating a large number of
objects and has the most samples available. Both Havok and PhysX feature a system
for vehicle simulation, which makes them a preferable option when creating games
that include vehicles. Bullet performs badly, compared to PhysX and Havok, but this
is to be expected from an engine that is open-sourced. Some developers will prefer
Bullet over Havok or PhysX solely because of its openness and user base. PhysX
proved to be the most precise engine with the greatest simulation quality and is a
perfect solution for games with moderate amount of rigid body objects.
5.2 Further work
The artefact lacks some crucial features for a successful performance measurement
such as the ability to create different types of joints as well as pre-made objects that
use joints. Some such objects can include ragdolls, vehicles as well as robots that use
joints for walking and jumping.
The feature that lets the user change the material of the objects can be extended,
adding additional options that can provide the functionality to create unique
materials.
For future versions some additional engines such as ODE, Chrono and Newton can
be included.

53. Grigor Todorov
1102166 53
The main.cpp file of the artefact should be recreated with object orientation in mind.
Another approach should be taken for the drawing of the scene and the UI, because
the current state of the main.cpp is untidy and hard to understand.
References
Anttweakbar , 2013. anttweakbar with GLUT. [Online]
Available at: http://anttweakbar.sourceforge.net/doc/tools:anttweakbar:howto
[Accessed 19 2 2014].
Anttweakbar, 2013. Anttweakbar. [Online]
Available at: http://anttweakbar.sourceforge.net/doc/
[Accessed 15 8 2013].
Boeing, A., 2007. Evaluation of real-time physics simulation systems. Association for
Computing Machinery , p. 8.
bullet Hello World, 2013. bulletphysics.org. [Online]
Available at: http://www.bulletphysics.org/mediawiki-1.5.8/index.php/Hello_World
[Accessed 28 12 2013].
bullet physics download, 2013. code.google.com. [Online]
Available at: https://code.google.com/p/bullet/downloads/list
[Accessed 22 12 2013].
Bullet, 2013. bulletphysics.org. [Online]
Available at: http://bulletphysics.org/mediawiki-1.5.8/index.php/Constraints
[Accessed 03 14 2014].
bulletphysics, 2012. http://bulletphysics.org/. [Online]
Available at: http://bulletphysics.org/mediawiki-
1.5.8/index.php/Creating_a_project_from_scratch#Link_order_for_libraries
[Accessed 22 12 2013].
Chalikias, T. P., 2013. devkast.com. [Online]
Available at: http://www.devkast.com/2013/02/24/getting-started-on-physx-3-2-1-opengl/
[Accessed 22 12 2013].
Coumans, E., 2013. GPU rigid body teaser video for my GDC 2013. [Online]
Available at: https://www.youtube.com/watch?v=ZkF4yMmP0R8
[Accessed 15 10 2013].
Cunningham, W., 2001. Manifesto for Agile Software Development. [Online]
Available at: http://agilemanifesto.org/
[Accessed 12 2 2014].

54. Grigor Todorov
1102166 54
Fischer, A., 2005. OPAL Overview. [Online]
Available at: http://opal.sourceforge.net/overview.html
[Accessed 15 04 2014].
gamedev forum, 2012. gamedev.net. [Online]
Available at: http://www.gamedev.net/topic/475753-list-of-physics-engines-and-reference-
material-updated-7-march-2011/
[Accessed 22 12 2013].
Geeknet, 2009. The Gangsta Wrapper. [Online]
Available at: http://gangsta.sourceforge.net/
[Accessed 22 03 2014].
Havok, 2002. Havok Game Dynamics SDK. In: s.l.:online, p. 33.
Hoffman, B., 2014. CMake Documentation. [Online]
Available at: http://www.cmake.org/cmake/help/documentation.html
[Accessed 20 11 2013].
Hummel, J., 2012. An Evaluation of Open Source Physics Engines. ISVC, p. 12.
IBM, unknown. Abstract classes (C++ only). [Online]
Available at:
https://publib.boulder.ibm.com/infocenter/lnxpcomp/v8v101/index.jsp?topic=%2Fcom.ibm.
xlcpp8l.doc%2Flanguage%2Fref%2Fcplr142.htm
[Accessed 10 11 2013].
IGN, 2013. Havok Engine Demo. [Online]
Available at: https://www.youtube.com/watch?v=QnKNliV7gwU
[Accessed 20 1 2014].
jgraph, 2014. draw.io. [Online]
Available at: https://www.draw.io/
[Accessed 12 1 2014].
Jim, unknown. Interfaces in Object Oriented Programming Languages. [Online]
Available at: http://www.cs.utah.edu/~germain/PPS/Topics/interfaces.html
[Accessed 4 12 2013].
johnny6, 2013. http://www.thingiverse.com/. [Online]
Available at: http://www.thingiverse.com/thing:151081/#files
[Accessed 20 2 2014].
marcoarena, 2011. marcoarena.wordpress.com. [Online]
Available at: http://marcoarena.wordpress.com/2011/04/17/nice-to-meet-you-havok/
[Accessed 22 12 2013].
Mountaingoatsoftware, 2012. Scrum Overview for Agile Software Development. [Online]
Available at: http://www.mountaingoatsoftware.com/agile/scrum/overview/
[Accessed 17 1 2014].

55. Grigor Todorov
1102166 55
Nvidia Documentation, 2013. developer.nvidia.com. [Online]
Available at:
https://developer.nvidia.com/sites/default/files/akamai/physx/Manual/Basics.html
[Accessed 22 12 2013].
Nvidia, 2013. developer.nvidia.com. [Online]
Available at: https://developer.nvidia.com/sites/default/files/akamai/physx/Docs/Joints.html
[Accessed 12 03 2014].
Nvidia, 2013. FLEX: Unified GPU Physics. [Online]
Available at: https://developer.nvidia.com/content/flex-unified-gpu-physics
[Accessed 20 3 2014].
PAL, 2009. Building PAL with CMake Tutorial. [Online]
Available at:
http://sourceforge.net/apps/mediawiki/pal/index.php?title=Building_PAL_with_CMake_Tut
orial
[Accessed 15 3 2014].
Rassweiler, T., 2012 . Rapid Prototyping: Tips for Running an Effective R&D Process.
[Online]
Available at:
http://www.gamasutra.com/view/feature/179501/rapid_prototyping_tips_for_.php
[Accessed 20 03 2014].
Seugling, A., 2006. Evaluation of Physics Engines and Implementation of a Physics Module
in a 3d-Authoring Tool. Master’s Thesis in Computing Science.
Stanford, 2013. The Stanford 3D Scanning Repository. [Online]
Available at: http://www-graphics.stanford.edu/data/3Dscanrep/
[Accessed 25 10 2013].
UMN, 2014. www.d.umn.edu. [Online]
Available at:
http://www.d.umn.edu/~ddunham/cs5721f07/schedule/resources/lab_opengl07.html
[Accessed 10 2 2014].
Wilcox-Netepczuk, D., 2013. Immersion and Realism in Video Games - The Confused
Moniker of Video Game. [Online]
Available at: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6632613
[Accessed 05 12 2013].
Zogrim, physxinfo.com, 2013. physxinfo.com. [Online]
Available at: http://physxinfo.com/news/11822/star-citizen-and-project-cars-will-include-
gpu-accelerated-physx-and-apex-effects/
[Accessed 12 12 2013].

56. Grigor Todorov
1102166 56
Appendices