Slashdot Mirror


OpenGL Distilled

Martin Ecker writes "Until now, if you were looking for an introduction to the OpenGL graphics API, the "OpenGL Programming Guide" (also known as the Red Book) was your best bet. Now Addison Wesley Publishing provides a new alternative that is easier to digest than the all-encompassing Red Book with its more than 800 pages. Paul Martz's "OpenGL Distilled" concentrates on discussing only the important fundamentals you need to program 3D graphics using OpenGL 2.0 and provides a concise introduction to the most important cross-platform graphics API currently available." Read the rest of Martin's review. OpenGL Distilled author Paul Martz pages 266 publisher Addison-Wesley Publishing rating 8/10 reviewer Martin Ecker ISBN 0-321-33679-8 summary A concise introduction to the OpenGL graphics API

Before going into more detail and reviewing the chapters of the book I have to disclose that I was a technical reviewer of the book before it was published.

"OpenGL Distilled" is aimed at people interested in learning the basics of OpenGL. The reader should already be familiar with programming in C++ and have a basic grasp of linear algebra, in particular vector and matrix algebra. Familiarity with other 3D graphics APIs, such as Direct3D, is an advantage, but not a necessity. The book does a good job of presenting only the fundamental aspects of OpenGL and 3D graphics programming in general and never overwhelms the reader with too much unnecessary detail. The author draws a good line between what to discuss and what is beyond the scope of the book. More advanced features of the API are only mentioned shortly with appropriate references to more in-depth literature. Some deprecated features, such as the feedback buffer, that are no longer commonly used are left out as well. In my opinion an unfortunate omission, is shader programming with the OpenGL Shading Language, which is only briefly mentioned in an appendix. A full chapter introducing the basics would be a nice addition to the book. Until then the reader is referred to the Orange Book, which discusses shader programming in OpenGL in detail.

One thing I highly appreciate about "OpenGL Distilled" is the introductory section of each chapter, which contains a "What You'll Learn" and a "What You Won't Learn" bullet list. This makes it clear what the chapter is about and - more importantly - what it is not about. Especially the latter is mostly missing in other books.

The book has a total of 8 chapters and 4 appendices. The first chapter explains what OpenGL is, talks a bit about setting up a development environment on the most common operating systems to actually develop OpenGL programs, and immediately gets your feet wet with a first simple example program. The chapter is concluded by a whirlwind tour through the almost 15-year history of OpenGL and its predecessors.

Chapter two focuses on drawing primitives, such as lines and triangles, and the various ways supported by OpenGL to specify vertex data. In particular, vertex arrays and vertex buffer objects (VBOs), a fairly recent addition to OpenGL to allow high-performance rendering, are the focus of this chapter. Additionally, a first overview of the OpenGL pipeline that a primitive passes through until it finally ends up in the framebuffer is presented. A more detailed discussion of this pipeline, in particular with regard to coordinate transformations, follows in chapter three. The various coordinate systems used in OpenGL programming, such as object, world, eye, and clip coordinates, are presented and discussed in detail in this chapter.

Now that we can render primitives we need to light them to make them look more interesting. Chapter four sheds some light on this by discussing the lighting and material model used in OpenGL's fixed-function pipeline. The best part of this chapter is the section titled "Debugging Lights", which gives some insights and helpful advice on how to debug OpenGL programs that use lighting. Many other books only describe the features of OpenGL lighting but do not explain common debugging techniques that can be applied when all you get is a black window instead of a nicely lit scene.

Chapter five is about pixel rectangles, in particular how to read from and write to the framebuffer. Some performance considerations are also discussed, which is a good thing since reading from the framebuffer is a costly operation. Again, this chapter concludes with a nice section on debugging techniques. The explanation of the raster position in this section is probably the easiest to understand that I have read to date.

Chapter six is a comprehensive chapter on 2-dimensional texture mapping that also discusses some more advanced applications of the technique, such as light maps and depth maps. Also using cube maps as environment maps is introduced. 1-dimensional and 3-dimensional texture mapping was omitted from the discussion.

Chapter seven deals with detecting the feature set of the OpenGL implementation, in particular, determining the version of the OpenGL specification the implementation adheres to and the available extensions. This chapter also discusses how to retrieve and use entry points for available extensions.

Finally, chapter eight deals with the platform-specific interfaces required to hook up an OpenGL program with the underlying operation system. These platform-specific interfaces are called GLX for Unix, WGL for Windows, and AGL for Mac.

The book has four appendices, which deal with a quick overview of advanced features, best practices, performance-related issues and debugging tips and tricks. Especially the latter two appendices on performance and debugging contain a lot of insights invaluable to programmers just starting out with OpenGL.

The book is printed in black and white throughout. Having some color plates in the book itself would have been a welcome addition considering that the topic is computer graphics. However, you can download some color plates from the books website at where you will also find the source code to the example programs in the book.

In conclusion, "OpenGL Distilled" is an excellent introduction to OpenGL, not only for someone new to 3D graphics programming but also for those that have worked with other 3D graphics APIs in the past that wish to get up to speed with OpenGL quickly. The book omits advanced and deprecated features that would unnecessarily overwhelm a beginner with OpenGL and is a good companion on the way to becoming an experienced OpenGL programmer.

The review author has been involved in real-time graphics programming for more than 10 years and works as a games developer for arcade games. In his rare spare time he works on a graphics-related open source project called XEngine http://xengine.sourceforge.net./

You can purchase OpenGL Distilled from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

6 of 96 comments (clear)

  1. picking by stinkytoe · · Score: 2, Interesting
    Some deprecated features, such as the feedback buffer, that are no longer commonly used are left out as well.
    Just out of curiosity, how is picking usually done nowadays, if not with the feedback buffer? Geometrically (i.e. outside of the OpenGL Machine)? Or does OpenGL provide another tool for picking?
    1. Re:picking by Intron · · Score: 3, Interesting

      Use selection mode instead of feedback mode and render at the coordinates. The hit records will indicate the rendered objects and their depths.

      --
      Intron: the portion of DNA which expresses nothing useful.
  2. Re:No, we're not gaming. We're doing real work. by jackbird · · Score: 2, Interesting

    ...which is why Vista's lack of OpenGL support scares the bejeezus out of me as a 3D artist with 10 years on a Windows-only app under my belt.

  3. Re:Speaking as a software engineer by uchian · · Score: 2, Interesting

    Direct X is not cross platform, so is not an option for us, but Direct X is very heavy in areas that openGL is very light (in openGL, the limitation on drawing geometries is much less than the Draw index Primitives (DIP's) in directX, although state changes are heavy.

    Overall, the openGL interface is much simpler to optimize than directX. That is from my experience of both (althoguh I admit my experience of optimizing direct X is much less than that of openGL), in both cases batching is incredibly important, in openGl what is going on is very transparent.

    But coming from the simplicity of openGL, it has to be said the over-complicated COM interface of Direct X is hideous...

  4. Re:Hey guyz! Lets pretend anyone uses OpenGL! by CherniyVolk · · Score: 2, Interesting

    DirectX does kick the shit out of OpenGL, but OpenGL is free.

    How ignorant, and blind, can a person be to make this statement? DirectX, is probably... why even try to explain how much crap DirectX is. You're definately a consumer. In the most negative sense of the word.

    DirectX, will, and you mark my words, NEVER be of enough quality to be used in CGI REALISM. OpenGL can, generate very realistic renders... so realistic, it's used in all major film FX.

    The reason why OpenGL games aren't as good looking, is becuase it targets the consumer; you know, morons like yourself. Who, do not have the hardware to render heavy duty OpenGL sequences. Before you jump up and down, your lame GeForce 9999999 is crap and only geared towards the most common 3D calls for GAMERS and CONSUMER LEVEL 3d applications. There is NOT ONE consumer level card, even for a scant 400-500 dollar hot release, that has hardware acceleration for 100% of ANY 3D API... even DirectX.

    Now, what Microsoft did, was compose a bunch of wiz-bang API calls into DirectX, while OpenGL programmers are left to write their own. OK, does this mean DirectX is better? The only thing "better", is time for development. As far as seeing an EXACT same effect used in ALL DirectX games???? Anyways... with all the exposure of the white collar sweat shops of EA Games and other such game development houses... no wonder a lot of games on the shelf were developed under pure management and they chose DirectX and Windows as their primary market. However, a few of those programming houses actually know a thing or two about 3D programming, actually have the resources and clout to take the time to do something RIGHT. idSoftware for one, and what API do they chose? Not DirectX! And, there's a reason why. Becuase it f*cking sucks, I can't put it anymore blatant than that.

  5. Buy this book! Support Paul! by XenonOfArcticus · · Score: 3, Interesting

    Full disclosure: Paul is a friend of mine, and I helped proof this book too.

    In all seriousness, this is an excellent book. Paul wrote this book to fill a serious need -- an updated, quality OpenGL book for this age. So much of what is in the canonical texts is no longer important (geometry by Begin/End), and they won't cover the new recommended practices (VBOs, Vertex Arrays, etc).

    On a personal level, Paul is one of the most generous and helpful programmers I know. I owe him lots of beer for all the advice he has provided. He also participates in the open source OpenScenGraph project:
    http://openscenegraph.org/
    a high-performance 3D toolkit for Windows, Mac and Unix/Linux, used in hundreds of open source and commercial simulator, game and 3D visualization projects (including my company's NatureView Express tool http://3dnature.com/nv.html -- plug plug!)

    --
    -- There is no truth. There is only Perception. To Percieve is to Exist.