software design

My interest is physics and physics simulations, not gaming per se...so my observations should be viewed in that light.

The main problem with this book is the treatment is incomplete, superficial, or just wrong (from a physics/math point of view), and the typical programmer/computer scientist is not likely to know it. I am reminded of the great fluid dynamicist von Karmen's definition of an engineer as that person who perpetuates the mistakes made by the previous generation. The REASON a game programmer can get away with this is that he is not testing his results by real experiment...his world is a computer generated simulation with arbitrary approximations to physical laws that the programmer deems to impose.

The other problem is that there are usually a multitude of techniques that one can pick to solve a given mechanics problem...and what would have been really valuable is if the author had shown why a particular method is better (for example, Newton's Laws vs. Lagrange's Equations) when the time comes to code the algorithm. We are not looking for Eberly primarily to teach us physics (but if he makes the attempt, it should be correct!)-that is always going to be the job of physics courses. Instead, he needs to tell us which method is useful for coding and why-this, sadly, he has not done.

As an illustration of what I mean...look at how Petzold in 'Programming Windows with C#' discuss the elementary process of using GDI+ to draw a curve. There are two approaches, using rectangular coordinates, or using parametric equations (polar coordinates). Petzold explains WHY the parametric approach is superior from a programming point of view.

Any advanced sophomore or junior physics student will know most of the physics presented here (classical mechanics)...but in addition, they will also know the CORRECT statement of conservation of angular momentum (the author got it wrong) ...AND they will have a deeper understanding, because they will have likely studied something like Marion's Classical Dynamics which is rigorous and physical. Especially egregious is Eberly's twice incorrectly defining an inertial reference frame. In classical mechanics, an inertial reference frame is one in which Newton's laws are valid.

Same comment for the math...The math is maybe sophomore/junior level (except for the Quaternions)...but it is not rigorous nor is it motivated, and sometimes it is wrong. Compare Eberly's terse treatment of the delta function with Marion's motivated and physical discussion. Also, we see things like interchange of limits and integration, without explaining when this is mathematically legal. Then there is the unmotivated vector spaces treatment. Eberly goes to the effort to define a field, but then restricts his definition of a vector space to having real coefficients...Then why bother defining fields if you are not going to use them. We are given the mathematician's definition of the determinant (i.e., the unique, alternating, n-linear function with identity) but this is completely useless from a computational view! If Eberly wants to present some advanced linear algebra, then some tensor analysis would have served the game programmer better, as it is often used in continuum mechanics and fluids, neither of which are discussed by the author. He had a perfect opportunity in the Affine Algebra chapter when he stumbles upon the Levi-Civita tensor, which he then dismisses as unimportant! The Affine Algebra chapter is really bad from both a physics and a geometry view. First, a physicist does not think of a vector as something with direction and magnitude, and a geometer is more inclined to think of them as a derivation. Second, affine spaces are too weak a tool to use to distinuish points from vectors, though we do mod out the origin..this really needs a manifold with vector fields and parallel translation. Third, linear algebra is the study of vector spaces and isomorphism.

There is a chapter on numerical methods, but again incomplete! We should have at least got Numerov's method and some Monte Carlo techniques.

The chapter on shading is ridiculous from a physics point of view. Essentially we have Snell's law, and a cursory reference to Fresnel and that's it...Evidently, the author was not up to discussing some real physics ala Maxwell. Why spend so much time on classical mechanics, and then almost totally dismiss optics with a non-physical discussion? We don't even get Huygens principal. But we do get a wrong definition of polarization of light.Thankfully, he did not try to define helicity.

In summary, this book has two uses:
1) It presents a list of physics and some numerical methods which the game programmer will find useful, and which he will then go ELSEWHERE to actually learn. (I can recommend Landau (of OSU, not Russia) "Computational Physics" and also the CUPS Physics Simulations books for excellent starters.)
2) There is the happy possibility that a budding game programmer, in his pursuit of the knowledge to build a better computer game, will discover the much more interesting game called Physics.

Undoubtedly this is a must-have for people who are serious about developing real-time computer graphics simulations with physically based modeling.

This book can be compared with Coutinho's "Dynamic Simulations of Multibody Systems". I believe the latter covers more materials, but Eberly's is easier to read. The book would be almost sufficient if you also have his previous book "3D Game Engine Design".

I am not sure why the author wrote chapter 4 and 6. I suppose these can be left out. It would have been more compact.

Escrito para prefesores !
No es un libro que explique las cosas "con manzanitas".