on 11 February 2005
A few days ago, I found David Baraff's '97 Siggraph course notes - they're available for free download from his website (search Baraff on Google). I realised, as I leafed through them, that much of this book is just a complete rip-off of these notes. All the author has really added is a load of typos and some *seriously* bad explanations... this really deserves a paragraph of its own...
Now it's not often that a mathematical mind capable of this sort of explanation comes into being. I really don't know how he does it! But honestly, Dave is undeniably the worst maths writer I have *ever* come across, and this is after doing a maths degree. Now I know that maths can be hard to explain, but this is a disaster - there is sooo much irrelevant information, but you can't skip any of it because it's always mixed with important stuff (which is impossible to find without reading everything). This is made particularly poignant by the fact that Baraff is Eberly's very antithesis - his explanations are lucid and crystal clear. Note that I make these criticisms not only on the basis of this book, but also after reading Eberly's "Geometric Tools for Computer Graphics", for which I notice there are already some slightly scathing reviews in existence.
One thing that particularly gets my goat with this book is that the physics engine Eberly develops, he claims, guarantees non-penetration of objects (p280). But then he goes and makes approximations in the collision detection phase which violate this!!! Specifically, the collision detection he describes only takes account of linear velocity - rotational movements during a time step are applied as an afterthought (see p343), and allow for objects to becomes locked together. Also, throughout the book he analyses in terms of real numbers (rather than floating point numbers) including testing for "boundary intersection" (i.e. when two objects intersect *only* at their boundaries) as a separate event from interpenetration. But obviously, when time is discretised and numbers are floating point, one simply cannot deal with things in this way - it's like testing one f.p. number being exactly equal to another. I really can't believe this oversight! Overall, the book has a feel of each chapter being completely independent and unaware of the others, as though they're all plagarised from different papers without any consideration of continuity or interdependence.
To be fair, there are one or two things that this book has going for it. There's a chapter which explains the absolute basics of pixel shading (albeit now out-of-date) and mentions a few examples of how to use it for some optical effects, but no real explanations are given - you're left to read the source on the CD. And there's enough about collision detection to get you started, but if you're serious about it you'll need to (guess what?!) buy another book in his Series in Interactive 3D Technology (specifically "Collision Detection in Interactive 3D Environments").
Anyway, when I bought this book a few months ago, it was because I wanted to know about how to do collision detection and response in games. I write this review because I *wish* I had known that the relevant information was available on the web for free before I forked out over £30. Take a look at Baraff's papers, and their references (which you'll mostly be able to download for free from ACM or CiteSeer - search for these sites on Google). Not only will you get the info you need, you'll also get a feel for how to read research papers, if you don't already (it's no harder than reading books, just slightly more focussed). Eberly has literally contributed less-than-nothing with this book - the only section worth reading is the bibliography.
on 30 September 2004
I've just finished a maths and computer science course, and have been programming in C, C++ and Java for the last 5-10 years. I wanted to learn about collision detection and response, so I bought this book.
Firstly, I was certainly not disappointed. This book covers these topics very well, and giving enough detail for you to go away and start implementing. It opens up plenty of avenues for thought as well.
However, there are a few criticisms. Even with a maths degree (I didn't do much mechanics, though) I found the maths pretty hard going. To make matters worse, there is a lot of physics information that's pretty much irrelevant, or could have been covered much more concisely. Also, there are quite a few mistakes (usually just typos) in explanations and formulas. If you're paying attention, you'll spot them, and there is an errata list on the website.
The book contains a token chapter on optics (i.e. physically realistic graphics effects) but the explanations are weak and rushed, covering only the bare minimum, and leaving you to investigate the source on the CD.
However, I don't want to give the impression that this is a bad book. Overall, I'm proud to own it, and truly cherish it's advice. Once you've worked your way through the unnecessary preliminaries, it's an enthralling and inspiring read, and contains enough detail for you to go away and code. I would highly recommend this book to anyone with a strong mathematical background who is interested in physics modelling in games.
on 2 March 2004
Dave Eberly has carved out a reputation as an author of serious books for the serious business of game development. None of his titles fall into the trap of being really simple (and therefore wrong), but they give a solid grounding in the maths and coding of the subject.
This book is no different. Real-time physics is hard, and Dave's book is the first time I've seen many of the techniques brought down to the level of mere mortal understanding.
Having said all this, the math is hard. You'll not get far with this book if you aren't reasonably comfortable with linear algebra, matrices and calculus (but you'll get nowhere writing a physics engine without those things either). The diagrams help understanding, and Dave's text is as readable as ever. The equations and source code are up to an extremely high standard, which is so rare in game development texts.
Dave covers a range of different physics solutions, and here is my only criticism. To my knowledge only a couple of his approaches are used by developers to build games. In particular only about 25% of the book covers material that I have seen in used in real game projects. Maybe he is trying to introduce the other 75% to developers, I don't know but it didn't strike me as stuff I'm going to need. But while the practical 25% would be worth the cover price (it isn't covered in any other book), it is a shame that the other 75% didn't get slimmed in its favour.
Working in the industry, I know Dave's books are respected and find their way onto many programmers desks. This will join his graphics texts, despite its minor shortcoming.