OpenGL Programming Guide 6th Ed. 86
Martin Ecker writes "The Red Book, also known as the OpenGL Programming Guide published by Addison-Wesley Professional, returns in its sixth edition with additions covering OpenGL 2.1. The Red Book, so called because of its nice, red cover, is probably the most-well known, standard introduction to the OpenGL graphics API. Let me take you on a tour through the pages of this book to see what it has to offer." Read on for the rest of Martin's review.
Just as the previous, fifth edition of the book, the sixth edition is incredibly complete and thorough. It contains explanations of pretty much every feature of OpenGL, even the rarely used ones. You want to know about the fairly new occlusion query support of OpenGL? It's in this book. You want to know about the accumulation buffer and its uses? It's in this book. You want to know about the (mostly deprecated) use of indexed color buffers? It's in this book. The sixth edition also covers vertex and fragment shaders and recent additions to the GLSL, the OpenGL Shading Language, such as the preprocessor. Even though the coverage was expanded, the authoritative guide to shader programming in OpenGL still remains the Orange Book aka The OpenGL Shading Language (see my previous Slashdot review).| OpenGL Programming Guide (Sixth Edition) - The Official Guide to Learning OpenGL, Version 2.1 | |
| author | Dave Shreiner, Mason Woo, Jackie Neider, Tom Davis |
| pages | 862 |
| publisher | Addison-Wesley Professional |
| rating | 8/10 |
| reviewer | Martin Ecker |
| ISBN | 0-321-48100-3 |
| summary | The Red Book is the authoritative guide to OpenGL. |
The Red Book is aimed at the beginning to intermediate graphics programmer that is not yet familiar with OpenGL. It assumes a basic background in computer graphics theory and working knowledge of the C programming language. The book consists of 15 chapters and 9 appendices that together span approximately 860 pages.
The first chapter gives a brief introduction to the basic concepts of OpenGL and describes the rendering pipeline model used in the API. GLUT, a cross-platform library that allows easily creating OpenGL applications, is also shortly discussed together with a program that shows GLUT in action. The following chapters proceed to explain the basic geometric primitives, such as lines and polygons, supported by OpenGL and how to render them in different positions and from different viewpoints using the various OpenGL matrix stacks. Also the basics of using colors, fixed-function lighting, framebuffer blending, and fog are discussed.
Chapter seven contains a description of display lists, a unique feature of OpenGL that allows to store OpenGL API calls for efficient multiple uses later on in a program. Chapter eight then moves on to discuss what an image is for OpenGL. Most notably this chapter now covers pixel buffer objects, a fairly recent addition to OpenGL, which the fifth edition of the book did not mention. The discussion of images in chapter eight bring us straight to chapter nine on texture mapping, one of the largest chapters in the book. This chapter discusses everything you need to know about textures, from specifying texture images in uncompressed and compressed form to applying textures to triangles using the various kinds of supported texture filters. Also depth textures and their application in the form of shadow maps and — new in the sixth edition — sRGB format textures added in OpenGL 2.1 are presented.
In chapter ten the authors discuss the buffers that make up the framebuffer, such as the color buffer, depth buffer, and stencil buffer. This chapter summarizes some of the things already presented in the earlier chapters and then describes the various framebuffer operations in more detail. Also the accumulation buffer and its uses, such as motion blur and depth of field effects, are discussed. Chapter eleven and twelve are on the tools provided by GLU, the GL utility library, in particular tesselators, quadrics, evaluators, and NURBs. GLU is nowadays rarely ever used in production code, so these chapters mostly demonstrate just how complete the Red Book is in its coverage of OpenGL. This also applies to chapter thirteen on selection and feedback, which are rarely used features, mostly because of the lack of hardware acceleration in today's GPUs (Graphics Processing Units).
Finally, chapter fourteen is a collection of topics that didn't fit into the other chapters, such as error handling and the OpenGL extension mechanism. Additionally, this chapter presents various higher level techniques and tricks, for example how to implement a simple fade effect, how to render antialiased text, and some examples of using the stencil buffer. The final chapter of the book is a discussion of the OpenGL Shading Language (GLSL, for short). In the sixth edition this chapter has been updated to version 1.20 of GLSL as required by OpenGL 2.1. Even though the OpenGL API functions required to use GLSL are presented, this is only a rough overview of how programmable shaders are used in OpenGL. For a more detailed description of GLSL the reader is referred to the Orange Book.
The book closes with quite a few appendices on the order of operations in the OpenGL rendering pipeline, the state variables that can be queried, the interaction of OpenGL with the operating system-specific windowing systems, a brief discussion of homogeneous coordinates as used in OpenGL, and some programming tips. Also a reference of the built-in GLSL variables and functions is included.
The book contains a large number of images and diagrams, all of them in black and white except for 32 color plates in the middle of the book. The illustrations are of high quality and generally help make the explained concepts and techniques easier to understand. Most of the color plates depict spheres, teapots, and other simple geometric objects, so they aren't overly eye-catching but do serve their purpose of showing what can be achieved with OpenGL.
All in all, the Red Book remains the definitive guide to OpenGL. Apart from being a good introduction, it also contains many interesting tips and tricks that make the experienced OpenGL programmer come back to it often. If you've read through the Red Book and the Orange Book in their entirety you pretty much know everything there is to know about OpenGL.
Martin 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 Programming Guide (Sixth Edition) - The Official Guide to Learning OpenGL, Version 2.1 from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
I'd wait! (Score:5, Informative)
Out with state machines and in with OO abstractions.
Re:I'd wait! (Score:4, Interesting)
I am not a programmer but I play one on TV.
So help out a N00b. Is Open GL strictly for graphics, or does it cover other system calls like sound and user IO? What I am getting at here is that most of the times when I see a windows game that also runs on Linux, it uses Open GL. Those that do not use Direct X. Is the problem that the Open GL standard does not include sufficient API's to deliver all the standard calls need to write a game? Is it that other standards like ALSA (I am guessing that is a sound API) do not have windows ports? Why oh why is there nothing out there that allows programmers to write some kind of ANSI coded games that will compile on mutiple operating systems without error or modification?
OK I admit I am ignorant in this area, so please don't call me ignorant, I have already done so myself. It just seems to me that if Microsoft can do it with Direct X, the rest of the world should be able to do it better, more cross compliant, and portable.
Re:I'd wait! (Score:5, Informative)
Graphics only.
Why oh why is there nothing out there that allows programmers to write some kind of ANSI coded games that will compile on mutiple operating systems without error or modification?
I take it you've never heard of SDL [libsdl.org]? Just use an OpenGL-enabled surface for graphics, and the standard SDL APIs for sound and input.
Re: (Score:2)
Re: (Score:2)
OpenGL-enabled surface for graphics (Score:2)
Re: (Score:2)
So if you want to do game programming that is cross platform, OpenGL only handles graphics. And just the low level bits - you need to write code to do higher level management of game object, like for example if you have a model of a pirate you need to know the position of each body part relative to the ne
Re: (Score:1)
Microsoft puts a lot of money into research on the DX apis, and also works with the graphics vendors to make sure that DX will be able to take advantage of all the whiz bang features on every new generation of graphics cards.
If you want to write a cutting edge game, it leaves you with no choice. You can't get the same to the metal speed on OGL that you can on DX. As a result, a lot of developers choose to go with DX as their API. Since a lot of
Plenty of FUD there.... (Score:2, Interesting)
They do spend a lot of money on PR and taking games company bosses to lunch.
You can definitely get the exact same speed from OpenGL as Direct3D on top end hardware - I do it every day.
OpenGL drivers for major graphics cards (ATI/Nvidia/
Re: (Score:1)
Re: (Score:1)
I've been waiting for Perl 6 to come out... (Score:4, Funny)
Re: (Score:2)
Re: (Score:2)
This is more in line with the design of scene-graph API's.
Re: (Score:2)
An object is a state machine. The whole idea of OO is to couple the state with the functions which manipulate it. So instead of having drawCircle(context, vertex[] VertexArray), you'd have context.drawPolygon(vertex[] vertexArray) or even context.draw(new Polygon(vertex[] vertexArray)). These all do the exact same thing (and the last does it inefficiently since it allocates memory), and manipulate the underlaying state machine (physical hardware) in th
Re: (Score:2)
Having implemented OpenGL on the Wii, there is no reason why you can't do both. (oo abstractions under the hood.)
Not every GPU is a stream processor. At some point you have to manage rendering states (blending,fog,etc.)
You mean 'ho-hum' edition? (Score:2)
By "meanwhile", do you mean "ho-hum"? (e.g.,, nothing new to see here?)
For those not wanting to RTFS... (Score:1)
The Red Book, also known as the OpenGL Programming Guide published by Addison-Wesley Professional, returns in its meanwhile sixth edition with additions covering OpenGL 2.1. It's in this book. It's in this book. It's in this book. Even though the coverage was expanded, the authoritative guide to shader programming in OpenGL still remains the Orange Book aka The OpenGL Shading Language
The Red Book is aimed at the beginning to intermediate graphics programmer that is not yet familiar with OpenGL. The book consists of 15 chapters and 9 appendices that together span approximately 860 pages.
The first chapter gives a brief introduction to the basic concepts of OpenGL and describes the rendering pipeline model used in the API. Chapter seven contains a description of display lists, a unique feature of OpenGL that allows to store OpenGL API calls for efficient multiple uses later on in a program. Chapter eight then moves on to discuss what an image is for OpenGL. Most notably this chapter now covers pixel buffer objects, a fairly recent addition to OpenGL, which the fifth edition of the book did not mention. The discussion of images in chapter eight bring us straight to chapter nine on texture mapping, one of the largest chapters in the book. The final chapter of the book is a discussion of the OpenGL Shading Language (GLSL, for short). In the sixth edition this chapter has been updated to version 1.20 of GLSL as required by OpenGL 2.1. All in all, the Red Book remains the definitive guide to OpenGL.
Re: (Score:2, Funny)
Re: (Score:1)
An arguably better summary, courtesy of ots (Score:1)
Gah. (Score:1, Troll)
Incidentally, I didn't realize my copy was three editions behind... Sophomore year seems so long ago.
Re: (Score:3, Funny)
http://www.digibarn.com/stories/dankottke/Image03.jpg [digibarn.com]
Re: (Score:2)
Umm... isn't that what the table of contents is for?
Re: (Score:2, Informative)
http://www.glprogramming.com/red/ [glprogramming.com]
I learned OGL mostly from this book (along with NeHe's tutorial on gamedev.net).
Re: (Score:1)
BTW, why was parent modded as troll? I thought it was an entirely valid to criticise "reviews" that mostly just list chapter contents as a way of padding out a couple of lines comment into an "article".
Re: (Score:1)
Which Red Book? (Score:2)
Then there's the old O'Reilly "Rainbow Books", the eight or nine volumes on X Windows specs and programming -- but glancing over at my bookshelf, none of them are red, exactly.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Seriously, (looking more closely at shelf) the Volume 3 X Windows System User's Guide OSF/Motif 1.2 Edition is more of a dark reddish brown. But (digs around a bit) yeah, you're right, the straight Vol 3 is indeed (mostly) red.
Sorry about that.
Re: (Score:2)
Got it cheap a few years back. I had no idea it was so out of date.
Re: (Score:2)
Most people use a toolkit (GTK, Qt, Motif, etc) on top of Xlib these days anyway.
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
showpage
Re: (Score:2)
Comparison to DirectX (Score:1)
Re:Comparison to DirectX (Score:5, Informative)
OpenGL 3.0 will move to a an OO API. It should make programming in OpenGL a lot more attractive. I've heard from people they feel it's easier to do a lot more things in DirectX than OpenGL. It's all opinion, of course.
I'm not a graphics programmer but I have played one on TV.
Re:Comparison to DirectX (Score:5, Insightful)
DirectX is a nightmare of ActiveX/COM objects. It's anything but pretty to look at it. It takes a lot of code to get started before you can do anything. There's a very steep learning curve to fight through before you can do anything at all with it. It gets easier once you've managed to get it going, but it still isn't pretty.
OpenGL is a state machine, programmed in good 'ol C.
Which makes it very straightforward to work with. You don't find yourself wondering how something will work. If you have any background in 3D graphics theory, things work in OpenGL exactly as you'd expect.
DirectX has an OO API and what some would argue a more complete library.
The OO API doesn't make things easier, as it's COM based. It's advantage is integration with Windows.
The library is where DirectX has an advantage. It's got some higher level functionality built in that OpenGL doesn't have.
Re: (Score:1)
Except that you have to apply matrix transformations in exactly the opposite order as you would if computing by hand
Re: (Score:1)
Re: (Score:2)
When was the last time you've used DirectX? COM is nicely hidden (See the code below).
It's anything but pretty to look at it. It takes a lot of code to get started before you can do anything. There's a very steep learning curve to fight through before you can do anything at all with it. It gets easier once you've managed to get it going, but i
Re: (Score:2)
This has been fixed up heavily in recent years. The only remaining headache is keeping track of reference counts; in C++, you can use the CComPtr smart pointer template class
Re: (Score:2)
Linus, is that you?
j/k :)
--Rob
this is why dx is better than opengl (Score:1)
it is easy to create a directx application,
- you no longer have to deal with the crazy amounts of COM crap
- the init calls are really streamlined now.
- also nehe has tutorials for lots of dx apps
directx mirrors the hardware more correctly (was more true back with DX8/9), meaning that your code will run faster. (however opengl is catching up fast)
game developers really really care about performance.
microsoft gives support, and hs a really
Re: (Score:2, Interesting)
Or any other language you want. I've used it from Python, and it's great. It's portable, fast enough for me (though I'm not writing Doom3 here), close enough to the C API that I can use any C reference, but still Pythonic enough that it's pleasant to work with. Plus, if you can put something (or everything) into a display list, it *really* flies.
It's trivial to wrap a state machine. It took me about 2 minutes to wrap glBegin/glEnd with a Python 2.5 con
Re: (Score:2)
While I strongly prefer OpenGL over DirectX, on some points you just can't deny that it's easier with DirectX, being a more extensive library. Sound and multi-media along with 3d and more in "one package". It also has functions for stuff which is complex to implement, ready to be used (for example the Precomputed Radiance Transfer API [microsoft.com]).
Another reason is that it's easier to verify that you
Re: (Score:2)
The current version of OpenGL has a couple of patented bits that make a 100% open source implementation difficult. Is that going to be even worse in OpenGL 3.0 or are they avoiding such traps this time?
Re:Comparison to DirectX (Score:5, Interesting)
DirectX is the native API to the OS on most peoples computers.
Microsoft has experienced technical writers publish books about DirectX the day it comes out.
OpenGL books are being written mostly by developers, which aren't always good technical writers.
Microsoft managed to mastermind OpenGL standard development to halt to a freeze for several years, they no longer hold the same influence.
My opinion:
OpenGL is a more logical language, with a few features that are far better.
OpenGL makes me happy, no clue why, but I enjoy coding up against it, DirectX makes me concentrate and for some reason, I never manage to dispose properly of all my "managed" objects in DirectX. That being said, one thing i like about directX is DirectView.
OpenGL + Cg makes me happy
My captcha was porters, proving that there is not necessarily a direct link between what you write and what captcha you get
Re: (Score:2)
Re: (Score:2)
Not for DirectX.
>> DirectX is the native API to the OS on most peoples computers.
There's nothing "native" about DirectX on Windows. I know, I worked on graphics drivers for one of the three big GPU companies (those three are Intel, NVIDIA, and ATI, in that order).
I won't contest the book points.
>> Microsoft managed to mastermind OpenGL standard development to halt to a freeze for several years, they no longer hold the same influence.
To misquote Obi
Re: (Score:2)
There are a couple of reasons. First of all, Microsoft tailors the API to the latest graphics hardware much more quickly. This allows the developer to take better advantage o
Re: (Score:2)
Not really. Pretty much the first thing GPU companies do upon releasing fancy new hardware is to ship new drivers with OpenGL extensions letting developers get at the new functionality. D3D only exposes new functionality when Microsoft decide to rev the API.
Second, partly as a consequence of that, you can usually do things faster under DirectX than under OpenGL, with a 2:1 speed ratio bei
Re: (Score:2)
This is true to only a minimal degree. nVidia does quite a few extensions, and they do give some access to new "stuff". In a lot of cases, it's rather minimal access though, and in other cases, it's basically nonexistent. Just for an obvious exampl
Re: (Score:2)
EXT_geometry_shader4 [opengl.org]
What other stuff do you feel there's 'minimal' access to? nVidia has a history of doing real
Re:Comparison to Direct3D (Score:1)
...Direct3D is different. It is a separate 3D graphics API whose specification is controlled by Microsoft. As such, Microsoft can make the requirement that any graphics HW, consumer or workstation, that wishes to be WHQL (Windows Hardware Quality Lab) certified for Windows, must pass the WHQL testing and certification suite which tests for compliance with the Direct3D specification. This assures that if a graphics driver passes WHQL certification, there is a certain level of compliance and reliability associated with the graphics driver, both for 2D (e.g. GDI, GDI+) and 3D (meaning Direct3D but _not_ OpenGL).
Specifically, regarding your question about working around developments in the gaming industry ... Autodesk is working very closely with Microsoft to incorporate support for CAD features and capabilities into Direct3D. We are working very closely with Microsoft to make sure that CAD usage is tested as part of WHQL testing and certification of Direct3D graphics drivers. This will apply to _all_ graphics HW on the Windows platform, meaning high end "workstation" graphics HW, consumer graphics HW, and low-cost graphics chipsets that come on-the-motherboard.
I would like to take a slight digression just to give a bit of a historical perspective on the issue of 3D graphics HW. I have been around long enough to have worked with 3D graphics HW _before_ OpenGL existed. In that earlier time period, I worked with over seven different 3D graphics APIs. When SGI succeeded in imposing OpenGL as "the" 3D graphics API on the entire industry, this was not viewed as a "wonderful event" by everyone in the SW industry. The HW industry loved it, and they have been rather successful in ignoring any innovation or suggestions for 3D graphics development from the SW community during the entire time OpenGL has existed. Autodesk has attempted to work with the OpenGL HW community to enhance 3D graphics but has been met with a very deaf ear by the OpenGL HW community, similar to the experiences of many other SW vendors. Perhaps one exception to this situation has been the willingness of some OpenGL HW vendors to "adjust" their OpenGL implementations so some 3D games using OpenGL will run better ... but there has been little, if any, serious collaboration between graphics HW vendors and CAD SW vendors to incorporate features that seem reasonable from a SW perspective. Perhaps this is one reason why there are over _350_ documented OpenGL "extensions" that expose various "features" available on various generations of graphics HW from various HW vendors.
Microsoft has had a long and interesting history with Direct3D and they have had some evolving to go through to reach the point where they are now with Direct3D 9 on WinXP (and Win2K) and Direct3D 10 on Windows Vista. However, the _most_ important aspect from a SW development (and computer user) perspective is that Microsoft has been willing to listen and incorporate suggestions from the SW community. The resulting Direct3D specifications (as well as SW development tools) that have come from Microsoft are at least a generation or more advanced beyond the rather obtuse, cryptic OpenGL specifications and stone age development environments that the graphics HW vendors push at SW developers to use with OpenGL.
The bottom line is that competition is good and the fact that we have Direct3D as a professionally developed 3D standard instead of being forced to use OpenGL is very healthy. Without Direct3D, we are completely at the mercy of the graphics HW vendors in terms of what they believe the industry needs. For example, I continue to be amazed at how we as computer users seem willing to "accept" a blue screen crash or an application crash-to-the-desktop caused by an OpenGL graphics driver. We seem to have been intimidated by the graphics HW vendors to wilingly accept the fact that we just need to upgrade to the latest graphics driver and all our problems will go away. Isn't something wrong with this picture??? We don't expect our hard drives to fail, or our system RAM to fail, or our network cards to fail in the same catastrophic way ... or at least, if they do, we get righteously upset. However, when our OpenGL graphics driver causes blue screen crashes or application crashes, we meekly accept this as our lot in life.
Using Direct3D, Microsoft is attempting to set a standard for 3D graphics HW _and_ SW on the Windows platform ... and catastrophic failure is no longer considered acceptable for graphics drivers. We fully support this position and are happy to provide any support to help motivate the graphics HW vendors to join the rest of the computer community in providing a higher level of quality than unfortunately has frequently been the situation with OpenGL.
Yup, it's another Microsoft fan for sure.
What's missing in the review (Score:1, Funny)
Questions (Score:2)
Re: (Score:2)
Ugh, no. (Score:2)
OpenGL is the name of an API. Various companies make implementations for their hardware / OS, and then they pay SGI for the right to call their implementations 'OpenGL' (after passing a load of conformance tests).
Mesa is an implementation of the OpenGL, it just hasn't been officially blessed by SGI (although they do support it's existance in other ways) so it can't legally call itself OpenGL.
Urgh, yes. (AKA: oss.sgi.com 101) (Score:2)
INTERFACE, not implementation. (Score:1)
Q about book (Score:2)
Is this one of those books where the 860 pages is mostly filled with API documentation? Or is this a genuine how-to book? I'm definitely interested in learning OpenGL so that I can write a nice GUI for simple games, but it's hard to know where to start.
Thanks,
--Rob
Re: (Score:3, Informative)
Re: (Score:3, Informative)
Believe it or not, it's actually both. It is the official standard API documentation, but it's written for the benefit of both implementers and users. Because the standard describes very specific behavior (including side-effects) of implementations, it's the most important and useful resource for users of the API. That, and the book describes in very clear terms how to use the API. It's not a beginner's HOWTO manual, but it's very, very close.
I own 5th edition, and it's the OpenGL reference I use the m