Soft Body Simulation The addition of soft body dynamics to the Havok Physics Engine on the PlayStation 3

Version 1.01

Author Student number Date Company mentor School supervisor

Okke Schrijvers 270359 04-06-2008 R. de Feijter T. Harkema

Summary  This report describes the implementation of soft body dynamics using the Havok Physics Engine on the Playstation 3. Soft Body dynamics are a currently barely used form of physics simulation where objects are able to bend or stretch. Because up until now, there have been almost no games that implemented this feature, it is an excellent way for Playlogic to distinguish itself as a developer. To implement soft bodies, the FastLSM algorithm was chosen as it promises to provide fast and stable results. First a demo was created where the algorithm was applied in two dimensions. This provided Playlogic with early feedback to see if the soft bodies would be fun to play with. Furthermore it served as a way to see if the algorithm could deliver what it promised. After the 2D demo, the usability of the soft bodies needed to be proven in three dimensions. The soft bodies were implemented while working in a simple test environment. The development of the soft bodies progressed quickly and a 3D demo was soon created. After the 3D demo was created, time was spent on porting parts of the code to the SPUs, which are five additional processors on the Playstation 3, to improve performance. The soft bodies have the following features: • • • • • •

The soft bodies exist in the same physics environment as all other physics objects. Any form of soft body is supported. The soft bodies can be simulated in real time. The soft bodies provide two way interaction. The environment affects them and they affect the environment. The soft bodies make use of the SPUs to improve performance. The soft bodies have minimal dependencies on a particular framework (besides the SPU code) and thus can be ported with minimal effort to any other framework or platform.

The soft bodies are ready for use in a real game, after which it can be assessed if they really provide fun gameplay.

Soft Body Simulation

iii

Preface  Four years ago I started a bachelor’s study of Computer Science at Hanze University in the hope of landing a job in the games industry. This report is the result of my final internship, followed at Playlogic Game Factory, one of the largest game developers in the Netherlands. Over a period of five months, I implemented and optimised an algorithm of simulating soft body dynamics in a computer game. Although this process involved a great amount of mathematics, I purposefully decided to exclude this from the main report wherever possible. In my opinion this makes the report understandable to all who are interested, rather than only those who have studied mathematics. For those who are interested in the mathematical details, Appendix B provides the used mathematical concepts and equations. During the internship I received help from a few people that I would like to mention here. First of all I would like to thank Ronald de Feijter who was my company mentor and came up with the idea of implementing soft bodies to fit my interest in mathematics. His insight in mathematical problems was of great help to me. Furthermore his feedback on early drafts of this report was excellent. I’d also like to thank Kees van Kooten as he too helped with a lot of the mathematical problems, as well as with programming issues. For his help with programming on the SPUs, I’d like to thank Tijs Gobbens, who spend two whole days pair programming with me to get things to work. From the art team, I would like to thank Bart-Willem van Lith, as he was always there to help me create the graphic side of the demos and report. And last but not least, Tjerk Harkema, who helped me to look differently at how to structure and write a report.

Soft Body Simulation

v

Contents  Summary ..............................................................................................iii  Preface ................................................................................................. v  Notation .............................................................................................. ix  1 

Introduction........................................................................................ 1 

2 

Game development at Playlogic Game Factory ......................................... 3  2.1  Playlogic Company Description ......................................................... 3  2.2  The needs of Playlogic Game Factory ................................................ 5 

3 

Physics Simulation in Games ................................................................. 9  3.1  Physics Engines ............................................................................. 9  3.2  Soft Bodies vs. Rigid Bodies............................................................. 9  3.3  Soft body Implementations ........................................................... 10 

4 

Soft Body Physics Using FastLSM ......................................................... 13  4.1  Structure .................................................................................... 13  4.2  Fast Summations ......................................................................... 14  4.3  Pre-processing ............................................................................. 17  4.4  Shape Matching ........................................................................... 17  4.5  Interpolation ............................................................................... 17 

5 

Internship Assignment: Analysis .......................................................... 5.1  Goal ........................................................................................... 5.2  Tasks ......................................................................................... 5.3  Project Scope Limits ..................................................................... 5.4  Risks .......................................................................................... 5.5  Deliverables ................................................................................ 5.6  Project Management .....................................................................

6 

Internship Assignment: Realisation ...................................................... 29  6.1  2D Demo .................................................................................... 29  6.2  3D Demo .................................................................................... 31  6.3  Framework Integration ................................................................. 33  6.4  Testing ....................................................................................... 36 

7 

Conclusions and Recommendations ...................................................... 7.1  Soft Body Physics Usability ............................................................ 7.2  Innovation in Games .................................................................... 7.3  Recommendations ........................................................................

41  41  41  42 

8 

Reflection and Evaluation.................................................................... 8.1  2D Demo Breakdown .................................................................... 8.2  3D Demo Breakdown .................................................................... 8.3  Optimizing .................................................................................. 8.4  Personal Experience .....................................................................

43  43  44  46  47 

19  19  20  21  22  22  25 

Soft Body Simulation

vii

- Contents Appendix A: Planning ............................................................................ 49  Appendix B: FastLSM ............................................................................ 51  Appendix C: Intern Assignment .............................................................. 59  Appendix D: Internal Structure of the Playstation 3 ................................... 61  References .......................................................................................... 63  Glossary ............................................................................................. 65 

viii

Okke Schrijvers, Playlogic Game Factory, 2008

Notation  Symbol

∆

̂ ̂

Description Scalar,  0 …  1  , used to indicate how fast particles should go to their goal position. Interpolation weight of tangent vector with regard to the cell vertex with index . Interpolation weight of tangent vector with regard to the cell vertex with index . Interpolation weight of a model vertex with regard to the cell vertex with index . Difference in velocity between vertex / particle with index and the object / region it’s part of. Directional derivative. Derivative of a scalar function, which is a vector pointing in the direction of the greatest increase. Angular velocity. Partial derivative. Linear transformation matrix. Deformation gradient (as used in mechanics). Goal position of the particle / vertex with index . Time step of simulation. Index (used in various contexts). Inertia tensor. Base vector of the X axis in the three-dimensional Cartesian coordinate system: 1, 0, 0 . Base vector of the Y axis in the three-dimensional Cartesian coordinate system: 0, 1, 0 . Base vector of the Z axis in the three-dimensional Cartesian coordinate system: 0, 0, 1 . Scalar 0 … 1 used to dampen the particles by simulating internal friction. Angular momentum. The mass of particle . The mass of particle divided by the number of regions it’s part of. The transpose of matrix . Normal vector of a model vertex. Computational cost dependent on . Offset of the current position of vertex with index to the current center of mass of the entire object. Offset of the material position of vertex with index to the material center of mass of the entire object. Same as . Soft Body Simulation

ix

- Notation Symbol ̃

x

Description Matrix with the feature that ̃ . Rotation matrix. Symmetric part of a linear transformation matrix. Current time of simulation. Next time step in the simulation. Deformed tangent vector of a model vertex, derived from . Material tangent vector of a model vertex, perpendicular to . Deformed tangent vector of a model vertex, derived from . Material tangent vector of a model vertex, perpendicular to . Linear velocity of vertex / particle . Linear velocity of the center of mass. Region half-width parameter. Position. Material position. Position of the center of mass of the entire object in shape matching. Material position of the center of mass of the entire object in shape matching.

Okke Schrijvers, Playlogic Game Factory, 2008

1  

INTRODUCTION  The world of game development is running at a quick pace. Game developers everywhere are trying to distinguish themselves by providing new and exhilarating gameplay. One way of providing new gameplay is to add soft body simulation to games. This is a part of physics simulation where objects are able to bend or stretch when forces are applied. This report is the result of an internship assignment that was completed over a period of five months at Playlogic Game Factory.

Objective The objective of this report is to provide an overview of the functionality of soft bodies. Additionally, from this report it should be clear how the process evolved. The objectives of this report are: • • • • •

Explain the rationale behind the need for soft bodies Explain the functionality of soft bodies Describe the implementation of soft bodies Provide conclusions on the usability of soft bodies Reflect on the process

Outline The report can be divided in two parts. The first part provides a context in which to place to the internship. It contains the following chapters: Chapter 2: Game Development at Playlogic Game Factory. This chapter reveals the structure of Playlogic Entertainment, Inc. and its subsidiary Playlogic Game Factory. Furthermore it describes the needs of Playlogic Game Factory. Chapter 3: Physics Simulation in Games. This chapter gives insight in physics simulation in general. It also explains the difference between soft and rigid bodies and provides some soft body implementations. Chapter 4: Soft Body Physics Using FastLSM. This chapter provides an overview of the algorithm used to implement soft bodies on a conceptual level. This means no actual calculations are discussed but from this chapter it should be clear what the algorithm does. The second part of this report describes the internship assignment itself. Chapter 5: Internship Assignment: Analysis. The analysis details all the research done needed for the implementation. It describes goals, tasks and a planning among other things. Soft Body Simulation

1

- Introduction -

Chapter 6: Internship Assignment: Realisation. This chapter discusses the results of the implementation of soft bodies. It provides overviews of the two created demos and describes how to integrate soft bodies in a real game. Furthermore it provides conclusions on the test results. Chapter 7: Conclusions and Recommendations. This chapter reflects on whether the goals set in chapter 5 have been achieved and if the needs of Playlogic Game Factory described in chapter 2 have been fulfilled. Furthermore it provides recommendations for future work / research. Chapter 8: Reflection and Evaluation. The final chapter discusses the process of the internship. It also contains the personal experiences of the author of this report. Finally, there are four appendices; a planning, a detailed breakdown of FastLSM, the original internship assignment and the structure of the Playstation 3. For those with a mathematical background, the appendix on FastLSM proves an instructive addition to chapter 4. It is highly recommended to anyone interested in a more substantial overview of the algorithm. Since this report covers a specialized subject, both a glossary and a notation index have been added. The notation index can be found up front, after the contents. The glossary is in the back, after the references.

2

Okke Schrijvers, Playlogic Game Factory, 2008

2  

GAME DEVELOPMENT AT PLAYLOGIC GAME FACTORY  The organization, at which the internship takes place, is the Dutch game developer Playlogic Game Factory, which is part of Playlogic Entertainment, Inc. This chapter describes the organizational structure of Playlogic and uncovers its general needs.

2.1 

Playlogic Company Description  This paragraph describes the context in which Playlogic operates. The first section will start off with describing the overarching structure of Playlogic Entertainment, Inc. and the part that Playlogic Game Factory plays in it. In the second paragraph, the spotlight is put on Playlogic Game Factory itself, including its organizational structure.

Playlogic Entertainment, Inc. Playlogic Entertainment, Inc. is an independent video game publisher that publishes games for all major platforms. These include the consoles from Sony, Microsoft and Nintendo as well as the PC platform. It was founded in 2002 and consists of two departments. The first department is called Playlogic International. This is the part of the company that publishes games. The headquarters of Playlogic is located in Amsterdam and they have an office in New York, overseeing its operations in the United States. The games Playlogic International publishes are for the most part created by external studios, with Playlogic International financing and selling the games. These external studios include Hydravision from France, World Forge from Russia, Synetic from Germany and many others. Apart from the external studios, Playlogic International also publishes titles from an internal studio, called Playlogic Game Factory, which is the second department of Playlogic Entertainment. This department is located in Breda. Not all games developed by Playlogic Game Factory are published by Playlogic International. Playlogic Game Factory is also a first party developer for Sony Computer Entertainment Europe, which means that Sony finances games that it subsequently publishes. As mentioned before, Playlogic Game Factory is the department at which the internship took place. A general overview of the structure of Playlogic Entertainment, Inc. and its subsidiaries is given in figure 2.1.

Soft Body Simulation

3

- Game development at Playlogic Game Factory -

Playlogic Entertainment, Inc.

Playlogic International

Sony Computer Entertainment

Playlogic Game Factory

Legend Internal entity

Projects by Playlogic

External entity

External projects

External Studios

Figure 2.1 The structure of Playlogic Entertainment, Inc.

Playlogic Game Factory As stated before, Playlogic Game Factory is the in-house game developer of Playlogic Entertainment as well as a first-party developer for Sony Computer Entertainment. At the time of the internship, the company was divided in three development teams, each working on their own game. Each team consists of artists and programmers as well as a project manager and game designer. Artists are responsible for the visual aspects of a game. This can range from concept art, to (3D) models, to animation and even special effects. The artists are guided by an art director, who is responsible for the quality as well as coherency of the assets. Programmers are responsible for the interactivity of a game. This can range from the reaction of the avatar (playable character) to the player’s controls, to the reaction of the game environment to the avatar, to the structure of in-game menus. Programmers can also be responsible for special effects, as these are often created procedurally nowadays. The programmers are referred to as the development team and are lead by a lead programmer. The lead programmer is responsible for a coherent coding style, as well as the general structure of a game as a computer program. The project manager is responsible for the planning of a game. The planning is guarded by the means of scrum meetings that take place every day for each of the two teams (art / development) separately. Finally the game designer is responsible for the gameplay of a game. This ranges from the style of a game, to how the avatar should respond to input. He is basically responsible for the game being fun. Besides the teams that are responsible for the development of games, there are multiple support roles. Foremost there’s a managing director, 4

Okke Schrijvers, Playlogic Game Factory, 2008

- Game development at Playlogic Game Factory -

who is responsible for all the different teams. Furthermore, there is a human resource manager, an office assistant and a system administrator. Figure 2.2 shows the organization chart of Playlogic Game Factory, without the supporting roles.

Figure 2.2 Organization chart of Playlogic Game Factory

The internship assignment was done on one of the two teams working for Sony. As such, the internal structure changed a little. Mainly, there’s an added layer of leads, this one from Sony. In this situation, the leads are the art director, lead programmer, game designer and project manager. In practice, this has two consequences. Firstly the leads have to cooperate with the leads from Sony instead of being able to decide things themselves. And as a result, for the production team this means that not all questions can be answered directly by their lead. Except for those differences, the team functions the same as the other teams.

2.2 

The needs of Playlogic Game Factory  In this paragraph, the needs of Playlogic Game Factory are uncovered to demonstrate the rationale behind the internship assignment. It starts by defining the general needs of the company. After which the need for innovation and later on physics is explained.

General Needs Playlogic Game Factory is a game developer. For self-financed games, this means that its profits are directly dependent on how well games are selling. For games financed by a third party (in current situation this is Sony Computer Entertainment Europe), future collaboration is dependent on the quality of the work and to what extend Playlogic can do things the third party can’t do or hasn’t thought of. From these two situations three general goals can be derived: Soft Body Simulation

5

- Game development at Playlogic Game Factory -

1. The games have to sell well 2. The games have to be of high quality 3. The games should do something new These goals are also described in classified, internal documents. In the following section the focus turns to the third of these goals as the importance of innovation in games is highlighted.

Importance of Innovation in Games To see how innovation in games leads to higher profits, one has to look at why someone would want something new. Fortunately this is a well covered subject and can be credited to the human brain thriving on learning new patterns (see [Kos04]). What [Kos04] describes about the learning curve of a game, also applies to games in general. If there are no new patterns to learn, the player will become bored. Since this is quite the opposite of what games are intended to do (provide fun), this leads to poor quality and thus low sales. By creating new patterns that the player has to figure out, you provide fun, as stated in [Kos04].

Importance of Physics Physics simulation in games is the natural evolution of scripted events. Where in earlier games, objects would react to each other in a predefined manner (i.e. scripted), physics simulation provides different reactions when variables are changed. Even though the reaction is different most of the time, the reaction is still based on a set of rules and thus a pattern can be detected. However, this pattern is much more diverse than a predefined pattern and is therefore more interesting to the player. In the next chapter, more emphasis is placed on physics simulation in games and a better overview of its applications is given. Figures 2.3 and 2.4 display two different applications of physics in games.

6

Okke Schrijvers, Playlogic Game Factory, 2008

- Game development at Playlogic Game Factory -

Figure 2.3 An explosion in Halo 3 sends players and even a buggy flying (source: gamespot.com)

Figure 2.4 A car crash results in cars flying around in Burnout Paradise (source: gamespot.com)

Soft Body Simulation

7

3 PHYSICS SIMULATION IN GAMES  This chapter further delves into the applications of physics in games. It starts off with a short overview of two generic physics simulation solutions called physics engines. In the second paragraph it describes the difference between soft and rigid bodies, which is crucial to the internship. The last paragraph summarizes different soft body implementations in order to provide a starting point for the internship.

3.1 

Physics Engines  The fact that physics simulation has become so popular in games has lead to a trend where generic solutions are available for licensing. These so called physics engines provide a lot of functionality including collision detection and response, the ability to apply a force to an object, set constraints to objects or parts of objects and provide specialized vehicle simulation. Currently there are two major physics engines available; Intel’s Havok Physics and NVIDIA’s Ageia PhysX. Both engines are available on all current generation platforms.

3.2 

Soft Bodies vs. Rigid Bodies  Even within physics simulation, there are certain areas that are better covered than others. An area that is very well covered is that of rigid body simulation. Rigid bodies are bodies that are unable the change shape and therefore only have to respond to external forces. Internal forces would cause the object to deform or break and are thus omitted. Contrary to rigid bodies, soft bodies are able to change shape. Soft bodies come in two variants, deformable objects and flexible objects. In this context deformable objects are objects whose shape can change when a force is applied, after which it retains that deformed shape. A much used example of a deformable body is a barrel. Flexible bodies also change shape when a force is applied, but revert back to their original shape when the force is removed. With flexible objects you can think of a rubber toy. The difference between deformable and flexible bodies is one also observed in mechanics, where a deformable body is referred to as plastic and a flexible body as elastic. Figures 3.1 and 3.2 respectively show deformable objects and a flexible object.

Soft Body Simulation

9

- Physics Simulation in Games -

Figure 3.1 Multiple deformed barrels (source: internal demo)

Figure 3.2 A flexible rubber duck (source [Mue05])

The simulation of soft bodies is an area that is barely covered in physics engines and games and is therefore an ideal area in which to innovate. Havok Physics provides no support of them and Ageia PhysX only very limited.

3.3 

Soft body Implementations  Although commercially not widely available, there has been research into soft body dynamics. In this paragraph two techniques are highlighted, one being the most used in physics simulation, the other being fairly new, but quite promising. These are the mass-spring system and shape matching.

Mass-Spring System A mass spring system is a form of soft body where the model consists of points in space that each have a mass. These points are connected by 10

Okke Schrijvers, Playlogic Game Factory, 2008

- Physics Simulation in Games -

springs. This is where the system gets its name. However, the problem with mass-spring systems is the inherent instability. Figure 3.3 shows a possible configuration of a mass-spring system. Mass-spring systems are described in more detail in [Ebe03] chapter 4.1. The numerical instability is explained in [Mue05].

Figure 3.3 A mass-spring system with four particles connected by four springs.

Shape Matching Shape matching is a fairly new technique based on geometry rather than physics. In the case of a mass-spring system, the positions of particles are defined by the connected springs, but shape matching particles have no knowledge about adjacent particles. Basically put, they only carry their position and a goal position. The independence of other particles introduces stability, which makes it fully applicable in games. In fact, NVIDIA uses shape matching for soft bodies in their Ageia PhysX engine. [Mue05] describes in more detail why shape matching is stable and [Riv07] proposes a way of speeding up the process of shape matching. The latter technique is explained in further detail in the next chapter.

Soft Body Simulation

11

4

        SOFT BODY PHYSICS USING FASTLSM  Given the stability and speed of shape matching, it is ideal to use in realtime applications. The method proposed in [Riv07], Fast Lattice Shape Matching, or FastLSM, uses shape matching and introduces a way of reducing the calculations necessary to achieve a convincing result. Thus it makes sense to implement the algorithm discussed in this paper as opposed to the one in [Mue05]. In this chapter a global outline is provided as to how the FastLSM algorithm works. A more detailed insight in the algorithm is provided in Appendix B: FastLSM, including many of the calculations necessary as well as the rationale behind those calculations. Since the work done during the internship was in most cases an extension of this algorithm, it is highly recommended to read the appendix for anyone who is not already familiar with it. The original paper, [Riv07], is also a very valuable resource, although it lacks the rationale behind most calculations. We start off by defining the structure of the soft body in the first part of this paragraph. This is needed to understand the need for fast summations, which are dealt with in the second part. This is where the algorithm gains its speed. The third paragraph explains the pre-processing that is needed. The fourth paragraph describes the shape matching procedure and the final paragraph covers the interpolation of the original model.

4.1 

Structure  The whole thing starts off with a 3D model that will represent the soft body. This model can have any shape or size. The model is divided into small cubes that combined, occupy approximately the same space as the original model. This can be observed in figure 4.1. The left side shows a 3D model of a penguin. The right side shows how the model is approximated using a series of cubes. The collection of cubes is called a lattice and each cube a lattice vertex. The process of creating the lattice is called voxelation (from voxel, [Wik08b]). For each lattice vertex, a region is created using the half-width parameter . The region spans from to in all dimensions, with being the index of the lattice vertex. The regions are used in the calculations of the dynamics of the soft body. They determine their position and orientation based on the positions of the lattice vertices that are part of that region. After that, the lattice vertices determine their goal position based on the position and orientation of the regions they are a part of.

Soft Body Simulation

13

- Soft Body Physics Using FastLSM Because regions are created for all lattice vertices, they overlap quite extensively. This overlapping insures that all deformations are performed smoothly.

Figure 4.1 A penguin model (left) and the voxelated approximation (right) (source: [Riv07]).

The downside of the overlapping of regions is that it introduces a lot of overhead in the calculations. This overhead scales cubically with region width and can be described as , with 2 1 being the width of a region. An example of regions in two dimensions can be observed in figure 4.2. In this case . The lattice vertices are represented by circles. The colored regions are created from the colored lattice vertices. The regions created from the black lattice vertices are omitted in this figure. It is clear that the lattice vertices in the middle column are part of all three regions.

Figure 4.2 Overlapping regions cause lattice vertices to be part of more than one region.

4.2 

Fast Summations  The main bottleneck of calculating positions based on regions, is that all lattice vertices are processed once for each region they’re part of. This introduces a lot over unnecessary overhead. Fast summations provide a

14

Okke Schrijvers, Playlogic Game Factory, 2008

- Soft Body Physics Using FastLSM -

way to remove this overhead by dividing the calculations over multiple smaller parts. The concept is best understood by means of an example. Take for instance the calculation of the position of a region. A region would look at the positions of all the lattice vertices it contains, add these values and divide the result by the number of lattice vertices to get its own position. Now instead of adding all the lattice vertex positions at once, multiple subdivisions are created that contain preliminary calculations of the lattice vertices it contains. The creation of these subdivisions in two dimensions can be observed in figure 4.3. The figure on the top left shows nine lattice vertices and the region created from the middle lattice vertex. On the top right are the subdivisions shown in black. In that situation, no improvement is noticeable (still eight addition operations), since the regions don’t overlap. The bottom pair of figures shows what happens when two regions overlap. The middle two subdivisions are used twice, but only have to be calculated once! This leads to only twelve additions as opposed to sixteen.

Figure 4.3 The effects of dividing regions in subdivisions.

In the case of position calculation the process now starts with the lattice vertices dividing their own position by the number of regions they’re in (this prevents lattice vertices that are part of more regions than others from influencing the soft body more). The bars (subdivisions) add the different weighted positions and save that preliminary value. The regions add the values of the bars to finally get their own position. This value doesn’t have to be divided by the number of lattice vertices, since the cells already did this.

Soft Body Simulation

15

- Soft Body Physics Using FastLSM This process can also be performed the other way around. Values from a region can be divided by the number of lattice vertices it contains. Bars gather the data from all regions they’re part of and lattice vertices gather the data from all bars they’re part of. The process of calculating values from lattice vertex to region is called summing up the hierarchy and from region to lattice vertex is called summing down. The concept shown in figure 4.3 also applies to three dimensions. The extra dimension adds an extra layer of subdivisions. Where in two dimensions you have a hierarchy of: 1. Region 2. Bar 3. Lattice vertex In three dimensions you have the following hierarchy: 1. 2. 3. 4.

Region Plate Bar Lattice vertex

In three dimensions, the plate is the same as a region in two dimensions and a region in three dimensions is a collection of multiple plates. Figure 4.4 shows an example of lattice vertices, bars, plates and the region as a cube.

Figure 4.4 The 3D summation structure with a lattice vertex, bar, plate and region. 16

Okke Schrijvers, Playlogic Game Factory, 2008

- Soft Body Physics Using FastLSM -

4.3 

Pre­processing  The first step is creating regions for all lattice vertices based on the region half-width parameter . Each region is divided in multiple plates. In border cases it is possible for two plates to be identical. In that case, only one plate is kept to even further reduce calculations. From the remaining plates, bars are created. Identical bars are also removed. Regions, plates, bars and lattice vertices all have references to all relations they have up and down the hierarchy. For all regions, the center of mass is calculated by averaging the positions of all the contained lattice vertices. This is considered to be the material position of the region. Given the manner in which the soft body itself is created (i.e. axis aligned), the orientation can be described by a rotation matrix that is equal to the identity matrix. All lattice vertices also store their material position.

4.4 

Shape Matching  Each frame, the position of the center of mass of each region is recalculated by summing the position of lattice vertices up the hierarchy. The algorithm calculates the translation and rotation that best match these new positions. No other transformations are allowed, as the object wants to return to its original shape. Translation and rotation don’t change this shape, but other transformations do. The translation and rotation are summed down the hierarchy to all the lattice vertices. They use this translation and rotation to calculate a goal position, at which they are placed every frame.

4.5 

Interpolation  The previous four paragraphs described how the soft body is created and how the dynamics are calculated. This paragraph describes how the original model is updated based on the deformed soft body. First of a distinction will be made. From now on, when a lattice vertex is named in the context of interpolating the original model, it will be called a ‘cell’. This prevents confusion when talking about model vertices, lattice vertices and lattice vertex vertices. The 3D model itself consists of a number of vertices. These vertices form the outer shell of the model. Each of these vertices is contained by exactly one cell, with each cell containing zero or more model vertices. The position, orientation and shape of the cells is updated by the FastLSM algorithm. The model vertices are placed on the correct position within the cell by trilinear interpolation. By placing each model vertex individually, based on the deformed cell, the entire model is deformed. Soft Body Simulation

17

- Soft Body Physics Using FastLSM In figure 4.5 a 2D example is shown of how the interpolation works. The leftmost part demonstrates a red model vertex within a 2D cell. The middle part shows how the model vertex is interpolated when one of the cell vertices is transformed. The dotted lines run from opposing edges. The position where the dotted line meets the cell edge is at the same relative position as the material position (i.e. for the top edge, it is always at 20% from the top left vertex en 80% from the top right vertex). The right picture shows how the model vertex is rotated when the cell vertices are translated but remain at the same distance to each other. C

D

D

D

C M

M

M

A

A

B

A

B

Figure 4.5 The interpolation of a model vertex inside a cell

18

Okke Schrijvers, Playlogic Game Factory, 2008

B

C

5  

INTERNSHIP ASSIGNMENT: ANALYSIS  With the previous three chapters providing all the necessary background information, this chapter is devoted to defining what the internship assignment actually is. The original intern assignment can be found in Appendix C. The first paragraph defines the goal and requirements of the internship. The second paragraph lists the tasks that have to be completed in order for the goal to be achieved. The third paragraph provides the scope limits of the project. The fourth paragraph is an assessment of the risks. Deliverables are defined in the fifth paragraph and finally the tasks are prioritised using the MoSCoW method in the sixth paragraph.

5.1 

Goal  In order to formulate the goal of the internship first a couple of requirements have to be defined: 1. 2. 3. 4.

The The The The

type of soft bodies has to be flexible (elastic) soft bodies have to run on the Playstation 3 soft bodies have to use Havok soft bodies have to interact with Havoks rigid bodies

A brief elaboration of the requirements will provide some clarity. Given the nature of the game, flexible bodies are the most useful, so it makes sense to implement these as opposed to deformable bodies. Given that the project is done for Sony, the choice for Playstation 3 is one made by them. Sony has also made the choice for Havok. Ageia does support a limited form of soft bodies, but since these currently still lack the required speed, there’s not much to say for switching physics engines. In order for the soft bodies to be of real use, they have to exist in the same physics environment and be able to interact with Havok rigid bodies. With these requirements in place, the goal of the internship can be formulated as: “The addition of soft body dynamics to the Havok Physics Engine on the Playstation 3”.

Soft Body Simulation

19

- Internship Assignment: Analysis -

5.2 

Tasks  In order to achieve the goal of adding soft body functionality to the Havok Physics Engine, a number of tasks have to be performed. In this paragraph these tasks are identified and a brief summary is given.

Test Environment In order to observe the behaviour of soft bodies, a test environment is needed. This differs from a demo application in the sense that it doesn’t have to be as complete. A mere scene in which a soft body can collide with a wall will suffice.

Construct a Mesh Approximation The dynamics of the soft body are applied to a regular lattice. This lattice has to be constructed based on a model. The lattice itself consists of evenly placed voxels (volumetric pixels), called lattice vertices. Each of these cells should be a physics object in the form of a rigid body.

Render the Lattice Vertices In order to see how the physics model is deformed (or even constructed on creation), the lattice vertices should be visible in some way. By rendering the lattice vertices, the dynamics can be observed as they occur.

Implement Relation between Lattice Vertices Placing lattice vertices at the right position and displaying them is not enough. All lattice vertices are distributed in regions, which have to be constructed. The regions are aligned along the axes to create plates and bars. Since this plays a key part in the algorithm, this is a separate task.

Implement the Dynamics With all the correct relations in place, the dynamics can be implemented. The dynamics determine the behaviour of the soft body, so they are the core of the algorithm and thus much emphasis should be placed on this task.

Interpolate Vertices inside Lattice Vertices In order to deform the actual model, the model vertices have to be repositioned to reflect the deformed state. Since all vertices are contained within a lattice vertex, these can be interpolated within them.

Demo Application To prove the usability of the soft bodies, a more sophisticated demo application should be created. In here, the dynamics can be tested in a varied environment. In this demo, the visuals also have to be polished.

20

Okke Schrijvers, Playlogic Game Factory, 2008

- Internship Assignment: Analysis -

Implement the Dynamics on the SPUs Since the dynamics are most likely the bottleneck of the application, effort should be put into putting them on the SPUs. These are seven processors in the Playstation 3 that aren’t used unless you specifically write your program to use them.

Research the Advantages of Vertex Interpolation on the GPU The GPU can be used to transform model vertices by using a vertex shader. Research should go into combining a custom vertex shader that interpolates the vertices within the lattice vertex with the currently used vertex shaders, as this will most likely provide a big speed improvement.

Self-Collision Checking Since soft bodies can change their shape, it is possible for part of the body to go through another part. This is called self-collision and can be prevented by checking for it every frame.

5.3 

Project Scope Limits  There are some topics that fall outside the scope of this project. These include:

Rigid body physics Rigid body physics are done by the Havok Physics engine and therefore fall outside the scope of the project.

Permanently deformable bodies Permanently deformable bodies are similar to flexible bodies, with the exception that they stay in the deformed position. Should there be time, research can be performed into devising these permanently deformable bodies from the flexible bodies, but this is not part of the project.

Breakable objects Breaking objects requires a mesh to be divided in multiple other meshes and a dynamic algorithm to fill the mesh at the breaking point. This is not included in this project.

Mesh Tessellation Mesh tessellation is the act of creating additional polygons in a mesh in order to create a more realistic deformation. It is however assumed that the meshes have sufficient polygons to provide a realistic deformation, so mesh tessellation falls outside the scope.

Soft Body Simulation

21

- Internship Assignment: Analysis -

5.4 

Risks  This section describes the identified risks concerning the project. Each risk is elaborated briefly.

Dynamics can’t be Computed Fast Enough The main risk is that the actual dynamics can’t be done on a real-time system. The fact alone that these soft body dynamics are not yet implemented in Havok Physics and not implemented with the desired speed in Ageia PhysX is an indication that the software technology might not be sophisticated enough to be able to simulate soft body dynamics on a real-time system. However, research papers from Müller and Rivers indicate that it is possible, if implemented properly. Should speed really turn out to be an issue, more emphasis can be placed on calculating the dynamics on the SPUs and GPU.

Dynamics aren’t Stable Enough Even though shape matching is said to be unconditionally stable, the dynamics aren’t guaranteed to be stable when integrated with Havok Physics. The unconditional stability is dependant on a custom integration that differs from the one done by the physics engine. Since that part of the engine is closed source, a workaround has to be implemented that is not guaranteed to be stable.

Patent Breach As stated in the previous section (‘Dynamics can’t be computed fast enough’), there are techniques to create soft body dynamics. Some of these techniques have been patented, but it’s not clear what exactly has been patented. Therefore there is the risk that some of the implementation breaches patents of other parties.

Havok doesn’t Support Deformation Seen as Havok doesn’t support soft bodies, it hasn’t adopted the dynamic altering of physics bodies. This means, you can’t change the geometry of a Havok physics object after it has been created. Since altering of the shape of objects is the whole idea behind soft bodies, this means an extension of the Havok Physics Engine has to be written to support the altering of shapes. Alternatively, an optimised algorithm could be created to replace deformed bodies.

5.5 

Deliverables  To assess the usability of soft bodies, two milestone deliverables have been defined. Additionally the final documentation is considered a deliverable. Firstly, there’s a 2D demo program in which the dynamics are applied in two dimensions. Even though two dimensional soft bodies will

22

Okke Schrijvers, Playlogic Game Factory, 2008

- Internship Assignment: Analysis -

most likely never be used, creating a 2D demo does have its benefits. A 2D demo can be evaluated by a game designer to see if soft bodies can improve gameplay. Furthermore, by creating the demo, the algorithm itself can be proven to be applicable in real-time simulations. Additionally, it eases the learning curve since it is a new technique. Secondly there’s a 3D demo program in which the dynamics are applied in all three dimensions and the usability of the soft bodies is proven. This will be the final result of the internship. Finally there’s the documentation that goes alongside the delivery of the soft bodies implementation. This documents how soft bodies can be used and describes test results.

2D Demo The 2D demo is supposed to demonstrate the possibilities of FastLSM early on in the development, as well as to identify potential problems. The demo is structured as follows. A rectangular framework is displayed on the screen that serves as a boundary for a soft body constructed within the framework. The soft body itself is displayed as a grid of dots, representing the lattice vertices. From now on in this report a distinction will be made. A lattice vertex refers to the position in the lattice, whereas a particle will represent all the physical attributes of a lattice vertex. The user will be able to apply a force on one of the particles of the soft body. When the body hits a wall, it cannot penetrate it and will respond correctly to the applied force of the wall. Additionally to being able to apply a force directly to one of the particles, the user is also able to set a gravitational force, either upwards, or downwards. Figure 5.1 shows how FastLSM provides a similar 2D demo. The idea behind the demos is comparable. In order to create a 2D demo, multiple steps can be omitted. As the 2D implementation will most likely never be used in a real game, the body can be statically created. Furthermore, no interpolation of the original model is needed, as there is no original model. The soft body can either be constructed procedurally or from a script-file. Rendering the particles can be as simple as rendering dots at the positions of the particles.

Soft Body Simulation

23

- Internship Assignment: Analysis -

Figure 5.1 A 2D demo from FastLSM (source: FastLSM)

3D Demo The 3D demo is used to prove the usability of the soft bodies. The following setup is proposed. The player sees a soft body lying on a floor surrounded by four walls. Multiple shapes are sticking out of the floor with which the soft body can interact. The user can tilt the environment, making the soft body roll to a side. The behaviour of the soft body can be observed as it bounces off the other objects and walls. As with the 2D demo, the player can also adjust gravitational forces. More features can be added to the demo by the game designer should the need arise. Figure 5.2 demonstrates how the 3D demo can be organised. The arrows show movement.

24

Okke Schrijvers, Playlogic Game Factory, 2008

- Internship Assignment: Analysis -

Figure 5.2 The idea for the 3D demo.

Documentation The documentation should describe two things. In the first place it must serve as a user manual that shows how to create and use soft bodies. Secondly it serves as test documentation detailing test cases and conclusions.

5.6 

Project Management  In the second paragraph, the creation of soft bodies was divided in different, manageable tasks. Additionally, three deliverables were defined to measure the usability of soft bodies. This paragraph focuses on how the tasks and deliverables are implemented. The first section provides a short overview of the MoSCoW method of prioritizing tasks. It also states why MoSCoW was chosen for the project. In the second paragraph the time, quality and budget triangle is evaluated. The subsequent four paragraphs show the four priorities of the MoSCoW method and list all the tasks at their priority. The actual planning of the tasks can be observed in Appendix A: Planning.

Soft Body Simulation

25

- Internship Assignment: Analysis -

MoSCoW The MoSCoW method is a way of prioritizing requirements to minimize the risk of not delivering a useful product. It divides the requirements or tasks into four categories, starting with the letters MSCW, hence the name. The categories are “Must have”, “Should have”, “Could have” and “Would have”. The last one is sometimes also referred to as “Won’t have right now, but would like in the future”, as it is virtually never implemented. One of the reasons to use the MoSCoW method, is that is gives the customer a recognizable way to prioritize tasks instead of assigning it a meaningless number. Furthermore, tasks aren’t fixed in one category. Depending on the progress of the project, tasks can move from one category to another. For more information on the MoSCoW method, see [Wik08a].

Time, quality and budget In development there’s always a trinity of time, quality and budget, which dictates whether (sub-)systems should be developed or bought. In this case, buying is not an option as this would render the internship assignment useless. Time is also fixed as the internship will last for a period of five months. This means the quality is also fixed. To still get the highest quality possible, MoSCoW is used to prioritize the tasks as effectively as possible.

Must Haves In order for the product to be in working order, all the musts, have to be implemented. Therefore, only if all the musts are implemented can the internship be considered successful. The tasks in this category are: 1. 2. 3. 4. 5. 6. 7.

2D demo Test environment Construct a static mesh approximation Render the lattice vertices Implement relations between lattice vertices Implement the dynamics Interpolate vertices inside lattice vertices

The 2D demo will prove whether or not soft bodies are interesting enough to be used in a game and is therefore crucial to the continuation of the assignment. The mesh approximation was divided in two tasks, one to do it manually and one to do it automatically. Only manual, or static, approximation is needed as all tests can be performed with the same model. The rest of the tasks lead to the minimum effort required to see a model deform in a game environment. If any of the tasks are omitted, the soft bodies are of no use and therefore all these tasks are musts. 26

Okke Schrijvers, Playlogic Game Factory, 2008

- Internship Assignment: Analysis -

Should Haves A should is a task that is very desirable, but not critical to the functioning of the product. Should there be any time, these are the tasks that have to be performed first. 1. Demo application 2. Construct a dynamic mesh approximation A demo application is desirable to demonstrate the use of soft bodies in a more varied way than in the test environment. Dynamic mesh approximation is implemented so the process of creating a soft body from a model is streamlined and artists can do it without help from a programmer. This has a higher priority than speed optimizations, as it is not sure if speed will be a problem.

Could Haves A could improves the quality of the product, but even without it, the product is very much in a usable form. These are implemented if there’s time after the shoulds have been implemented 1. Implement the dynamics on the SPUs 2. Research the possibilities of vertex interpolation on the GPU The coulds both have to do with speed optimizations. The faster the algorithm is, the more resources are available for more or bigger soft bodies or other effects. Should the algorithm prove to be too slow without these speed improvements, they could turn into shoulds, with the dynamic mesh approximation becoming a could.

Would Haves A would is part of the program that would be nice, but isn’t really necessary. Usually, after the shoulds and coulds, there’s no time left anyway. 1. Self-collision checking Self-collision will only be necessary for convex models and even then only in a few extreme situations and therefore no emphasis has to be placed on it beforehand.

Soft Body Simulation

27

6  

INTERNSHIP ASSIGNMENT: REALISATION  In the previous chapter a detailed analysis was provided to define the internship assignment. In this chapter the results of the internship are provided. It starts off by looking at the deliverables. The first paragraph looks at the first deliverable, the 2D demo. The second paragraph looks at the 3D demo, which was the second deliverable. The third deliverable was a document detailing how to use the soft bodies and also contained test results. Instead of reviewing this document, two paragraphs are dedicated to both subjects of the document. Paragraph three details the framework integration and also describes the structure of the soft bodies from a software perspective. Paragraph four concludes with some of the test results. Since the analysis of the demos as well as the test results are very specific for the Playstation 3, it is recommended to read ‘Appendix D: Internal structure of the Playstation 3’ for anyone not familiar with it. Furthermore, this chapter covers the results of the deliverables. Interesting facts from the implementation can be found in the reflection chapter.

6.1 

2D Demo  Before going into the 2D demo, let’s recap what the 2D demo was all about. Since not much has ever been done with soft bodies, this was going to be a test ground for them, to see if it’s fun to play with. Additionally, this was a check to see if the algorithm could be performed fast enough for real time simulation. Furthermore, since this was a gameplay test for internal purposes, the graphics were kept at a minimum. Figures 6.1 to 6.3 provide screenshots of the application as it runs on the Playstation 3.

Figure 6.1 Large deformation

Figure 6.2 Our hero kneeling down

Soft Body Simulation

29

- Internship Assignment: Realisation -

Figure 6.3 Overview of the demo application including runtime stats

To start off, let’s take a look at the speed of the application. As we can see in figure 6.3, we have a soft body of 132 particles. The PPU time of each frame is 6.7 ms seconds which is about 40% of 16.6 ms (the target framerate of games is usually 60, this gives 16.6 ms time per frame). For testing purposes 40% PPU time is excellent although in a real game environment, it is unacceptable as many other systems would be running at the same time. Considering that the SPUs were still untouched these were excellent results. This answers the first concern, about the speed of the algorithm. This leaves the question if the soft bodies actually provide fun gameplay. While testing, it became apparent that there’s something very satisfying about throwing a man around and making him do tricks. While at first it was just fun to make him dive head first to a wall, this later turned into doing tricks like making him stand on his legs, stand on his head, and even dance. However, personal experiences don’t count, so a game designer had to take a look at it to see if it’s fun. He was impressed by the results and excited about the possibilities it might present in 3D. This basically meant that the assignment had a green light to continue with the 3D implementation. With the feedback of the game designer, it was clear that soft bodies have a future in games. The 2D demo had served its purpose of demonstrating the soft bodies’ capabilities. 30

Okke Schrijvers, Playlogic Game Factory, 2008

- Internship Assignment: Realisation -

6.2 

3D Demo  The goal of the 3D demo was to demonstrate the capabilities of the final product and, to a lesser extend, see if soft bodies are also fun to play with in three dimensions. Screenshots of the 3D demo can be seen in figures 6.4 to 6.8.

Figure 6.4 A torus on a spike

Figure 6.5 A sphere on a wall

Figure 6.6 Overview with bumper car. Its antenna proves more flexible than the rest.

The demo uses the motion sensing capabilities of the controller to tilt the environment by tilting the controller. The soft body is able to jump by pressing the square button. By far the most interesting thing to notice, can be seen in figure 6.6. A detailed bumper car model is deformed in real time with the frame only Soft Body Simulation

31

- Internship Assignment: Realisation taking 4.0 ms. This is only 23.9% PPU time and is a speed improvement of about 17% over the 2D demo. This can be credited in part to the program running partly on the SPUs, but for the most part its because the lattice is not all that detailed. The entire lattice is constructed of only 112 particles, which is less than the man figure in the 2D demo. The sphere and torus in figures 6.4 and 6.5 are constructed with approximately the same amount of particles. Figures 6.4 and 6.6 also show another property of the soft bodies, which is the support for convex objects. Also, although the figures themselves don’t show it, the objects are created dynamically without the need for any manual preprocessing of an artist. This makes sure it’s easy to create a new soft body from an existing model. The bumper car, which was an already created asset not specially created to be a soft body, proves this. Figure 6.6 also shows that the antenna of the bumper car is deformed extensively while the rest of the car isn’t. This is behaviour that one would expect in the real world as well. To summarize: the results look convincing, lots of different shapes of objects are supported and the algorithm runs at an acceptable speed. There are however two main issues with the soft bodies. These are shown in figures 6.7 and 6.8.

Figure 6.7 The object is stuck

Figure 6.8 Physics object is too large

Figure 6.7 shows what happens when a scene has small objects in it. Since the soft body exists of a series of physics objects rather than one large physics object, it is possible for other objects to penetrate the soft body. This can only occur when the second physics object is smaller than the gap between the spheres that make up the soft body and even in that case, it doesn’t happen a lot. A possible solution would be to make the physics object that make up the soft body larger, but this brings us to the second problem. The physics object is always a little bit larger than the original object. This is because all model vertices have to be inside a cell in order to be interpolated. Because the physics object is a little larger, it reacts to the environment before the actual model touches it. This can be observed in 32

Okke Schrijvers, Playlogic Game Factory, 2008

- Internship Assignment: Realisation -

figure 6.8. The torus surrounds the spike, but doesn’t actually touch it. This also happens when it collides with walls and other scenery. The 3D demo showed the capabilities of the soft bodies as well as its limitations. Furthermore it showed that the soft bodies are fun to play with in three dimensions as well. This was confirmed by the game designer.

6.3 

Framework Integration  The previous two paragraphs detailed the two demos and described what conclusions could be made based on them. This paragraph shows how the soft bodies can be implemented in a real game. This is done by showing the structure of the soft bodies in terms of entities. These entities can be converted almost one on one to the classes the soft bodies are made of. Figure 6.9 shows this entity diagram. Since it deviates a bit from standard UML for the sake of clarity, a few things need to be explained. Arrows indicate that an entity either creates or has a reference to objects of that other entity. The circle at the end of a line indicates a dependency without creation or ownership of that entity. The different colours of the entities indicate that they have different responsibilities. The entities ‘Shape Match Math’ and ‘Vector Conversions’ offer helper functions for all other classes. No all dependencies are displayed for these classes to avoid cluttering the diagram. The cell, particle and lattice vertex are surrounded by a black dotted line. This is because these represent one entity with three distinctly different responsibilities. This is a separation also made in the source code. The orange dotted line shows the scope of the soft bodies. External dependencies have been excluded for the most part, even thought this wasn’t possible for the connection to Havok. This, however, is contained within the particle entity. A soft body can be created by an application by providing the Soft Body Generator with a model from the ET framework and specifying the lattice vertex width. A model is created and returned to the application. After this, the only thing the application has to do is call the update function of the soft body every frame. The rest is done by the soft body and Havok. The soft body can be given a new position but no forces can be directly applied by the application.

Soft Body Simulation

33

- Internship Assignment: Realisation -

ET Framework

Application

Soft Body Generator

Soft Body

Region

Plate

Model Vertex

Cell Vertex

Summation Data

Bar

Cell

Particle Havok

Lattice Vertex

Shape Match Math Point3D

Legend

Vector Conversions

Soft body scope

Helper Classes

Summation Structure

Soft Body Definition

Application

Rendering

External Software

Lattice vertex scope Dependency Creation / Containment

Figure 6.9 Entity diagram of the soft body package.

Seen as the core of the algorithm is in the update function of the soft body, a schematic overview of this function can be found in figure 6.10. The function is divided in three parts, the first is shape matching, the second region damping and the third interpolation.

34

Okke Schrijvers, Playlogic Game Factory, 2008

- Internship Assignment: Realisation -

While shape matching and the interpolation have been well covered in chapter 4 ‘Implementing soft bodies using FastLSM’, region damping requires some extra attention. Physics laws dictate that when an object is in motion, it will stay in motion until opposite forces cause it to slow down. Since the particles receive no friction from each other from Havok, a custom solution is needed in the form of region damping. This method dampens all the velocity components of a particle in directions perpendicular to the velocity of the regions it’s part of. For a more detailed overview of region damping, see Appendix B or [Mue06].

Prepare for shape match Shape matching

Sum up to regions

Legend Particles Summation

Shape match regions Sum down to particles

Regions Cells Data flow

Calculate goal position Prepare for region damping Region damping

Sum up to regions Perform region damping Sum down to particles Apply region damping

Interpolate

Update cell vertex positions Interpolate model

6.10 The update function of the soft body.

After the soft body code was written, an optimisation was made to do some of the work on the SPUs instead of the PPU. This can be observed in figure 6.11. Soft Body Simulation

35

- Internship Assignment: Realisation -

Soft Body

Legend Soft Body Definition

Cell Job Manager

Helper Classes SPU Program

Cell

Cell SPU Job

Rendering Containment

Model Vertex Cell Vertex Figure 6.11 Entity diagram of the rendering part after the SPU optimization.

In this diagram, two new entities are introduced. First there’s the Cell Job Manager which runs everything from the PPU. Secondly there’s the Cell SPU Job which runs on one of the SPUs and sends the result back to main memory. On startup the Cell Job Manager gets all the cells from the Soft Body and creates a job for each one of them. Instead of the soft body calling the update of each cell, the Cell Job Manager is told to run its jobs. Each job is pushed to the SPU and the next frame, all the results are retrieved. This is done to prevent the PPU from stalling while waiting for the results. This optimization resulted in the complete removal of the bottleneck caused by a large number of model vertices.

6.4 

Testing  The testing was divided in four areas (namely functionality, speed, stability and fun) with each its own test method. The functionality was tested by calling all functions of the soft body from the application and checking if they perform as expected. Speed was tested using a profiler for the Playstation 3 called ProDG Tuner. The stability was tested by running the simulation for a long period of time and while checking for errors (such as the ones described in paragraph 6.2 ‘3D demo’). The fun was determined by the game designer. In the following four sections each area is covered and the conclusions, rather than the test results, provided.

36

Okke Schrijvers, Playlogic Game Factory, 2008

- Internship Assignment: Realisation -

Functionality As stated, the functionality was tested by calling the functions of the soft body from the application. There are basically just three functions to test. These are: 1. The possibility to move the entire object to another location without putting any force to it. 2. The possibility to reset the deformation of the soft body back to the original shape. 3. The deformation itself, which is performed by updating the soft body every frame. The resetting and moving of the soft body was easily tested by exposing this functionality through a button press in the 3D demo. This resets the body and places it in its original position. This works completely as expected. The deformation itself is performed by calling the update function of the soft body. This takes care of the shape matching and interpolation. Both the shape matching and the interpolation provide convincing results. There are however a few considerations for both cases. For the shape matching, when the object is too flexible, it’s possible for it to intersect itself. Given the standard parameters, it’s unlikely for it to happen. But when an artist or programmer changes these parameters to create a more flexible object, this is something to check. Also for the shape matching, the computational costs scale linearly ( ) with the amount of particles. This is because every particle needs a Havok object. Having too little particles leads to a physics object that might be a lot larger than the model. This in turn leads to the object reacting to other objects without actually touching it, as can be seen in figure 6.8. This is a case by case consideration. Finally for the interpolation there are two considerations. The model should be created such that no two adjacent vertices are separated by more than the width of a lattice vertex. This is because of the way the soft body is generated. It checks where all the model vertices are and creates cells on the appropriate places. The model is filled with lattice vertices by placing lattice vertices between cells on the same row. If a row doesn’t contain any cells because there were no model vertices, no cells or lattice vertices are placed and the model is incorrect. This problem can be solved procedurally by mesh tessellation, which is outside the scope of the project. The second consideration is that a model that is too detailed (i.e. has too many model vertices within one cell) can display some artifacts in the form of hard edges. This has to do with the intricacies of smooth shading algorithms (like lambert or phong shading) and only occurs on flat surfaces. Either the flat surface has to be less detailed in the number of Soft Body Simulation

37

- Internship Assignment: Realisation vertices or the soft body has to be more detailed to prevent this from happening. Besides the considerations, the effects of the soft bodies look convincing and are ready to be used in real games.

Speed The speed of the application was tested by using a profiler which displayed how long certain functions took to complete. Using this, during development bottlenecks can be identified and improvements measured. While testing it was used to see how size affected the speed of the program and to see what is realistically possible in a game. A few conclusions can be drawn. 1. The speed of the soft bodies scales linearly with the number of particles used. 2. The time it takes to interpolate the model is negligible compared to the time needed for the dynamics. This can be credited to the SPUs performing the calculations. 3. Soft bodies with a particle count of over 250 take about 80% PPU time, in situations where a lot of collisions take place, Havok causes the game to slow down up to 300% PPU time which results in a momentary frame rate drop to 20 fps. Since this is noticeable, it is recommended to have a maximum of about 150 - 200 particles in a soft body.

Stability Stability was measured by running the program for a long period of time while continuously testing the soft bodies. The soft bodies can run for hours without slowing down, which indicated no memory leaks are present while executing. Furthermore, no memory leaks were reported by the debugger when closing down. The soft bodies have been tested with a gravity of over 300 while still performing completely normal as long as they can’t gain in velocity. Allowing the soft body to fall for even 10 meters at a gravity setting of 300 resulted in bad collision detected which in turn resulted in the soft body being stuck. This shows that soft bodies should not move at extreme speeds. This however is true for all physics objects and not inherent to soft bodies specifically. Soft bodies always return to their shape except for when a soft body is extremely flexible and convex. This happened with the torus shape, which collapsed and turned into a smaller torus. This can be prevented by not creating extremely flexible convex objects. There was a problem with creating a soft body with regions that span only two dimensions, rather than three. This is a problem in the original equations and can’t easily be prevented. It has to do with the fact that 38

Okke Schrijvers, Playlogic Game Factory, 2008

- Internship Assignment: Realisation -

when one dimension is removed, the simulation is of cloth rather than a soft body. These use other calculations.

Fun Even though fun is hard to measure, it still had to be tested as the soft bodies being fun was one of the main goals of the internship. Testing was performed by the game designer who indicated that the soft bodies were fun to play with and that he had a few ideas of how to use them in games. Despite their potential, in the end, the fun will depend on how soft bodies are used in a game.

Soft Body Simulation

39

7  

CONCLUSIONS AND RECOMMENDATIONS  In this chapter conclusions are drawn to see if the internship was successful. Furthermore, recommendations are made about further improvements to the algorithm as well as possible new research to be conducted. In the first paragraph the goal of the internship is reviewed in light of the results and it is described to what extend the goal is achieved. The second paragraph looks at the goal from a higher level and described to what extend the need of the company has been fulfilled. Finally in the third paragraph recommendations are made about future work.

7.1 

Soft Body Physics Usability  First, let’s take a look at the goal of the internship: “The addition of soft body dynamics to the Havok Physics Engine on the Playstation 3”. This goal had the following additional requirements: 1. 2. 3. 4.

The The The The

type of soft bodies has to be flexible (elastic) soft bodies have to run on the Playstation 3 soft bodies have to use Havok soft bodies have to interact with Havoks rigid bodies

All these requirements have been met and the goal has been achieved. It is possible to generate a soft body from a mesh with minimal effort. All possible shapes are applicable. There are a few issues, namely the speed which prevents more than a couple of soft bodies to be simulated at the same time. Furthermore meshes can require minor alterations if the level of detail differs (way) too much from the level of detail of the soft body. Finally, soft bodies can become stuck in scenery when the scenery contains long, thin objects on which the soft body can fall.

7.2 

Innovation in Games  The reason Playlogic Game Factory wanted soft bodies in the first place was to create innovative gameplay. Since the soft bodies have yet to be incorporated in games, it would be premature to claim this goal achieved. Looking at the demo created to prove the usability of the soft bodies, some conclusions can be drawn. Soft Body Simulation

41

- Conclusions and Recommendations Soft bodies can provide visual effects, never seen before in games. Also, game designers now have a new tool that they can use in their design. Additionally it is now possible to create a Loco Roco style game (which had 2d soft bodies) in three dimensions. It will be up to the game designers what they will do with it to prove its worth in a game.

7.3 

Recommendations  The main concern of the soft bodies is speed. Part of the code has already been ported to the SPUs and additional speed improvement can be achieved by porting other parts. However, since profiling showed that there’s no single bottleneck in the algorithm, but rather all the (on each other dependent) steps, a different solution is proposed. Instead of having an SPU job manager and a PPU side class to coordinate this, small bits of code can run on the SPUs that load other code once they complete their task. This can almost completely eliminate all PPU time required by the soft bodies. In that case only the limit of the SPUs and Havok are relevant. Research in loading code as data has to be conducted. The process is described in [Act07] and [Act08] and can be found on http://www.insomniacgames.com/tech/. Furthermore, SPU intrinsics can be used to further speed up the calculations on the SPUs. These intrinsics specialize in SIMD (single instruction, multiple data) and vector math in particular. Since this is exactly what is needed, great speed improvements are expected. A way to improve the scalability of the soft bodies is to only create particles for the outer lattice cells. This means less Havok objects and thus faster collision detection.

42

Okke Schrijvers, Playlogic Game Factory, 2008

8  

REFLECTION AND EVALUATION  The previous chapter provided the results of the internship assignment as well as recommendations on how to further improve the result. This chapter is dedicated to describing the process. It is divided in four parts. The first paragraph documents the 2D demo and how it influenced the rest of the internship. The second paragraph describes the 3D demo. This includes pretty much the whole implementation of the algorithm in three dimensions. The optimizations are discussed in the third paragraph. In the fourth paragraph I share my personal experiences of the internship.

8.1 

2D Demo Breakdown  The 2D demo was created to prove the usability of soft bodies as well as provide a smooth learning curve for myself, since I had no previous experience with physics simulation, let alone FastLSM. Creating a 2D demo meant that certain tasks could be omitted and the calculations could be simplified. The soft bodies are supposed to work with the so called ET (which stands for EyeToy) Framework. To create a new application, a dummy application is provided which can be copied and altered only slightly to get a new application. A scene was created using Maya and it was converted to the right format using the Sony EyeToy Tool Chain. After the framework was created, a soft body had to be created by means of a static mesh approximation. This could be done statically because there was no real mesh to approximate. The definition of the lattice was put in a separate Lua file that doesn’t have to be compiled, to save compile time. Implementing the dynamics proved to be the first challenging task as assessed in the risks (paragraph 5.4). The FastLSM algorithm calculates the goal position of each of the particles. Using Havok, you can’t simply place the particles at that position as that will delete all collision data. Without this collision data, Havok doesn’t respond to collisions and the soft body moves through all other objects. Instead of placing the particles at their goal position, the direction to their goal position is calculated and their velocity is updated accordingly. This makes the algorithm a little less stable (large time steps give weird results), but you get the collisions with other Havok objects which is one of the requirements. After the dynamics were implemented a weird situation occurred in which the particles would always keep moving in different directions, creating a very shaky soft body. This can be explained by the lack of internal friction. This was solved by implementing per region damping of the particles. The regions calculated their (linear) velocity. The particles compared their own Soft Body Simulation

43

- Reflection and Evaluation velocity to the velocity of their parent regions, and removed a percentage of their velocity in the direction other than the regions velocity. Creating a 2D demo before the 3D implementation was an excellent decision in my opinion. It allowed me to ease in to physics simulation and allowed me to understand the FastLSM algorithm in a less complex manner before the 3D case. The demo was supposed to be created in ten days. I had finished after nine.

8.2 

3D Demo Breakdown  The 3D demo was going to be a lot more elaborate than the 2D demo. Since this had to be done on final quality the code had to be entirely clean, without any memory leaks. Furthermore the calculations had to be performed in three dimensions which added another layer of complexity. First of all new framework was created and the classes to create the FastLSM structure added. A new soft body could again be created by means of a lua file that only supported cubic shapes. By first creating a static mesh approximation, the focus could turn to the dynamics early on in development. After the creation, the lattice vertices had to be rendered. Since this was only going to be used for debugging purposes, I decided the Havok Visual Debugger (that displays physics objects) would suffice. The next task to perform was to create the relation between the lattice vertices. This was basically the same as for the 2D demo with the exception for the addition of the plates in the summation structure and a more sophisticated region creation algorithm. A breadth-first search algorithm was used to find all the lattice vertices within range of region. The algorithm was extended with a random number instead of a Boolean to indicate it has been visited, to avoid conflicts when particles are added to different regions. After the relation between the particles was implemented, I was ahead one week on the schedule. Seen as I reached the bottleneck of the 2D demo, the dynamics, this was well appreciated. The dynamics in three dimensions proved the first real problem. Everything went smoothly until I got to extracting a rotation matrix from a transformation matrix containing rotation and stretch. The technique to do this is called polar decomposition. While implementing it wasn’t all that difficult, I decided to put some effort in researching why things were done, not only how. As this research led through all sorts of areas in mathematics of which I had no knowledge, it sparked my interest in the subject again. Finally I found (most of) the answer in [Sho92]. A book which also provided a lot of background information was [Str93]. The fact that this was the only major issue with implementing the dynamics in three dimensions can be credited to the 2D demo. Instead of

44

Okke Schrijvers, Playlogic Game Factory, 2008

- Reflection and Evaluation -

the calculated four weeks, only one week was needed. This meant that the creation of the 2D demo (that took less than two weeks) already paid out. Things were going great with the internship. Five weeks in I was four weeks ahead of schedule and one task, the mesh interpolation, away from implementing all the musts. Of course this was where things went wrong. The interpolation of the mesh was basically not much different from another technique used extensively in game development called skinning. Since this would mean minimal actual programming, I decided to test if this would work instead of implementing the method proposed by [Riv07]. After a series of tests, it was revealed that the method was unsuitable for use as it would enforce a limit of 128 particles. I decided to go with the method proposed in [Riv07] instead, but this proved to have its own downsides. The calculations were obfuscated to the extent that it after days of research I couldn’t figure out what the intentions were. Two days of brainstorming with two programmers (Ronald and Kees) finally lead to the right calculations, which were then implemented in a couple of days. Appendix B shows the calculations we derived from the ones shown in [Riv07]. To finally place the vertices at the right positions, conversions from the float data type to the half data type were necessary. The latter is a custom half precision floating point data type. This conversion was done with a couple of bit shifts, bit masks and exception handling, but was finally completed in a couple of days. This marked the implementation of the final must task. Although it took a full week longer than expected, I was still three weeks ahead of schedule. Before I started to create the final 3D demo, a game designer took a look at it and he was immediately impressed and started to brainstorm about different possibilities. One of these ideas was to use the motion sensing capabilities of the Playstation controller to tilt the environment. Seen as I was ahead of schedule three weeks, Ronald allowed me to create the 3D demo without creating a new planning first. After the 2D demo I was already glad I started with that to ease myself in physics simulation and FastLSM. During the 3D demo I really noticed the upside of it. The tasks that I already had to perform with the 2D demo went really smoothly. The one major problem I faced was the interpolation, which wasn’t in the 2D demo. The dynamics in three dimensions were implemented about as quickly as the dynamics in two dimensions, which can be credited to the 2D demo. Researching polar decomposition sparked my interest in mathematics again to the extent that I intent to study mathematics after I finish my bachelors in Computer Science. The brainstorm sessions about the interpolation made me even surer about this decision, as I am now convinced that this will also improve my position as game programmer on the market. Soft Body Simulation

45

- Reflection and Evaluation -

8.3 

Optimizing  With the 3D demo finished, there were two tasks left to do in the shoulds and coulds department. These were implementing the dynamics on the SPUs and researching interpolation on the GPU. As it turns out, these two tasks overlapped quite extensively. As I used a profiler to determine which functions took the longest to complete and thus should be transferred to the SPUs first, I discovered the interpolation was the main bottleneck. After consultation with the most experienced SPU programmer (Tijs), I decided to perform the interpolation on the SPUs. Apparently vertex shaders aren’t all that fast on the Playstation 3 and the GPU is 100% occupied most of the time anyways. This meant that you would get a better performance by running the interpolation on the SPUs. The fact that the Playstation 3 is known for its difficulty to program on (see [Sid07]) can be credited to these SPUs. They’re basically seven embedded systems that operate parallel to the main processor, the PPU. They have only 256 kilobytes of memory and don’t have direct access to the main memory. I made use of the SPUs by using a lightweight kernel that can manage jobs. A job is a simple program that reads data from main memory, does some calculations using that data and then sends the results back to main memory. For the SPUs to work properly, every data block has to be aligned in memory and, to improve speed, exist as one consecutive memory block. This is basically the opposite of object oriented design where data used in a class is grouped together rather than all data used for a calculation. This meant reordering the data a bit, but wasn’t all that hard. The main problem was discovering that the SPUs can’t write data directly to a vertex buffer. This is a feature that was necessary for the interpolation. Since the SPUs provide no debug information except the possibility to print to the terminal, this was quite hard to catch (which is often the case in embedded programming). After that was discovered, the results were written to a predefined place in main memory after which that was written to the vertex buffer on the PPU. Waiting for the SPUs to finish their jobs introduced a new stall, albeit a small one. Therefore the results are written to the vertex buffer a frame later. This means the original model has a delay of 16ms that isn’t noticeable. This relieved the bottleneck and almost eliminated all the PPU time necessary for the interpolation. Further speed improvements can be achieved by putting more calculations on the SPUs, but since these are only small calculations on different datasets you quickly reach the ceiling if it comes to speed improvement. Therefore a different, more elaborate scheme is proposed. On the SPUs, code is data, just like the data the code operates on. Since it is possible to load data from the SPUs, it is also possible to load code from the SPUs. By doing so, you could create a series of small code blocks that consecutively operate on the results the previous code block produced. This requires

46

Okke Schrijvers, Playlogic Game Factory, 2008

- Reflection and Evaluation -

almost no PPU time (only to start things up) and can therefore theoretically make it nearly PPU independent. This however requires a complete redesign of the data as well as all code, but as I stated in paragraph 7.3 (Recommendations) I think it will be worth the effort. Although working with the SPUs was a drag, it also showed me the importance of embedded software engineering. After discovering the possibilities of the SPUs (with regard to loading code as data), I started to get excited about programming on them. The possibilities are amazing and I’d like to devote the rest of my time at Playlogic to uncover the full potential of them.

8.4 

Personal Experience  This paragraph is dedicated to describe my own experiences at Playlogic Game Factory. For many years, it has been my goal to find a job as game programmer. My previous internship gave me the opportunity to work at a small game developer and provided me with the necessary background to apply at the largest game developers in the Netherlands. Playlogic Game Factory is one of those companies and I am very glad that I was able to follow an internship there. Ronald de Feijter, who was my company mentor, asked about my interests and provided me with an excellent internship assignment. The implementation of soft bodies was very heavy on the math side, which is something that I really enjoyed. Ever since the first day, things have been a blast. The facilities are great; state-of-the-art computers to work with, my own personal Playstation 3 devkit (a special Playstation 3 used for development that costs about 20.000 euros) and two monitors. Working hours are really flexible as you can come in between 8 and 10. But all these things are worthless if you don’t have the right people around you. Fortunately my colleagues are amazing. There’s something to learn from each and every one of them and they are great to hang out with. From the first week I felt right at home. The supervision by Ronald was also great. He gave me space to discover things for myself, but was always there if I couldn’t figure something out. He also provided excellent feedback on early drafts of this report. During the internship I learned a lot about physics simulation, mathematics, game programming and game development, but the most valuable things I learned, were things I realised along the way. Studying mathematics would not only be fun for me to do, it also serves a great purpose in this industry. Therefore I plan to study it alongside having a career in the industry. But most importantly I realised I made the right career choice. I love making computer games and I love working with the kind of people that love making computer games.

Soft Body Simulation

47

Appendix A: Planning  In this appendix a planning is supplied for the first twelve weeks of the internship. Bold indicates a deadline of a deliverable. In these twelve weeks, all musts are planned to have been implemented. After these twelve weeks a new planning should be made depending on the tasks that still have to be performed. Since I’ve got no experience with physics simulation, it is very hard to make an exact estimate as to how long it will take to implement the musts. Therefore, even though they are planned in twelve weeks, it might take the full internship to implement these. Even if they are implemented within the twelve weeks, it is unsure what tasks will have to be performed next. The shoulds and coulds as defined in paragraph 5.6 can easily swap priority as the project progresses, so any planning created now will most likely be altered once the musts are implemented. 11 February 11 – 13 February

First day of work First draft Internship Initiation Document 14 – 15 February Start 2D Demo Weeks 2,3 (18 – 29 February) 2D Demo 29 February 2D Demo and meeting with company mentor and school supervisor Week 4 (3 – 7 March) Static mesh approximation and rendering the voxels Week 5 (10 – 14 March) Implement relation between voxels, Research dynamics Weeks 6-9 (17 March – 11 Implement and iterate through April) dynamics Weeks 10 – 11 (14 – 25 April) Interpolate vertices inside voxels 25 April Preliminary demo Weeks 12-17 (28 April – 6 Should haves and could haves and June) writing of the report 9 June 2008 Report Deadline Weeks 18-21 (9 June – 4 July) Week 20 (23 – 27 June) 4 July

Loose ends Presentation at Hanze University Final demo

Soft Body Simulation

49

- Appendix A: Planning -

The Updated Planning After the first nine weeks a new planning was created. This was done two weeks in advance as all the tasks had already been implemented. There were no priorities shifts in the tasks as the demo ran at 65% processor time at 60 frames per second (which is the frame rate cap). The 3D demo was created before the new planning was made so it was omitted from the planning. Italicized text stand for tasks that were already performed or deadlines already met. Bold again indicates a deadline. 11 February 11 – 13 February

First day of work First draft Internship Initiation Document 14 – 15 February Start 2D Demo Weeks 2,3 (18 – 29 February) 2D Demo 29 February 2D Demo and meeting with company mentor and school supervisor Week 4 (3 – 7 March) Static mesh approximation (rendering the voxels) Implement relation between voxels, Research dynamics Week 5 (10 – 14 March) Implement and iterate through dynamics Weeks 6-8 (17 March – 4 Interpolate vertices inside voxels April) 4 April Preliminary demo Week 9 (7 – 11 April) 3D Demo and writing of report Weeks 10,11 (14 April - 25 April) Weeks 12-15 (28 April – 23 May) Week 16 (26 May – 30 May)

Dynamic mesh approximation

Week 17 (2 June – 6 June)

Implement the dynamics on the SPUs Research possibilities of interpolation on the GPU Writing of report

9 June 2008

Report Deadline

Week 18 (9 June – 13 June) Week 19 (16 June – 20 June)

Implement interpolation on the GPU Create presentation and tryout in Playlogic Game Factory Week 20 (23 – 27 June) Presentation at Hanze University Weeks 20, 21 (23 June – 4 Loose ends, polishing demo July) 4 July Final demo 50

Okke Schrijvers, Playlogic Game Factory, 2008

Appendix B: FastLSM  This appendix provides the mathematical side of the FastLSM algorithm. Although some explanation is provided about how the FastLSM algorithm works, it is highly recommended to read chapter 4 before this appendix. This appendix is basically an explanation of [Riv07] as well as [Mue05] as the first paper is based on the latter. The order of this appendix is based on the update function of the soft bodies as described in figure 6.10. However it starts with two different sections. The first describes how shape matching works without the FastLSM structure. Doing so creates a distinction between shape matching and [Riv07]’s contributions. The second section describes damping, which is used to bleed off velocity in directions other than the general direction of an object.

Shape Matching Shape matching was proposed by [Mue05] and replaces energies by geometric constraints and forces by distances of current position to goal position. It makes use of the vertices of a model rather than a different physics object. The algorithm stores the material position of all the vertices as the distance from the center of mass of the entire object to the vertex. Each frame, a rotation matrix is calculated using the least squares technique. The function to minimize is:   Equation A.1

Where is the mass of vertex , is the rotation matrix to calculate. is the position of a particle, is the material position of a particle.   is the material center of mass of the object and is the current center of mass. and are calculated as: ∑ ∑

,

∑ ∑

Equation A.2

Now instead of calculating a rotation matrix directly, first a linear transformation matrix is calculated. This contains rotation but also other linear transformations like stretch. To calculate this linear transformation Soft Body Simulation

51

- Appendix B: FastLSM matrix two additional vectors are needed that describe the distance of a vertex to the center of mass in its current and material position. These are and . The term to minimize becomes: vectors

Equation A.3

This leads to:

Equation A.4

Since

is symmetric (matrices created by multiplying a vector with its

transpose always results in a symmetric matrix) and thus contains no rotation. Therefore the optimal rotation is the rotational part of which where

can be found by polar decomposition

is a transformation

matrix containing only stretch. The symmetric part is leads to the rotational part being

, which

.

Using the rotation matrix, the goal position is calculated by:

Equation A.5

To determine the final position where the vertex is placed the following integration scheme is used to calculate the velocity and position. / Equation A.6

Equation A.7

Where is the velocity of vertex . 0 … 1 is a scalar that indicates stiffness. is the time, is the time step and are the external forces by for instance collision response or gravity. For the rules on matrix calculations and linear algebra, [Str93] provides an excellent source.

52

Okke Schrijvers, Playlogic Game Factory, 2008

- Appendix B: FastLSM -

Damping The damping algorithm used in FastLSM was first proposed by [Mue06] paragraph 3.5. This section gives an overview of how this damping works. To start off, the position of the center of mass is calculated by equation A.2. The linear velocity is calculated similarly by ∑ ∑ Equation A.8

The next step is to calculate the angular velocity of the entire object. Calculating the angular velocity is very similar to calculating the linear velocity. The linear velocity is calculated as

Equation A.9

Where

is the linear momentum. Calculating the angular velocity is

Equation A.10

Where is angular velocity, is the inertia tensor and is the angular momentum. This is in essence the same calculation but since is a matrix rather than a scalar, you can’t divide by it and instead you have to multiply by its inverse. So in order to calculate the angular velocity, first the inertia tensor and angular momentum have to be assembled. This is done in the following two equations

Equation A.11

 

̃ ̃ Equation A.12

Where and ̃ is a 3x3 matrix with the property that ̃ . The angular velocity can now be computed with equation A.10. Now that the angular velocity of the object is known, the linear velocity of the vertices can be damped in directions other than the general motion of Soft Body Simulation

53

- Appendix B: FastLSM the object. The difference of motion compared to the general motion can be calculated by ∆ Equation A.13

Where ∆ is the vector that points from the tip of the velocity of the vertex to the tip of the velocity of the object. The final velocity of vertex can be calculated by ∆ Equation A.14

Where

0 … 1 is a scalar that indicates how much the velocity in

a different direction should be damped.

Prepare Particles for Shape Matching With FastLSM, to achieve better results, is calculated per region instead of per object. This means has to be assembled per region. To do this, first the deformed center of mass has to be calculated. The particles prepare for this by pre calculating where is the mass of a particle divided by the number of regions it’s part of. Furthermore, to calculate linear transformation matrix , has to be calculated. This vector and matrix are summed upwards to the regions where the shape matching happens.

Shape Match Regions Let’s take a look at how the calculations defined in the shape matching section translate to those used in FastLSM. First of all the center of mass has to be assembled per region. This is done by 1 Equation A.15

Where

∑

is the precomputed region mass.

is the collection of

particles inside region . The linear transformation matrix is quite similar to the one in [Mue05] and is described as

Equation A.16

To allow fast summations, this equation is rewritten as 54

Okke Schrijvers, Playlogic Game Factory, 2008

- Appendix B: FastLSM -

Equation A.17

For the entire process of deriving equation A.17 from equation A.16, see [Riv07]. The particles precomputed the first part of equation A.17 as well as the last part of A.16 which is used in the last part of equation A.17. Given the complexity of polar decomposition it is not described here in full detail. The process can be summarized as follows. Polar decomposition is a way of decomposing a linear transformation matrix in two matrices, a rotation matrix and a stretch matrix. Since the rotation can not be extracted directly, the stretch part is first derived. This is done by diagonalizing the matrix using Jacobi rotations. [Riv07] proposes the eigenvectors of the previous matrix decomposition should be used to jumpstart the composition as described in [Gol89]. The inverse of this diagonal matrix is multiplied by the original linear transformation matrix to get the rotation matrix. For more details on polar decomposition, see [Sho92]. Finally a translation vector is created by

Equation A.18

This is done because equation A.5 is dependant on the position of the particle relative to the center of mass and this information is not available with fast summations. So every region produces a translation vector that is used by the particles to calculate the goal position. The results are summed down to the particles.

Calculate Goal Position of the Particles The particles now average the results by dividing them by the number of regions they’re part of. They calculate their goal position by

Equation A.19

Where is the averaged rotation matrix and is the averaged translation vector. The integration of the particles is done nearly identical to equations A.6 and A.7. The only difference is that the scalar is omitted. Soft Body Simulation

55

- Appendix B: FastLSM The implementation of the FastLSM algorithm using the Havok Physics engine put some restrictions on the equations. Foremost, the integration itself is done by Havok and therefore equation A.7 is not implemented in the soft bodies. Furthermore the external forces are also handled by Havok, so these too are omitted from the equations. This leaves the following equation to integrate the soft bodies with Havok:

Equation A.20

This is identical to the first part of equation A.6.

Prepare Particles for Region Damping In FastLSM, the damping proposed in [Mue06] is applied on a per region basis rather than the whole object. This makes it also applicable for fast summations. To perform region damping each particle precomputes its , and . These are used in the equations weighted velocity for the region damping.

Perform Region Damping Region damping is performed by using equations derived from the ones used in [Mue06]. First the equation for calculating region velocity is 1 Equation A.21

This is comparable to the calculation for the position. The angular momentum is calculated as

Equation A.22

And the inertia tensor as

Equation A.23

All summations have already been precomputed per particle. The angular velocity is calculated like the case in [Mue06]. This result is then summed down to the particles.

56

Okke Schrijvers, Playlogic Game Factory, 2008

- Appendix B: FastLSM -

Apply Region Damping To fit the FastLSM summation structure, equation A.13 is redefined as 1

∆

Equation A.24

Where is the number of regions the particle is part of. Finally the linear velocity is update as equation A.14.

Interpolate Model For the interpolation of the original model, [Riv07] proposes trilinear interpolation using the following equation

Equation A.25

Where

is the location of the model vertex ,

the model vertex inside the cell,

is the material position of

is the position of a cell vertex and

. Although this is pretty straightforward, is a scalar from the function the paper doesn’t elaborate on the function . This function was reversed engineered to be 1

1

1 Equation A.26

Where

,

and

are calculated as the following equation for .  

. Equation A.27

With being the material position of a cell vertex. Besides the position, the normals of the model also have to be updated. This can be done using

Equation A.28

is called the deformation gradient and is a second-order tensor (matrix).    

X

is the gradient of a scalar function. As with equation A.25, the paper

doesn’t elaborate on what in this case calculated like

is. It is the gradient can be

Soft Body Simulation

57

- Appendix B: FastLSM -

̂

̂ Equation A.29

Where ̂ 1 0 0 , ̂ 0 1 0 and 0 0 1 are the base vectors of three dimensional Euclidean space. , and are the same as in Equation A.26. is the partial derivative. It is different for each base and is based on the value it replaces. When the original value is positive or zero, the partial derivative is -1 and it’s 1 if the value was zero. Finally the normals are not calculated directly as the deformation gradient also contains stretch. To counter this two perpendicular tangent vectors are used, and . These are deformed using the following equation

Equation A.30

Where · Equation A.31

is called the directional derivative and is a scalar. The same two equations also apply for the calculation of is calculated by .

58

Okke Schrijvers, Playlogic Game Factory, 2008

based on

. Finally the normal

Appendix C: Intern Assignment   Intern Assignment Playlogic Game Factory Intern: Okke Schrijvers Company Supervisor: Ronald de Feijter Playlogic Game Factory develops computer games for various platforms. One of the current projects concerns a game for the Sony Playstation 3 using the Playstation Eye camera. According to the design documents, this game will contain a lot of physics simulations. The Havok physics engine will be used to implement these in-game physics. Besides rigid body physics, which is fully supported by Havok, the game should also contain some form of soft body physics. In this context, soft body physics either means deformable objects (objects that deform after a collision and maintain deformed, such as a metal barrel) or flexible objects (objects that deform upon impact but return to their original shape after the force has been removed, such as a rubber toy). Both kinds of objects are not naturally supported by Havok and therefore require a custom solution. A simple deformable object has already been implemented, but it requires a lot of optimization and generalization to be fully applicable in the game. The goal of this assignment is to provide the game engine with soft body physics. These soft bodies should operate in the same world as the rigid bodies and interact with those. Soft body physics should be implemented as a custom extension of Havok, which should preferably also be applicable in later games. Depending on the further development of the game design as well as the progress of this assignment, the assignment focus may shift either to flexible or deformable objects. To get idea of what we are aiming for, take a look at: Flexible objects: http://www.fastlsm.com/ Deformable objects: http://www.ageia.com/physx/tech_demos.html video)

(top

Soft Body Simulation

59

Appendix D: Internal Structure of the Playstation 3  This appendix is provided to give an overview of the internal structure of the Playstation 3. It helps to understand the need to put parts of a computer game on the SPUs rather than the PPU and also why programming on the SPUs is so difficult. The following three sections are Wikipedia1 excerpts and finally a figure is provided, demonstrating the structure of the Cell Processor.

Playstation 3 The Playstation 3 is the third home video game console produced by Sony Computer Entertainment and successor to the PlayStation 2 as part of the PlayStation series. Playstation 3 uses the IBM designed Cell microprocessor as its CPU, utilizing seven of the eight “Synergistic Processing Elements” (SPE). The eighth SPE is disabled to improve chip yields (for example, the chips do not have to be discarded if one of the SPEs is defective). Only six of the seven SPEs are accessible to developers as one is reserved by the OS. Graphics processing is handled by the NVIDIA RSX, which can output resolutions up to 1080p HD. The PlayStation 3 has 256MB of XDR main memory and 256MB of GDDR3 video memory for the RSX. ([Wik08c])

Cell Processor Cell is a microprocessor architecture jointly developed by Sony Computer Entertainment, Toshiba and IBM, an alliance known as “STI”. The first major commercial application of Cell was in Sony’s PlayStation 3 game console and Mercury Computer Systems (a dual Cell Server). The Cell architecture emphasizes efficiency/watt, prioritizes bandwidth over latency, and favors peak computational throughput over simplicity of program code. For these reasons, Cell is widely regarded as a challenging environment for software development. Despite those challenges, research has indicated that Cell excels at several types of scientific computation. ([Wik08d])

Synergistic Processing Elements (SPE) Each SPE is composed of a Synergistic Processing Unit (SPU) and a Memory Flow Controller (MFC). With the current generation of the Cell, each SPE contains a 256 KB embedded SRAM for instruction and data called “Local Storage” which is visible to the Power Processor Element (PPE) and can be addressed directly by software. The “Local Storage” does not operate like a conventional CPU cache since it is neither transparent to 1

http://en.wikipedia.org/

Soft Body Simulation

61

- Appendix D: Internal Structure of the Playstation 3 software nor does it contain hardware structures that predict which data to load. Note that the SPU cannot directly access system memory, the 64-bit virtual memory addresses formed by the PPU is passed to the SPU memory. ([Wik08d]) In one typical usage scenario, the system will load the SPEs with small programs (similar to threads), chaining the SPEs together to handle each step in a complex operation. For instance, is to partition the input data set and have several SPEs performing the same kind of operation in parallel. ([Wik08d])

Figure A.1 The internal structure of the Cell Processor (source: Nicholas Blachford, http://www.blachford.info/computer/Cell/Cell1_v2.html)

62

Okke Schrijvers, Playlogic Game Factory, 2008

References  [Act07]

Mike Acton. Dynamic SPU Code. http://www.insomniacgames.com/tech/articles/0807/ dynamic_spu_code.php. 2007

[Act08]

Mike Acton. More on SPU Shaders. http://www.insomniacgames.com/tech/articles/0108/ more_on_spu_shaders.php. 2008.

[Ebe03]

David H. Eberly. Game Physics. Morgan Kaufmann, San Fransisco, California, USA, 2003.

[Gol89]

Gene H. Golub and Charles F. van Loan. Matrix Computations, 2nd ed. John Hopkins University Press, USA, 1989.

[Kos04]

Ralph Koster, A Theory of Fun for Game Design. Paraglyph Press, USA, 2004.

[Mue05]

Matthias Müller, Bruno Heidelberger, Matthias Teschner, Markus Gross. Meshless Deformation Based on Shape Matching. Proceedings of SIGGRAPH'05, pp. 471-478, Los Angeles, USA, 2005.

[Mue06]

Matthias Müller, Bruno Heidelberger, Marcus Hennix, John Ratcliff. Position Based Dynamics. Proceedings of Virtual Reality Interactions and Physical Simulations (VRIPhys), pp. 71-80, Madrid, 2006.

[Riv07]

Alec R. Rivers and Doug L. James. FastLSM: Fast Lattice Shape Matching for Robust Real-Time Deformation. 2007.

[Sho92]

Ken Shoemake. Matrix Animation and Polar Decomposition. Proceedings of the 1992 Graphics Interface Conference. 1992.

[Sid07]

Vicious Sid. PS3 faster than Xbox 360, harder to manage. http://www.gamepro.com/news.cfm?article_id=116728. 2007.

[Str93]

Gilbert Strang. Introduction to Linear Algebra. WellesleyCambridge Press, Massachusetts, USA, 1993.

[Wik08a]

Wikipedia. MoSCoW Method. http://en.wikipedia.org/wiki/MoSCoW_Method. 2008.

[Wik08b] Wikipedia. Voxel. http://en.wikipedia.org/wiki/Voxel. 2008.

Soft Body Simulation

63

- References [Wik08c]

Wikipedia. PlayStation 3. http://en.wikipedia.org/wiki/PlayStation_3. 2008.

[Wik08d] Wikipedia. Cell (microprocessor). http://en.wikipedia.org/wiki/ Cell_processor. 2008.

64

Okke Schrijvers, Playlogic Game Factory, 2008

Glossary  Cell

A cell is used in the soft body implementation to hold all information regarding the rendering of the original object.

Deformable body

A deformable body is an object which shape can change, if a force is applied. In the context of this report, deformable bodies retain their deformed shape and don’t return to their original shape. An example of such an object is a metal barrel.

Eigendecomposition

Eigendecomposition is the act of decomposing a matrix to get its eigenvalues and eigenvectors.

Flexible body

A flexible body is an object whose shape can change if a force is applied. When the force is removed, the body returns to its original shape. An example of such an object is a rubber duck.

Gameplay

The overall experience of playing a video game.

Integration

The act of updating the position and velocity of physics objects after a time step.

Jacobi rotations

Jacobi rotations are a way to retrieve eigenvalues and eigenvectors of a matrix.

Lattice

A lattice is a regular tiling of a space using primitive cells. This means that space is divided into equally shaped cells, which are then combined into a lattice. Lattices come in different variations, but the ones used in this report are rectangular lattices, meaning the cells are cubes.

Lattice vertex

A lattice vertex is the primitive cell, referred to at the lattice description. It is effectively one point inside the lattice. It doesn’t contain any physical properties, these are stored in a particle.

Least squares

Least squares is applied to a system of linear equations where there’s no solution, to find the optimal solution (the one that has the least squared distances).

the

Soft Body Simulation

65

- Glossary -

66

Linear velocity

The velocity of an object that only describes direction and speed. The rotational speed of an object is described in angular velocity.

Lua

A scripting language that can also be used to declare variables.

Material

The adjective material is used to indicate the initial value of a property, meaning the value of that property at t=0. For instance, the material position of a particle is the position the particle had at the beginning of the simulation.

Particle

A particle is the physical representation of a lattice vertex, with physical properties like position, velocity and mass.

Polar decomposition

Decomposing a matrix in a rotation matrix and a stretch matrix. It is analogous to the polar form of a complex number.

PPU

Power Processor Unit. The main processor of the Playstation 3.

Rigid body

A rigid body is an object that can’t change its shape. A rigid body doesn’t have to be an entire object. A person, for instance, can consist of multiple connected rigid bodies, to allow the person to move (rag-doll physics). An example of a rigid body is a baseball bat.

Scalar function

A function that returns a scalar.

Scene

An environment that can be rendered. This is what you actually see when playing a game.

Shape matching region

A shape matching region is a collection of connected particles in a lattice. The size of the region is dependent on its half-width value w.

Soft body

In the context of this report a soft body can either refer to a deformable, or a flexible body. In general, things like cloth, water or sand can also be considered as soft bodies.

Soft body dynamics

Soft body dynamics (also referred to as soft body physics) is an area of physics simulation which focuses on the simulation of deformable and flexible objects. This could also include the simulation of cloth, water, or sand.

Okke Schrijvers, Playlogic Game Factory, 2008

- Glossary -

SPU

Synergistic Processing Unit. Additional processor of the Playstation 3. There are eight on in each Playstation 3, while only five can be used.

Transpose

A matrix or vector that is mirrored along the main diagonal. The columns of the original matrix are the rows of the transposed vector.

Vertex

A point in n-dimensional space. Among other things, this is used to define a 3D model.

Soft Body Simulation

67