OpenGL SuperBible 5th ed. 98
asgard4 writes "OpenGL SuperBible in its fifth edition is almost a complete rewrite. The authors threw out the discussion of old-style, fixed-function programming and replaced it with an introduction to OpenGL that is exclusively focused on using shaders from the very beginning. All the things that got deprecated with the advent of OpenGL 3 got removed, making it a more relevant and up-to-date book than the previous editions. The OpenGL SuperBible still strives to be the 'world's best introduction to OpenGL' according to the authors. Let's see if it can keep that promise." Read on for the rest of Martin's review.
With the removal of the fixed-function pipeline, the OpenGL SuperBible is no longer quite the heavy-weight it used to be. It shrunk from more than 1200 to about 970 pages, which is not necessarily a bad thing. The book starts out with a basic introduction to 3D graphics, coordinate systems, and some basic math concepts, followed by short rundown of the history of OpenGL and a first little example program that renders a triangle. The authors even provide instructions on how to setup the C/C++ projects to build the example on Windows and MacOS. The writing is to the point but still verbose enough to easily follow the text. The authors analyze the example program in detail making it easy for a beginner to follow and understand the code. Overall, I really like the writing style and the flow of the book.| OpenGL SuperBible (Fifth Edition) | |
| author | Richard S. Wright, Jr., Nicholas Haemel, Graham Sellers, Benjamin Lipchak |
| pages | 969 |
| publisher | Addison-Wesley Publishing http://www.awl.com |
| rating | 9/10 |
| reviewer | Martin Ecker |
| ISBN | 0-32-171261-7 |
| summary | : Quite possibly the best introduction to OpenGL 3.3 programming that focuses exclusively on graphics programming using shaders |
The next few chapters gradually introduce more and more OpenGL API functionality intermixed with new 3D graphics concepts, such as rendering points, lines, and polygons in various ways, alpha blending, how to use geometric transformations and projections, and how to move objects and the camera. Eventually, basic texture mapping is introduced with most of the basic things you need to know about the topic. In particular, specifying textures coordinates, sampling textures in the fragment shader, the various filtering modes (even anisotropic filtering), and texture compression are discussed. In a later chapter the authors do another deep dive into the topic of textures, in particular rectangle textures, cube maps, multitexturing, point sprites, and using texture arrays
Until this point the authors used haven't really talked much about shader programming yet. Most of the examples use simple pre-made shaders that don't really do much. This changes with chapter six titled "Nonstock Shaders" where we get a first glimpse of how to write our own shaders in GLSL, the OpenGL Shading Language. In particular, a fragment shader that uses a simple lighting model to light objects is developed.
After these introductory chapters presenting the basics of OpenGL programming, the next part of the book focuses on more advanced topics, beginning with buffer objects and how to use them to make your OpenGL programs run much more efficiently on modern hardware. Some of the examples presented in this part of the book include using render-to-texture to do reflections, tone mapping, and bloom. This part of the book closes with two fairly long chapters on advanced usage of the shader pipeline, in particular the transform feedback and the geometry shader stages. There is also some discussion on more advanced effects achievable with fragment shaders, in particular applying filters to images, such as a Gaussian blur or a Sobel filter. Finally, rendering geometry efficiently with vertex buffer objects and rendering many objects via geometry instancing is presented.
The final part of the book consists of 4 chapters explaining how to integrate OpenGL with the underlying operating system, in particular with Windows, Mac OS X, and Linux plus various other Unix flavors. The last chapter of this part of the book is about OpenGL ES, which is a version of OpenGL designed to be used especially on embedded system devices, in particular mobile phones and PDAs, to render real-time, interactive 3D graphics.
The book has a lot of images and diagrams throughout, though unfortunately not all of them are in color. There are however 24 color plates of the most interesting images in the middle of the book. The complete source code of the book, and even precompiled binaries for Windows and Mac OS X, can be downloaded from the book's webpage.
If you are new to both 3D graphics programming and OpenGL with a bit of C/C++ programming experience and you are eager to learn how to develop interactive programs with OpenGL, then this book is exactly right for you. The book is written in an easy to understand style without skimming the details (or even more advanced topics). It is the most comprehensive introduction to OpenGL that doesn't require a lot of previous knowledge I have seen to date. The decision to completely drop any discussion of the fixed-function pipeline turned out to be an excellent choice. Finally there is a book that no longer wastes the reader's time with the parts of OpenGL that nobody who does serious graphics development uses and instead presents up-to-date information on how to do 3D graphics on modern graphics hardware.
All in all, the OpenGL SuperBible in its fifth edition succeeds very well in keeping its promise to be the best introduction to OpenGL and 3D graphics programming. Even after you're done working your way through the main parts of the book you will always come back to the handy OpenGL API reference in the appendix of the book.
The review author has been involved in real-time graphics programming for more than 10 years and works as a professional game developer for High Moon Studios in sunny California.
You can purchase OpenGL SuperBible (Fifth Edition) from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Re:How about non-Windows and non-Mac? (Score:4, Interesting)
I'm just fed arguing with the "3D means DirectX games on Windows only" crowd. with Apple's ascent it is time for them to eat crow since their point-of-view was as sensible as the web-development "target IE6 only and forget about W3C compat" crowd (which was a battle we had to fight in the enterprise space as many "ohh, shiny" operations people have short-term horizons). This snideness is vindication and not intended to insult the sensitive, so please don't take it personally.
> 2) It's really not that hard to port a DirectX game to PS3 (I won't say OpenGL, since most PS3 games don't use OpenGL.) Dozens of games have already done that, including DirectX-supporting companies like Valve.
Huh? The official graphics API for the PS3 at the lowest level is OpenGL. Of course ports can be done. It simply takes more time (eg. money) if you start with DirectX instead of OpenGL
> 3) In the gaming world, you only care about the game working for its sale period, which is maybe two years at best. Trying to sell game developers on long-term technology are a waste of time.
Nope, you need to look at the whole equation. The tools and experience of the developers really counts. A single game sales might be two years tops but the tech a studio chooses (investing time and developer experience in) has to last a lot longer than that somce they don't like to change their technology often. Changing tech costs significant money and time. This is why the DirectX-only shops will have a period of inefficiency while they retooling for iPad etc). Fortunately many shops use professional frameworks which hide most of the underlying DirectX-ness or OpenGL-ness from the developer, which allows them to target multiple platforms.
All I'm saying is OpenGL is a good tech to investigate that has *lots* of strategic benefits compared to its closest competitor (for those still mezmerized by the now-waning DirectX hype).
Re:How about non-Windows and non-Mac? (Score:1, Interesting)
I'm just fed arguing with the "3D means DirectX games on Windows only" crowd. with Apple's ascent it is time for them to eat crow since their point-of-view was as sensible as the web-development "target IE6 only and forget about W3C compat" crowd (which was a battle we had to fight in the enterprise space as many "ohh, shiny" operations people have short-term horizons). This snideness is vindication and not intended to insult the sensitive, so please don't take it personally.
I didn't realize that there was a "3D means DirectX games on Windows only" crowd. Nor do I really know what that even means...
I understand your general point, but everything you bring up still doesn't necessarily make OpenGL the best choice for game development. Developers should pick the best tool for their task-- if they don't care about porting to consoles or Mac, if they don't care about mobile, if they don't care whether the game runs in 5 years-- DirectX could very well be the best tool for their task. And demonstrably is, for a lot of PC/Xbox games. Otherwise they wouldn't choose it.
Huh? The official graphics API for the PS3 at the lowest level is OpenGL. Of course ports can be done. It simply takes more time (eg. money) if you start with DirectX instead of OpenGL ... and you should be thinking about the long-term *money* if you are a half-decent architect.
I didn't say the PS3 didn't have OpenGL, or that OpenGL wasn't "official", I said most PS3 games didn't use OpenGL. Which is true; most use LibGCM. OpenGL is mostly there to enable quick porting.
Nope, you need to look at the whole equation. The tools and experience of the developers really counts. A single game sales might be two years tops but the tech a studio chooses (investing time and developer experience in) has to last a lot longer than that somce they don't like to change their technology often.
Yes, but on the other hand: :) This helps keep the number of qualified DirectX programmers up.
1) Game development with OpenGL consumes significantly more time than equivalent development in DirectX.
2) There are a LOT of DirectX-skilled developers around, which could hugely drive down your staffing costs.
3) Microsoft is doing a very good job, with programs like XNA, of exposing developers to DirectX. OpenGL, in comparison, has very little in the way of community outreach except a few outspoken commenters on Slashdot.
4) DirectX's new features are driven by a small focused team who ensure that mainstream video cards fully support the features in a reasonable timeframe. OpenGL's new features are the results of a committee that's consistently 3-5 years behind the state-of-the-art, and implemented by OS and video card driver programmers who (and let's be frank) don't do a very good job.
And finally:
5) Your point falls a little flat, since it's really not very difficult to port a game from DirectX to OpenGL if needed. Again, it's been done dozens of times before, and it only (at most) a few months worth of work. You bring this up yourself in your last sentence, which I didn't quote.
All I'm saying is OpenGL is a good tech to investigate that has *lots* of strategic benefits compared to its closest competitor (for those still mezmerized by the now-waning DirectX hype).
Look, if you have two politicians, A and B. A's in the news every day, running TV ads, plastering the city with flyers and posters-- who do you think people are going to vote for? If OpenGL doesn't have an evangelism, it doesn't get any users... that should be self-evident to anybody who's not completely aspie.
Since OpenGL is managed by a slow, bloated committee and not a single party who's interested in growing its marketshare, well, there's no evangelism, and thus there's not as many users. Again, there's no surprise here.
Re:OpenGL - do they still have that? (Score:3, Interesting)
For graphics quality and capability, there really isn't that much difference between OpenGL and DirectX. They have the same feature set and the same rendering ability. The only difference is that DirectX uses this ridiculous counterintuitive left and rule for polygons. OpenGL uses right hand rule which is the way Engineering and God intended.
Other than that, OpenGL is the only real open standard for graphics. DirectX is only on Windows. OpenGL is on Windows and most other platforms.
Also OpenGL is the only solution if you want to generate your own 3D stereoscopic scenes. DirectX does it for you in the driver but this is just a cheap approximation. If you want accurate, non-eye fatiguing stereo, then OpenGL is the only solution.
Re:How about non-Windows and non-Mac? (Score:3, Interesting)
Game Development with OpenGL consumes significantly more time than equivalent development in DirectX
Can you elaborate? I'm curious as to why you would say that. In my experience OpenGL is far easier to understand and write than DirectX.