Gift Guide

Game Physics Engine Development: How to Build a Robust Commercial-Grade Physics Engine for your Game / Edition 2

Paperback (Print)
Buy New
Buy New from
Used and New from Other Sellers
Used and New from Other Sellers
from $46.58
Usually ships in 1-2 business days
(Save 16%)
Other sellers (Paperback)
  • All (10) from $46.58   
  • New (8) from $46.58   
  • Used (2) from $49.42   


Physics is really important to game programmers who need to know how to add physical realism to their games. They need to take into account the laws of physics when creating a simulation or game engine, particularly in 3D computer graphics, for the purpose of making the effects appear more real to the observer or player.The game engine needs to recognize the physical properties of objects that artists create, and combine them with realistic motion.

The physics ENGINE is a computer program that you work into your game that simulates Newtonian physics and predict effects under different conditions. In video games, the physics engine uses real-time physics to improve realism.

This is the only book in its category to take readers through the process of building a complete game-ready physics engine from scratch. The Cyclone game engine featured in the book was written specifically for this book and has been utilized in iPhone application development and Adobe Flash projects. There is a good deal of master-class level information available, but almost nothing in any format that teaches the basics in a practical way. The second edition includes NEW and/or revised material on collision detection, 2D physics, casual game physics for Flash games, more references, a glossary, and end-of-chapter exercises. The companion website will include the full source code of the Cyclone physics engine, along with example applications that show the physics system in operation.

Read More Show Less

Editorial Reviews

From the Publisher

Praise for 1st edition:

"The first game physics book to emphasize building an actual engine...his book fills a gap by demonstrating how you actually build a physics engine." - Dave Eberly, President, Geometric Tools.

"A competent programmer with sufficient mathematical sophistication could build a physics engine just from the text and equations--even without the accompanying source code. You can't say this about a lot of books!" - Philip J. Schneider, Industrial Light & Magic.

Read More Show Less

Product Details

  • ISBN-13: 9780123819765
  • Publisher: Taylor & Francis
  • Publication date: 8/29/2010
  • Edition number: 2
  • Pages: 552
  • Sales rank: 805,775
  • Product dimensions: 7.50 (w) x 9.10 (h) x 0.80 (d)

Meet the Author

Ian Millington is a partner of IPR Ventures, a consulting company developing next-generation AI technologies for entertainment, modeling, and simulation. Previously he founded Mindlathe Ltd, the largest specialist AI middleware company in computer games, working with on a huge range of game genres and technologies. He has a long background in AI, including PhD research in complexity theory and natural computing. He has published academic and professional papers and articles on topics ranging from paleontology to hypertext.
Read More Show Less

Read an Excerpt


How to Build a Robust Commercial-Grade Physics Engine for your Game

Morgan Kaufmann Publishers

Copyright © 2010 Elsevier Inc.
All right reserved.

ISBN: 978-0-12-381977-2

Chapter One


Physics is a hot topic in computer games. No self-respecting action game can get by without a good physics engine, and the trend has recently spread through other genres, including strategy games and puzzles. This growth has been largely fueled by middleware companies offering high-powered physics simulation. Most high-profile games now feature commercial physics engines.

But commercial packages come at a high price, and for a huge range of developers building a custom physics solution can be better, as it can be cheaper, provide more control, and be more flexible. Unfortunately, physics is a topic shrouded in mystery, mathematics, and horror stories.

When I came to build a general physics engine in 2000, I found that there was almost no good information available, almost no code to work from, and lots of contradictory advice. I struggled through and built a commercial engine, and learned a huge amount in the process. Over the last 10 years I've applied my own engine and other commercial physics systems to a range of real games. Almost a decade of effort and experience is contained in this book.

There are other books, websites, and articles on game physics, much of it quite excellent. But there is still almost no reliable information on building a physics engine from scratch—a complete simulation technology that can be used in game after game. This book aims to step you through the creation of a physics engine. It goes through a sample physics engine (provided on the CD), as well as giving you insight into the design decisions that were made in its construction. You can use the engine as is, use it as a base for further experimentation, or make various design decisions and create your own system under the guidance that this book provides.

1.1 What Is Game Physics?

Physics is a huge discipline, and academic physics has hundreds of subfields. Each describes some aspect of the physical world, from the way light works to the nuclear reactions inside a star.

Lots of these areas of physics might be useful in games. We could use optics, for example, to simulate the way light travels and bounces, and use to make great-looking graphics. This is the way ray tracing works, and (although it is still very slow compared to other approaches) it has been used in several game titles. Although these areas are part of academic physics, they are not part of what we mean by game physics and I won't consider them in this book.

Other bits of physics have a more tenuous connection with games. I cannot think of a use for nuclear physics simulation in a game, unless the nuclear reactions were the whole point of the game play.

When we talk about physics in a game, we really mean classical mechanics, that is, the laws that govern how large objects move under the influence of gravity and other forces. In academic physics these laws have largely been superceded by relativity and quantum mechanics. Almost all of the physics described in this book has long since stopped being an active area of research; all the results we'll be relying on were settled before the turn of the twentieth century.

In games, classical mechanics is used to give game objects the feel of being solid things, with mass, inertia, bounce, and buoyancy.

Game physics has been around almost since the first games were written. It was first seen in the way particles move: the ballistics of bullets, sparks, fireworks, smoke, and explosions. Physics simulation has also been used to create flight simulators for nearly three decades. Next came automotive physics, with ever-increasing sophistication of tire, suspension, and engine models.

As processing power became available, we saw crates that could be moved around or stacked, and walls that could be destroyed and crumble into their constituent blocks. This is rigid-body physics, which rapidly expanded to include softer objects: clothes, flags, and rope. Then came the rise of the ragdoll: a physical simulation of the human skeleton that allows more realistic trips, falls, and death throes. And recently we've seen a lot of effort focused on simulating fluid flow: water, fire, and smoke.

In this book we'll cover a representative sample of physics tasks. With a gradually more comprehensive technology suite, our physics engine will support particle effects, flight simulation, car physics, crates, destructible objects, cloth, and ragdolls, along with many other effects.

1.2 What Is a Physics Engine?

Although physics in games is more than 30 years old, there has been a distinct change in recent years in the way that physics is implemented. Originally, each effect was programmed for its own sake, creating a game with only the physics needed for that title. If a game needed arrows to follow trajectories, then the equation of the trajectory could be programmed into the game. It would be useless for simulating anything but the trajectory of arrows, but it would be perfect for that.

This is fine for simple simulations, where the amount of code is small and the scope of the physics is quite limited. As we'll see, a basic particle system can be programmed in only a hundred lines or so of code. But directly implementing phyical behavior becomes a difficult task as the complexity increases.

In the original Half-Life game, for example, you can push crates around, but the physics code isn't quite right, and the way crates move looks odd. The difficulty of getting physics to look good, combined with the need for almost the same effects in game after game encouraged developers to look for general solutions that could be reused.

Resuable technology needs to be quite general: a ballistics simulator that will only deal with arrows can have the behavior of arrows hard coded into it. If the same code needs to cope with bullets too, then the software needs to abstract away from particular projectiles and simulate the general physics that they all have in common. This is what we call a physics engine: a common piece of code that knows about physics in general, but isn't programmed with the specifics of each game.

This leaves us with a gap. If we have special code for simulating an arrow, then we need nothing else in order to simulate an arrow. If we have a general physics engine for simulating any projectile, and we want to simulate an arrow, we also need to tell the engine the characteristics of the thing we are simulating. We need the physical properties of arrows, or bullets, or crates, and so on.

This is an important distinction. The physics engine is basically a big calculator: it does the mathematics needed to simulate physics. But it doesn't know what needs to be simulated. In addition to the engine we also need game-specific data that represents the objects in our level.

Although we'll look at the kind of data we need throughout this book, I won't focus on how the data gets into the game. In a commercial game, there will likely be some kind of level-editing tool that allows level designers to place crates, flags, ragdolls, or aeroplanes to set their weight, the way they move through the air, their buoyancy, and so on. For a physics engine drivinga flight simulator, the data may have to be acquired from real aircraft capabilities. For simpler games, it may be hardcoded somewhere in the source code.

The physics engine we'll be developing throughout this book needs gradually more and more datato drive it. I'll cover in depth what kind of data this is, and reasonable values it can take, but for our purposes we will assume this data can be provided to the engine. It is beyond the scope of the book to consider the tool chain that you will use to author these properties for the specific objects in your game.

1.2.1 Advantages of a Physics Engine

There are two compelling advantages for using a physics engine in your games. First, there is the time savings. If you intend to use physics effects in more than one game (and you'll probably be using them in most of your games from now on), then putting the effort into creating a physics engine now pays off when you can simply import it into each new project. A lightweight, general-purpose physics system, of the kind we develop in this book, doesn't have to be difficult to program either. A couple of thousand lines of code will set you up for most of the game effects you need.

The second reason is quality. You will most likely be including more and more physical effects in your game as time goes on. You could implement each of these as you need it, such as building a cloth simulator for capes and flags, and a water simulator for floating boxes, and a separate particle engine. Each might work perfectly, but you would have a very hard time combining their effects. When the character with a flowing cloak comes to stand in the water, how will her clothes behave? If they keep blowing in the wind even when underwater, then the illusion is spoiled.

A physics engine provides you with the ability to have effects interact in believable ways. Remember the moveable crates in Half-Life 1? They formed the basis of only one or two puzzles in the game. When it came to Half-Life 2, crate physics was replaced by a full physics engine. This opens up all kinds of new opportunities. The pieces of a shattered crate float on water, objects can be stacked and used as moveable shields, and so on.

It's not easy to create a physics engine to cope with water, wind, and clothes, but it's much easier than trying to take three separate ad-hoc chunks of code and make them look good together in all situations.

1.2.2 Weaknesses of a Physics Engine

This isn't to say that a physics engine is a panacea. There are reasons that you might not want to use a full physics engine in your game.

The most common reason is speed. A general-purpose physics engine is quite processor-intensive. Because it has to be general, it can make no assumptions about the kinds of objects it is simulating. When you are working with a very simple game environment, this generality can mean wasted processing power. This isn't an issue on modern consoles or the PC, but on handheld devices such as phones and PDAs, it can be significant. You could create a pool game using a full physics engine on a PC, but the same game on a mobile phone would run faster with some specialized pool physics.

The need to provide the engine with data can also be a serious issue. In a game that I worked on we needed no physics other than flags waving in the wind. We could have used a commercial physics engine (one was available to the developer), but the developer would need to have calculated the properties of each flag, its mass, springiness, and so on. This data would then need to be fed into the physics engine to get it to simulate the flags.

There was no suitable level-design tool that could be easily extended to provide this data, so instead we created a special bit of code just for flag simulation, the characteristics of flags were hardcoded in the software, and the designer needed to do nothing special to support it. We avoided using a physics engine because special-case code was more convenient.

A final reason to avoid physics engines is scope. If you are a one-person hobbyist working on your game in the evenings, then developing a complete physics solution might take your time away from improving other aspects of your game, such as the graphics or game play. Or worse, it might distract you from finishing, releasing, and promoting your game. On the other hand, even amateur games need to compete with commercial titles for attention, and top-quality physics is a must for a top-quality title of any kind.

1.3 Approaches to Physics Engines

There are several different approaches to building a physics engine. From the very simple (and wrong) to the cutting-edge physics engines of top middleware companies. Creating a usable engine means balancing the complexity of the programming task with the sophistication of the effects you need to simulate.

There are a few broad distinctions we can make to categorize different approaches.

1.3.1 Types of Objects

The first distinction is between engines that simulate full rigid bodies or so-called "mass aggregate" engines. Rigid-body engines treat objects as a whole, and work out the way they move and rotate. A crate is a single object, and can be simulated as a whole. Mass aggregate engines treat objects as if they were made up of lots of little masses. A box might be simulated as if it were made up of eight masses, one at each corner, connected by rods.

Mass aggregate engines are easier to program because they don't need to understand rotations. A large amount of effort is needed to support rotations, and it forms a sizable chunk of this book. Mass aggregate engines treat each mass as if it were located at a single point, and the equations of motion can be expressed purely in terms of linear motion. The whole object rotates naturally as a result of the connections between masses.

Because it is very difficult to make things truly rigid in a physics engine, it is difficult to make really firm objects in a mass aggregate system. Our eight-mass crate will have a certain degree of flex in it. To avoid this being visible to the player, extra code is needed to reconstruct the rigid box from the slightly springy set of masses. While the basic mass aggregate system is very simple to program, these extra checks and corrections are more hit and miss, and very quickly the engine becomes a mess of fixes and ugly code.

Fortunately, we can extend a mass aggregate engine into a full rigid-body system, simply by adding rotations. In this book, we will develop a mass aggregate physics engine on the way to a full rigid-body physics engine. Because we are heading for a more robust engine, I won't spend the time creating the correction code for springy aggregates.

1.3.2 Contact Resolution

The second distinction involves the way in which touching objects are processed. As we'll see in this book, a lot of the difficulty in writing a rigid-body physics engine is simulating contacts—locations where two objects touch or are connected. This includes objects resting on the floor, objects connected together, and, to some extent, collisions.

One approach is to handle these contacts one by one, making sure each works well on its own. This is called the "iterative" approach and it has the advantage of speed. Each contact is fast to resolve, and with only a few tens of contacts, the whole set can be resolved quickly. It has the downside that one contact can affect another, and sometimes these interactions can be significant. This is the easiest approach to implement, and can form the basics of more complex methods. It is the technique we will use in the engine in this book.

A more physically realistic way is to calculate the exact interaction between different contacts and calculate an overall set of effects to apply to all objects at the same time. This is called a "Jacobian-based" approach, but it is very time consuming. The mathematics needed to process the Jacobian is very complex, and solving the equations can involve millions of calculations. In some cases there is simply no valid answer and the developer needs to add special code to fall back on when the equations can't be solved. Most physics middleware packages andseveral open-source physics engines use this approach, and each has its own techniques for solving the equations and dealing with inconsistencies.

A third option is to calculate a set of equations based on the contacts and constraints between objects. Rather than use Newton's laws of motion, we can create our own set of laws for the specific configuration of objects we are dealing with. These equations will change from frame to frame, and most of the effort for the physics engine goes into creating them (even though solving them is no picnic either). This is called a "reduced coordinate" approach. Some physics systems have been created with this approach, and it is the most common one used in engineering software to achieve really accurate simulation. Unfortunately, it is very slow, and isn't very useful in games, where speed and believability are more important than accuracy.

We'll return to the Jacobian and reduced coordinate approaches in Chapter 20, after we've looked at the physics involved in the first approach.


Excerpted from GAME PHYSICS ENGINE DEVELOPMENT by IAN MILLINGTON Copyright © 2010 by Elsevier Inc.. Excerpted by permission of Morgan Kaufmann Publishers. All rights reserved. No part of this excerpt may be reproduced or reprinted without permission in writing from the publisher.
Excerpts are provided by Dial-A-Book Inc. solely for the personal use of visitors to this web site.

Read More Show Less

Table of Contents

List Of Figures

Preface To The Second Edition

Preface To The First Edition


About The Author

Chapter 1 Introduction 1

1.1 What Is Game Physics? 2

1.2 What Is A Physics Engine? 2

1.2.1 Advantages Of A Physics Engine 3

1.2.2 Weaknesses Of A Physics Engine 4

1.3 Approaches To Physics Engines 5

1.3.1 Types Of Objects 5

1.3.2 Contact Resolution 6

1.3.3 Impulses And Forces 6

1.3.4 What We're Building 7

1.4 The Mathematics Of Physics Engines 8

1.4.1 The Math You Need To Know 8

1.4.2 The Math We'll Review 9

1.4.3 The Math I'll Introduce 10

1.5 The Source Code In The Book 10

1.6 How The Book Is Structured 11

1.6.1 Exercises And Projects 12

Part I Particle Physics 15

Chapter 2 The Mathematics Of Particles 17

2.1 Vectors 17

2.1.1 The Handedness Of Space 21

2.1.2 Vectors And Directions 23

2.1.3 Scalar And Vector Multiplication 25

2.1.4 Vector Addition And Subtraction 27

2.1.5 Multiplying Vectors 29

2.1.6 The Component Product 30

2.1.7 The Scalar Product 31

2.1.8 The Vector Product 33

2.1.9 The Orthonormal Basis 37

2.2 Calculus 38

2.2.1 Differential Calculus 38

2.2.2 Integral Calculus 43

2.3 Summary 44

2.4 Exercises 45

Chapter 3 The Laws Of Motion 47

3.1 The Particle 48

3.2 The First Two Laws 49

3.2.1 The Force Equations 50

3.2.2 Adding Mass To Particles 51

3.2.3 Momentum And Velocity 52

3.2.4 The Force Of Gravity 53

3.3 The Integrator 55

3.3.1 The Update Equations 55

3.3.2 The Complete Integrator 57

3.4 Summary 58

3.5 Exercises 59

Chapter 4 The Particle Physics Engine 61

4.1 Ballistics 61

4.1.1 Setting Projectile Properties 62

4.1.2 Implementation 63

4.2 Fireworks 66

4.2.1 The Fireworks Data 66

4.2.2 Firework Rules 67

4.2.3 The Implementation 69

4.3 Summary 73

4.4 Projects 73

Part II Mass Aggregate Physics 75

Chapter 5 Adding General Forces 77

5.1 D'alembert's Principle 77

5.2 Force Generators 80

5.2.1 Interfaces And Polymorphism 81

5.2.2 Implementation 81

5.2.3 A Gravity Force Generator 84

5.2.4 A Drag Force Generator 85

5.3 Built-In Gravity And Damping 87

5.4 Summary 87

5.5 Exercises 88

Chapter 6 Springs And Spring-Like Things 89

6.1 Hook's Law 89

6.2 Spring-Like Force Generators 92

6.2.1 A Basic Spring Force Generator 92

6.2.2 An Anchored Spring Generator 94

6.2.3 An Elastic Bungee Generator 96

6.2.4 A Buoyancy Force Generator 98

6.3 Stiff Springs 101

6.3.1 The Stiff Springs Problem 102

6.3.2 Faking Stiff Springs 104

6.4 Summary 110

6.5 Exercises 110

Chapter 7 Hard Constraints 113

7.1 Simple Collision Resolution 113

7.1.1 The Closing Velocity 114

7.1.2 The Coefficient Of Restitution 115

7.1.3 The Collision Direction And The Contact Normal 115

7.1.4 Impulses 117

7.2 Collision Processing 118

7.2.1 Collision Detection 121

7.2.2 Resolving Interpenetration 123

7.2.3 Resting Contacts 126

7.3 The Contact Resolver Algorithm 130

7.3.1 Resolution Order 131

7.3.2 Time-Division Engines 135

7.4 Collision-Like Things 136

7.4.1 Cables 137

7.4.2 Rods 140

7.5 Summary 142

7.6 Exercises 142

Chapter 8 The Mass Aggregate Physics Engine 145

8.1 Overview Of The Engine 145

8.2 Using The Physics Engine 151

8.2.1 Rope Bridges And Cables 151

8.2.2 Friction 152

8.2.3 Blob Games 153

8.3 Summary 153

8.4 Projects 154

Part III Rigid-Body Physics 155

Chapter 9 The Mathematics Of Rotations 157

9.1 Rotating Objects In 2d 158

9.1.1 The Mathematics Of Angles 158

9.1.2 Angular Speed 159

9.1.3 The Origin And The Center Of Mass 160

9.2 Orientation In 3d 165

9.2.1 Euler Angles 165

9.2.2 Axis-Angle 167

9.2.3 Rotation Matrices 168

9.2.4 Quaternions 169

9.3 Angular Velocity And Acceleration 172

9.3.1 Velocity Of A Point 173

9.3.2 Angular Acceleration 173

9.4 Implementing The Mathematics 173

9.4.1 The Matrix Classes 174

9.4.2 Matrix Multiplication 175

9.4.3 Matrix Inverse And Transpose 184

9.4.4 Converting A Quaternion To A Matrix 191

9.4.5 Transforming Vectors 193

9.4.6 Changing The Basis Of A Matrix 197

9.4.7 The Quaternion Class 198

9.4.8 Normalizing Quaternions 200

9.4.9 Combining Quaternions 200

9.4.10 Rotating 201

9.4.11 Updating By The Angular Velocity 202

9.5 Summary 203

9.6 Exercises 203

Chapter 10 Laws Of Motion For Rigid Bodies 207

10.1 The Rigid Body 207

10.2 Newton-2 For Rotation 211

10.2.1 Torque 211

10.2.2 The Moment Of Inertia 213

10.2.3 Inertia Tensor In World Coordinates 216

10.3 D'alembert For Rotation 220

10.3.1 Force Generators 223

10.4 The Rigid-Body Integration 226

10.5 Summary 228

10.6 Exercises 228

Chapter 11 The Rigid-Body Physics Engine 231

11.1 Overview Of The Engine 231

11.2 Using The Physics Engine 234

11.2.1 A Flight Simulator 234

11.2.2 A Sailing Simulator 242

11.3 Summary 247

11.4 Projects 248

Part IV Collision Detection 251

Chapter 12 Collision Detection 253

12.1 The Collision Detection Pipeline 254

12.2 Broad-Phase Collision Detection 255

12.2.1 Requirements 256

12.3 Bounding Volume Hierarchies 257

12.3.1 Hierarchies 259

12.3.2 Building The Hierarchy 266

12.3.3 Subobject Hierarchies 275

12.4 Spatial Partitioning 276

12.4.1 Binary Space Partitioning 276

12.4.2 Oct-Trees And Quad-Trees 281

12.4.3 Grids 283

12.4.4 Multiresolution Maps 287

12.5 Summary 288

12.6 Exercises 288

Chapter 13 Generating Contacts 291

13.1 Collision Geometry 292

13.1.1 Primitive Assemblies 293

13.2 Contact Generation 294

13.2.1 Contact Types 295

13.2.2 Contact Data 298

13.2.3 Vertex face Contacts 300

13.2.4 Edge -Edge Contacts 301

13.2.5 Edge face Contacts 301

13.2.6 Face face Contacts 302

13.2.7 Testing Before Generating Contacts 303

13.3 Simple Collision Algorithms 304

13.3.1 Colliding Two Spheres 305

13.3.2 Colliding A Sphere And A Plane 307

13.3.3 Colliding A Box And A Plane 310

13.3.4 Colliding A Box And A Sphere 315

13.4 Separating Axis Tests 319

13.4.1 Generating Contact Data With SATS 320

13.4.2 Colliding Two Boxes 322

13.4.3 Colliding Convex Polyhedra 326

13.5 Coherence 328

13.6 Summary 331

13.7 Exercises 331

Part V Contact Physics 333

Chapter 14 Collision Resolution 335

14.1 Impulse And Impulsive Torque 335

14.1.1 Impulsive Torque 336

14.1.2 Rotating Collisions 338

14.1.3 Handling Rotating Collisions 339

14.2 Collision Impulses 340

14.2.1 Change To Contact Coordinates 340

14.2.2 Velocity Change By Impulse 347

14.2.3 Impulse Change By Velocity 351

14.2.4 Calculating The Desired Velocity Change 351

14.2.5 Calculating The Impulse 353

14.2.6 Applying The Impulse 353

14.3 Resolving Interpenetration 355

14.3.1 Choosing A Resolution Method 355

14.3.2 Implementing Nonlinear Projection 359

14.3.3 Avoiding Overrotation 362

14.4 The Collision Resolution Process 364

14.4.1 The Collision Resolution Pipeline 365

14.4.2 Preparing Contact Data 367

14.4.3 Resolving Penetration 372

14.4.4 Resolving Velocity 379

14.4.5 Alternative Update Algorithms 381

14.5 Summary 384

14.6 Exercises 385

Chapter 15 Resting Contacts And Friction 387

15.1 Resting Forces 388

15.1.1 Force Calculations 389

15.2 Microcollisions 390

15.2.1 Removing Accelerated Velocity 392

15.2.2 Lowering The Restitution 393

15.2.3 The New Velocity Calculation 394

15.3 Types Of Friction 395

15.3.1 Static And Dynamic Friction 395

15.3.2 Isotropic And Anisotropic Friction 398

15.4 Implementing Friction 399

15.4.1 Friction As Impulses 400

15.4.2 Modifying The Velocity Resolution Algorithm 402

15.4.3 Putting It All Together 407

15.5 Friction And Sequential Contact Resolution 410

15.6 Summary 411

15.7 Exercises 412

Chapter 16 Stability And Optimization 413

16.1 Stability 413

16.1.1 Quaternion Drift 414

16.1.2 Interpenetration On Slopes 415

16.1.3 Integration Stability 417

16.1.4 The Benefit Of Pessimistic Collision Detection 419

16.1.5 Changing Mathematical Accuracy 420

16.2 Optimizations 421

16.2.1 Sleep 422

16.2.2 Margins Of Error For Penetration And Velocity 430

16.2.3 Contact Grouping 432

16.2.4 Code Optimizations 434

16.3 Summary 436

Chapter 17 Putting It All Together 437

17.1 Overview Of The Engine 437

17.2 Using The Physics Engine 439

17.2.1 Ragdolls 440

17.2.2 Fracture Physics 445

17.2.3 Explosive Physics 451

17.3 Limitations Of The Engine 458

17.3.1 Stacks 458

17.3.2 Reaction Force Friction 458

17.3.3 Joint Assemblies 459

17.3.4 Stiff Springs 459

17.4 Summary 459

17.5 Projects 459

Part VI Further Topics In Physics 461

Chapter 18 Physics In Two Dimensions 463

18.1 2d Or 3d? 463

18.2 Vector Mathematics 465

18.3 Particle And Mass Aggregate Physics 467

18.4 The Mathematics Of Rotation 467

18.4.1 Representing Rotation 467

18.4.2 Matrices 469

18.5 Rigid-Body Dynamics 469

18.6 Collision Detection 471

18.6.1 Vertex edge Contacts 472

18.6.2 Edge edge Contacts 472

18.6.3 Contact Generation 472

18.7 Collision Response 473

18.8 Summary 473

18.9 Projects 474

Chapter 19 Other Programming Languages 475

19.1 Actionscript 3 475

19.2 C 479

19.3 Java 480

19.4 C# 481

19.5 Other Scripting Languages 482

Chapter 20 Other Types Of Physics 483

20.1 Simultaneous Contact Resolution 483

20.1.1 The Jacobian 484

20.1.2 The Linear-Complementarity Problem 485

20.2 Reduced Coordinate Approaches 488

20.3 Summary 489

Appendix A Useful Inertia Tensors 491

A.1 Discrete Masses 492

A.2 Continuous Masses 492

A.3 Common Shapes 493

A.3.1 Cuboid 493

A.3.2 Sphere 493

A.3.3 Cylinder 494

A.3.4 Cone 494

A.3.5 Hemisphere 495

A.4 Moments Of Inertia In 2d 495

A.4.1 Common 2d Shapes 495

Appendix B Useful Friction Coefficients 497

Appendix C Mathematics Summary 499

C.1 Vectors 499

C.2 Quaternions 500

C.3 Matrices 501

C.4 Integration 502

C.5 Physics 503

C.6 Other Formulas 504

Glossary 505

Bibliography 509

Index 511

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star


4 Star


3 Star


2 Star


1 Star


Your Rating:

Your Name: Create a Pen Name or

Barnes & Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation


  • - By submitting a review, you grant to Barnes & and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Terms of Use.
  • - Barnes & reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously

    If you find inappropriate content, please report it to Barnes & Noble
    Why is this product inappropriate?
    Comments (optional)