Forgot your password?
typodupeerror

OpenGL Shading Language 2nd Edition 52

Posted by samzenpus
from the making-better-shadows dept.
Martin Ecker writes "The Orange Book is back in its second edition. Randi J. Rost's "OpenGL Shading Language" (also called the Orange Book because of its orange cover) published by Addison-Wesley returns with 4 new chapters, roughly 140 new pages and quite a few new sample shaders. Like the first edition, the second edition of the book is one of the best introductions to GLSL - the OpenGL Shading Language - that also explains in-depth how to develop shaders in GLSL for lighting, shadows, animation, and other topics. The book targets an audience that is already familiar with computer graphics and with OpenGL. Knowledge of the C programming language is also advantageous for the reader. Since I've reviewed the first edition previously, I will focus on the new chapters of the book in this review." Read the rest of Martin's review.
OpenGL Shading Language (Second Edition)
author Randi J. Rost
pages 740
publisher Addison-Wesley Publishing
rating 9/10
reviewer Martin Ecker
ISBN 0-321-33489-2
summary A solid introduction to developing shaders in the OpenGL Shading Language GLSL.


GLSL is now officially a part of OpenGL 2.0, whereas it was only an extension to core OpenGL at the time of release of the book's first edition. Naturally, the Orange Book has been updated to reflect all the changes. Not much has changed in the shading language itself, though. However, there were some minor modifications to the C shader API used to create and upload shaders to the graphics hardware from the program running on the CPU. In order to make the transition easier for old-timers like me who have worked with the old API, the book contains an appendix that details all the changes that the shader API has undergone with the promotion to core OpenGL.

The most notable additions to the book in its second edition are the new chapters on lighting, shadows, surface characteristics, and RealWorldz, a demo that uses shaders exclusively for all rendering and that generates even the rendered models purely procedurally via shaders.

The new chapter on lighting goes into the details of developing lighting shaders that differ from traditional fixed-function lighting offered by the OpenGL fixed-function pipeline. In particular, shaders for hemi-sphere lighting, image-based lighting using environment maps as light probes, and spherical harmonics lighting are developed in this chapter. Note that the theory behind spherical harmonics lighting is not presented in the book. So if you want to fully understand the presented shaders, you will have to read up on the theory in the references given in the book. The chapter on lighting is concluded by a discussion of the ÜberLight shader, a shader for a very versatile lighting model initially presented as RenderMan shader by Pixar Animation Studios.

An important topic in computer graphics now has its own chapter in the Orange Book: Shadows. The new chapter on shadows presents ambient occlusion, shadow maps, and an interesting technique for rendering shadow volumes using deferred shading. The latter technique can be used to render soft shadows convincingly.

Another new chapter in the second edition of the book is on surface characteristics. This chapter discusses and develops shaders to render surface materials that exhibit complex light interaction. The chapter starts out with a discussion of refraction and presents shaders to archive the classic Fresnel reflection/refraction and chromatic aberration effects. Then diffraction, i.e. light bending around sharp edges, is discussed and a shader is developed that renders a vinyl record realistically. Finally, the chapter focuses on BRDF-based lighting and develops various material shaders using the BRDF model.

The final new chapter in the second edition is on RealWorldz. RealWorldz is a demo that renders planets with fractal terrain, oceans, sky, and other effects. Everything in the demo is generated procedurally through GLSL shaders and the chapter describes the techniques used in implementing the demo. At the end of the chapter it says that the demo is available upon request from 3Dlabs, which I find ab it disappointing. Let's hope that the authors put up a downloadable version of the demo, or at least a video of the demo, on the book's webpage.

As in the previous edition, all images and diagrams in the book are in black and white, except for a few pages that contain 38 color plates in the middle of the book. In addition to the images from the first edition, the book now has some very impressive images from the RealWorldz demo. A nice addition to the book is the detachable cheat sheet at the end of the book, which contains a quick reference of GLSL and the shader API entry points - very handy to have on your desk in the heat of a late-night coding session.

The book's accompanying website at http://www.3dshaders.com/ offers the source code to all the shaders presented in the book for download. Also available are other shaders not mentioned in the book and a demo application including source code, which nicely demonstrates the shaders in action. The demo application and most of the shaders are available under a very liberal BSD-style open source license.

The book "OpenGL Shading Language (Second Edition)" remains an excellent introduction to shader programming with GLSL. It provides a profound discussion of the shading language itself as well as the C shader API used to create and manage shaders in the host program. The book also has numerous chapters on developing shaders for various applications, such as lighting, shadows, animation, and other areas of real-time computer graphics. The newly added chapters in the second edition nicely complement an already good book. If you're interested in learning GLSL and shader programming in OpenGL, this is the book to get.

About the review author:
The 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 Shading Language 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 Shading Language 2nd Edition

Comments Filter:
  • GLSL compiler (Score:3, Interesting)

    by ardor (673957) on Wednesday February 22, 2006 @03:17PM (#14778578)
    I still don't understand why the compiler was moved into the GL server. I mean, it makes writing ICDs even harder than it is already, and doesn't have any obvious benefits. Why not simply standardize some bytecodes and have people write free GLSL->bytecode compilers?
    • Re:GLSL compiler (Score:3, Informative)

      by Anonymous Coward
      it allows the driver to do optimisations related to the card's architecture
    • Re:GLSL compiler (Score:5, Informative)

      by AKAImBatman (238306) <<akaimbatman> <at> <gmail.com>> on Wednesday February 22, 2006 @03:29PM (#14778685) Homepage Journal
      I still don't understand why the compiler was moved into the GL server.

      Because the different graphics cards implement very different processors. Taking maximum advantage of those processors is easier if you can glean the intent of the source code. Once it's compiled down to a bytecode level, you have to start looking for structure among all those instructions before you can decide which ones can be optimized.

      The compiler can also consider tradeoffs that bytecode cannot. For example, the compiler can decide if variables X and Y will be used shortly and thus should be loaded into registers, or if they'll be hanging around for quite a long time and should be pushed onto the stack. It can also more easily detect out-of-order instructions, and do an analysis of the code to produce SMID instructions if the code is streaming. Again, all much more difficult to do from a bytecode level.
      • Uh, not really. It depends what your bytecode looks like. It can be much easier to analyze bytecode than source code.
  • PS3? (Score:3, Interesting)

    by Anonymous Coward on Wednesday February 22, 2006 @03:30PM (#14778691)
    Since the Playstation 3 is using OpenGL, could the information in this book be relevant for people writing games for the PS3? Or are shaders in the RSX different?
    • Re:PS3? (Score:4, Insightful)

      by mikael (484) on Wednesday February 22, 2006 @03:50PM (#14778854)
      The mathematics of rendering and lighting remain the same regardless of the underlying architecture or graphics API. That's the whole point of shading languages; developers can focus on the mathematics without having to worry about the small details (ie. which assembly language instructions are available on which card).
    • No, it is not relevant. PS3 is using Cg (a bit logical, nVidia developed the graphic chipset) and OpenGL ES which is quite different to the standard OpenGL (it's OpenGL without the 'legacy' stuff like glBegin / glEnd).
      • Re:PS3? (Score:5, Informative)

        by SlayerDave (555409) <elddm1.gmail@com> on Wednesday February 22, 2006 @04:21PM (#14779116) Homepage
        The driver-level compiler for GLSL and Cg is identical in NVIDIA cards. In fact, the little-publicized OpenGL extenstion GL_EXT_Cg_shader allows the programmer to use shaders written in Cg through the GLSL API without having to use the Cg runtime library. The point is that Cg and GLSL are extremely similar in syntax and structure. There are a few differences, but if you know one shading language, you basically know them all.
        • Re:PS3? (Score:2, Insightful)

          by jinzumkei (802273)
          Yup makes no difference if you learned GLSL, Cg, or HLSL you should have no problem using any.
    • Re:PS3? (Score:3, Informative)

      by sysrpl (740738)
      While shading language like Microsoft's HLSL, Nvidia's Cg, and OpenGL's GLSL are similar, they have slight syntax and usage differences.

      In this case, the PS3 shading language is Nvidia's Cg with a few enhancements. So, if you wanted to write GFX for it you are going to need to Cg and you should study that (as oppossed to GLSL).
  • What's the latest with Windows Vista and support for OpenGL beyond the 1.4 APIs? Last I heard it was a no-go due to the heavy integration of DirectX/Direct3D into the desktop (unless you shut off the schwingy graphics anyhow). Is that still the case or will vendors be able to support OpenGL 2.0 and beyond in Vista?
    • by ardor (673957) on Wednesday February 22, 2006 @04:04PM (#14778952)
      AFAIK it is a driver issue, actually. If MS wanted to kill off OpenGL, they would simply dump it. However, since writing an OpenGL ICD is far from being an easy task, the d3d-gl-bridge serves as a default 1.4 GL implementation. This is useful for cheap graphics chips which have drivers lacking good GL support (my old laptops Lynx3DM chip for example). IHVs still have the option to provide their own ICD simply by replacing the OpenGL32.dll. Since D3D and OGL are just interfaces to the driver, it is possible for them to mix the two, for example by providing an overall graphics server (which acts like a GL server too) and D3D/OGL apps being clients.
      • The controversy is that for IHVs to provide their own ICD requires internal knowledge of the Desktop Compositing system that Microsoft has apparently not provided to the level needed for proper support. Microsoft is taking full steps to eliminate OpenGL in Windows Vista, starting with pushing it aside as a second-class citizen. The goal is to put their Windows/DirectX APIs everywhere, which was the whole purpose of the X-Box to begin with (in other words, they don't give two shits about games; they just w
        • I doubt Vista's WDM architecture is mature and stable enough to be released. Thus, it would not make ANY sense to send nVidia & co. the specs right now, since they are still subject to change. Furthermore, the IHVs WILL demand knowledge about the internal structure in order to optimize their drivers. Also, don't forget that Autodesk, Alias, nVidia itself, XSI etc. demand OpenGL support; don't underestimate this pressure.

          Time will tell. Once Vista is released, we'll see.
    • The current nVidia drivers do not contain OpenGL support - instead, you get the Microsoft wrapper. However, this very well could be a case of nVidia just giving you the bare minimum to mess around with the beta. So there is still hope..
  • <rant>
    Sigh.....
    It really hurts my language designer nerve when I see the state of shading languages. They are all supposedly based on C, which is total nonsense. Only the syntax looks like C, the semantics is much more like Ada than anything else. And then there is the question of whether C or Ada are the most suitable language to mimic in this situation. I think not. Shading computations are inherently functional. Any shader is easily and succinctly specified as a mathematical formula. I think that
  • The final new chapter in the second edition is on RealWorldz. RealWorldz is a demo that renders planets with fractal terrain, oceans, sky, and other effects. Everything in the demo is generated procedurally through GLSL shaders and the chapter describes the techniques used in implementing the demo.

    While this is a nice tour-de-force demo of a capability, it strikes me that a more important demo of this scale is to use ALL of OpenGL's capabilities to its fullest, and highlight "best practices" for presentin

    • Keep in mind that OpenGL does not itself directly support scene graphs.
      The modelview matrix stack can easily be used to implement scene graphs,
      but OpenGL defines no data structure for actually representing a scene graph.

      I'm just nitpicking though. Your point is a good one: just because you can code an entire application as a bunch of shaders, doesn't mean it makes sense to.

"Out of register space (ugh)" -- vi

Working...