Slashdot Mirror


OpenGL Programming Guide 7th Edition

Martin Ecker writes "The Red Book, also known as the OpenGL Programming Guide published by Addison-Wesley Professional, returns in its seventh edition, now covering OpenGL up to and including version 3.1. The Red Book, so called because of its deep red cover, is the most-well known, authoritative introduction to the OpenGL graphics API. In this review I want to take you on a whirlwind tour through the pages of this book to see what it has to offer." Keep reading for the rest of Martin's review. OpenGL Programming Guide (Seventh Edition) – The Official Guide to Learning OpenGL, Versions 3.0 and 3.1 author Dave Shreiner, The Khronos OpenGL ARB Working Group pages 883 publisher Addison-Wesley Professional rating 8/10 reviewer Martin Ecke ISBN 0-321-55262-8 summary The Red Book remains 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. Just as the previous edition of the book, the seventh edition is incredibly comprehensive and thorough. It contains explanations of pretty much every feature OpenGL has to offer, even the more obscure and rarely used ones. This is good in the sense that it's a fairly complete book, but it can also be somewhat overwhelming for a beginner when confronted with a book that weighs in at almost 900 pages. However, the good news is that the material is presented in a logical progression and even a novice will get up to speed with the basics of OpenGL after reading only the first few chapters of the book. Some of the early chapters in the book contain a few more advanced sections mostly explaining new features that got introduced with OpenGL 3.1. These sections are conveniently marked as advanced and can probably be skipped on a first read-through of the material.

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, lighting, framebuffer blending, and fog are discussed.

Chapter seven contains a description of display lists, a unique and with OpenGL 3.1 deprecated 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, and most notably covers pixel buffer objects, a somewhat recent addition to OpenGL. The discussion of images in chapter eight brings us straight to chapter nine on texture mapping, one of the largest and arguably most important chapters in the book. Everything you need to know about textures is discussed, 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 seventh edition – floating-point textures and texture arrays added in OpenGL 3.0 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. 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.

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 seventh edition this chapter has been updated to version 1.30 and 1.40 of GLSL, as required by OpenGL 3.0 and 3.1, respectively. 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 book "OpenGL Shading Language. Third Edition" also called 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.

With OpenGL 3.1 deprecating many older API features of OpenGL in favor of more modern alternatives, the seventh edition of the Red Book seems to have a bit of a split personality at times. If you're only interested in functionality not deprecated in 3.1 you can skip entire chapters, such as the chapter on display lists or fixed-function lighting. Of course, the knowledge of matrix stacks and how to use transformations is still relevant, but the corresponding OpenGL functions have been deprecated in favor of doing all the transformation math in the vertex shader or, what most people have been doing anyway, using your own matrix structures/classes on the CPU. The situation is similar for many of the other deprecated features (such as fixed-function lighting, color index mode, immediate mode, ...) that are still described in the book. I think the time is right to combine the Red Book with the Orange Book, removing any discussion of deprecated features, to have a book that focuses solely on the modern approach to graphics programming, which is mostly based on shaders. I can only hope such an OpenGL 3.1-only focused book will see the light of day soon.

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.

The 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 Programming Guide 7th 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.

48 comments

  1. 7th edition by cormander · · Score: 1, Funny

    7th times the charm.

  2. – by gardyloo · · Score: 3, Funny

    OpenGL Programming Guide (Seventh Edition) –

        That's some heavy-duty OpenGL code, right there.

  3. Another Viewpoint by eldavojohn · · Score: 4, Informative

    From the Amazon link, I found several reviews giving the book a thrashing for continuing to include deprecated APIs and not teaching the new paradigms of the APIs after OpenGL 3.0. One review was upset with the regurgitation and lack of new material. Another reviewer was looking for a book that concisely covers OpenGL 3.1 and the new way of coding things since 3.0 instead of the backwards compatible context and forward compatible context intricacies.

    I was thinking of picking up a good OpenGL book but this one sounds like it'd be most useful to people who need to move old projects forward and have to deal with old APIs and transitioning the graphics up to 3.0. But if you're coding from scratch and want the latest OpenGL, this book might have a lot of material you shouldn't even pay attention to because it's deprecated. I guess for hobbyist meddling I'll stick to the wiki as it's a difficult task for people to write documentation books on a changing spec. Probably a good one stop shop for all versions of OpenGL but I think sometimes the spec implementers just want you to move forward and aim to ask you to do that as infrequently as possible. I guess 3.0 appears to have addressed that.

    --
    My work here is dung.
    1. Re:Another Viewpoint by MostAwesomeDude · · Score: 4, Insightful

      It is, unfortunately, frustrating to write performant GL these days. While we would like to think that you can do what you want in GL, and the driver will magically make it go fast, the fact remains that some ways of drawing are slow and some are fast. Games are written for specific cards, and drivers get app-specific code. It's a mess, but a necessary mess.

      The other problem is that the majority of available hardware and drivers don't support GL 3.x. No open-source driver does, and in fact most Intel, Radeon, and nVidia hardware already in use can only do GL 2.x.

      The Red Book is doing what it should. It's providing a transitional viewpoint for writing apps that will work with GL 1.5-2.1 stacks, discussing both the fixed-function and shaderful pipelines. It talks about the maths needed to make things happen, and shows both the old and new ways of accelerating those maths on hardware.

      There's a reason that we recommend Red Book to people that are coming in and wanting to write drivers. Well, okay, two reasons. It's available online, for free. Maybe it's a slightly older version, but it's still a good primer. (http://fly.cc.fer.hr/~unreal/theredbook/ is a fairly readable version, but you can find others out there too.)

      --
      ~ C.
    2. Re:Another Viewpoint by Hurricane78 · · Score: 3, Interesting

      The other problem is that the majority of available hardware and drivers don't support GL 3.x.

      What the... Since when? I had no trouble with GLSL. And that’s basically the only important thing.

      --
      Any sufficiently advanced intelligence is indistinguishable from stupidity.
    3. Re:Another Viewpoint by Anonymous Coward · · Score: 0

      $ glxinfo | grep "OpenGL version"
      OpenGL version string: 3.0.0 NVIDIA 180.44

      So fuck you.

    4. Re:Another Viewpoint by pnewhook · · Score: 4, Informative

      The other problem is that the majority of available hardware and drivers don't support GL 3.x. No open-source driver does, and in fact most Intel, Radeon, and nVidia hardware already in use can only do GL 2.x.

      That's simply not true at all. Even my laptop supports OpenGL 3.x

      --
      Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
    5. Re:Another Viewpoint by JohnyDog · · Score: 1

      It is, unfortunately, frustrating to write performant GL these days. While we would like to think that you can do what you want in GL, and the driver will magically make it go fast, the fact remains that some ways of drawing are slow and some are fast. Games are written for specific cards, and drivers get app-specific code. It's a mess, but a necessary mess.

      Yes, but that is true for any bleeding-edge performance programming. It is true for Direct3D drivers, it is also true for general x86 programming - i remember having to fine-tune core loop of one app for specific CPUs distincted only by L2/L3 cache sizes - cache misses kill performance better than anything else.

      The other problem is that the majority of available hardware and drivers don't support GL 3.x. No open-source driver does, and in fact most Intel, Radeon, and nVidia hardware already in use can only do GL 2.x.
      The Red Book is doing what it should. It's providing a transitional viewpoint for writing apps that will work with GL 1.5-2.1 stacks, discussing both the fixed-function and shaderful pipelines. It talks about the maths needed to make things happen, and shows both the old and new ways of accelerating those maths on hardware.

      The major addition of GL 3.x series is *deprecating* stuff (and streamlining and integrating some stuff that was already available through extensions). You don't need the deprecated stuff for transition, as GL 2.1 will give you everything you need to drop the fixed function entirely, and code that you write against 2.1 with deprecation in mind will work under 3.0 profiles without problems. Seriously it's time to force change to fully programmable API as the hardware don't have any fixed function for several years now. Every time you use fixed function the drivers will just compile custom shader, and that is something you (or high-level library) can do as well, without the need to complicate the drivers.

      --
      People who like this sort of sig will find this the sort of sig they like.
    6. Re:Another Viewpoint by MostAwesomeDude · · Score: 1

      I'm talking about hardware already deployed, not new hardware. All the new stuff coming out is GL 3.1-capable, sure. (Except the boards being sold with old IGPs, of course.)

      --
      ~ C.
    7. Re:Another Viewpoint by MostAwesomeDude · · Score: 2, Insightful

      Well, that's a driver problem and not an app problem, and moreover, it's already been solved. Even Mesa already has a fixed-function->shader setup, and Gallium is fully shaderful.

      --
      ~ C.
    8. Re:Another Viewpoint by MostAwesomeDude · · Score: 2, Informative

      $ glxinfo | grep OpenGL
      OpenGL vendor string: VMware, Inc.
      OpenGL renderer string: Gallium 0.3 on softpipe
      OpenGL version string: 2.1 Mesa 7.8-devel
      OpenGL shading language version string: 1.20
      OpenGL vendor string: X.Org R300 Project
      OpenGL renderer string: Gallium 0.3 on R580
      OpenGL version string: 2.1 Mesa 7.8-devel
      OpenGL shading language version string: 1.20

      Two GPUs. So fuck you. :3

      --
      ~ C.
    9. Re:Another Viewpoint by Anonymous Coward · · Score: 0

      It not because you got shit implementation and hardware that there is no opengl 3.x support avaible. You are a liar and full of shit.

    10. Re:Another Viewpoint by pnewhook · · Score: 1

      Well if you go back far enough sure, and the old stuff doesn't support DirectX 10 or 11 either. You can say that of any new technology / hardware.

      My 2 year old car doesn't have a bluetooth interface. What's your point?

      --
      Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
    11. Re:Another Viewpoint by forkazoo · · Score: 1

      What the... Since when? I had no trouble with GLSL. And that's basically the only important thing.

      GLSL started as an extension to OpenGL 1.4, and was promoted to a part of the core API spec in 2.0. It's consequently not a very good example of what's new in 3.x.

    12. Re:Another Viewpoint by Svartalf · · Score: 1

      I do believe that he said "The other problem is that the majority of available hardware and drivers don't support GL 3.x. No open-source driver does, and in fact most Intel, Radeon, and nVidia hardware already in use can only do GL 2.x."

      This would be consistent with my understanding of the subject- and I port games over from Windows to Linux as a second vocation. Only part of the hardware out there really supports 3.0, only recent drivers happen to support it- and NONE of the FOSS drivers support it right at the moment. He's one of the gents working towards making that all happen on the FOSS drivers, so he should probably know what he's talking about.

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    13. Re:Another Viewpoint by X0563511 · · Score: 1

      OpenGL vendor string: NVIDIA Corporation
      OpenGL renderer string: GeForce 8400 GS/PCI/SSE2
      OpenGL version string: 3.2.0 NVIDIA 190.53
      OpenGL extensions:

      1 GPU, but OpenGL 3.2. So, fuck you :P

      --
      For large sets, this will be our guide even unto death, for the LORD will work for each type of data it is applied to...
    14. Re:Another Viewpoint by Svartalf · · Score: 1

      And I'm eagerly waiting for the full-on driver support for AMD parts to show up- as much to be vindicated for the comments I made to Benj Lipchak and others in Marlborough some ages ago as anything else... :-D

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    15. Re:Another Viewpoint by MostAwesomeDude · · Score: 1

      :3

      Stuff's really starting to come together. With r300-gallium, I'm almost able to play Openarena reasonably, and my next target is probably Team Fortress 2 because I love torching Spies. r600-gallium is starting to gather attention and we might really dig in on that front in a month or so.

      Thanks for your hard work in porting games.

      --
      ~ C.
    16. Re:Another Viewpoint by Anonymous Coward · · Score: 0

      Don't troll the dude writing the drivers

    17. Re:Another Viewpoint by Anonymous Coward · · Score: 0

      Citation Needed.

    18. Re:Another Viewpoint by pnewhook · · Score: 1

      Sorry to hear your fingers are broken and cant use a search engine.

      Here's the nvidia link stating what hardware and software is OpenGl 3.x capable. it's quite extensive. http://developer.nvidia.com/object/opengl_3_driver.html

      FYI, my laptop has a Quadro FX 1700M.

      --
      Tesla was a genius. Edison however was a overrated hack who liked to torture puppies.
    19. Re:Another Viewpoint by JackieBrown · · Score: 1

      glxinfo | grep "OpenGL version"
      OpenGL version string: 3.2.0 NVIDIA 190.42

      That came with my onboard motherboard (which strangely has gone up in price since I bought it over a year ago)
      http://www.newegg.com/Product/Product.aspx?Item=N82E16813131318

  4. Blue Book and Green Book not included by bugeaterr · · Score: 1

    You need the trilogy to code life like colours.

    1. Re:Blue Book and Green Book not included by ZenDragon · · Score: 1

      And of course the Pink Shirt Book, Guide to IBM PCs. So called due to the nasty pink shirt the guy wears on the cover

    2. Re:Blue Book and Green Book not included by jhoegl · · Score: 1

      Obligatory Hackers reference quota received and processed.
      Yeah, I thought of hackers too when I saw the "Big Red Book" title.

    3. Re:Blue Book and Green Book not included by Creepy · · Score: 3, Informative

      First off, it's not a trilogy, unless you're Douglas Adams - their are at least FIVE books - Blue, Green, Orange, Red, and White. Possibly 6, but I don't remember if AGL ever came in hard copy (I've personally always used the online AGL and Cocoa reference).

      The red book is the only real essential one. Some may say the Orange book as well, but I personally found NeHe tutorials and samples from other sites like nVidia helped me much more than the Orange book.

      The blue is basically the man pages for all functions and pointless today (just go to Khronos and download the reference). I haven't opened my blue book since about 1996.

      The green and white books are also pointless IMO, unless you really can't find sample code for them, since they cover XWindows and Windows non-portable pieces, such as setting up graphical contexts and other parameters and settings. In fact, I actually don't like how they do it, preferring more flexible parameter lists.

  5. Timing is everything by Bobfrankly1 · · Score: 1

    Amusingly well timed posting. Right after the Apple Zealots get a new toy that uses openGL, a book review on programming openGL appears as a slashvertisment.

    1. Re:Timing is everything by jhoegl · · Score: 1

      A conspiracy.... on the internets?!?!?!
      you sir, are crazy!

    2. Re:Timing is everything by Creepy · · Score: 1

      Except from what I read, the tablet runs the iPhone OS, so would use OpenGL ES, which is a subset of OpenGL for embedded systems.

    3. Re:Timing is everything by TheRaven64 · · Score: 2, Informative

      OpenGL ES is not a subset of OpenGL. There is a shared subset that is in both OpenGL and OpenGL ES, but both contain things that are not part of the other. Yes, I know the Wikipedia article that you cited says that it is, but if you read any of the sources that it links to then you'll find that it's wrong.

      --
      I am TheRaven on Soylent News
    4. Re:Timing is everything by erwincoumans · · Score: 2, Informative

      Khronos, the main authority of OpenGL ES, tells that it "consists of well-defined subsets of desktop OpenGL"

      http://www.khronos.org/opengles/

    5. Re:Timing is everything by TheRaven64 · · Score: 1

      And then it contradicts that in the very next sentence. The fixed point types in OpenGL ES, for example, are not part of OpenGL.

      --
      I am TheRaven on Soylent News
    6. Re:Timing is everything by Svartalf · · Score: 1

      You're picking nits. If you use the shared subset, you're largely programming in OpenGL ES 1.1 or 2.0. Fixed Point should only be used on systems with no HW FP present. Not something you're going to find very often in the bulk of the ES systems these days. Definitely not in the case of anything sporting a Cortex series ARM.

      --
      I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
    7. Re:Timing is everything by Anonymous Coward · · Score: 0

      fix it you moron, without asking

  6. –??? by Hurricane78 · · Score: 3, Funny

    OpenGL Programming Guide (Seventh Edition) – The Official Guide to Learning OpenGL, Versions 3.0 and 3.1

    WTF, editors? Did you fail HTML class again? ^^
    Please turn in your geek cards, and cue up at the ass kicking machine.
    Thank you for posting on teh Intarnetz!

    --
    Any sufficiently advanced intelligence is indistinguishable from stupidity.
  7. Re:– by rs79 · · Score: 0, Troll

    If it's open, why do I have to buy the book?

    Can I trade for my postscript manuals, in red blue and green? I'm sure I can get the Reid brothers to sign theirs.

    --
    Need Mercedes parts ?
  8. Re: –??? by ezzzD55J · · Score: 1

    queue.

  9. Re: –??? by Monkeedude1212 · · Score: 1

    Wait a second, are you insinuating that is NOT the correct title?

  10. Re:– by Zero__Kelvin · · Score: 0, Troll

    The Book isn't open; the standard is open. You can feel free to wade through the standard and figure it all out for yourself, and I'm sure there are plenty of free tutorials, etc. on the web. However, if you want a book written by consumate professionals in physical form, you pay for it. While there is a trend toward open books in the FOSS community, don't either deliberately or unintentionally confuse the concepts, OK?

    --
    Guns don't kill people; Physics kills people! - John Lithgow as Dick Solomon on Third Rock From The Sun
  11. Universally Stupid by DoogZaNator · · Score: 1

    You never review a book across state lines man...Stupid man...universally stupid.

  12. I might give this a try... by Anonymous Coward · · Score: 0

    Given i'm not really good in my programming... maybe a 1/10 haha

    Though I'm really interested in game development... I hope I still have the brain cells needed to understand this book.

  13. Anonymous Coward by Anonymous Coward · · Score: 0

    i learned the basics of openGL in computer graphics class, but never went as far as shader stuff (GLSL, HLSL or whatever it's supposed to be called). Does this new red book cover the subject ?