Slashdot Mirror
OpenGL SuperBible 5th ed.
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.
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
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.
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.
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.
Just try to imagine, for a moment, my disappointment when I realized this was not an open source 3d rendering of a comic-book version of Jesus SuperChrist.
... that science and religion are compatible.
Read the EFF's Fair Use FAQ
Funny, when I scanned the article title I though that someone was coming out with a Christian bible produced by open sources. Then I thought about the sheer volume of revisions, flame wars and arbitrary editing meted out over the centuries by transcribing monks, and realized that the Bible is probably the original Wiki (minus the OR, of course).
When you have nothing left to burn you must set yourself on fire
Smooth move getting a referral link on the front page of slashdot.
Does the book cover OpenGL on the iPhone, iPod touch and iPad? How about OpenGL on the Wii or the Nintendo DSi? Or the PS3 or PSP?
I've heard that some of these devices use a subset/smaller specifications of OpenGL, but I guess most of the book should still apply.
OpenGL SuperBible' Hyper Fighting -- David vs Goliath, round one, FIGHT!
I've come to... anesthetize you!
Do Muslims have to wait for the SuperKoran version?
Who would win this election: Andrew Weiner vs Andrew Weiner's weiner.
Do Muslims have to wait for the SuperKoran version?
http://www.amazon.com/Ultimate-Programming-DirectX-Allen-Sherrod/dp/1584505591
OP may or may not be intentionally trolling, but the question is pretty easy to answer:
Yes.
Just about every program that does 3D graphics on anything besides MS Windows or XBox uses OpenGL, today.
How awesome would "the" bible become if it were rewritten by 3D graphics geeks? Every time it's been rewritten over the thousands of years it's been more a story of what the contemporary rewriters believed god told them. And the OpenGL people think god tells them to make computer graphics more open and faster, with superstition and tribal supremacy not really in the script. Lord save me!
--
make install -not war
But seriously, how many AAA rated games come out for OpenGL anymore? Don't get me wrong, I rooted like hell for OpenGL when they fought side by side with Dx in the 90s, as I feared then they'd tie versions of Dx with windows (as they did with Dx10 and Vista) but it is pretty obvious now that the group controlling OpenGL cares more about CAD than actually making a competitor to Dx. And from what I've read the OpenGL ES (as in embedded) used by companies like Sony is just adding their own proprietary extensions so it isn't like it is easy to switch between the PS3 and Windows like Dx and X360, so what is the point?
Back in the 90s OpenGL was gonna be THE layer, and for quite awhile it was, that allowed anyone playing on anything that had OpenGL to play all the cool stuff and have the whiz bang features. Maybe it is time for the FOSS guys to do a LibreOffice and fork it away from the Kronos group and make OpenGL what it was back in the day, THE kick ass graphics layer. Because right now it sure ain't it, and hasn't been it for nearly a decade.
ACs don't waste your time replying, your posts are never seen by me.
I haven't even started reading the old one.
Can we stop using religious terms for technological things that are based in facts?
What's next? The DirectX SuperTanakh?
Are we talking console(OpenGL ES)? Pretty much all of them.
Are we talking PC (OpenGL "proper")? Isn't Valve's Source Engine OpenGL capable now?
Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
In the gaming world, you only care about the game working for its sale period, which is maybe two years at best.
What is the sale period of a game combined with the sale period of its sequels on the same platform?
Hasn't netcraft confirmed it?
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.
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
Actually, unlike OpenGL, DirectX can be left handed or right handed. You get to decide.
-]Phreak Out[-
This looks like a good book, but it covers OpenGL 3.3. Can someone provide a high-level overview of the differences between OpenGL 3.3 and 4.1?
Starcraft 2, Diablo 3 and the next Blizzard mmorpg will run in opengl too for sure, can't see that changing.
The only "consoles" where people are using OpenGL ES are the smartphones. Nobody is using it on the other real consoles even though some form of it is usually available. Developers generally prefer the proprietary APIs console manufacturers provide, because they are usually lower level than OpenGL so they can get more performance out of them.
Mada mada dane.
You must not be familiar with OpenGL. You can easily implement either type of coordinate system using OpenGL. You're in full control of the matrix transforms and the depth buffer test so it's trivial to switch from one system to the other.
> Are we talking console(OpenGL ES)? Pretty much all of them.
Try again.
XBox 360 - no.
Wii - no. (I wrote an in-house OpenGL implementation using the native GX calls and shipped 2 games that used it.)
DS - no.
PS2 - no. (I fixed a few bugs in the existing in-house OpenGL implementation.)
Except there is no such thing as a left hand coordinate system. It's just plain WRONG.
Also, according to here, it says "Direct3D uses a left-handed coordinate system. If you are porting an application that is based on a right-handed coordinate system, you must make two changes to the data passed to Direct3D."
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
So you say there's no left hand coordinate system, then say D3D uses one... Then you post a link that says it can be either.
-]Phreak Out[-
Apple only supports OpenGL 2.1 (plus extensions). The Fifth Edition of the book only covers OpenGL 3. GLSL has changed a great deal since 2.1 and this book is very incompatible with any released version of OS X as of this writing.
If you want to write OpenGL that is compatible with a Mac, get the Fourth Edition of the book.
Why is this so hard to understand?
There is NO left hand coordinate system in the REAL world. All of physics, engineering, robotics and most graphics use a right hand coordinate system. Obviously you can define a coordinate system to be anything you like, and DirectX has defined theirs to be left handed which is contrary to every other standard out there.
The link does not say it can be either. It says DirectX uses a left hand coordinate system. They then tell you how to use right hand coordinate DATA but fundamentally the internals are still left handed.
Does that explain it for you?
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
So if you're doing all your calculations in right handed, and it accepts that right handed data... Then what does it matter what it is internally? BTW, some people have tried to figure out what OpenGL becomes internally, and it appears to be LEFT HANDED. It's just the graphics cards work apparently. So I guess you should stop using computers because they are left handed?
-]Phreak Out[-
That's not what it says. It says if your data is right handed, here is how to read it in. Calculations are still left handed, and the scene is still left handed. So if I take a cross product of x and y vectors, a left handed system has the z going in one direction and a right hand system has it going the other. If I expect to move in my scene based on these calculations, and I'm taking calculations from the scientific world with right hand calculations, the directions can be backwards in the left hand world of DirectX.
OpenGL is most certainly right handed. Has been this way ever since its inception from IrisGL in the 80's.
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
You don't seem to understand. You can setup your projection and all matrices in D3D to be right handed. All the data/calculations would be right handed. This is further evidenced by all the right handed functions available in DX. (Contrast with GL which only provides right handed functions). However, when submitting to the GPU, everything goes through a transform to left handed. Be it OpenGL or DX. (This is evidenced by the third row of the matrix, negative in GL and in DX when right handed coordinate systems are used).
-]Phreak Out[-
Read over this if you want. Seems to be a good discussion of the whole thing. http://www.gamedev.net/community/forums/topic.asp?topic_id=566282
-]Phreak Out[-
Well I do serious graphics programming and I used the fixed functionality pipeline, i.e. CAE work. After all who needs later than OpenGL 1.1?
Must admit it would be nice to rip out the graphics and drop in a scenegraph, add in a Gooch shader and the product might even start to look a bit flash.
I may be wrong, but I'm pretty sure that RenderMan and Luxrender/pbrt are based on left handed coordinate system (at least by default).
But they may not be part of "All of physics, engineering, robotics and most graphics"...
Anyways, OpenGL is an open standard, supported by open platforms and most of closed ones, it's a no-brainer.
Maybe I'm not familiar enought with DirectX. I know you can convert right handded to left handed, but how would I set up my DirectX environment such that my world coordinate system has +x to the right of the screen, +y to the top of the screen and +Z towards the camera (right hand)? In DirectX isn't +z always towards the screen regardless of what your data is set up to be?
Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.