Approaches to Destruction Effects in Real

Statement of Authorship
I hereby declare that this thesis has been written only by the undersigned and
without any assistance from third parties. Furthermore, I confirm that no sources
have been used in the preparation of this thesis other than those indicated in the
thesis itself.
Eidesstattliche Erklärung
Hiermit versichere ich die vorliegende Thesis, ohne unzulässige fremde Hilfe, selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel
benutzt zu haben.
Karlsruhe, June 17, 2013
Signature
Contact
Raphael Hettich
Advisor
Prof. Dr. Holger Vogelsang
Hochschule Karlsruhe – Technik und Wirtschaft
Fakultät für Informatik und Wirtschaftsinformatik
Moltkestraße 30
76133 Karlsruhe
[email protected]
Abstract
The thesis will focus on historical and modern approaches to destruction effects
in real-time computer graphics. Historical perspectives will be presented, starting
with older techniques and why no other approaches were possible and continuing
to semi-modern tricks that tried to simulate dynamic destruction. The evolution
of destruction technology will be demonstrated by exploring specific game engines
that helped advance the technology, such as: GeoMod, the Frostbite Engines, the
Unreal Engines and the CryENGINEs. The remainder will primarily focus on techniques introduced within the last five years, such as rigid body simulation, dynamic
destruction and upcoming techniques utilizing PhysX and other physics engines.
This includes discussions of current approaches using a combination of PhysX and
APEX and the requirements to utilize these frameworks in a prototype or within
an existing computer game’s engine. The main focus will lie on techniques that
are used in APEX Destruction, its asset preparation, tool pipeline and obstacles
to using them. Finally there will be a comparison between the commercial Havok
physics engine and the free PhysX. The thesis will end with an analysis of current
trends with destruction systems, forecasts for short term advancements as well as
research being done to further the technology in the long term, such as full dynamic
fracturing.
Abstract
Die Thesis konzentriert sich auf historische und moderne Ansätze für Zerstörungseffekte in der Echtzeit-Computergrafik. Historische Ansätze werden präsentiert, beginnend mit älteren Techniken und Erklärungen, warum damals kein anderer Lösungsweg möglich war. Danach werden die Tricks der letzten Jahre präsentiert, um
dynamische Zerstörungen zu simulieren. Die Weiterentwicklung dieser Zerstörungstechnologien wird demonstriert, indem die wichtigsten Spiele-Engines vorgestellt
werden, die durch besagte Technologien weiterentwickelt wurden, wie z. B. GeoMod, die Frostbite-, Unreal- oder Cry-Engines. Der Rest der Thesis konzentriert sich hauptsächlich auf die vorgestellten Techniken der letzten fünf Jahre, wie
z. B. die Rigid-Body-Simulation, der dynamischen Zerstörung und die Techniken,
welche zurzeit entwickelt werden, damit PhysX sowie andere Physik-Engines genutzt
werden können. Des Weiteren beinhaltet die Thesis eine Diskussion aktueller Ansätze, die eine Kombination aus PhysX und APEX verwenden. Zusätzlich werden
Voraussetzungen erläutert, die nötig sind, um diese Frameworks in einem Prototyp oder einer existierenden Computerspiele-Engine zu nutzen. Der Hauptfokus
liegt auf den Techniken, welche von APEX Destruction, dessen Asset-Vorbereitung
und Toolpipeline genutzt werden und welche Hindernisse dabei zu bewältigen sind.
Gegen Ende zieht die Thesis einen Vergleich zwischen der kommerziellen HavokPhysik- sowie der freien PhysX-Engine. Zuletzt schließt sie mit einer Analyse der
aktuellen Trends für Zerstörungssysteme, Voraussagen für kurzfristige Verbesserungen sowie Forschung, die noch durchgeführt wird um die Technologie langfristig zu
verbessern und weiterzuentwickeln, wie z. B. Full-Dynamic-Fracturing, ab.
Acknowledgments
I would like to thank my advisor, Prof. Dr. Vogelsang, for accepting my proposed
thesis and providing guidance through the process. I would like to thank Andreas
Jung for working in cooperation with me on our shared prototype and for discussing
many topics with me. My gratitude goes out to Johnny Costello from NVIDIA for
pointing me to the right direction when doing my research and to all the people that
helped me gather the statistical information that I was able to use in my analysis. I
am indebted to Nathaniel Wilson Grady, Dalton Debellotte, Rod Dee and Andrew
Skinner for helping me with grammar and editing. Also, I would like to thank Adam
Burry for helping with render setups. Lastly, I wish to thank my parents and close
friends, whose enthusiasm and support have given me the motivation to realize this
achievement.
Contents
1. Introduction
2. Historical View on Approaches to Destruction
2.1. GeoMod . . . . . . . . . . . . . . . . . . . .
2.2. The Frostbite Engines . . . . . . . . . . . .
2.2.1. Destruction 1.0 . . . . . . . . . . . .
2.2.2. Destruction 2.0 . . . . . . . . . . . .
2.2.3. Destruction 3.0 . . . . . . . . . . . .
2.3. Unreal Engine 3 and 4 utilizing APEX . . .
2.4. CryENGINE - The Crysis Series . . . . . . .
1
.
.
.
.
.
.
.
3
3
5
7
8
10
10
13
3. Modern Physics Engines and their Destruction Engines
3.1. PhysX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.2. Havok . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3. Bullet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
18
18
22
24
4. Base Technologies for Destruction Effects
4.1. CSG - Constructive Solid Geometry . . . . . . . . . . . . . .
4.2. Voxels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3. Voronoi Diagrams . . . . . . . . . . . . . . . . . . . . . . . .
4.3.1. Voronoi Definition . . . . . . . . . . . . . . . . . . .
4.3.2. Voronoi Diagram Properties . . . . . . . . . . . . . .
4.3.3. Delaunay Triangulation . . . . . . . . . . . . . . . .
4.3.4. Voronoi Construction . . . . . . . . . . . . . . . . . .
4.3.5. Voronoi Diagrams and Delaunay Tesselestions in 3D
4.3.6. Using a Voronoi Diagram for Destruction . . . . . .
4.4. Tetrahedralization . . . . . . . . . . . . . . . . . . . . . . .
4.5. Digital Molecular Matter . . . . . . . . . . . . . . . . . . . .
4.6. Semi-Automated Convex Decomposition . . . . . . . . . . .
4.7. Fracture Maps . . . . . . . . . . . . . . . . . . . . . . . . .
4.8. Particles Systems . . . . . . . . . . . . . . . . . . . . . . . .
4.9. Turbulence Effects . . . . . . . . . . . . . . . . . . . . . . .
4.10. Destruction Masking . . . . . . . . . . . . . . . . . . . . . .
26
26
29
31
32
33
35
37
40
40
41
42
42
45
46
49
51
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5. Utilizing APEX Destruction
54
5.1. APEX PhysX Lab . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.2. APEX Fileformat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
5.3. Approaches to Fracturing .
5.3.1. Common Mistakes .
5.3.2. Slicing . . . . . . . .
5.3.3. Cut-Out . . . . . . .
5.3.4. Voronoi . . . . . . .
5.3.5. Pre-Fracturing Speed
5.3.6. The Slice Method . .
5.3.7. The Voronoi Method
5.3.8. The Results . . . . .
. . .
. . .
. . .
. . .
. . .
Test
. . .
. . .
. . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
55
57
59
62
65
65
66
67
68
6. Prototype Analysis
68
7. Conclusion
70
8. Future Prospects
73
A. List of Figures
74
B. Listings
76
C. References
76
1. Introduction
During the past 15 years, real-time computer games have come a long way. With
expanding hardware capabilities, developers realized they were able to create increasingly more impressive visuals. A great number of techniques and concepts that
have been developed by computer scientists all over the world in various papers
and theses in the past was now at the grasp of their fingertips. However, with
the capacity to create more impressive visual assets, players demanded not only
better graphics, but also improved interactivity and depth in terms of physics and
realism.
The so called AAA titles1 soon provided this interactivity and the major studios
started working closely with GPU vendors to provide new technologies for their
titles. Physics Engines such as NVIDIA PhysX2 , Bullet Physics3 or Havok4 appeared
and were soon implemented in the major gaming engines like the Unreal Engine by
EPIC Games5 and the CryENGINE by Crytek6 . With these physics engines more
realism and interactivity were possible. However, due to the fact that such engines
were only available as big and often very expensive middleware, smaller developers
and projects usually lacked such features. This was usually because it was either
prohibitively expensive or too hard to implement with a small core of developers
and thus not worth the effort.
In the last couple of years independent video games, created by small teams and
with often a very small budget or no budget at all, became more and more popular.
But it was not until the development of famous titles, such as Minecraft7 , Braid8 ,
World of Goo9 etc., that this became a major topic. Still, despite the visibility of
this topic in the minds of consumers and media outlets and the need for independent
studios to compete with AAA-title developers, it was even harder for small teams
to reach their goals.
At this time middleware and engine providers realized the potential of independent development and many offered their middleware for free, unless the project
1
High quality games with high budget
https://developer.NVIDIA.com/physx
3
http://www.bulletphysics.com
4
http://www.havok.com
5
http://epicgames.com
6
http://www.crytek.com
7
https://minecraft.net
8
http://braid-game.com
9
http://www.worldofgoo.com
2
1
became commercial. With this technology available, developers could in theory create similarly good games on par with AAA studios. However, the small developers
always lacked support. Conversely, AAA studios could easily acquire a consultant
and usually got the middleware implemented as part of their contract. This was
because middleware developers such as NVIDIA gained mutual benefit in terms of
profits, distribution and visibility as a result of this relationship. Regardless of the
implementation of the middleware, all game developers began to require increasingly powerful GPUs in order to achieve their desired results and therefore had to
purchase from NVIDIA or ATI or choose to do without.
Currently, the so called “destruction pipeline” is especially featured in shooting
games as a key aspect in terms of visuals and gameplay. This creates a difficult
problem for inexperienced and independent developers, as well as for those lacking a
technical or academic background. Specifically, there is very little documentation on
this subject. What does exist is highly technical and scientific literature on advanced
destruction effects in computer games. This requires a thorough understanding of
the scientific and mathematical principles involved and is therefore inaccessible to
the majority of the population who may take interest in game development.
The goal of this thesis in combination with Andreas Jung’s “Implementing Dynamic
Destruction in Real-Time Computer Graphics using PhysX and APEX”[1] is to
provide the reader with a very broad and accessible overview of techniques that are
available today. It will focus on what has been done in the past and how well it has
worked. Additionally, this will provide the basis for understanding the technologies
without a thorough scientific or mathematical background. It will also provide
insight into the best destruction framework available for free today, which will suit
small developers and studios: NVIDIA APEX Destruction. Common mistakes will
be discussed and solved where possible, in order to allow the reader to avoid most
of these issues before it is too late for a change. In combination with the thesis by
Andreas Jung[1], a prototype will also be discussed and the analysis at the end of
this thesis should give the reader an idea of how well this solution performs and how
scalable it is.
The main goal of this thesis is therefore providing independent developers and beginners with an insight into the technologies to save time as well as to help them
gain an understanding if dealing with “the Art of blowing crap up”[2] is really worth
the effort for their project.
2
2. Historical View on Approaches to Destruction
Destruction has always been a part of video games. Ever since the very first video
games, destruction has been about the interaction between the player and the game’s
environment. The concept was nothing new, whether it was “Space Invaders”10 or
“Super Mario”11 . Taking one step back, destruction is merely a special case of
interaction. Interactions in real-time computer graphics are however a more recent
development. One of the very first real-time 3D computer games that made use of 3D
models, objects and 3D environments was “Quake”, a first-person shooter developed
by “id Software”12 and mainly programmed by John Carmack13 . Quake offered a
variety of interactions with the entities in the game. Objects were touchable, and if
they were shot there was a simple scripted effect. In the following games, interaction,
e. g. the destruction of a door or rock, was often script-based or the obstacle entity
was removed as a whole, while the physics of these objects were in most cases
only based on simple bounding boxes. These so called physics were in most cases
nothing more than simple collision detection. No movement of these objects were
ever intended. The first big attempt to implement dynamic destruction in a 3D
real-time environment was a technology called GeoMod.
2.1. GeoMod
GeoMod is short for Geometry Modification
which was first introduced in a game called
Red Faction, developed by Volition Inc.14 .
Red Faction was released for several platforms, starting as early as May 21st , 2001 for
the PlayStation 2 and on September 17th,
2001 for the PC. The technology allowed the
player to destroy large parts of the environment to an extent that was previously unknown in real-time environments. The purFigure 1: Red Faction screenshot: Missing
pose of this destruction was to give the playproper physics simulation.
ers more freedom. Whether it was to find a
10
Space Invaders was a classic arcade video game released in 1987
Super Mario Bros by Nintendo
12
id Software LLC – video game development company - www.idsoftware.com
13
John D. Carmack II (*August 20th 1970) is the co-founder of id Software
14
Voliction Inc. – American game developer company - http://www.dsvolition.com
11
3
way to unlock a door or passage or to use explosives to create a tunnel or blow a
hole into a wall. It was the choice of the player. In addition, this offered a wide
range of tactical possibilities as to why this game was such a success, even though
many critics did not give the story a positive review. At this point, all the physics
performed in the game and material modifications were still limited and could not
compare to the physics engines of today. Even so, what remained was the ability
to dig a whole tunnel with the use of a rocket launcher, provided you had enough
ammunition to perform this. According to the proprietary Red Faction Wiki: “This
was performed with a unique method at the time; rather than simply altering an
object to a damaged state, the Geo-Mod engine created a new ’empty space’ object
to approximate the size and shape of the damaged area. In the first game, this
allowed players a limited ability to tunnel through even the rock walls surrounding
the playable area of the map.”[3] This technique still had many limitations, which
resulted in some effects seeming rather unrealistic (see Figure 1). To cover the clipping and geometry substitution process, the engine spawned a range of sprites to
create an effect of dust and smoke. If one was to break the leftover edge, showed in
Figure 1 the platform would simply drop and substitute to a random small number
of static bodies.
While these leftover bodies were
taken into account, when the
collision detection was calculated, the edges of the fractures had a rather simple material assigned to them. In other
words, the inside material when
something broke was always the
same (see Figure 2). The second version of the GeoMod Engine, GeoMod 2.0, featured a
different approach. As opposed
to the original concept of destructible terrain and environment, the second version of the
engine focused mainly on rigid
bodies controlled by a “ragdoll physics simulation with a
Figure 2: Red Faction screenshot: Inner material of a brostress-based collapse model for
ken wall.
4
buildings”[3]. Using this technology – released with the successor titles “Red Faction: Guerrilla” (GeoMod 2.0) and the next title of the series “Red Faction: Armageddon” (GeoMod 2.5) – an actual physics based simulation was possible and
believable, since the previously discussed issues with missing physical simulation of
a stress-based model was resolved.
After THQ15 filed bankruptcy in late 2012, development on the entire Red Faction
franchise ceased. The question of the GeoMod engine’s demise arose and senior
producer Greg Donovan16 answered this. Donovan stated that: “As far as GeoMod
goes, that’s our most mature tech now. I do not know what THQ has planned for
it, but personally I would say that it would be a shame if it did not go anywhere.
That’s unlikely to be the case.”[4] Unfortunately there has never been any technical
documentation released on the technology, therefore one could only speculate on
the technical implementation. However, it is most likely that GeoMod technology
made use of boolean operations on the geometry - such an approach is also known
as CSG, short for Constructive Solid Geometry (see subsection 4.1).
2.2. The Frostbite Engines
The Frostbite engines are at the heart of the majority of the Battlefield series17
games. These engines are technically very interesting when it comes to the topic
of this thesis, thus their approach on dynamic destruction shall be discussed here.
In 2007 Joakim Grundvall18 explained in an interview that when they started to
develop the Frostbite engine, they asked themselves the question: “What do we
want to do that has not been done before?”[5] The answer was: “To create a truly
dynamic and destructible world.”[5]. This presented a great number of technical
challenges for the developers to overcome. Especially when dealing with real-time
environments such as those present in the Battlefield games. Therefore not only
is the ability to dynamically destroy parts of the environment important, but it is
critical to understand how this integrates with the renderer. From the very beginning, Frostbite 1.0 was designed to not only function on the PC, but on the XBox
360 and Playstation 3 as well. The first title that was released using this engine was
Battlefield: Bad Company19 . The game featured DICE’s “Destruction 1.0” subsub15
THQ (Toy Head-Quarters) - an American game developer and publisher founded in 1989. Filed
bankruptcy in late 2012.
16
currently senior producer at Volition Inc.
17
Battlefield is a series of FPS video games
18
CTO, DICE
19
a first-person shooter game developed by DICE for the PS3 and XBox360
5
section 2.2.1 the first version of their destruction engine, which first offered what
seemed to be dynamic destruction for most people. It featured partially destructible
buildings, destructible vehicles and some experimental terrain deformations. Due
to the success of Frostbite 1.0 the next iteration of the engine Frostbite 1.5 was
developed and was used in three titles: Battlefield 1943, Medal of Honor’s Multiplayer and Battlefield: Bad Company 2. In this version of the engine, the developers
tried to improve on what they had created with the preceding destruction engine.
Therefore, Frostbite 1.5 featured “Destruction 2.0” subsubsection 2.2.2, which gave
the player more options to destroy the environment. It featured fully destructible
buildings, giving the player the tactical option of bringing down a whole building
crushing everything that is inside. Like its predecessor, it also featured a large
amount of micro destruction, such as chippable surfaces. Frostbite 2.0 is next to
the CryEngine (see subsection 2.4) and the Unreal Development Kit (UDK) (see
subsection 2.3), one of today’s most advanced real-time engines and is not only used
in the first person shooter Battlefield 3, but so far as well in the following titles:
• Need for Speed: The Run - A racing simulation, developed by EA Black Box20
released for the PC, PS3 and XBox 360.
• Medal of Honor: Warfigher - A first person shooter, developed by Danger
Close Games21 released for PC, PS3 and XBox 360.
• Army of Two: The Devil’s Cartel - A third person shooter, to be released in
2013 by Visceral games22 for PS3 and XBox 360.
• Command & Conquer - A real time strategy game by Victory Games23 for the
PC.
This list shows that the engine
is very versatile and can be used
across several platforms and
genres. This also means that
the destruction system within
“Destruction 3.0” (see subsubsection 2.2.3) must be compatible with the many different renderers as well. Feature-wise the
Figure 3: Frostbite 2: Interior Destruction [6].
20
www.eablackbox.com
21
http://www.dangerclosegames.com
22
http://www.visceralgames.com
23
formerly BioWare Victory
6
destruction engine of Frostbite 2.0 is able to use enhanced in-game destruction as
seen in many videos and screenshots. Buildings also feature stress based collapse
caused by earthquakes and other similarly programmed physics simulations. “Destruction is enhanced on both a macro and micro level. Chips fly off blocks of
concrete used for cover, while whole facades and buildings collapse in clouds of dust
and debris.”[7]
2.2.1. Destruction 1.0
Destruction 1.0 was the destruction engine used
by Frostbite 1.0 and featured partially destructible buildings (see subsection 4.10), simple terrain deformation, tree felling, chippable surfaces
and micro effects, such as particle debris. “The
Destruction 1.0 mechanic introduced selective
destruction, where only certain weapons or objects could cause damage - for instance a Cobra 4WD24 could not run over a tree, whereas
a Black Eagle battle tank could. This limited
the amount of destruction that could be caused
by certain players in certain scenarios. By creating the Destruction 1.0 mechanic fully with the
Frostbite Engine in mind, the DICE developers
were able to combine the Destruction 1.0, the
dynamic lighting and sound mechanics to create
a ’sandbox world’, where the destruction caused
by the player(s) would cause the lighting and Figure 4: Battlefield: Bad Company:
Destruction masking [8].
sound to change with the removal of walls, fences
and trees.”[8] Due to the way that Frostbite 1
handled its terrain rendering, it was possible to create 3D craters in real-time. Using Procedural Shader Splatting25 , it was easily possible to add destruction masks
to the splatting. At Siggraph 2007 Johan Andersson from DICE demonstrated the
steps that were necessary to utilize this feature.
24
25
a Turkish four-wheeled light armored vehicle designed by Otokar in the 1990s
“low-resolution unique color maps for low-frequency details with multiple tiled detail maps for
high-frequency details that are blended in at certain distance to the camera”(see [9])
7
• Change material and/or look
around craters to resemble a crater.
• Render decals into destruction mask
texture (see Figure 6).
– Covers playable area(2x2 or 4x4
km).
Figure 5: Battlefield: Bad Company:
Crater screenshot [9].
– Usually 2 pixels/meter.
• Material shader get access to simple
0-1 value in order to blend in or replaces textures and colors.
Andersson further states in his presentation that 100% destruction is not possible
in practice due to gameplay needs.
2.2.2. Destruction 2.0
Figure 6: Battlefield:
Bad Company: Crater mask (pointfiltering)[9].
The main upgrade that came with destruction 2.0 in Frostbite 1.5 was fully destructible buildings, which were showcased in Battlefield: Bad Company 2. However, this
was limited to buildings which were built specifically for this purpose and carefully
prepared by the artists. Den Kirson, one of the project developers explained the
functionality in this manner:
“A building is a group of entities linked together. The entities are a bunch of wall
and roof segments. Destroy a part, the wall disappears behind a smoke particle and
is replaced by a hole. When a percentage of the walls are destroyed, the building
plays its collapse animation. There’s little else to it. For example, the building
behind the first MCOM on Port Valdez. Break about 26 of those parts, and the
thing goes down.” [10]
8
Figure 7: Battlefield: Bad Company 2: Structural model of a building by Den Kirson [10].
While “Destruction 2.0” looks like it is a step forward, in comparison with the old
school csg-technique used by GeoMod 1.0 basing the destruction on a house on a
set of entities might seem backward and less dynamic, but what really matters is
how it appears to the player in-game. As long as a development team has enough
artists to cope with manually constructing each destructible building, the players
will not perceive a difference. The primary benefit in this method is that by staging
the collapse by manipulating each part-entity, (see Figure 7) the destruction follows
a choreography in such a manner that the end result is predictable in every case,
thus guaranteeing a good outcome from the point of view of the player.
Figure 8: Battlefield: Bad Company 2: Destruction [8].
9
2.2.3. Destruction 3.0
Destruction 3.0, as the third iteration of
DICE’s destruction engine, was shipped
for the first time with the release of Battlefield 3 and was highly anticipated as
it featured a new form of destruction
called “microdestruction”. With this
technology the engine was not only able
to destroy large parts and then cause a
reaction if enough part-entities were destroyed but the player was able to damage structures on a much smaller scale.
Each piece of a building that fell of was
a rigid body that was able to interact
with the player and the world. In other
words: “Falling pieces of rubble and collapsing buildings can potentially kill a
player.”[8]
Figure 9: Battlefield 3: Destruction[8].
2.3. Unreal Engine 3 and 4 utilizing APEX
Another major player in game engines, if not the most utilized engine lately, is the
Unreal Engine 3 and the free UDK326 . The UE3 and it’s successor the Unreal Engine
4 which is currently in development are next to the Cryengine the most feature rich
engines available, giving the developers the ability to bring their visions in game
with intuitive tools and a pipeline that has proven useful for many years. Quoting
Epic Games:
Unreal Engine 4’s architecture offers fully dynamic lighting features,
cutting down on development time and ensuring less iteration on creative
ideas. With significant new visual features, Unreal Engine 4 enables
developers to achieve high-end visuals, while remaining both scalable
and accessible to make games for low-spec PCs.
26
UDK3 - Unreal Development Kit “is a free full-feature development set for creating high-end simulations of all types including interactive computer games”(http://www.udk3developer.com)
10
While this is certainly a promise that is hard to keep, scalability was always a key
feature of high-end engines which enables these engines to break away from smaller
engines such as Unity, C4 or OGRE, even though Unity is catching up as the top
choice for independent developers.
Unreal Engine 4’s feature highlights for developers according to Alan Willard, senior
technical artist at Epic Games are:
• Instant Game Preview: Allows not only to view but to actually spawn a playing
entity that fully interacts with the game.
• Hot Reload and Code View: This is probably one of the most amazing features
for developers. If for instance an object is selected in the Editor, the Engine
will automatically load corresponding C++ Symbols and jump to the code
function that relates to them. Changes to the source can then be made and
with only a very short pause editing can continue live without a full recompile
required, this above all allows for very short iteration times and speeds up
debugging a great amount.
• Live Kismet27 Debugging: Gives the developer the ability to change the blueprint of events modeled in Kismet while the game is running in the background.
• Simulation Mode: With this mode the developer can run certain aspects of
the game logic and debug them in real-time if desired. Check how the AI is
behaving and perform possible fixed on the fly.
• Immersive View: The immersive view mode enables the developer or artist to
view the editor in full screen. Changes can be made even without UI control
at that time.
• Possess/Eject: This is a feature that allows the developer to switch out of
the game and into the Unreal Editor at any given time while testing, without
changing the state of what’s happening in game. This allows the developer to
inspect specific entities in real-time and reconfigure them if necessary.
The interesting part for this Thesis is the Unreal Engine’s destruction module which
directly utilizes NVIDIA APEX Destruction. This feature enables the Unreal Engine 3 and 4 to provide the developers with real-time destruction effects such as
Fracturing objects, breaking walls and so forth. This Thesis will go into the details
of APEX Destruction in this section section 3.1.
27
Unreal Kismet - a visual scripting component of the Unreal Engine
11
The remarkable part about APEX Destruction in the Unreal Engine is how well it
was integrated and became a part of the Engine’s Editor:
Build a gorgeous world and then let your players crush it to pieces.
Unreal Engine 3’s fracturing tool and runtime enable you to take virtually any existing mesh, slice it up into as many fragments as desired,
and destroy structures. Unreal Engine 3 supports the destruction of everything from metal to cloth, bringing more realism and interaction to
your environment. Unreal Engine 3’s fracture tool makes it possible to
create remarkably interactive, deformable worlds. Easily craft all types
of destructible environments and objects that break apart just as you
would expect them to in real life. Splinter walls and floors layer by
layer. Blow apart rocky structures chunk by chunk. Add cool physics
elements and particle effects. Unreal Engine gives you total control over
destruction. Destructible environments enable scene elements to break
apart and collapse realistically.
As good as it sounds, creating good results with the tools that come with it is
not an easy task and a thorough understanding of the underlying technologies (see
section 4) is often required to prevent artists from running into trouble, such as
issues with having concave objects that are too complex to handle and would have
needed a proper decomposition (see subsection 4.6).
Nonetheless with the Unreal Engine 3 and 4 developers can easily slice or fracture
meshes, adapt the chunks size and amount of pieces to meet the required performance and add the prepared assets into the running game world using Unreal’s
World Editor. On top Unreal offers a structural analysis tool, that helps artists to
create their destructibles.
There have been many videos uploaded to YouTube by hobby developers and modders. One particularly impressive video that demonstrated the new technology was
however the “Art Gallery” uploaded march 10th, 2011 by NVIDIA. According to
NVIDIA: “Art Gallery Destruction Tech Demo using up to 10,000 GPU Rigid Bodies
(GRB’s) to provide a fully destructible environment. Everything can be destructed
e. g. the ceiling, drywalls, pillars even the wooden floor. Secondary destruction from
debris can be seen right at the beginning.”
12
2.4. CryENGINE - The Crysis Series
The CryENGINE is Crytek’s gaming engine and is available in three versions CryENGINE
3 being the most current one. When Crytek released Farcry28 in 2004 it was considered one of the most graphically impressive Games at that time. Due to techniques
that became possible due to vertex- and pixel-shader 2.0, which were relatively new
at that time, it became very popular. According to Crytek the CryENGINE 1 was
the first engine to use per pixel shading29 and HDR lighting30 . With the success
of Farcry, Crytek released Crysis31 in november 2007, based on the CryENGINE 2,
which again set a milestone in real-time visuals and featured advanced physics and
breakable assets. One of the most impressive features was soft-physics on foliage
and dynamically breakable trees. The next iteration, CryENGINE 3 featuring Crysis 2 was even more impressive and was even awarded the German Computergames
Award for Best German Game in 2012.
The CryENGINEs starting with version 2 featured a WYSIWYG32 Editor called
the Sandbox-Editor which has similar features to the Unreal Engines Editor. The
CryENGINE 2 and 3 feature a Voxel(see subsection 4.2) based Terrain and developers planned on basing dynamic terrain destruction and deformation on it, however
that feature never made it ingame and was later re-enabled by a third-party modification.
Breakable Assets
The CryENGINE 3 features several types of breakable assets and methods of setting
them up. According to Crytek, instances are not supported. Artists are required to
set their assets in place using the Sandbox Editor, making sure that the combined
n
∩
number of pieces, P (Object) =
Pi with P representing the unbroken object and n
i=1
being the amount of breakable sub-pieces, are equal to P. Both the complete object,
and the breakable pieces should be present, substitution only occurs when necessary.
For example, when the object is destroyed. Crytek gives four reasons for this [11]:
• Render speed
28
a first-person shooter video game
refers to a technique for lighting, that calculates light for each pixel
30
lighting calculations are being processed using a larger range, e. g. 32-bit floating point textures
to store lightmaps
31
a first-person shooter video game
32
What you see is what you get
29
13
• Easier asset creation (because of possible gaps between the pieces)
• Better visual results (avoidance of seams between the pieces)
• Easier to work with for the artists
Since the CryENGINE 3 offers such a wide array of breakable assets it is important
to know where artists want to use what kind of asset and what its purpose will be.
Knowing that, a developer can provide a matching type of asset that is suited for
exactly that task and situation. For that the engine also offers different classes of
entities that are suited for one or the other breakables dependent on their features.
• Jointed Breakable Object
A jointed breakable object is a pre-fractured object that is based on joints
connecting the individual sub-pieces. “As soon as a certain amount of force
(defined in the joints UDP33 Settings) is applied to the joint it will break
the connection between the pieces and spawn a particle effect defined in the
surface type of the proxy. A jointed breakable is a complex object that has a
big impact on performance regarding drawcalls, memory impact and physics
calculations. Whenever building one, be smart and use as few pieces you
can get away with. Besides just breaking parts off your model, you can also
make pieces disappear or spawn one or several new pieces when the joint gets
broken.”[11]
• Destroyable Objects
“Destroyable objects are structures that contain the original object and precreated pieces that appear when the original object is destroyed. Its setup is
similar to a jointed breakable but it does not use any bones. Instead it uses
the model in its unbroken state and the pieces in the broken state embedded
in one cgf. It can be used to completely destroy specific types of objects
in the environment. It shatters into the pre-created pieces by taking more
damage then the specified ”health“ property of the object. It is placed using
the DestroyableObject Entity in the engine.
A Destroyable Object can be in two states, an ”Alive“ or a ”Dead“ state. In
the ”Alive“ state, it acts exactly like a normal physical entity. It can be set up
33
User defined properties
14
to be a rigid body or a static physical entity. After taking more damage then
the specified ”health“, it will go into the Dead state. When going into the Dead
state, it can optionally generate a physical explosion and apply area damage
on the surrounding entities, spawn a particle effect (for example, an explosion),
and replace the original geometry of the entity with either destroyed geometry
and/or pre-broken pieces of the original geometry. If the object breaks due
to a hit (bullet), that hit impulse is applied to the pieces in addition to any
explosion (outward) impulse.”[11]
• Jointed Destructible Object
“Jointed Destructible Objects can be set up to break in smaller pieces when
being detached from the joint. For example a wooden sign falls off the signpost and breaks into several planks. The object properties must contain the
information about the pieces used. The pieces need to be linked to the object
that was formerly whole. The pieces must also be referenced in the Object
properties/UDP of this object.”[11]
• Deformable Objects
“Deformable objects are basically cloth objects skinned to a skeleton. Unlike
cloth, they are not constantly moving, but instead ”freeze“ in their deformed
position, so they can be used to create deformable metal or other bending
materials. To set up a deformable object, first make sure it is sufficiently
tessellated, so the deformation looks convincing. A deformable object consists
of two nodes: The render mesh, physics mesh, and the skeleton. The skeleton
is the actual deforming object, the rendermesh and physics mesh are following
its deformations in a similar fashion similarly to a skinned character mesh is
following bones.
The skeleton is not an actual bone setup in a DCC package, but simply a
normal geometry mesh. Its shape has to be similar to the rendermesh. The
way the mesh is following the deformation of the skeleton is controlled through
the position of the skeleton mesh vertices. If the skeleton vertices are outside
of the render mesh, they are considered attached to the object and will not be
deformed. If they are inside to the rendermesh, the mesh will be ”skinned“ to
them and follow their deformation. This can be used to control the degree of
bending (i.e. with a deformable box, pulling the skeleton vertices at the edge
15
of the box outside of the rendermesh will make this edge ”stiff“ or fixed, while
the rest of the mesh is following the deformation completely.”[11]
• Procedural Breaking
“Breakable glass is the most common used type of breakability and allows you
to create glass the player can destroy.Procedural 3D breaking created with a
boolean substract shape. This is why the asset which will be broken must
have its size and shape taken into account with the boolean shape so that (if
desired) it can break the asset in half. ”[11]
• Boolean Destructibles
“The underlying physics technology is versatile enough to break many things,
not only tree trunks. It is just a matter of setting up the assets. For the
examples below we will concentrate on tree trunks, though.
The Boolean Destructibles system allows you to cause dynamic physical mesh
damage (holes) to an otherwise solid object from gunshots or explosions. This
is done without the need to pre-model broken states for the object. It uses a
pre-modeled 3D shape that is subtracted (boolean operation) from the original
object in realtime in the exact location of bullet impacts.
Because the boolean operations happen in real time, the system dynamically
re-triangulates the original model (adding polygons) as necessary in order to
maintain the original solid shape with the additional holes or missing pieces.
The new interior faces that are added to the object take on the material properties and textures (including UVs) of the boolean (subtractive) shape.”[11]
When dealing with boolean destructibles there is a performance impact that
must not be forgotten. Accoring to Crytek: “The actual performance impact
of the boolean system depends on a combination of the geometric complexity
of the breakable object.”[11] The performance of the object depends on the
manner in which it was constructed. The following need to be considered:
– Geometric complexity of the boolean shape.
– The number of breakable objects used in the level.
– The number of successive booleans applied to the breakable object.
16
– The number of shooters firing at the breakable object simultaneously.
General performance guidelines[11]:
– Keep breakable object very low poly.
– Keep boolean object very low poly.
– Use breakable objects sparingly in levels, for interesting/strategic gameplay situations.
– Create and use Surface Type parameters to limit how often a boolean
occurs.
– Create and use Surface Type parameters to limit the maximum number
of booleans a single object can take.
– Performance can lag noticeably when multiple shooters are firing rapidly
at a single breakable object, causing multiple booleans simultaneously –
to avoid this lag, try not to place boolean breakable objects in an area
populated with a great amount of shooters.
• Pre-Baked Physics for Cinematic Destruction
“The pre-baked physics pipeline allows you to bake out a physics simulation in
a 3D asset creation package to keyframe data, and load it into CryENGINE.
Once the pre-baked physics is in the engine, the pieces can be detached from
the animation become physicalized.”[11]
17
3. Modern Physics Engines and their Destruction
Engines
With computers becoming more powerful and gamers demanding increasing levels of
realism in computer games, physics engines have become more popular. As a result,
these middlewares now need to take on far more complicated tasks than ever before.
While early physics engines did not deal with much more than simple collisions,
modern engines such as PhysX, Havok and Bullet need to deal with tasks such as:
• Rigid Body Mechanics and Simulation
• Soft Body Dynamics
• Continuous Collision Detection
• Cloth Simulation
• Fluid Simulation
• Dynamic Destruction and Stress-Based Simulation
The following sections will give a brief overview of the most popular physics engines
(see section 7) and how they deal with the topic of this thesis: Dynamic Destruction
in real-time.
3.1. PhysX
PhysX is a state of the art physics engine middleware for computer games currently
being developed by NVIDIA. The engine enables computer games to use real-time
physics calculations and has been implemented at this time in more than 300 computer games and is in use by more than 10,000 developers according to NVIDIA
[12]. One great benefit of using PhysX is that the engine has been hardware accelerated from the start and is heavily parallelized. Having a middleware like PhysX for
gaming is important because it defines how objects interact with the environment
and how they move. The goal is to create a result that is believable, though not
perfectly realistic.
The question as to why PhysX is one of the better choices for real-time computer
games can be answered by going back a few years. Before PhysX became NVIDIA’s
property it was developed by a company named Ageia. NVIDIA acquired the whole
company including PhysX in 2008. Back then PhysX was accelerated by a special
18
hardware card, that became integrated into NVIDIA’s GPUs later. Today PhysX
is accelerated by either that PhysX PPU34 or any GPU that features CUDA35 .
Since the PhysX engine was specifically designed for multithreaded environments,
it functions best in massively parallel environments, and a GPU, being highly multithreaded, was the ideal choice to run the calculations. “GPUs are the natural
place to compute physics calculations because, like graphics, physics processing is
driven by thousands of parallel computations. Today (2012), NVIDIA’s GPUs,
have as many as 480 cores, so they are well-suited to take advantage of PhysX
software.”[12].
What is PhysX Really?
The following list should give a brief overview of the most important features that
come with PhysX according to the PhysX Guide (see [13]).
• Rigid Bodies: Solid volumetric objects with position and rotation in space
that ignores any form of deformation.
• Joints: An object, which connects two or more separate objects and acts upon
them within the constraints of defined variables.
• Forcefields: Block certain areas or simulate attractors or pushers.
• Fluid and Particles: Uses physically enhanced particles or have particles behave as a fluid.
• Cloth and Soft-Body Simulation: Based on deformable objects with many
features especially created for character cloth. This includes: Tearing of cloth,
two-way interaction and world collision.
APEX
APEX is a framework built on top of the PhysX SDK and significantly extends its
features. APEX’s first public version 1.0 was released on March 24th, 2011 and
included the Clothing and Destruction modules. “By providing [a] set of authoring
tools, special pipelines and optimizations, APEX allows developers to create complex
physically simulated systems (e. g. fully simulated clothing), without necessity to
relay on low-level API or write all underlaying toolset by themselves. ” [14].
34
35
Physics Processing Unit
Compute Unified Device Architecture
19
APEX comes with a whole set of tools, such as plugins for 3d-Studio Max and Maya,
as well as the so called “PhysX Lab” which is a tool that will later be discussed (see
subsection 5.1). The second part is the SDK itself that enables “game developers
to create extended physical effects to their games, such as destruction” according to
Johnny Costello from NVIDIA who demonstrated APEX for the Unreal Engine 3
at the MIGS2011. However, APEX is not only about destruction, as it is split into
several modules:
• APEX Destruction: Uses PhysX Rigid Bodies and PhysX Particles and is
being used to create and simulate a large amount of breakable dynamic game
assets.
• APEX Particles: Provides developers with advanced particles that can be used
for debris, smoke or fluids in combination with dynamic destruction since they
are fully physically simulated.
• APEX Turbulence: Bridges the interaction of rigid bodies and forces with
particles. More information can be found in subsection 4.9.
• APEX Clothing: This bundle is being used for cloth simulation and is heavily
based on constraints and a so called cloth solver.
• APEX Force Field: Allows developers to create customizable forces that affect
particles, rigid bodies and other objects in their proximity. This can be used
for explosions, wind or shockwaves when dealing with dynamic destruction.
APEX Destruction
APEX Destruction is meant for fully and partially destructible environments. With
the PhysX Lab tool a functional preview editor exists that helps developers test out
their assets in a sandbox (playground mode). In its current version, it features three
different approaches on pre-fracturing breakable assets in order to prepare them for
dynamic destruction: slicing, cut-out and Voronoi based fracturing (see section 5).
20
Figure 10: APEX Destruction runtime [15].
It comes with many useful features such as [15]:
• Impact Damage Calculation.
• Stress Solver.
• Fracture Event Callbacks.
• Per-actor Materials.
• Chunk creation can be amortized over many frames.
• Multiple-collision hulls per chunk.
• Debug Visualization.
In an interview at PhysXInfo.com [16] NVIDIA developer Rev Lebaredian answered
the question: “What other features are planned for future versions of APEX Destruction?”
Rev Lebaredian: There are a great amount of things we want to do
with Destruction, real-time fracturing instead of pre-fracturing, all kinds
of stuff. There are a great amount of things in the plan and we have
ideas on how to implement a great amount of them, but what ends up
driving features is the content. We work with game developers, see what
it is they want, and we will change the priority based on demand.
21
3.2. Havok
Havok, just like PhysX, is a full-fledged state of the art physics engine that has
been used in “more than 400 titles” and “has become the gold standard within the
games industry” according to Havok[17]. What is certain is that the engine features everything a modern physics engine should have, ranging from basic collision
detection of rigid bodies to constraints and fluid dynamics, soft bodies, ragdolls,
vehicle physics and much more. It also features a set of tools for artists to prepare
models for any physics related task. The main difference from PhysX is that Havok
is, with very few exceptions, not a free library and licensing can be very expensive
especially for smaller developers. The Havok team is generally not up front about
these costs. With independent games becoming more popular and big engines offering their SDKs for free, Havok released a statement regarding piloting a program to
help independent game developers. However, it was never clearly stated how exactly
that would work and there were speculations about a possible fee if the game became successful. For this reason Havok was usually popular with the big studios and
AAA-titles. There is very little known about the exact details of Havok’s products
and bundles.
Havok features multiple bundles:
• Havok Physics: “Havok Physics offers the fastest, most robust collision detection and physical simulation technology available, which is why it has become the gold standard within the games industry and has been used by
leading game developers in over 300 launched titles and many more in development.”[18]
• Havok Animation: “Havok Animation Runtime is a fast and flexible animation
SDK and toolset that provides optimized playback and real-time blending on
leading game platforms. Comprehensive compression of animation data, pose
retargeting, inverse kinematics, and out-of-the-box integration with Havok
Physics enable a new range of game-play possibilities.”[18]
• Havok Animation Studio: “Havok Animation Studio (formally known as Havok Behavior) is a system for developing event-driven character behaviors in a
game. In addition to the standalone Havok Animation SDK and toolset, Havok Animation Studio is comprised of an intuitive composition tool for artists
and designers, and a run-time SDK for game programmers. Together, the
composition tool and SDK provide “what you see is what you get” results,
22
accelerating development of cutting edge character performances for leading
game titles.”[18]
• Havok Cloth: “Havok Cloth is a platform-optimized runtime and toolset that
dramatically increases the believability of game characters and environments.
It allows character designers to go beyond simplistic, tight-fitting or handanimated clothing, and to add believable, physically-based motion to garments
like skirts, capes, shirts, trousers, and coats as well as other deformable items
like hair, bellies, tails, flags, banners, curtains, and foliage. Havok Cloth is
easily customizable and fits into today’s workflow without burdening artists,
animators or programmers.”[18]
• Havok Destruction: see section 3.2
• Havok AI: “Havok AI provides developers with an optimized cross-platform
SDK to perform navigation mesh generation, pathfinding and path following
for highly dynamic and destructible game environments.”[18]
• Havok Script: “Havok Script is a Lua compatible Virtual Machine designed for
console game development. Havok Script is significantly faster than standard
Lua and through a combination of internal optimizations and use of the Havok
Script profiler, customers typically achieve a 2x speed improvement. Havok
Script ships with Havok Script Studio, an integrated environment for Microsoft
Visual Studio® and on-target profiler.”[18]
• Havok Vision Engine: “The Havok Vision Game Engine provides a powerful tool suite and versatile multi-platform runtime technology ideally suited
for all types of games. Providing a extensible tool chain and well-designed,
modular C++ API, the technology includes a variety of features to help you
break through technical barriers, opening up a range of possibilities for game
development.”[18]
Havok Destruction
“Havok Destruction is the cross-platform tool for simulation of rigid body destruction. Destruction gives the game artist total control over the simulation, drastically
reducing the production time and cost of creating large numbers of believable destructible game objects. Havok Destruction can create a completely new gameplay
experience by giving additional believability to structural mechanics, graphical effects, and game level design.”[18]
23
Unfortunately Havok Destruction is not available for free and there is no public
insight available as to what technologies this destruction bundle is based upon or
to what extent it can be used. Available demo videos look impressive and one can
make conjectures that they use similar technologies as NVIDIA’s APEX Destruction,
however this is uncertain.
3.3. Bullet
Bullet, or Bullet Physics is an open source physics engine originally developed by
Erwin Coumans, who is still the leading developer. From 2010, Bullet was additionally supported by AMD, which could be speculated as the result of Erwin
Coumans working for AMD, and AMD buying ATI. ATI being the main competitor
of NVIDIA with NVIDIA PhysX, it could be speculated that AMD is trying to push
Bullet to become a competitive product to PhysX.
Bullets main features are [19]:
• Discrete and continuous collision detection (CCD).
• Swept collision queries36 .
• Ray casting with custom collision filtering37 .
• Generic convex support: capsule, cylinder, cone, sphere, box and non-convex
triangle meshes.
• Support for dynamic deformation of non-convex triangle meshes, by refitting
the acceleration structures.
• Rigid body dynamics38 including constraint solvers, generic constraints, ragdolls, hinge, ball-socket.
• Support for constraint limits and motors.
• Soft body support including cloth, rope and deformable.
• Bullet is integrated into Maya, Houdini, Cinema 4D, Lightwave, Blender and
Carrara. Plugins for 3ds Max are available.
• Serialization of physics data in the cross-platform binary .bullet file format.
36
Testing for collision along a path
filter for specific entities, or collision objects
38
rigid bodies with advanced behavior logic
37
24
While this is certainly an impressive list, Bullet far fewer AAA reference projects
in the game industry in comparison to NVIDIA PhysX and Havok. This may be
for several reasons. Bullet has been in development for almost 10 years, however
due to the open-source nature and that there was no professional support available.
AAA developers wanted to avoid the risk of encountering critical problems and not
having the necessary support to resolve the issue. On top that Bullet came with
very few samples that could properly be used in-game. When developing a game,
developers usually try to implement the most essential physics first and for a game.
For example, the character controller, which determines the basic collision detection
of their characters within the context of the world. Engines like PhysX or Havok
come with an already perfectly optimized and working character controller, that is
well documented, offers many parameters and works efficiently in almost all cases.
Bullet was lacking that feature and even when they added such a sample it performed
poorly in complex environments. Combined with the lack of professional support
plus slow fixes for bugs and even slower implementation of requested and important
features was the main reason AAA developers have avoided Bullet. In short, if
Bullet was chosen, then developers had to implement virtually all the controllers
themselves and due so without support. That being said, not all developers shy
away from Bullet. Grand Theft Auto IV and V use Bullet, and potentially future
Rockstar Games39 titles as well.
However, according to many videos on youtube as well as articles such as “Art of
Destruction (or Art of Blowing Crap Up)”[2] by Mike Seymour, Bullet is a very useful
middleware for non-real-time environments and projects, because it was actually
optimized for real-time and therefore delivers very fast results. Due to its open
source nature, it could be seamlessly integrated in various destruction pipelines.
The new upcoming Bullet 3.x looks very promising and if a developer or a studio
has enough time, skill and manpower Bullet is a great asset for dynamic destruction
in real-time environments especially since it has a “Modular extendible C++ design
with hot-swap of most components”[19], “Optimized back-ends for pthreads/Win32
Threads multi-threading and PS3 Cell SPU”[19] and “Preparation for OpenCL data
parallel optimizations for upcoming Bullet 3.x”[19]
39
Rockstar Games - a multinational video game developer
25
4. Base Technologies for Destruction Effects
In order to understand the underlying technologies, that dynamic destruction middlewares, frameworks and APIs like APEX Destruction are using, the most important technologies and concepts will be mentioned and explained in the following
sections. This will make the next chapter that will deal with the utilization of
APEX Destruction much more accessible. Each of the subsections will cover topics
that are key to explaining the difference between the technologies. A full technical
explanation has been withheld, as to not go beyond the scope of this thesis. Instead,
the sections will focus on key points that are relevant to understanding the structure
for a possible implementation and when dealing with industry samples.
4.1. CSG - Constructive Solid Geometry
When dealing with volume models understanding constructive solid geometry is one
of the most important aspects of generatively creating a volume model as well as
modeling complex shapes with any major modeling program. Many people know
Constructive Solid Geometry only as “the boolean tool” in reference to the boolean
tool that can be found in Autodesk’s40 3D-Studio Max41 . Before going into the
technical details, let us take a look at Figure 11 which will provide a hint as to how
it works.
In its original sense, CSG is a part of solid modeling. This means representing a
three dimensional body by a mathematical formula. This is especially useful for
architectural applications. As seen in Figure 11 it can be used for combining many
basic primitives into complex shapes and bodies by means of a series of boolean
operations applied in a specific order. There are three major operations that are
commonly used in CSG:
• Difference −: the second operand will be subtracted from the first operand.
This is the cut out operation and the most important one for dynamic destruction as this is the technique to leave craters and holes in existing geometry.
40
Autodesk is a world leader in 3D design software for entertainment, natural resources, manufacturing, engineering, construction, and civil infrastructure.
41
Autodesk 3ds Max is 3D modeling, animation, simulation, and rendering software for games,
film, and motion graphics artists
26
Figure 11: Constructive Solid Geometry: Binary tree representation of a shape (composition idea
taken from [20]).
• Union ∪: This means adding to the two operands together. In other words
merging the geometry to a new piece that contains both operands.
• Intersection ∩: the intersection operation can be used to only leave the part
of geometry that both operands share.
While representing a complex shape by a series of binary operations one has to keep
in mind that the order of operations is not commutative, however they can be represented by a binary tree like seen in Figure 11. The author of the book “Geometric
and solid modeling” Christoph M. Hoffmann says that “the streams of geometric
and solid modeling are converging, and that as the importance of this convergence
is anticipated and recognized, the need for the development of techniques to bridge
the gap between the two becomes critical” [21]. This is important because especially
nowadays this technique is not only applied to simple primitives but also to complex geometry. Finding proper differences and unions when dealing with polygons
is critical, especially when it comes to constructing models and models that may
change their polygonal makeup over time (level of detail, tesselation etc.). When
dealing with CSG operations on polygons several key factors are changing and must
be dealt with. Shapes can have many different resolutions when it comes to details.
Dealing with a real time environment, the amount of polygons used to represent a
shape is not unlimited nor unimportant and that leaves one with a more or less time
consuming task of finding proper intersection lines and adapting the geometry. The
27
more complex the geometry the more time it takes to calculate real time results of
the boolean operations.
Figure 12: Two spheres, each with a different amount of polygons being subtracted from a box.
Looking at dynamically cutting out a piece of geometry from an already existing
large polygonal mesh like a landscape is a task that should not be underestimated.
Finding the right intersections and replacing parts of the mesh is something that
might take more time to process than one can spend. Therefore only dealing with
the smallest possible part of the big geometry is key. There are several ways to
make sure one minimized the amount of effort that the engine has to spend on the
calculation of the operation. One technique is having an Octree42 or a BSP-Tree43
representation of the geometry, so that the operation can find the proper part of
the geometry that is about to be the left-side operand of the difference operation
in a justifiable time. An actual algorithm for computing the union, intersection or
difference of two complex polygons can be found in several papers and books [22] [23]
[24] . One of the more important algorithms was developed by Avraha Margalit and
Gary D. Knott of the University of Maryland who presented their way of handling
polygons in a paper released in 1989 (see [25]).
As stated earlier proper implementations of these algorithms into simple tools can
be found in any major 3D modeling program or CAD44 application.
42
a tree data structure with each note having eight children or representing a leave. Used in
computer graphics to hierarchically represent 3d-data sets and to use them for efficient culling.
43
BSP short for binary space partitioning is also a data structure used in computer graphics to
efficiently access 3d-data sets for efficient culling.
44
Computer-aided design
28
4.2. Voxels
Voxels45 represent data points on a three dimensional grid. The value itself can
contain many different kinds of data, let it be a single value like the transparency
or a triple like the RGB-color for that voxel. Voxels were commonly used in the
visualization of medical or scientific data but have been used in computer graphics
as well as in video games. Some famous examples for their usage in video games
and engines are:
• Minecraft: “A game about breaking and placing blocks. At first, people built
structures to protect against nocturnal monsters, but as the game grew players
worked together to create wonderful, imaginative things”(minecraft.net).
• Outcast: An action/adventure by Appeal, released in 1999.
• Crysis: For their level editor “Sandbox2” the Cryengine2 uses a voxel based
terrain editor that is capable of sculpting overhanging cliffs as well as caves or
holes.
• Block Warfare: Operations a voxel-based first person shooter by Ammonite
Design Studios Ltd.
• Unreal Engine 4: “Uses a technique that is known as SVOGI – Sparse Voxel
Octree Global Illumination, and was developed by Andrew Scheidecker at
Epic[...] UE4 completely eliminates pre-computed lighting. In its place, it
uses voxels stored in a tree structure. This tree is updated per frame and all
pixels use it to gather lighting information.”[26].
• Atomontage Engine: In early 2013 the youtube video “Atomontage Engine Voxelized Geometry” raised some attention as it was showing previously not
seen details of voxel based high-poly geometry (according to the description
138M polygons in real time). (http://www.atomontage.com).
Not only since Crysis with its Cryengine using voxels, as a combination with heightmaps
to generate their terrain, voxels are attractive when it comes to dynamic destruction
or real time deformations. When dealing with voxels there are two main issues that
one has to deal with.
1. The kind of a data structure required for the needs of the system in order to
efficiently perform selection, addition and deletion operations on the structure.
45
Voxel - volumentric pixel or sometimes volumetric picture element
29
Figure 13: Voxel representation of a teapot (generated by the Voxelizer from drububu.com).
2. How to visualize the structure in an efficient way, IE Marching Cubes46 to
generate geometry from the voxel data structure.
To perform dynamic destruction or deformation on procedural terrain in a justifiable
performance it is necessary to generate that terrain using the GPU.
“Procedural terrains have traditionally
been limited to height fields that are
generated by the CPU and rendered by
the GPU. However, the serial processing
nature of the CPU is not well suited to
generating extremely complex terrains,
which is a highly parallel task. Plus, the
simple height fields that the CPU can
process do not offer interesting terrain
features (such as caves or overhangs).
To generate procedural terrains with a Figure 14: Voxel-based terrain: Created entirely
on the GPU [28]
high level of complexity, at interactive
frame rates, we look to the GPU. By
utilizing several new DirectX 10 capabilities such as the geometry shader (GS),
stream output, and rendering to 3D textures, we can use the GPU to quickly generate large blocks of complex procedural terrain. Together, these blocks create a
46
“Marching Cubes is an algorithm for rendering isosurfaces in volumetric data. The basic notion
is that we can define a voxel(cube) by the pixel values at the eight corners of the cube. If
one or more pixels of a cube have values less than the user-specified isovalue, and one or more
have values greater than this value, we know the voxel must contribute some component of
the isosurface. By determining which edges of the cube are intersected by the isosurface, we
can create triangular patches which divide the cube between regions within the isosurface and
regions outside. By connecting the patches from all cubes on the isosurface boundary, we get
a surface representation.” [27]
30
large, detailed polygonal mesh that represents the terrain within the current view
frustum47 .” [28] [29] (see Figure 14).
Particularly with regard to the voxel technology used in crysis editor, one might
ask the question as to why this was not part of the gameplay experience? It would
certainly have been fun to blow a hole into the terrain to enrich the experience. The
answer is as simple as it is disappointing: Deformation technology always comes
at a price. While it might have made sense in some areas it could have become a
game breaker, because after all the player is supposed to walk a certain path and
the results could have been worse than the benefit. Just because you can bend or
deform the terrain under let’s say a house does not mean the physics can deal with
it. Therefore unrealistic results happen and a studio is always focused on delivering
the best overall experience possible. Even small glitches tend to break the illusion.
However there have been modifications and fan-based add-ons that demonstrated
the technology itself could have worked. In conclusion, using voxels as a base for
the terrain is a functional method of implementing dynamic destruction and terrain
deformation in real time.
4.3. Voronoi Diagrams
Voronoi diagrams are one of the most important
structures in modern computer graphics as well
as many scientific areas such as biology, chemistry, architecture and mathematics. It dates
back to a mention by René Descartes 1644 in his
book “Principia Philosopiae”, however a more
thorough analysis of the structure was done by
Georgy Voronoi and Lejeune Dirichlet. The objects they were analyzing were regularly ordered
points in Rd and the influence of p on a point
x of Rd being inversely proportional to the distance |px| (see next subsection). This decomposition was called a Dirichlet decomposition and
Voronoi diagram [30](Page 210). Historically it
was used by John Snow during the cholera outbreak 1854: “Snow considered the sources of
47
Figure 15: Voronoi Diagram in R2
the space, that the viewing perspective of the camera creates
31
drinking water, pumps distributed throughout the city, and drew a line labeled
”Boundary of equal distance between Broad Street Pump and other Pumps,“ which
essentially indicated the Broad Street Pump’s Voronoi cell.”[31]. As for computer
graphics, voronoi diagrams have often been used to create abstract modern art as
well as fractures on shapes in R3 . Due to its properties and the duality to the Delaunay triangulation (see subsubsection 4.3.3) it is extremely useful when dealing with
simulating destruction, as it offers a reliable way of easily generating fractures.
4.3.1. Voronoi Definition
Given a space, here R2 and within, a set seed points {p1 , ..., pn }. The space is then
separated into areas {A1 , ..., An } for each seed, so that each {A1 , ..., An } consists of
all the points in space that are closer to that seed than to any other. For easier imagination the following explanation will only feature the R2 . In subsubsection 4.3.5
R3 voronoi diagrams are discussed.
A more formal definition: For two seed points p and q in the plane of R2 a bisector
of p and q is defined so that it is perpendicular to the line pq. The bisector creates
two open half-spaces one being H(q, p) and the other one H(p, q). Let’s define
H(p, q) = {x ∈ R2 : |px| < |qx|}. Therefore we can now define a Voronoi Cell of
∩
a seed point p ∈ S as V C(p) = q∈S\{p} H(p, q). All the Voronoi cells combined
∪
are then p∈S V C(p) = V C(S). To the define the diagram as a whole one very
important aspect must be defined. The edges of the cells, which do not belong to
the areas of the cells define the diagram itself. This results in the voronoi diagram
being defined as V D(S) = R2 \ V C(S). V D(S) can also be seen as a mesh structure
containing Voronoi vertices and voronoi-edges.
32
Figure 16: The most simple Voronoi Diagram.
Two seed points q and p (red). The
line pq(green) and the perpendicular
bisector (blue).
Figure 17: A Voronoi Diagram with three seed
points with one Voronoi vertex where
blue Voronoi edges meet. The green
line represents the convex hull.
Figure 18: This Voronoi Diagram is a special
case of all the seed points being colinear.
Figure 19: A single Voronoi cell can have up
to n − 1 vertices and edges for n
spawned seed points.
4.3.2. Voronoi Diagram Properties
A few interesting properties of the voronoi diagram listed[32]:
• The maximum amount of voronoi-vertices in a VD is 2n − 5.
• The maximum amount of voronoi-edges in a VD is 2n − 6.
33
• Given a seed point p ∈ S and p is the closest seed to a seed point q ∈ S, then
the voronoi cells V C(p) and V C(q) are sharing an edge.
• The voronoi cell V C(p) is unbounded if and only if p is an extreme point of S.
This implies, that p is part of the convex hull of S as seen e. g. in Figure 17
where the green triangle represents the convex hull.
• One more property that is important is the so called circumcircle. Taking a
look at Figure 20 one can see the triangle △abc. Taking the perpendicular
bisector of each of the triangle’s edges one will find the intersection point q
named the circumcenter. This circumcenter is the center of a circle that intersects the points a, b, c and is therefore equi-distant from all three points. This
circle is called the circumcircle and has some properties of its own which are
important when dealing with the delaunay triangulation (see next subsection).
– One Circumcircle never includes another seed point excepting the three
that define it (see Figure 20).
– The center of the circumcircle - the circumcenter is a voronoi-vertex.
– The edges of the triangle are voronoi-edges.
Figure 20: Red: Voronoi seeds, Green: Circumcenter, Bold-Orange: Circumcircle of q and the
triangle △abc, Blue: Triangle △abc.
34
4.3.3. Delaunay Triangulation
One of the best features of a voronoi
diagram is its dual - the delaunay
triangulation.
“The Delaunay Triangulation is the geometric dual of
the Voronoi Diagram.
Alternately,
it can be defined as a triangulation
of the seed points with the property that for each triangle of the triangulation, the circumcircle of that
triangle is empty of all other seed
points. These closely related data structures have been found to be among
the most useful data structures of
and Voronoi
the field of Computational Geome- Figure 21: Delaunay Triangulation
Diagram in R2 . Red: Voronoi seed
try.”[33].
points, Black: Triangle edges, Blue:
Voronoi edges. Each Voronoi vertex
is the cirumcenter of a triangle.
The following properties apply to a delaunay triangulation:
• The interior of a triangle is never intersected by two edges of the triangulation
• Taking all the triangles of a delaunay triangulation: the circumcircle of each
triangle but be free of any other voronoi seed point inside of that circle (see
Figure 20).
• The delaunay triangulation is a superset of the Euclidean minimum spanning
tree48 of a point set.
The delaunay triangulation has many useful applications especially in computer
graphics. Important applications in context with dynamic destruction are:
• Given a set of points {p1 , ..., pn } the delaunay triangulation returns a set of
triangles that can represent e. g. a terrain or a model.
• Since the triangulation tries to maximize the angle when doing the triangulation[35] it will avoid narrow triangles, resulting in a good mesh.
48
If every edge in the graph carries a weight and the weight being the euclidean distance between
the vertices of that edge, then the minimum spanning tree for this graph is the EMST.[34]
35
Figure 22: [36]. Left: A false triangulation. Right: A correct triangulation meeting the Delaunay
condition.
“The general idea is to form a mesh where each triangle’s three points lie on
the edge of a circle that does not contain any other point. This means given
any two adjacent triangle’s (quadrilateral) the sum of the angles opposite the
dividing line are less than 180 degrees.Triangle mesh a, b, d and b, c, d do not
meet the Delaunay condition. But b, c, a and c, d, a do. This is because angle
bcd + dab > 180, but abc + cda < 180. This forces the mesh to have triangles
that tend to be as close to evenly spaced as possible.”[36]
• In 3D this technique can be used for tetrahedra generation (see subsection 4.4).
• visualize a differential equation [36].
• Fast mesh generation. This is not suited to create the best possible mesh,
but to create one fast, efficient and good enough to improve its quality after
adding more points to the seed set. [36]
Popular construction algorithms are divide and conquer as a representative of an incremental construction or the sweep algorithm, both can be achieved in O(n log n)
[37] (see the subsections below). When utilizing a delaunay triangulation one can
find efficient and reliable algorithms in the The Computational Geometry Algorithms Library (CGAL) at http://www.cgal.org/.
36
4.3.4. Voronoi Construction
There are many algorithms to create a voronoi diagram. Most of them have an
advantage for a specific issue. This section will give an overview over some algorithms
with the purpose of giving the reader a brief knowledge about the possibilities when
choosing one for a specific task.
• A Trivial Approach
The most trivial approach to constructing a
voronoi diagram is taking the a set S of seed
points and then for each point {p1 , ..., pn } ∈ S
construct its voronoi cell V C(pi ). Constructing
one cell at a time however brings a certain disadvantage due to the fact that this also means constructing n − 1 half-spaces H(p, q) : p, q ∈ S for
n seed points (see Figure 23). Doing this for all
the seeds seems like a waste of work. Doing this Figure 23: Construction of a Voronoi
cell by intersecting the halfwork for all the cells could results in constructspaces created by the perpening n ∗ (n − 1) half-spaces. Obviously that will
dicular bisectors ∩H(q, p) :
q, p ∈ S.
causes a runtime of O(n2 , log n). Fortunately
there are more efficient algorithms. This is very
important, because the goal of constructing a diagram or - in the case of destruction
simulation - a fracture.
• Incremental Construction
The incremental construction of a voronoi diagram is a way to construct a
new cell for a newly inserted voronoi seed point. This method is, next to the
trivial approach that was already discussed, the easiest and probably the most
understandable way of constructing the diagram.
37
Figure 24: Construction of a Voronoi cell by constructing it incrementally.
Let V D(S \ {q}) be the voronoi diagram for the set of seeds S and q be a
new Voronoi seed (see green arrow in Figure 24). Then V C(q) shall be the
voronoi-cell of q. To construct that cell one can follow these steps:
1. Identify the voronoi cell that includes the new seed q by comparing the
euclidean distance of all other seeds with q.
2. Start building the cell by creating the perpendicular bisectors H(pi , q)
(as seen in Figure 24 starting with top/center).
3. When all bisectors are created, create new Voronoi vertices at the intersections of the bisectors with the old voronoi-edges.
4. Delete the Voronoi vertices and directly connected edges inside of the
new voronoi-cell V C(q).
Since each step has a runtime of O(i) the total runtime is O(n2 ). While this
is not a very fast algorithm, one can optimize it significantly by supporting it
with a proper underlying data structure such as an quadtree or an octree in a
3-dimensional case.
• Divide and Conquer
A better approach that also provides a good candidate for parallelization is
the divide and conquer algorithm. This approach is partitioning the set of
seed points into two subsets based on their geometrical coordinates. It then
38
constructs the voronoi diagrams for each subset and finally merges the produced sub-diagrams. If the merging runs in linear time, then the construction
of the whole diagram V D(S) runs in O(n, log n) time [32].
• Construction via Convex Hull
As previously discussed the data-structure of a voronoi diagram can be represented by that of a delaunay triangulation due to its dual nature. One way
of building a voronoi diagram is via constructing a convex hull for a delaunay
triangulation and using the output as the data basis for the voronoi diagram.
Rolf Klein, describes this method in this book Algorithmische Geometrie (page
304ff).
Each 2D-point will be extended by a z-coordinate with z = x2 + y 2 . Now a
convex hull will be calculated around it, the convex hull being the surface.
The orientation of the triangles’ normals shall point outwards. Now take all
triangles with their orientation pointing below, so the ones with a negative
z-coordinate in their normal vectors and reproject them back into the original
xy-plane. The results will be the demanded 3d-delaunay triangle mesh. The
calculation time lies within O(n log n) [30]
• Sweep: Fortune’s algorithm
The Fortune’s algorithm49 is an algorithm that is based on a simple sweep line
and performs in O(n, log n). David Austin from the Grand Valley State University summorized the algorithm in his magnificent article “Voronoi Diagrams
and a Day at the Beach” as follows: “Fortune’s algorithm is a remarkably efficient way to compute the Voronoi diagram. Whichever algorithm we use, we
should expect that having more sites will require more work to find the Voronoi
diagram. We can, however, be more precise about this. Earlier, we considered
an algorithm for finding the Voronoi diagram by finding each Voronoi cell by
intersecting each half-plane containing the site. If n is the number of sites,
the number of steps required to implement this algorithm is proportional to
n2 log n . For a typical diagram, however, the number of steps required to
implement Fortune’s algorithm is proportional to n log n , which represents a
considerable improvement. ”[31]
49
Fortune’s algorithm by Steven Fortune developed in 1986 and published as “A sweepline algorithm for Voronoi diagrams”
39
4.3.5. Voronoi Diagrams and Delaunay Tesselestions in 3D
For computer graphics, not only in real-time, voronoi diagrams in R3 have been used to achieve fracturing. Take
a set of seed points {p1 , ..., pn } ∈ S in R3 then the perpendicular bisector, which was a line in R2 is now in R3
the perpendicular plane, that separates the line pq for
p, q ∈ S. The voronoi cell is now the convex intersection
of half-spaces made up by the perpendicular bisectors.
While voronoi-edges still exist, new to the 3D voronoi cell
are the voronoi-faces, created by the voronoi-edges (see
Figure 25). When dealing with 3D voronoi cells one must
think about if a cell that is face to face with another cell
should share the face or if a duplicate should be stored.
This is important when the purpose of the voronoi diagram is generation fractures, in the case of this thesis
for the purpose of destruction. If this is the case the
Figure 25: 3D Voronoi Diadecomposition of cells is important, because a complex
grams with 2 and
3 seed points. [38]
fractured model should be stored in a tree structure for
faster and more efficient accessibility. “In analogy to the
2D case, the Delaunay tesselation DT (S)in 3D e is defined as the geometric dual
of V (S). It contains a tetrahedron for each vertex, a triangle for each edge, and an
edge for each face of V (S). Equivalently, DT (S) may be defined using the empty
sphere property, by including a tetrahedron spanned by S as Delaunay if and only
if its circumsphere is empty of seed points in S. The circumcenters of these empty
spheres are just the vertices of V (S). DT (S) is a partition of the convex hull of
S into tetrahedra, provided S is in general position, which will be assumed in the
sequel. Note that the edges of DT (S) may form the complete graph on S” [39].
4.3.6. Using a Voronoi Diagram for Destruction
The last subsection dealt with 3D voronoi diagrams. This section will explain why
they are so important when it comes to processing a model for destruction. While
there are several techniques out there to destroy a polygonal mesh and make it
look like it has been destroyed, each technique has its advantage. Using a voronoi
diagram to fracture a model is before everything else a fast and efficient way that
delivers not necessarily accurate but believable results. Another big advantage is
40
that the resulting voronoi cells are all convex shaped polygons and therefore easier
to process by the physics engine. A more details explanation on basing a destruction
algorithm on a voronoi diagram can be found in the subsection ??
Listing 1: A simple algorithm for voronoi generation by Erwin Coumans as given in his GDC2012
presentation about destruction with the bullet physics engine. [40]
Distribute point set S within the 3D model
For each point A in S
{
Create cube around the point
For each point B in {S−A}
Create a plane between point A and B
Slice the cube by t h i s plane
Boolean Intersect cube with model
}
4.4. Tetrahedralization
Another useful case of using a delaunay triangulation is tetrahedra generation. Representing a
3D model mesh by a set of tetrahedras is useful
when dealing with variety of topics, such as soft
bodies50 (see Figure 26) or volume based simulations. This way it is possible to perform a
simulation, that delivers physically more satisfying results, this method is called Finite EleFigure 26: Bullet Physics: Utilizing
ment Method. “A 3D mesh is approximated ustetrahedra for soft-body simulation.
ing a collection of elements, usually tetrahedra.
The strains, stress and stiffness matrix is used to
compute the effect of forces and deformations.”[40]. The problem with FED is, that
until lately it was too much of a performance drain to be used in real-time, but in
2011: “some reseachers from Inria, Fances, showed the FED running on the GPU.
This way you can simulate tens of thousands of tetrahedra”[40]. A popular tool for
tetrahedralization is Netgen51 , a Mesh Generator by Joachim Schoberl.
50
51
soft-body: deformable objects in physics simulations
Netgen: http://www.hpfem.jku.at/netgen/
41
4.5. Digital Molecular Matter
Digital Molecular Matter is a technology that allows developers to simulate how
materials would behave in a real-world environment. For that Digital Molecular
Matter is based on real world properties. Basic examples would be behavior of
meta, wood, stone or plastic; each material will break like it would in the real
world. DMM is nowadays a middleware physics engine that can is available as
a proprietary license by developer Pixelux52 . The main difference to traditional
fracturing methods is that traditional methods usually rely of pre-fracturing and
setting up the material beforehand. This means that breaking a material with an
old-school technique will look very similar each time it will be broken, because even
if only partial fractions occur, the fractures are mostly predefines and predictable.
In contrast DMM technology will deliver different results each time a material gets
fractured.
There has been one major paper about Digital Molecular Matter which was written
by Prof. Dr. James O’Brien and Prof. Dr. Jessica Hodgins in 1999[41]. While DMM
has been used in many Movies as of late, such as: Avatar, Prometheur, Skyfall, Man
of Steel and After Earth and is available as a plugin for 3d Studio Max and Maya,
it was only used by two major AAA real-time game so far: Star Wars: The Force
Unleashed I + II. Utilizing DMM in a Game Environment has been published by Eric
G. Parker and Prof. Dr. James F. O’Brien in the paper “Real-Time Deformation
and Fracture in a Game Environment” [42], where they describe a system that is
able to do a “tetrahedral finite element method” in real-time.
The DMM-Engine by Pixelux runs on the PC, the PS3 and the XBox 360 and
includes: “the DMM toolchain for building DMM objects from art meshes, a sample engine integration with different pre-built DMM scenes, documentation and
libraries.” according to Pixelux.
4.6. Semi-Automated Convex Decomposition
Dealing with non-convex shapes has always been difficult for physics engines. Imagine one simple example in 3d-space: It is easier to calculate the collision with a
sphere or a box then calculating if an object hits a moving half-torus(half a hollow
donut shape) or passes through it. Another reason why convex shapes are so important is performance in real-time applications. With 3d models becoming more
52
http://www.pixelux.com
42
and more complex it is necessary to think about how the physics engine will handle
the collision of such complex meshes and if that is even necessary. The answer has
been in many cases to use convex hulls or even convex primitives such as spheres,
ellipsoids, capsules or boxes, however they often gave only poor results and thus
making an approximate convex decomposition very attractive. Also fracturing tools
had a great amount of issues dealing with concave shapes and artists often had to
manually decompose their models, fill holes, and remove overlapping edges.
In October 2011 Khaled Mammou posted a blog Entry titled: “HACD: Hierarchical
Approximate Convex Decomposition”, where he described his algorithm on approximate convex decomposition of a mesh. “There are some free implementations, one
is by John Ratcliff (ACD). This is a top down aproach: it recursively breaks down
a concave mesh into parts, until each part is convex.”[40] but Kaled Mammou’s
approach was far superior according to Ratcliff: “the open source implementation
released by Khaled Mamou is vastly superior to the brute force approach that mine
took. His is much more elegant and also solves a great amount of extremely hard
problems; such as objects with holes in them (something my algorithm could not deal
with). His also does not suffer with the problem mine had with excessive recursion
depths producing hollow interiors.”[43].
Figure 27: HACD vs. ACD comparision by John Ratcliff [43].
Khaled described his method as an approach that tried to cope with the problem that
an exact decomposition had, which is that an exact decomposition produced way
to many clusters to be practical for a real-time environment and to overcome those
problems he states that relaxing the constraint a little to give only an approximate
convex result did help a great amount. Therefore the user can profile the threshold
being used for the decomposition.
43
Khaled gives a brief overview in his blog where he states: “The HACD algorithm
exploits a bottom up approach in order to cluster the mesh triangles while minimizing the concavity of each patch. The algorithm proceeds as follows. First, the
dual graph of the mesh is computed. Then its vertices are iteratively clustered
by successively applying topological decimation operations, while minimizing a cost
function related to the concavity and the aspect ratio of the produced segmentation
clusters”[44]
A far more detailed description of his algorithm can be found in the paper “a simple
and efficient approach for 3d mesh approximate convex decomposition” that Khaled
released [45].
Figure 28: Hierachical Approximate Convex Decomposition by Khaled Mammou [40].
44
4.7. Fracture Maps
Fracture maps are a means of creating fractures
on materials by projection. A fracture map itself is not more than a simple black and white
image seen in Figure 29. White lines represent
the cut lines. However when fracture maps are
created or drawn, let’s say in photoshop, a few
basic principles should be considered.
The advantage to fracture maps is that the
artist has full control over the resulting fracture. One example where a fracture map is
extremely useful is shattered glass. A noise, Figure 29: Fracture Map: Representing fracture lines of shatvoronoi or cutout based approach just would not
tered glass.
look proper. Therefore a fracture map could create the perfect result. Another reason is that an artist can process a fracture pattern
of the real world to replicate a similar patter on his fracture map.
1. When drawing the lines you must make sure that each line connects to another
line, because otherwise one might end up with big holes. In other words making
sure that the diagram’s edges always connect to another edge or the edge of
the image.
2. Make sure that the lines are thin but still visible enough that the algorithm
can pick it up when it is being projected onto a geometry surface.
There are several ways to implement a fracture map, even though this is mostly
not needed, since efficient implementations already exist, e. g. the one in PhysX
Lab subsubsection 5.3.3 or plugins for the major modeling programs like 3ds Max
or Maya. One trivial but efficient approach would be the construction of all the
sub-polygons via line fitting and then use constructive solid geometry to cut out
the parts using boolean operations. However, this becomes increasingly difficult
and time consuming if a fracture map projection is supposed to be projected from
several axis, due to the fact that the emerging sub-mesh construction will become
more difficult. PhysX Lab has solved this issue tho and offers multi-axis cut-out
fracturing using fracture maps.
45
4.8. Particles Systems
1983 William T. Reeves53 stated: “A particle
system is a collection of many minute particles
that together represent a fuzzy object. Over a
period of time, particles are generated into a system, move and change from within the system,
and die from the system”
Even though particle systems are not part of any Figure 30: Unreal Engine 4: Turbulence particles [26].
geometrical modification to entities like the terrain, buildings, vehicles or any other kind of entity in the environment, they are a key aspect of creating a believable effect. Particle
systems are a technique to control the movement and behavior of a large amount of
sprites54 . While the sprites are usually very small, particle systems can have sprites
of any size or orientation and are not only limited to camera oriented 2D sprites,
but could consist of 3D shapes as well. They are commonly used to simulate:
• Dust clouds floating on the ground or through streets.
• Puffy clouds in the sky.
• Smoke and debris caused by explosions. This could be a volumetric smoke and
3D debris particles.
• Simulate fluids, like a waterfall, or breaking waves at the shore.
• Simulate fire or any form of fantasy like constructs.
• Create abstracts special effects.
• Falling leaves or tumble weeds
• Chemical reactions
• Create high quality explosion effects.
53
Willian T. Reeves created the first CG paper about particle systems for “Star Trek II: The wrath
of Kahn” where he described the Genesis sequence
54
an image that is displayed on the screen, like the mouse cursor e. g.
46
Like stated before the shape or the particle can range
from snow flakes to spikes are beams to 3D rock debris
particles. What they have in common is a controlling
entity, the particle system itself. The particle system
is what controls the swarm, spawns individual particles
and updates the particles properties according to the environment and the settings of the emitter. Properties of
a particle system must be split into two types: systemspecific and particle-specific properties. System-specific
properties are used to control the behavior of the system
as a whole that includes properties like: maximum particles, emit rate, orientation and origin bindings. Particlespecific properties are usually passed on to the individual
data structure that each particle holds. That usually includes: Shape, color, texture, position, velocity bindings,
scale or light affection (see Figure 31)
Particles have one major difference in comparison with
a rigid body simulation. Particles are point based, that
means, even though they extend in space, they are nothing put point geometrically and do not collide as a
shape but if, then only as points. Rigid bodies however are mostly 3D-polygons and shaped with volume,
vertices and edges. Nonetheless particles can have in- Figure 31: Particle system
architecture:
dividual mass points, forces and constraints that define
Basic sample.
their movement.
A particle’s movement is usually a simple equation with
a great number of optional parameters, but the most common form is the Euler
Integration that describes a particle’s movement:
47
Let ⃗a be the acceleration, ⃗v the velocity and p⃗ the position in world-space, additionally v⃗′ the velocity and p⃗′ the position of the previous frame. Lastly ∆t the time
delta to the last frame then we cal calculate the new position as follows [46]:
Figure 32: Euler integration to calculate the particle’s position[46].
• Step 1: Integrate acceleration to velocity: ⃗v = v⃗′ + ⃗a ∗ ∆t
• Step 2: Integrate velocity to position: p⃗ = p⃗′ + ⃗v ∗ ∆t
As mentioned before this is only the simplest form and not the only way to calculate a particle’s world position. However, it is computationally simple and easy
to understand and can be extended by any form of homogeneous transformations
like rotation or scaling. One must keep in mind tho that this form needs the storage of said properties in the particles, which might not be desired when going for
large-scale systems.
In general, the more particle are available for a single system, the more authentically
looking in can be. Only recently when utilizing the GPU for particles became
available the industry was able to take a huge leap forward with the amount of
particle that were now possible.
Since particle systems that are meant for real time computer graphics are to be
efficient enough to render a believable effect in justifiable time a developer must
not only think about what is technologically possible but also about the domain he
wants to use the systems in.
GPU-based particle systems have certain system requirements and the more complex a particle behavior should be the more difficult a GPU-implementation comes.
Implementing a particle system that is both fast enough to give a satisfying result
as well as being compatible with a wide range of hardware is challenging and should
only be pursued if existing APIs can not be used.
Most of the big game engine today have their own particle system on board, however
they are often only visual and particle systems rarely react on external forces. Swarm
behavior, turbulence or affection by rigid bodies is seldom seen.
48
One big particle system API should here be mentioned because it integrates into the
pipeline of creating believable destruction effects. This system is NVIDIA APEX
Particles and therefore a part of the NVIDIA APEX framework. It delivers a great
basis with PhysX being in the background helping out and nowadays with support
for Turbulence effects.
4.9. Turbulence Effects
Turbulence effects, are relatively new to real time graphics and have yet to become
a mainstream feature. So far only very few example have been shown and the only
technology that delivered believable and fast enough results come with NVIDIA
APEX Turbulence.
NVIDIA states: “APEX Turbulence enables high definition smoke and fog interaction, dust devils, sand and snow
storms as well as supernatural effects in
games to provide a much more dynamic
and interactive game experience. It can
be used to augment any existing particle techniques with realistic response to
Figure 33: APEX Particles: Demonstrating turmoving solid objects and turbulent fluid
bulence effects. [47]
motion. The simulation quality can be
easily scaled up or down based on target platform performance. The authoring tool
allows the artist to change parameters such as fluid viscosity, turbulence and particle
mass to create inspiring particle effects based on fluid dynamics.”[47]
It can be used to:
• create dust particles that get affected by rigid bodies
• particle effects that follow forces
• weather effects like blizzards and snow or rain and thunderstorms
• burning ashes or fire particles with swarm behavior
• smoke from tiers in racing simulations
• fantasy effects like fairies, swarms of fireflies or light elementals
• fluid simulation based on particles
49
Since APEX Turbulence is part of the APEX framework, it can only be used in
cooperation with the PhysX Physics Engine and the main APEX tool set and is
only able to run on the PC platform.
APEX runtime component does not come with any particle systems, the technology is only a tool to simulate already existing particle emitters by using a so called
Turbulence Grid and velocity fields to create forces that then can be applied to
a particle system. The Turbulence Grid is in APEX’ case a “grid-based Eulerian
fluid solver to simulate high-resolution smoke and particle effects, affected by turbulent forces.”[48]. A more detailed description of the technique that made it into
APEX Turbulence can be found in a presentation by Sarah Tariq from NVIDIA
held at the GDC 2010 [NVIDIA_dev_fluid_sim ] where they are talking about
their research results on their paper “Interactive Fluid-Particle Simulation using
Translating Eulerian Grids”[NVIDIA_fluid_sim_2 ]. Important for a real time
destruction pipeline is that the fluid solver is fast enough to perform unconditionally stable and efficient calculations to make it worth the effort. In their paper they
describe exactly that and even though APEX Turbulence is not open source, it is
very likely that this paper has been the basis for that technology.
50
4.10. Destruction Masking
Destruction masking (DM) is one of the major
techniques used for destruction in real time computer games and was featured in the Frostbite
engines. DM was a good system in terms of
visual quality as well as performance and render efficiency. According to Robert Kihl developer at DICE: “The main issue we wanted to
address was the time consuming workflow which
involved creating UV maps for each destructable
part. Although giving the artist full control of
the mask, we felt that speeding up the workflow,
to allow our artists to create more content, was
more important.”[51] This was also the main reason why several steps were taken to perfect this
technique for the Frostbite 2 engine.
As seen in Figure 34 the process consists of three
major steps:
• Identify the area of destruction and begin
by removing the matching geometry. This
can either be matching part-entities or one
could use the means of CSG(see subsection 4.1)
• Part two consists of adding prepared detail mashes on the edges of the removed
geometry (see picture three of Figure 34)
• Part three is about adding the actual destruction mask via projection, this is similar to the technique used to project decals
onto terrain.
To further optimize the workflow and to put less
effort on the artists, DICE came up with the usFigure 34: Constructive Solid Geomeage of Signed Volume Distance Fields for DM.
try: Binary tree representation of a shape [51].
51
SVDF are based on Volume Decals[52]. First off, spheres are created on the geometry with their center being about at the point of destruction and its radius
the destruction’s range. From that spheres the so called distance field is computed
and stored in a cubemap55 with each texel representing the shortest distance to any
sphere. DICE’s example featured a low resolution volume texture with approximately 2 meters per pixel. “The spheres are authored by the artist by first auto
generating a set of spheres so that each destructable part has one. The artist can
then go on and move/scale the spheres as well as add new ones. For example, to
cover a hole that is not close to square the artist might want to put several smaller
spheres to get a better fit”[51]. This results in a single cubemap per masked bit of
geometry.
Figure 35: Steps to create the Destruction Mask. [51]
The next step is to use the low resolution distance field to get a detailed destruction
mask. Pictures explained from left to right[51]:
• Here we can see a destroyed part of a building wall and the distance field
around it drawn with point sampling.
• Turning on trilinear filtering gives a smooth gradient, the surface of the destruction mask is at gradient value 0.5.
• By multiplying and adding an offset we can find the surface of the destruction
mask. Additionally we project a detail texture onto the geometry and use it to
offset the distance field. This breaks up the low frequency shape of the mask
and creates a more interesting look.
• Final result with texturing.
Like stated earlier, drawing the actual destruction mask can be done similar to a
deferred decal (see [52]). Deferred decals work in a similar way to lights.
1. Start drawing the geometry filling the g-buffer.
2. Draw a convex volume around the area of destruction.
55
3 dimensional texture
52
3. Drawing the volume itself and grab the depth from the z-buffer and translate
it to the local space position within the volume.
4. Now use the position to lookup the decal opacity in the cubemap.
5. Later on use alpha blending to combine the result with the g-buffer.
“One advantage of this method is that the convex volume we draw
covers only the decal area, and pixels outside of it are unaffected. So
if we can make a good fit for the convex volume for the decal area we
can save performance. Many optimization techniques has been developed for applying light sources in a deferred renderer (stenciling, tile
classification) and we could potentially use those here as well.”[51]
Figure 36: Frostbite 2: Destruction Masks on a house sample screenshot. [51]
53
5. Utilizing APEX Destruction
As previously discussed the only major players in terms of physics engine on the
market (see section 7) that offer a destruction pipeline that can be integrated into
a custom engine are Havok and NVIDIA PhysX. Both engines have previously been
mentioned and discussed. Havok has been ruled out as a possible candidate for
smaller and independent developers due to the lack of available documentation and
the fact that the destruction module is not part of the freely available SDK.
5.1. APEX PhysX Lab
APEX Destruction utilizes a standalone tool called PhysX Lab. This tool is being
used to prepare, create and test breakable assets for the destruction pipeline. The
artist can import meshes that have been modeled by another department and use
various techniques to split them into fragments. The results will then be used to
create so called APEX Destructible Assets and save them into APEX proprietary
format a so called APEX asset (*.apx and *.apb files) . “Besides exporting APEX file
formats, you can also save various aspects of your workspace. The entire workspace
can be saved into a project (.npproj) file, or you can just save the current mesh into
an .afm (“apex fractured mesh”) file. You can also save the current mesh’s material
library in an .aml (“apex material library”) file. This can be used as a material source
when choosing a fractured mesh’s interior material. Lastly, an important subset of
the project is the “fracture template.” These parameters control the splitting of
the mesh into chunks, and may be tuned to give various effects that emulate the
fracturing of wood, concrete, glass, etc. The user may save off the fracture template
into an .nppf (“preset fracture”) file”
Note: The following information is based on version 1.1.102(Beta).20130313.1337.
5.2. APEX Fileformat
APEX File format (*.apx and *.apb files) contain not only the model’s geometry data
and the hierarchy of the fractures and sub-pieces, it contains material properties like
texture information, tiling, outer and inner material as well as collision information
physical material parameters and support information for each of the sub-pieces. It
is available both as a binary version (*.apb) and an XML version (*.apx) and can
therefore not only be accesses by the APEX API but one can easily write a parser or
54
Figure 37: NVIDIA PhysX Lab: Showing the playground mode.
transform the output to one’s own needs in order to make it compatible with other
file formats or to convert it to a desired target format.
5.3. Approaches to Fracturing
Previously discussed base technologies and techniques should have made it clear
that there are more than just three methods of preparing assets for destruction,
however APEX Destruction features: Slicing, Cut-out and Voronoi Shattering in its
current version, however NVIDIA is planning to provide more variety in the future
(see [16]).
The following common options are available in all three fracturing modes:
• Calculate Mesh BSP: Manually invokes the calculation of the BSP-tree of the
main mesh. “The reason you might want to manually force the calculation of
the BSP is to ensure that it is reasonable. Using the BSP visualization options
55
Figure 38: PhysX Lab: Fracturing setting - common.
(see the Views menu, above), the ’inside’ regions should be a reasonable fullvolume representation of the original mesh. If it is not, then it is possible that
the BSP does not have a well-defined inside or outside. Or, the mesh may be
presenting some numerical difficulty for the BSP generation algorithm. If this
is the case, you can try selecting a different random seed and re-generating
the BSP.”[53]
• Mesh Processing:
– Island Generation: “If this is selected, then slices that create mesh islands will be turned into separate chunks. This prevents strange-looking
artifacts in which two separate-looking parts appear to be mysteriously
joined.”[53]
– Remove T-Junctions: “If this is selected, then the mesh triangles which
meet other triangle vertices along an edge will be split. This allows
deformation of the mesh without opening up gaps.”[53]
• Core Mesh
– Load Core Mesh...: “Import another mesh (.obj or .fbx) to be used as
an an indestructible “core” for slice-mode fracturing. When a core mesh
exists, it is first subtracted from the main mesh, and then slice-mode
fracturing is carried out on the remainder of the main mesh”[53]
– Export Core Mesh: If this is selected, the core mesh will be included in
the destructible asset as a child of the unfractured mesh, and have no
children (it will not fracture further). If this is not selected, the core
mesh will not be part of the destructible asset.
– View: When selected, causes the main mesh to be transparent, and renders the core mesh.
• Random Number Generator:
– Generate: “Generate a new seed for PhysXLab’s Random Number Generator (RNG).”[53].
56
– Seed: “The current seed for the RNG. This may be set manually. The
RNG is reset with this seed whenever fracture begins. This way the result
is deterministic.”[53].
5.3.1. Common Mistakes
Even though PhysX Lab seems intuitive at first there are some common mistakes
that should be mentioned here. Before processing with a fracturing method, it is
important to know if a provided mesh suits the needs of the fracturing. When
dealing with destructing artists often expect magic from a tool, but breaking down
what fracturing really does reveals some common flaws. Especially when an artist
tries to perform a fracturing to an already existing mesh and receives an unexpected
negative result. Correcting it at this point is often a slow and painful process.
Fracturing a 3-dimensional object is a process that needs a 3d-object to begin with.
Unfortunately with PhysX Lab’s current version a 3d-object that is about the receive
fracturing must meet one major condition: it should provide a closed manifold
mesh.
There are three types of meshes: Let M(V) be a mesh of the set of vertices V =
{p1 , ..., pi } and E the set of edges e(pi , pj ).
• Non Manifold Mesh: A mesh is non-manifold if there exists an edge e(pi , pj ) ∈
M (V ) for which there are more than two faces aligning.
• Open Manifold Mesh: An open manifold mesh exists if there is at least one
edge e(pi , pj ) ∈ M (V ) for which only one aligning face exists.
• Closed Manifold Mesh: Given a mesh, then it is only a closed manifold mesh
if each edge in the mesh has exactly two faces that align to the edge.
If an artist has to work with a given mesh, it is often wise to check the mesh for issues
that concern the closed manifold mesh property of the given mesh. High-end modeling tools such as 3d-studio max offer a modifier that can analyse a mesh for these
problems. A tutorial (http://www.hard-light.net/forums/index.php?topic=73970.0)
by “z64555” explains the usage of exactly this “STL Check Modifier”. Since this is
an extremely helpful way of dealing with a problem before it occurs after the mesh
has been processed in a long pre-fracturing process this technique will be briefly
described.
57
3ds Max STL Check Modifier
3ds Max STL Check Modifier was originally meant to check if a mesh is suited
for the so called stereolithography file format. Stereolithography is a term that
describes a technology that is e. g. used to produce a model by means of additive
manufacturing, also known as 3d printing. In order for that technique to work it
required a closed surface. The STL Check Modifier tests the model for exactly that
and therefore helps the artist to spot problems with the condition of a closed mesh,
before a model undergoes a process where failing those conditions would result in
unwanted behavior or failure of the processing algorithm. In other words using this
modifier one can make sure that there are no “illegal” 2d surfaces left in the model
that will later on cause issues with the fracturing.
The STL Check Modifier is able to check for the following conditions:
Figure 39: 2. Open edges, 3. Double faces, 4. Spikes, 5. Multiple edges
Fixing these conditions e. g. by capping open edges or extruding planes where
necessary has proven very useful in the preparation of a mesh before undergoing
pre-fracturing in order to avoid unwanted results.
58
5.3.2. Slicing
The first fracture method is called slicing. This
mode splits the mesh along predefined axis.The
algorithm is recursive and therefore is able to
slice each sub-piece again. The artist can control
a wide range of parameters to adapt the slicing
process to the results that are desired. The slice
method supports several depth-levels and each
level can have its own settings and therefore
produce different results.
Figure 40: PhysX Lab: Slice levels.
Figure 41: PhysX Lab: Slice
parameters.
The slicing method is especially suited for many materials. Due to its many parameters and possibilities it can produce fractures that splinter like wood or straight
cuts that look like you slices a mesh with a sword.
As seen on Figure 42 there are a great amount of ways to modify the parameter in
order to get very different results. To understand the results the parameters of the
Slicing method will be discussed here. The following information was acquired from
the PhysX Lab’s help documents (see [53]).
Figure 42: PhysX Lab: Slices.
59
• Use Target Proportions: “If this is not selected, the ’Chunk Proportion’ control
(see below) will be ignored, and the number of splits along each axis, for every
level of splitting, will always be given by the user selection (0 - 5) in the X, Y
and Z rows. If Use Target Proportions is selected, then the ’Chunk Proportion’
control gives the desired X:Y:Z size ratio for the fractured pieces. In this
case, the number of splits along each axis will be calculated automatically,
but always attempting to use the user’s input split counts as suggestions.
That is, the closest values to the user’s split count values will be used which
will lead to the target proportions. Since the number of splits is an integer
value, the target proportions will (usually) not be exactly met at any given
level of the hierarchy. But as the level gets deeper (chunks get smaller), the
chunks’ proportions will approach the target. Since the user’s input is used as
a suggestion, higher numbers will lead to more (and lower numbers to fewer)
splits used by the algorithm. To see the target proportions in action, it is best
to reduce the variation of the splitting surfaces (’Seams variation’). For an
initial experiment, try zero variation. You’ll also want to use zero Noise at
first. Increase the splitting depth (’Depth’ above) to 3 or 4. After fracturing,
the smallest pieces should have very nearly your target proportions.”[53].
• Use Displacement Maps: “If this is selected, the slice noise parameters (see
below) will be ignored during fracture. Instead, noise will be baked into an
optional, exportable displacement map, and per-vertex displacement flags will
be added during the export to aid in rendering (e. g. via tessellation)”.[53].
• Max Depth: “How many times to recursively slice, leading to the same number
of chunk hierarchical levels.”[53].
• Depth: “Display the slice settings at this depth. Every depth level can have
different slice settings. All of the Slice controls that follow (under ’Settings at
Depth’) depend on the Depth setting.”[53].
• Settings at Depth:
– Order: “The order in which to apply splitting along the X, Y and Z axes.
For example, ’XYZ’ means the X splits are done first, followed by the Y
splits and then Z splits. If there is no variation in the slicing surface, then
the result will be independent of the order. You may change the order
by dragging the X, Y and Z boxes into various orders.”[53].
– Through: “If this is selected, ’Order’ (above) is ignored. For each slice
along each axis, the same splitting surface is applied to all chunks (with-
60
out re-randomizing the surface after the first chunk is split). This has
the effect of splitting ’all the way through’ the mesh for each slice. In
this case, the result is statistically independent of the axis order, and
therefore there is only one ’Through’ option.”[53].
– X,Y,Z: “Slices along the x-, y-, and z-axis per hierarchical pass. These are
only suggestions if ’Use Target Proportions’ (see above) is selected.”[53].
– Seams Variation (Offset %): “A random offset for the slicing surfaces,
so they will not be evenly spaced. The number of slices along each axis
is given at each pass. If you imagine the mesh being divided up into
N equally spaced sections along an axis, then the Offset controls where
the slicing plane displacements may lie within those regions. Offset =
0 means the plane displacements will always be centered in the regions.
Offset = 100% means the plane displacements may lie anywhere within
those regions, at a randomly chosen location. This is controlled separately
for each axis”[53].
– Seams Variation (Degrees): “A random angle for the slicing surfaces, so
they will not all be axis-aligned. The value you choose is the maximum
angle (in degrees) that the slicing plane normals may deviate from axisalignment, for each slice direction.”[53].
– Noise Amplitude (Relative): “The amplitude of random variations applied to the splitting surfaces. The value is a percentage of the mesh size.
Be careful adding noise. It makes much more complex surfaces, which
tend to take much more memory to store. It also can take a long time to
calculate many recursive splits with high noise along all three axes.”[53].
– Noise Frequency (Relative): “The frequency of random variations applied
to the splitting surfaces. The value is a percentage of the reciprocal of
the grid spacing. (See Noise Field Grid Size, below.) Be careful adding
noise. It makes much more complex surfaces, which tend to take much
more memory to store. It also can take a long time to calculate many
recursive splits with high noise along all three axes.”[53].
– Noise Field Grid Size: “When generating a noisy surface, a height-field
grid is used. This is the minimum number of grid elements across the
mesh to be used, when slicing along each axis.”[53].
61
When an artist relies on noise for variation purposes, the artist must always keep in
mind that as the variation increases, so too does the processing and rendering times.
As the Noise field’s grid size increases, so do the calculation times for the fractures.
Using a too complex setup sometimes even freezes the PhysX Lab, therefore it is a
wise decision to plan the fracture in advance and to understand what each setting
does exactly, otherwise an artist might end up with a very long waiting time for a
simple change. Therefore understanding the properties and underlying technology
is key to keep iteration times short.
5.3.3. Cut-Out
The Cut-out method is based on a fracture map. This fracture map is then projected
onto the model’s surface to determine the cuts. The fracture map must be provided
as a bitmap. This fracture map has the cuts drawn on it (see subsection 4.7). The
algorithm calculated the intersection represented by the projected lines and fractures
the mesh along those lines. The projection includes all axis directions: +X, -X, +Y,
-Y, +Z and -Z.
This method is suited especially if the artists wants to create a chippable surface
structure as the artist can define the depth in which the fractures are applied. All
settings will be explained in detail now.
Figure 43: PhysX Lab: Cut-out parameters.
• Fracture Map: The chosen fracture map is displayed in a preview. Clicking on
the image will prompt the artist with a dialog to change or load the fracture
map.
• Periodic Boundary Conditions: if this is checked boundary conditions are set
in a way that periodic tiling becomes possible.
62
• Hide Fracture Plane: When switching to the Cut-out mode, a preview of
the projection plane for the fracture map will be rendered in the viewport.
However, sometimes the artists still needs to see the underlaying noise and
therefore wants to his the fracture map projection plane’s preview. Checking
this option will hide the preview.
• Show Mesh Texture: Checking this option let’s the artist see both the projection plane and the texture of the mesh.
• Cut-Out Setting:
– Order: This is a drag and drop option to define the order of applied
operations to each of the enabled fracturing axis.
– View: The view option let’s the artist switch around the axis that the
projection plane’s preview is based upon.
– Enable: The enable option defines which of the axis the fracture map will
be projected and applied to.
– Tiling Fracture: This specifies if the Fracture map gets projected as a
whole onto the projection plane or, if this option is checked gets tiled
across it. If this option is active the width and height modifiers act as
tiling factors.
– Instance Congruent Chunks: If the tiling fracture option is enabled, it is
very likely that congruent, similar or even equal chunks will be generated.
With this option enabled those chunks are identified and only a single
render mesh and collision mesh will be generated. This enables APEX
to render the chunks utilizing instanced rendering. Since APEX 1.2 even
UV offsets for instancing is supported.
– Fit to Object: This button will fit the projection plane with the bounding
box provided by the model’s mesh.
– Map Size: The width and height options will adjust the size of the projected map, the results can be previewed in the viewport. Note: if tiling
fracture is enabled, the width and height references to the tiling factors.
– Thinkness (%):This describes the depth in percent that will be cut away
from the mesh. This is based on the cut-out direction provided by the
axis settings that are enabled. Given no backface noise and a thinkness
setting at 100% will cut through the entire mesh.
63
– Snap Distance: “Line endpoints on the fracture map will be merged if
they are further than this distance apart (in pixels). If you notice cracks
between the cutouts in your fractured mesh, or other errors, adjusting
this parameter can sometimes fix the problem”[53].
– Offset: These modifiers can be used to offset the fracture map in U and
V direction.
– Invert U / Invert V: This allows the artist to invert the fracture map
either in U or V direction.
– Backface Noise: The Noise parameters in the Cut-out mode are similar
to those in the slice mode (see subsubsection 5.3.2).
– Interior Face Noise: The interior settings for face noise offers additional
behaviour which can either be to ’apply slice to cutout’ or to ’apply
voronoi to cutout’.
Either option will reference to the slice or voronoi fracture mode and their
respective settings must be applied by switching to either slice or voronoi
fracture mode, make the settings and switch back to the Cut-out mode.
Additionally is is mentioned that the depth setting in the slice mode will
result in additional depth on top of the cutout fractures.
– Trim Face Hulls: When checked, this is responsible for trimming the
backface and cutouts if: “(a) backface noise is non-zero or (b) the collision
hull is something other than the mesh convex hull. Trimming is done by
intersecting the face slice plane (without added noise) with the backface
and cutouts.”[53]
– Interior Texture Settings: Allows to perform flipping operations on the
interior material in all projection axis.
64
5.3.4. Voronoi
“The third pattern is called ’Voronoi’. By this manner a 3-D Voronoi partition will
be calculated first, and then the partition is applied to the mesh, thus divided into
several polyhedrons. What the user should provide is a number that specifies how
many parts will be resulted.”
The Voronoi Fracturing mode is the latest addition to the PhysX Lab and only
features on option: the amount of voronoi seed points (sites).
The voronoi fracturing mode is based on the calculation of a voronoi diagram in 3d
as discussed in subsubsection 4.3.5. And is well suited for any model that should
simulate the destruction of a concrete or stone based object. Even though the
result is not a physically realistic approach it is still a good compromise between
believable results and performance. The voronoi fractures are especially useful due
to their convex shape and perform very well with the physics engine even if they
occur in large amounts.
In order to make a statement about the pre-fracturing performance of PhysX Lab’s
voronoi fracturing algorithm the following simple tests have been performed.
5.3.5. Pre-Fracturing Speed Test
The specs used for this test are the following:
• PC-Specs: Intel Core i7 @3.9ghz, 24GB RAM, Geforce GTX 480, 1536MB
VRAM
• PhysX Lab Version: 1.1.102.1(Beta) .20130313.1337
• PhysX Version: 3.2
• Operating System: Windows 8 64-bit.
• GPU-Driver: 314.22
• Testmodel #1: Deespona Venus (43,357 triangle faces, 34,835
• Testmodel #2: Stanford Dragon (100,000 triangle faces, 50,000 vertices)
• Testmodel #3: Stanford Bunny (69,666 triangle faces, 31,410 vertices)
65
Figure 44: The test models Venus, Dragon and Bunny used for the speed tests.
5.3.6. The Slice Method
Even though the slice method has so many options that will change the output and
calculation speed drastically, what has been tested here is the default settings of
slicing the model with a depth of 1 and 2x2 slices, resulting in a maximum of 27
pieces.
Figure 45: Pre-Fracturing: Slicing - calculation speed, measured for a given percentage of the
original vertices of the test models.
66
5.3.7. The Voronoi Method
To test the Voronoi method for its speed in PhysX Lab, two tests have been performed, with the goal of demonstrating different factors affecting the calculation
speed.
1. Test with different amount of vertices/faces
2. Test with the same amount of vertices but a changing amount of voronoi cells.
Figure 46: Pre-Fracturing: Voronoi - Calculation Speed, measured for a given percentage of the
original vertices of the test models.
Figure 47: Pre-Fracturing: Voronoi - Calculation Speed, measured for given amount of Voronoi
cells.
67
5.3.8. The Results
The results show that a great amount of the calculation time is heavily based on the
model structure, topology and complexity. Still, with the exception of the Stanford
Bunny, calculation times seem to increase on a quadratic basis independent from
the chosen fracturing method. This will change as soon as more complex parameters
resulting in non-flat split surfaces will occur, such as noise settings to the interior
and edges of the fractures.
6. Prototype Analysis
To determine how well APEX Destruction works
and how scalable it is, a prototype application
has been developed in cooperation with Andreas
Jung’s thesis (see [1]).
This prototype is supposed to be a minimalistic example of an implementation of APEX Destruction. With this prototype the following systems have been tested for simulation times when
given increasing amounts of rigid body chunks
caused by APEX’s dynamic destruction. SimFigure 48: Screenshot of the prototype
ulations have been performed by collecting the
application showing a 5x5x5
arrangement of spheres.
PhysX simulation time per frame in milliseconds
and have been averaged per class of active shapes
in the scene.
• System #1: Core i7 930 @3.8ghz, 24GB RAM, NVIDIA Geforce GTX 480,
1536MB VRAM
• System #2: Core i7 3740 UM @2.7ghz, 16GB RAM, NVIDIA NVS 5200M,
1GB VRAM
• System #3: Core 2 Quad 6600 @2.4ghz, 8GB RAM, NVIDIA Geforce 8800GTX,
768MB VRAM
• System #4: Core i5 2500K @4.0ghz, 16GB RAM, NVIDIA Geforce GTX 670
OC, 2GB VRAM
68
• System #5: Core i7 3790K @4.5hz, 16GB RAM, NVIDIA Geforce GTX 680,
1536MB VRAM
• System #6: Core i7 3770 @3.4hz, 16GB RAM, ATI HD 6950, 1GB VRAM
Figure 49: The histogram showing the performance in milliseconds per test system for the given
amount of active shapes in the scene.
The simulation was done using spheres pre-fractured with the voronoi method, each
with 100 chunks and one depth level. They have been ordered in a 5x5x5 arrangement (see Figure 48). The graphs in Figure 49 and Figure 50 show that even though
tested on very different settings, it scales with a linear drain in performance. The
graph also shows that even though there have only been used up to 4,000 active rigid
bodies, the current system is hardly able to calculate that many pieces in real-time
without the help of GPU-acceleration e. g. using CUDA.
69
Figure 50: The histogram showing the performance in milliseconds per test system for the given
amount of active shapes in the scene. Zoomed in for less than 1000 active shapes.
7. Conclusion
Today, for developers planning to implement dynamic destruction, there are two
realistic choices, aside from implementing a custom physics engine and destruction pipeline: PhysX with APEX Destruction and Havok with Havok Destruction. As discussed, PhysX and
APEX are a superior universal option
due to cost and availability.
Another reason why APEX Destruction
Figure 51: PhysX vs. Havok: Market share of
might be a good choice are the following
released games.
statistics, based on the collected data
from the these sources, including more
than 600 games:
70
• PhysX titles: Collected from the semi-official source http://physxinfo.com that
NVIDIA references to.
• Havok’s titles: Collected from the official Havok website http://www.havok.com/customerprojects/games/other-titles
• Rating and Release Years: http://www.metacritic.com where available, individual rating and release years, taken from the developers website and rating
websites, such as http://www.gamestar.de, www.gamespot.com and www.ign.com/games.
During the their race for leading physics engine, PhysX not only caught up but
overtook Havok in terms of released titles as the following figure Figure 52 clearly
shows. This is also demonstrates what the games industry actually adopted in
terms of physics engines on a yearly basis. However this figure does not show any
properties such as quality, performance or support.
Figure 52: Released number of titles per physics engine, per year.
What can be roughly shown however is if there is a quality difference in the rating
of games using a specific engine. Using the weighted average metascore Figure 53
shows that even though PhysX has many more titles using its engine, it has a greater
number of titles rated at ’average’ and ’bad.’
When taking a look at Figure 54 the percentages of rated titles in comparison with
the amount of titles show that Havok seems to be used in more AAA-titles, which
strengthens the statement that Havok is not widely used among smaller teams and
independent projects with a smaller budgets
71
Figure 53: Weighted average metascore in numbers by number of titles per engine. Weights are
the following for given metascores: 0 <= bad < 50 < average < 75 < good < 90 <
outstanding <= 100.
Figure 54: Weighted average metascore in percent by number of titles per engine. Weights are
the following for given metascores: 0 <= bad < 50 < average < 75 < good < 90 <
outstanding <= 100.
A last look shall be taken at the platform distribution. For this only the big three
gaming platforms: Windows PC, PS3 and XBox 360 will be considered.
It is clearly visible that PhysX is mainly used on the PC. This might be due to the
fact that on the console market there have been virtually no independent games,
which could be due to the fact that released a title for a console is much more
complicated and requires a higher budget.
As a result PhysX seems to be the dominant engine in terms of released titles, while
Havok, even though it has fewer titles seems to be well distributed over the available
platforms.
In conclusion and due to the fact that the Independent Developer Program that
Havok wanted to offer, starting in 2010 apparently did not work out, PhysX seems
72
Figure 55: Number of released titles per platform per physics engine in total.
to be the right choice. While AAA-titles will most likely still use Havok, also due
to studio policies, many more projects such as the ones using the Unreal Engine or
Unity will be using PhysX and with PhysX most likely APEX.
8. Future Prospects
What will the future bring for dynamic destruction systems in computer games?
Given that the APEX Destruction is now supporting not only the PC, XBox 360
and PS3 but also the new PS4, XBox One and iOS as well as Android. So even
though it does not support Linux or Mac on the PC just yet, it is definitely a crossplatform tool and is increasingly interesting. Taking a look at the latest GDC2013
demo, NVIDIA showed that even dynamic fracturing will be possible and most likely
available within the next year or two. Key to that is an fast enough implementation
of the fracturing methods that have been discussed in this thesis. Also the fact that
the GPU-acceleration is based on CUDA which is a NVIDIA proprietary technology,
gives reason to believe that this will be further developed to most likely support
OpenCL in the future, the reason being, that e. g. the console like the XBox One
and the PS4 will feature a non-NVIDIA GPU.
The answer to the question what the future in terms of APEX Destruction will
bring, can be answered by referencing to the paper “Real Time Dynamic Fracture
with Volumetric Approximate Convex Decompositions” [54] by Matthias Müller,
Nuttapong Chentanez and Tae-Yong Kim, in which they describe the technique
behind the famous “Nvidia Real-Time Dynamic Fracture Tech Demo”[55] presented
at the GDC2013.
73
A. List of Figures
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
Red Faction screenshot: Missing proper physics simulation. . . . . . .
Red Faction screenshot: Inner material of a broken wall. . . . . . . .
Frostbite 2: Interior Destruction [6]. . . . . . . . . . . . . . . . . . .
Battlefield: Bad Company: Destruction masking [8]. . . . . . . . . .
Battlefield: Bad Company: Crater screenshot [9]. . . . . . . . . . . .
Battlefield: Bad Company: Crater mask (point-filtering)[9]. . . . . .
Battlefield: Bad Company 2: Structural model of a building by Den
Kirson [10]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Battlefield: Bad Company 2: Destruction [8]. . . . . . . . . . . . . .
Battlefield 3: Destruction[8]. . . . . . . . . . . . . . . . . . . . . . . .
APEX Destruction runtime [15]. . . . . . . . . . . . . . . . . . . . . .
Constructive Solid Geometry: Binary tree representation of a shape
(composition idea taken from [20]). . . . . . . . . . . . . . . . . . . .
Two spheres, each with a different amount of polygons being subtracted from a box. . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Voxel representation of a teapot (generated by the Voxelizer from
drububu.com). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Voxel-based terrain: Created entirely on the GPU [28] . . . . . . . .
Voronoi Diagram in R2 . . . . . . . . . . . . . . . . . . . . . . . . . .
The most simple Voronoi Diagram. Two seed points q and p (red).
The line pq(green) and the perpendicular bisector (blue). . . . . . .
A Voronoi Diagram with three seed points with one Voronoi vertex
where blue Voronoi edges meet. The green line represents the convex
hull. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
This Voronoi Diagram is a special case of all the seed points being
co-linear. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
A single Voronoi cell can have up to n − 1 vertices and edges for n
spawned seed points. . . . . . . . . . . . . . . . . . . . . . . . . . . .
Red: Voronoi seeds, Green: Circumcenter, Bold-Orange: Circumcircle of q and the triangle △abc, Blue: Triangle △abc. . . . . . . . . .
Delaunay Triangulation and Voronoi Diagram in R2 . Red: Voronoi
seed points, Black: Triangle edges, Blue: Voronoi edges. Each Voronoi
vertex is the cirumcenter of a triangle. . . . . . . . . . . . . . . . . .
[36]. Left: A false triangulation. Right: A correct triangulation
meeting the Delaunay condition. . . . . . . . . . . . . . . . . . . . .
74
3
4
6
7
8
8
9
9
10
21
27
28
30
30
31
33
33
33
33
34
35
36
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
Construction of a Voronoi cell by intersecting the half-spaces created
by the perpendicular bisectors ∩H(q, p) : q, p ∈ S. . . . . . . . . .
Construction of a Voronoi cell by constructing it incrementally. . .
3D Voronoi Diagrams with 2 and 3 seed points. [38] . . . . . . . .
Bullet Physics: Utilizing tetrahedra for soft-body simulation. . . .
HACD vs. ACD comparision by John Ratcliff [43]. . . . . . . . . .
Hierachical Approximate Convex Decomposition by Khaled Mammou [40]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fracture Map: Representing fracture lines of shattered glass. . . . .
Unreal Engine 4: Turbulence particles [26]. . . . . . . . . . . . . . .
Particle system architecture: Basic sample. . . . . . . . . . . . . . .
Euler integration to calculate the particle’s position[46]. . . . . . . .
APEX Particles: Demonstrating turbulence effects. [47] . . . . . . .
Constructive Solid Geometry: Binary tree representation of a shape
[51]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Steps to create the Destruction Mask. [51] . . . . . . . . . . . . . .
Frostbite 2: Destruction Masks on a house sample screenshot. [51] .
NVIDIA PhysX Lab: Showing the playground mode. . . . . . . . .
PhysX Lab: Fracturing setting - common. . . . . . . . . . . . . . .
2. Open edges, 3. Double faces, 4. Spikes, 5. Multiple edges . . . .
PhysX Lab: Slice levels. . . . . . . . . . . . . . . . . . . . . . . . .
PhysX Lab: Slice parameters. . . . . . . . . . . . . . . . . . . . . .
PhysX Lab: Slices. . . . . . . . . . . . . . . . . . . . . . . . . . . .
PhysX Lab: Cut-out parameters. . . . . . . . . . . . . . . . . . . .
The test models Venus, Dragon and Bunny used for the speed tests.
Pre-Fracturing: Slicing - calculation speed, measured for a given percentage of the original vertices of the test models. . . . . . . . . . .
Pre-Fracturing: Voronoi - Calculation Speed, measured for a given
percentage of the original vertices of the test models. . . . . . . . .
Pre-Fracturing: Voronoi - Calculation Speed, measured for given
amount of Voronoi cells. . . . . . . . . . . . . . . . . . . . . . . . .
Screenshot of the prototype application showing a 5x5x5 arrangement
of spheres. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
The histogram showing the performance in milliseconds per test system for the given amount of active shapes in the scene. . . . . . .
75
.
.
.
.
.
37
38
40
41
43
.
.
.
.
.
.
44
45
46
47
48
49
.
.
.
.
.
.
.
.
.
.
.
51
52
53
55
56
58
59
59
59
62
66
. 66
. 67
. 67
. 68
. 69
50.
51.
52.
53.
54.
55.
The histogram showing the performance in milliseconds per test system for the given amount of active shapes in the scene. Zoomed in
for less than 1000 active shapes. . . . . . . . . . . . . . . . . . . .
PhysX vs. Havok: Market share of released games. . . . . . . . . .
Released number of titles per physics engine, per year. . . . . . . .
Weighted average metascore in numbers by number of titles per engine. Weights are the following for given metascores: 0 <= bad <
50 < average < 75 < good < 90 < outstanding <= 100. . . . . . .
Weighted average metascore in percent by number of titles per engine.
Weights are the following for given metascores: 0 <= bad < 50 <
average < 75 < good < 90 < outstanding <= 100. . . . . . . . . .
Number of released titles per platform per physics engine in total.
. 70
. 70
. 71
. 72
. 72
. 73
B. Listings
1.
A simple algorithm for voronoi generation by Erwin Coumans as
given in his GDC2012 presentation about destruction with the bullet
physics engine. [40] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
C. References
[1] Andreas Jung. “Implementing dynamic destruction in real-time computer graphics with PhysX and APEX”. 2013.
[2] Mike Seymour. Art of Destruction (or Art of Blowing Crap Up). Dec. 13, 2011.
url: http://www.fxguide.com/featured/art-of-destruction-or-artof-blowing-crap-up (visited on 05/12/2013).
[3] Unknown Author. Geo-Mod - Red Faction Wiki. url: http://redfaction.
wikia.com/wiki/Geo-Mod (visited on 05/06/2013).
[4] CVG Staff for CVG UK. News - Red Faction destruction engine may live on.
url: http : / / http : / / www . computerandvideogames . com / 320589 / red faction- destruction- engine- may- live- on/?cid=OTC- RSS&attr=CVGGeneral-RSS (visited on 05/12/2013).
[5] Battlefield: Bad Company - Frostbite Engine Trailer - YouTube. url: http:
//www.youtube.com/watch?v=iey04xp2lUc (visited on 05/20/2013).
76
[6] Frostbite 2 Destruction. url: http://www.frostbite2.com/wp- content/
uploads/2012/09/frostbite2destruction.png (visited on 05/21/2013).
[7] Frostbite 2 - The next generation engine powering Battlefield 3 - Battlefield 3
(BF3). url: http://www.battlefield.com/battlefield3/1/frostbite2
(visited on 05/21/2013).
[8] Destruction - Battlefield Wiki - Battlefield 3, Bad Company 2, Weapons, Levels,
Maps, Characters and more! url: http://battlefield.wikia.com/wiki/
Destruction (visited on 05/20/2013).
[9] Johan Andersson. Terrain Rendering in Frostbite Using Procedural Shader
Splatting. url: http://developer.amd.com/wordpress/media/2013/02/
Chapter5-Andersson- Terrain_Rendering_in_Frostbite.pdf (visited on
05/20/2013).
[10] Hey, A Message Board - How to destroy a building? url: http://denkirson.
proboards.com/index.cgi?action=display&board=nonsense2&thread=
2757&page=1#43105 (visited on 05/21/2013).
[11] Crytek. Breakable Assets. url: http : / / freesdk . crydev . net / display /
SDKDOC3/Breakable+Assets (visited on 05/23/2013).
[12] NVIDIA. PhysX FAQ. url: http://www.nvidia.com/object/physx_faq.
html (visited on 05/27/2013).
[13] NVIDIA. NVIDIA PhysX SDK Documentation - User Guide. 2013.
[14] Zogrim. PhysX FAQ. url: http://physxinfo.com/wiki/Category:APEX
(visited on 05/27/2013).
[15] Zogrim. APEX Destruction. url: http : / / physxinfo . com / wiki / APEX _
Destruction (visited on 05/27/2013).
[16] Zogrim. Exclusive: NVIDIA talks present and future of PhysX Technology. url:
http://physxinfo.com/news/6419/exclusive-nvidia-talks-presentand-future-of-physx-technology/ (visited on 05/28/2013).
[17] Havok. Havok Physics. url: http : / / www . havok . com / products / physics
(visited on 05/28/2013).
[18] Havok. Havok Physics. url: http://www.havok.com/products (visited on
05/28/2013).
[19] Erwin Coumans. bullet - Bullet is a professional free 3D Game Multiphysics
Library. url: http://code.google.com/p/bullet/ (visited on 05/23/2013).
77
[20] Unknown. CSG Tree. url: http://commons.wikimedia.org/wiki/File:
Csg_tree.png (visited on 06/12/2013).
[21] Christoph M. Hoffmann. Geometric and solid modeling - an introduction. San
Francisco, Calif: Morgan Kaufmann, 1989. isbn: 978-1-558-60067-6.
[22] Aristides A G Requicha and H.B. Voelcker. “Boolean operations in solid modeling: Boundary evaluation and merging algorithms”. In: Proceedings of the IEEE
73.1 (1985), pp. 30–44. issn: 0018-9219. doi: 10.1109/PROC.1985.13108.
[23] R.B. Tilove. “Set Membership Classification: A Unified Approach to Geometric Intersection Problems”. In: Computers, IEEE Transactions on C-29.10
(1980), pp. 874–883. issn: 0018-9340. doi: 10.1109/TC.1980.1675470.
[24] D. Ayala et al. “Object representation by means of nonminimal division quadtrees
and octrees”. In: ACM Trans. Graph. 4.1 (Jan. 1985), pp. 41–59. issn: 07300301. doi: 10.1145/3973.3975. url: http://doi.acm.org/10.1145/3973.
3975.
[25] Gary D. Knott and Avraham Margalit. AN ALGORITHM FOR COMPUTING THE UNION,INTERSECTION OR DIFFERENCE OF TWO POLYGONS. 1989. url: http : / / gvu . gatech . edu / people / official / jarek /
graphics/papers/04PolygonBooleansMargalit.pdf (visited on 05/16/2013).
[26] Andrew Burnes. Epic Reveals Stunning Elemental Demo, and Tim Sweeney
On Unreal Engine 4. July 7, 2012. url: http://www.geforce.com/whatsnew/articles/stunning- videos- show- unreal- engine- 4s- next- gengtx-680-powered-real-time-graphics (visited on 05/22/2013).
[27] Matthew Ward. Overview of Marching Cubes Algorithm. url: http://www.
gamedev.net/page/resources/_/technical/math-and-physics/overviewof-marching-cubes-algorithm-r424 (visited on 05/22/2013).
[28] Ryan Geiss. GPU Gems 3 - Chapter 1. Generating Complex Procedural Terrains Using the GPU. url: http://http.developer.nvidia.com/GPUGems3/
gpugems3_ch01.html (visited on 05/22/2013).
[29] Nguyen Hubert. GPU Gems 3. Addison-Wesley Professional, 2007. isbn: 0321515269.
[30] Rolf Klein. Algorithmische Geometrie: Grundlagen, Methoden, Anwendungen
(eXamen.press) (German Edition). Springer, 2005. isbn: 3540209565.
[31] David Austin. Voronoi Diagrams and a Day at the Beach. url: http : / /
www . ams . org / samplings / feature - column / fcarc - voronoi (visited on
05/22/2013).
78
[32] Michael Horn and Julie Weber. Voronoi Diagrams. 2004. url: http://www.
cs . tufts . edu / comp / 163 / notes05 / voronoi _ handout . pdf (visited on
05/22/2013).
[33] Michael Horn and Julie Weber. Voronoi Diagram / Delaunay Triangulation.
1997. url: http : / / www . cs . cornell . edu / home / chew / Delaunay . html
(visited on 05/22/2013).
[34] Sanguthevar Rajasekaran. On the Euclidean Minimum Spanning Tree Problem. url: http://www.engr.uconn.edu/~rajasek/Jmsc3.pdf (visited on
05/22/2013).
[35] Thomas Prof. Dr. Ottmann. Algorithmische Geometrie - Delaunay Triangulation. 1999. url: http://algo.informatik.uni-freiburg.de/bibliothek/
books/ad-buch/k7/slides/15.pdf (visited on 05/22/2013).
[36] HoshiKata. Algorithmische Geometrie - Delaunay Triangulation. 1999. url:
http://www.codeproject.com/Articles/492435/Delaunay-TriangulationFor-Fast-Mesh-Generation (visited on 05/22/2013).
[37] Tomas Lehner. “Digitale Geländemodellierung mittels Delaunay-Triangulierung
und Abbauplanung in AutoCAD”. Diplomarbeit. Linz, Johannes Kepler Universität, 2002.
[38] F. van Houtte. Ooh, ooh, ooh! 3D Voronoi! url: http://www.wblut.com/
2009/04/28/ooh-ooh-ooh-3d-voronoi (visited on 05/22/2013).
[39] Rolf Klein and Franz Aurenhammer. Voronoi Diagrams. url: http://www.
pi6.fernuni-hagen.de/publ/tr198.pdf (visited on 05/22/2013).
[40] Erwin Coumans. GDC 2012 presentation about destruction. url: http : / /
bullet.googlecode.com/files/GDC12_ErwinCoumans_Destruction.pdf
(visited on 05/22/2013).
[41] James F. O’Brien and Jessica K. Hodgins. “Graphical Modeling and Animation of Brittle Fracture”. In: Proceedings of ACM SIGGRAPH 1999. ACM
Press/Addison-Wesley Publishing Co., Aug. 1999, pp. 137–146. doi: http :
/ / doi . acm . org / 10 . 1145 / 311535 . 311550. url: http : / / graphics . cs .
berkeley.edu/papers/Obrien-GMA-1999-08/.
[42] Eric G. Parker and James F. O’Brien. “Real-Time Deformation and Fracture in
a Game Environment”. In: Proceedings of the ACM SIGGRAPH/Eurographics
Symposium on Computer Animation. Aug. 2009, pp. 156–166. url: http :
//graphics.berkeley.edu/papers/Parker-RTD-2009-08/.
79
[43] John Ratcliff. HACD : Hierarchical Approximate Convex Decomposition by
Khaled Mamou. url: http://codesuppository.blogspot.de/2011/05/
hacd-hierarchical-approximate-convex.html (visited on 05/26/2013).
[44] Khaled Mamou. HACD : Hierarchical Approximate Convex Decomposition.
url: http://kmamou.blogspot.de/2011/10/hacd-hierarchical-approximateconvex.html (visited on 05/26/2013).
[45] Khaled Mamou and Ghorbel Faouzi. a simple and efficient approach for 3d
mesh approximate convex decomposition. 2009. url: http://khaledmammou.
com/AllPublications/icip2009.pdf (visited on 05/26/2013).
[46] Lutz Latta. Everything about Particle Effects. url: http://www.2ld.de/
gdc2007/EverythingAboutParticleEffectsSlides.pdf (visited on 05/22/2013).
[47] NVIDIA. APEX Turbulence. url: https://developer.nvidia.com/apexturbulence (visited on 05/22/2013).
[48] Zogrim: PhysXInfo.com founder. APEX Turbulence. url: http://physxinfo.
com/wiki/APEX_Turbulence (visited on 05/22/2013).
[49] Joe Cruz (Airtight Games) and Sarah Tariq(NVIDIA). APEX Turbulence.
url: http : / / developer . download . nvidia . com / presentations / 2010 /
gdc/Taking_Fluid_Simulation_Out_of_the_Box_Particle_Effects_in_
Dark_Void.pdf (visited on 05/22/2013).
[50] Jonathan M. Cohen, Sarah Tariq, and Simon Green. Interactive Fluid-Particle
Simulation using Translating Eulerian Grids. url: http : / / www . jcohen .
name/papers/Cohen_Interactive_2010.pdf (visited on 05/22/2013).
[51] Robert Kihl. Destruction Masking in Frostbite 2 using Volume Distance Fields.
Oct. 2010.
[52] Emil Persson. Volume Decals. url: http://www.humus.name/index.php?
page=3D&ID=83 (visited on 05/21/2013).
[53] NVIDIA. NVIDIA PhysXLab Documentation. 2013.
[54] Mathias Müller-Fischer, Nuttapong Chentanez, and Tae-Yong Kim. Real Time
Dynamic Fracture with Volumetric Approximate Convex Decompositions. url:
http://matthias-mueller-fischer.ch/publications/fractureSG2013.
pdf (visited on 06/10/2013).
[55] Mathias Müller-Fischer. Massive Destruction in Real-Time. url: http : / /
www.youtube.com/watch?v=ATU6IGCMpUA (visited on 06/10/2013).
80