Most Helpful Customer Reviews
|
|
110 of 118 people found the following review helpful:
3.0 out of 5 stars
Does not deliver as promised, November 14, 2000
The title of this book and the back cover convinced me to buy this book on sight. "At last," I thought, "a book covering the dificult task of game engine architechture." I was very wrong. This book does a fair job of going one level deeper than the Game Programming Gurus series, or 3D Game programming by De Geos, or any of the hack retained mode Direct X books, but it does not come close to the full knowledge of Foley - Van Dam, or the Watt and Watt books. It is written at a math level that if you can easily understand it, you don't need it. This book, ignoring its title for a minute is a poor substitute for Real Time Rendering even at twice the thickness. It is more complicated than the two excellent books by the Watt brothers, 3D Computer Graphics and Advanced Animation and Rendering Techniques. It fails to explain architecture even remotely as well as Lakos' book Large Scale C++. In short it does a poor job at replicating what many books have done before.What it does do though, is expose a glaring hole in all the books relating to graphics programming and games in particular. There still is no good book on designing a game engine. I work in the industry, and while I've seen some briliant ideas on visual effects and performance gains, I have never seen an architecture that wouldn't have the lead programmer fired from any other industry. There is a need for what the title indicates, but the subject is contained in appendix A. The rest of the book is about culling and collisions and ray tracing and every other low level library function I could have gotten from a dozen books. There is massive amounts of source code. And while reasonably well written as a library, the whole is woefully lacking as a framework. This book should have been the other way around. We all have the libraries, how about a little discussion on the framework to hang them in.
|
|
|
15 of 15 people found the following review helpful:
3.0 out of 5 stars
You'd better know a *lot* of advanced math before starting, July 7, 2001
By A Customer
First off, the positives:1. Dr. Eberly is writing about a subject which has never really been dealt with at an intermediate or advanced level. "Game Programming For Dummies" this ain't. 2. The discussions and subjects tackled are top-notch. If you really want to know how a solid graphics engine works, aside from stealing the code to Quake 2 and sifting through it (not an easy read, I'm sure), this is the best place to begin. All sorts of advanced topics are touched upon, things you won't find in any other book. 3. The writing itself is quite good, especially considering the technical discussions involved. Sad to say, however, the book gets only rates average for the following reasons: 1. The mathematical understanding needed to make sense of much of the text is considerably more than the preface and some reviewers would have you think, and 2. For a 3D "Game Programming" book, there are damn few illustrations in parts. The math used in this book requires you to know a fair amount of later-semester calculus, to be very fresh on your advanced linear algebra, and to even know some statistics. Covariance matrices? They're in there. Those of you who took calculus a few years back and forgot some of it, or maybe had linear algebra as a freshman, are in for quite a surprise. And those who haven't taken many math classes, period, can save your $60 and just forget it. I don't disagree with anyone who says you need to know a lot of math in order to work with computer graphics, and 3D in general. Anyone tackling the subjects Dr. Eberly does had better know their stuff. It's just that a shameless plug by the author for his favorite math texts (or a better primer) might have helped a lot of readers get up to speed. Even if you've got enough of a math background to follow the technical discussions, the bigger problem is the lack of diagrams in the book. When you're talking about bounding volumes or collision detection, it really helps to be able to see a sample of what the author is talking about. Instead, all we get for much of the book is equation after equation, with no images to try and place things against. Whether this was Dr. Eberly's oversight, or the fault of the publisher is unimportant. The book in it's present form just won't do for any but those looking for a code tidbit, or your run-of-the mill PhD who likes to sketch out his own illustrations as he reads the text. The rest of us will have a hard time making use of it. It's too bad, considering it's strengths.
|
|
|
12 of 12 people found the following review helpful:
4.0 out of 5 stars
Useful and informative, but not to be used in isolation, December 5, 2000
This is a really good book, and is quite useful, but having read both the reviews here, & the "review on the reviews" on david's website i can say that there are some caveats. Cons-> 1) Lots of Math Yes, this true, there *IS* lots of math, and at times it can see overwhelming, but it's all useful, and david is right, if you think you can do 3d graphics engine programming without mathematics you're either delusional or on some drugs (and why aren't you sharing?) 2) No real explanations on most of the Math, or most of the rest of the methodologies either.. Ok, now (for me) *THIS* is the big one.. he gives you lots of different methodolgies, like using lozenges vs. capsules vs. AABB or OOBB for containing an a set of Vertices, but he doesn't give (from what i've seen) reasons as to *WHY* you'd want to prefer one technique over another, i mean, what's the advantage of using lozenge's to contain objects instead of using a OOBB or a k-DOP ? i get no such explanation, or even am attempt at one. This book is what i would call "faith-based 3d graphics programming", he doesn't tell you *HOW* the math works, or even *WHY* it works, or *WHEN* you should use it, but he expects you to just understand and accept it, thanks but no thanks david. Pros-> 1) Lots of Math What is bad is also good. David has taken mathematical concepts and equations from a couple dozen books and SIGGRAPH articles and condensed them into one book. And it's done pretty nicely. 2) *COPIOUS* amounts of C++ code The amount of code this book comes with (indexed in the book by the mathematical equations defining the code) is truly staggering. But i hear you say , "hey wait, he's got code on his website, why can't i just use THAT?!?!" .. and you'd be right there is code on his site, but (barring a few exceptions) there's no math there to explain that code, so if you dont' know why it's there, and what it all means, the code's useless to you.Also, the code on the site (and in part the book) is meant to be used as drop-ins, take code drop into existing project,and keep going, the code in the book can be compiled, and there exist examples on *USING* the code. The only question i have is his "branding" thing, i mean i have no problem with the Mgc prefix, but if you're going to do that David, and you're using C++, why not just encapsulate everything in a few namespaces? namespace Mgc { class Quaternion{}; }; //and etc.. now, i hear ppl saying that Real-Time Rendering is "better" .. well not quite, RTR has good explanations but there's little math or code there, my suggestion would be in most part read the books in unison(course in places where the topics don't overlap you'd have to find other explanations, or math/code).. the math in this book and the explanations in RTR (+ a few other books i suppose) .. overall high quality..
--vat
|
|
|
Most Recent Customer Reviews
|