Forgot your password?
typodupeerror
Image

OpenGL Programming Guide 7th Edition 48

Posted by samzenpus
from the read-all-about-it dept.
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.

*

This discussion has been archived. No new comments can be posted.

OpenGL Programming Guide 7th Edition

Comments Filter:
  • 7th edition (Score:1, Funny)

    by cormander (1273812)
    7th times the charm.
  • by gardyloo (512791) on Wednesday January 27, 2010 @03:17PM (#30921966)

    OpenGL Programming Guide (Seventh Edition) –

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

  • Another Viewpoint (Score:5, Informative)

    by eldavojohn (898314) * <eldavojohn@gm[ ].com ['ail' in gap]> on Wednesday January 27, 2010 @03:18PM (#30922002) Journal
    From the Amazon link, I found several reviews giving the book a thrashing for continuing to include deprecated APIs [amazon.com] and not teaching the new paradigms [opengl.org] of the APIs after OpenGL 3.0. One review [amazon.com] was upset with the regurgitation and lack of new material. Another reviewer [amazon.com] 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 [opengl.org] 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.
    • by MostAwesomeDude (980382) on Wednesday January 27, 2010 @03:45PM (#30922732) Homepage

      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.)

      • Re:Another Viewpoint (Score:4, Interesting)

        by Hurricane78 (562437) <deleted @ s l a s h d ot.org> on Wednesday January 27, 2010 @04:02PM (#30923154)

        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.

        • by forkazoo (138186)

          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.

      • Re:Another Viewpoint (Score:5, Informative)

        by pnewhook (788591) on Wednesday January 27, 2010 @04:40PM (#30924050)

        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

        • 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.)

          • by pnewhook (788591)

            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?

      • by JohnyDog (129809)

        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 re

        • Re: (Score:3, 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.

          • by Svartalf (2997)

            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

            • :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.

      • 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 [newegg.com]

  • You need the trilogy to code life like colours.

    • 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
      • by jhoegl (638955)
        Obligatory Hackers reference quota received and processed.
        Yeah, I thought of hackers too when I saw the "Big Red Book" title.
    • by Creepy (93888) on Wednesday January 27, 2010 @04:01PM (#30923122) Journal

      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.

  • 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.
    • by jhoegl (638955)
      A conspiracy.... on the internets?!?!?!
      you sir, are crazy!
    • by Creepy (93888)

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

      • Re: (Score:3, Informative)

        by TheRaven64 (641858)
        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.
        • Re: (Score:2, Informative)

          by erwincoumans (865613)

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

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

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

              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.

  • by Hurricane78 (562437) <deleted @ s l a s h d ot.org> on Wednesday January 27, 2010 @03:53PM (#30922944)

    OpenGL Programming Guide (Seventh Edition) &amp;amp;amp;amp;amp;amp;ndash; 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!

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

UNIX is many things to many people, but it's never been everything to anybody.

Working...