Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×

OpenGL Distilled 96

Posted by samzenpus from the good-graphics dept.
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.
This discussion has been archived. No new comments can be posted.

OpenGL Distilled More

OpenGL Distilled

Comments Filter:

  • I like this book (Score:3, Informative)

    by 2.7182 ( 819680 ) on Wednesday August 30, 2006 @03:21PM (#16009807)
    My only complaint is that the binding broke in a couple of weeks, and I had lost the receipt. So hold onto it.

  • OpenGL 2.0 library for Linux from ATI/AMD? (Score:1, Insightful)

    by Anonymous Coward
    This is the sort of book that may become quite useful in the future. Over at OSNews there have been some rumors that the AMD/ATI combo will be releasing a high-quality OpenGL 2.0 implementation to take advantage of the many OpenGL-related advancements there have been for X recently. Supposedly they want to be at the cutting edge of technologies like Xgl, Compiz, glitz and so on.

    I really don't know if this is idle speculation or there is some basis to it, but it is something interesting to consider. Perhaps

    • Re: (Score:2, Funny)

      by Anonymous Coward
      Yeah, It's been a while since you last checked.

    • Re: (Score:1)

      by lee1026 ( 876806 )
      If this is true, then we might finally get some competent drivers from the new AMD/ATI. Also, they might cook up CPU instructions that are much faster at running ATI graphics drivers.

  • A reasonable overview of OpenGL (Score:5, Informative)

    by kafka47 ( 801886 ) on Wednesday August 30, 2006 @03:44PM (#16009994) Homepage

    I'm reading this right now, and it is substantive and helpful. The downside is that it can get rather terse at times, without as much explanation as I felt was deserved. I suppose that's why they called it, "distilled". :)

    Anyhow, the bulk of the book is not for the faint of heart. Be dialled when you read this, you're not getting any hand-holding.

    It's interesting the review above was written by one of the technical reviewers of the book, the result being more of an overview than a pure objective review (with positives, negatives). Or maybe I'm asking too much.

    /K

  • This sounds like an interesting book to read over coffee or something. But does it cover that weird thing where the RGB values are 16-bit in some places and 24-bit in others? That really confused me in the past.

  • picking (Score:2, Interesting)

    by stinkytoe ( 955163 )
    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?

    • Re:picking (Score:4, Interesting)

      by Intron ( 870560 ) on Wednesday August 30, 2006 @04:52PM (#16010596)
      Use selection mode instead of feedback mode and render at the coordinates. The hit records will indicate the rendered objects and their depths.
    • Nowadays most OpenGL apps do picking geometrically. It's true that using gl's selection mode does work, but this is not hardware accelerated and therefor avoided in most applications. There is a way to do accelerated picking using FBOs (framebuffer objects, or aka render to texture), by assigning each object a unique color, rendering to the FBO with a pick matrix, and then reading the color value out of the FBO, but as far as I know, this is only of limited usefulness since most OpenGL apps have access to t
    • Generally, it is done without OpenGL. The most common solution is probably just to trace a ray through the scene. It's almost always faster than going back and forth with the GPU.
    • if you are doing advanced picking such as picking on terrain and you want to retrieve the (x,y,z) you can use gluUnProject which converts screen coordinates to window coordinates. this takes the x,y of the mouse on the screen and sends a "ray" i assume to give you your 3D version of wherever you picked. You have to make sure that you do a glLoadIdentity() though. thats a very quick and dirty answer but really more detailed.
  • I'm in the market for a new computer, and I'm going to be writing games for it.

    What's the deal with developing with OpenGL on linux at the moment? Last time I tried (2002 maybe?), there was something called Mesa, another thing called DRI or some such, another thing called GLX. It all got a bit confusing. I ended up using cygwin for a bit, then finding something else to do.

    Is it the case now that I can just 'apt-get install opengl-devel' and have stuff just work?
    • OpenGL is a open source 3D graphics rendering standard, sort of like direct x without sound and I/O support.

      Mesa is a open source linux OpenGL compatible library, you will find that other venders make Linux openGL compatible librarys like ATI. Example if you install the Official ATI linux video drivers you also get their version of openGL library along with it.

      DRI (Direct Rendering Infrastructure) this open source video driver system allows direct access to the video card which in turn improves OpenGL pref
    • There is a devel package for mesa that provides basic OpenGL bindings (since Mesa is a software OpenGL-compatible library) and headers. It provides a (roughly) complete OpenGL 1.3 implementation (I'm pretty sure it's 1.3 with extensions), and while not explicitly licensed, is widely considered a standard implementation. It's everything you need to develop OpenGL apps.

      Of course, nVidia and ATi drivers provide their OWN OpenGL libs and headers, nVidia's implementation being a full-blown version 2.0, and it

  • That's odd (Score:4, Funny)

    by o-hayo ( 700478 ) <andy@[ ]x.org ['lbo' in gap]> on Wednesday August 30, 2006 @05:41PM (#16011051)
    If movies taught me anything its that The Red Book is NSA Trusted Networks and doesn't fit on shelves.
  • I like OpenGL, but my one problems is the lack of ease it gives for Win32 Programmers. I know it is cross-platform, but to program a opengl app in linux and win32 are totally different, so what's the point in developing a OpenGL app if the audience you intent on targeting is small(I.E. Linux)? Why not just setup for MS's DirectX which will obviousally win your apps much more support.

    • Re: (Score:2, Insightful)

      by Anonymous Coward
      What the hell are you gibbering about? An OpenGL app isn't automatically cross-platform, so you may as well use Direct3D? Huh?

      The platform-specific code you need to get an OpenGL app working on Windows is virtually identical to the code you need to get a Direct3D app working on Windows. It's a little more complicated, because Microsoft haven't updated it in well over a decade, but it's really quite simple to do if you know anything about Win32 programming. It's also a tiny little thing that you only have to
    • Use Simple DirectMedia Layer [libsdl.org] or Qt [trolltech.com].
      • Just because SDL compiles on a platform doesn't mean it automatically works. You still need to test it and make some platform specific changes. Someone was bitten by this in a 24hour gamedev competition I was in. Their game worked fine in Linux, but nobody else had that so we couldn't run his app. He compiled a Windows version but it didn't work.

        • Re: (Score:3, Insightful)

          by babbling ( 952366 )
          ... so?

          You'd be crazy not to perform some testing on all platforms. Small tweaks for each platform is a hell of a lot better than completely different code for each platform.

    • Re: (Score:1)

      by sowth ( 748135 ) *

      Yes, and you could also write your programs so they only work with a specific joystick and a specific soundcard only on computers made by IBM.

      When you write a program, you should make sure it only works on the exact equipment you specify. Damn those stupid lusers for wanting anything else!

    • Re: (Score:2, Insightful)

      by Fartacus ( 715599 )
      OpenGL works just fine on Windows. At the end of the day, OpenGL draws triangles and DirectX draws triangles, and they both do it pretty well.
      What sort of support will DirectX win your apps? I develop with OpenGL and with DirectX (my renderer has a backend for both), and I get about the same amount and quality of support for both APIs.
      My preference is DirectX, but that's just a matter of taste. Like I said, OGL and DX both draw triangles pretty well.
  • How well does the book cover the subject of stereoscopic 3D?
    BTW, for anyone reading this -- does anyone know how to get Google Earth to do stereoscopic 3D?
    • Stereoscopic 3d: Render with the camera at 1.5" to the left and 1.5" to the right of the viewpoint. Depending on your stereo-rendering abilities:
      Flick them in even/odd to left/right respectively, sending the 'change' signal to your LCD glasses on each frame.

      Render them simultaneously to a pair of framebuffers. Combine the left:red channel and the right:blue/green channels to the screen. Put on your 50's 3d movie glasses.

      Render half-screens, right and left swapped, and cross your eyes.

      Render half-screens,
    • This book does not cover stereo rendering. Sorry, but being "distilled" meant that many things had to fall by the wayside.

  • Buy this book! Support Paul! (Score:4, Interesting)

    by XenonOfArcticus ( 53312 ) on Thursday August 31, 2006 @12:18AM (#16013223) Homepage
    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/ [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 [3dnature.com] -- plug plug!)

    • Re: (Score:1)

      by bobtodd ( 189451 )
      I recognise Paul's name from comp.graphics.api.opengl, used to read it several years ago. It's great to see him condensing his knowledge into book form, thus helping newbies en masse. I learned a great deal from reading his posts, and iirc he used to maintain the FAQ. Kudos to someone who helped make (a part of) Usenet useful.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close