Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

OpenGL Shading Language 3rd Edition

samzenpus posted more than 4 years ago | from the read-all-about-it dept.

Graphics 46

Martin Ecker writes "The “OpenGL Shading Language” (also called the Orange Book because of its orange cover) is back in its third edition, with updated discussions of the OpenGL shading language (up to version 1.40, introduced with OpenGL 3.1). Like the previous edition, the third edition of the book is one of the best introductions to GLSL — the OpenGL Shading Language — that not only teaches the ins and outs of GLSL itself but also explains in-depth how to develop shaders in GLSL for lighting, shadows, animation, and other topics relevant to real-time computer graphics." Keep reading for the rest of Martin's review.Not unexpectedly the book starts out with a brief review of OpenGL basics. However, I would not recommend diving into this book without having prior experience with OpenGL, or at least with some other kind of 3D API, such as Direct3D. The book targets an audience that is already familiar with computer graphics and with OpenGL. Furthermore, knowledge of the C programming language is expected.

The next few chapters introduce the syntax and semantics of GLSL. At its core, GLSL is very similar to C. All the usual control flow statements, such as if statements and for loops, are available. However, the language adds some graphics-specific types, such as vectors and matrices. Even though this material is fairly dry, the writing is easy to follow and all concepts are presented with plenty of examples. Also uniform blocks — a new feature of GLSL version 1.40 — are discussed. Uniform blocks are used to efficiently send a block of variables via a uniform buffer to the GPU.

After familiarizing the reader with the language itself, chapter four delves into the integration of the shader-programmable units into the OpenGL pipeline, in particular the vertex and fragment shader units. Note that geometry shaders are not discussed in this book since they are a fairly recent addition to the OpenGL 3.2 specification. The next chapter goes over all the built-in, common functions that GLSL provides, such as sin, cos, abs, fract, and so on. Being more of a visual learner, what I really like about this chapter that the authors provide function graphs for each of the functions introduced. After all the basics of the shading language have been laid out in previous chapters, chapter six is dedicated to a full-fledged example that uses GLSL to procedurally render a brick pattern. If you're already familiar with other shading languages, such as Direct3D's HLSL or Cg, and you want to switch over to OpenGL/GLSL, I recommend jumping straight to this chapter to see how much you can grasp and then going back to the preceding pages to fill in the blanks if necessary.

The somewhat lengthy chapter seven contains detailed descriptions of the entry points provided by OpenGL to create and set up shader programs. Among other things, it describes how shader objects are created, compiled, and then linked to form shader programs that can then be used to render objects. Chapter seven concludes the dry, technical part of the book that introduced both the shading language and the necessary infrastructure to use it from a host program running on the CPU. The remainder of the book concentrates on numerous graphics techniques that can be achieved with shaders, such as bump mapping, lighting, shadows, animation, procedural effects, and many more. In short, it's the real fun part of the book where all the theory gets put into practice.

One of the highlights for me is the chapter on writing lighting shaders that discusses hemi-sphere lighting, image-based lighting using environment maps as light probes, and spherical harmonics lighting. 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.
Where there's no light there's shadow and so the book has an interesting chapter on various shadowing techniques, in particular 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.

The most interesting chapter for me in the book is the one on surface characteristics. It discusses and develops shaders to render surface materials that exhibit complex light interaction. The authors start out with a discussion of refraction and present shaders to achieve the classic Fresnel reflection/refraction and chromatic aberration effects. Then diffraction, i.e. light bending around sharp edges, is discussed and a shader that renders a vinyl record realistically is developed. Finally, the chapter focuses on BRDF-based lighting and develops various material shaders using the BRDF model, a quite important topic nowadays since more and more video games now actually use BRDF-based lighting models.

Another important chapter in the book in my opinion is chapter seventeen about antialiased procedural textures. I consider it important because it is often ignored that shaders that procedurally create textures usually suffer from aliasing artifacts. This chapter shows a number of anti-aliasing techniques to diminish these issues. Chapter eighteen is a fun chapter on non-photorealistic rendering, discussing hatching, Gooch shading, and how to render the Mandelbrot set in a shader. Finally, the book closes with a comparison of GLSL with other shading languages, in particular RenderMan, HLSL, and Cg. This is mostly of interest to real geeks and language lawyers ;)

As in the previous edition, all images and diagrams in the book are in black and white, except for a few pages that contain 34 color plates in the middle of the book. Most of the images are not overly "flashy" but do give a practical idea of the types of rendered images a particular shader can produce.

The book’s accompanying website 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. Most of the shaders are available under a very liberal BSD-style open source license.

The third edition of "OpenGL Shading Language" is an excellent introduction to shader programming with GLSL. It provides an in-depth and comprehensive discussion of the shading language itself as well as the C shader API used to create and manage shaders in the host program. The best and largest part of the book focuses on developing shaders for various applications, such as lighting, shadows, animation, and other areas of real-time computer graphics. If you’re interested in learning GLSL and shader programming in OpenGL, this is the book to get.

Martin 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 Shading Language 3rd ed. from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

cancel ×


Sorry! There are no comments related to the filter you selected.

Tricky language to get your head around. (3, Interesting)

jcr (53032) | more than 4 years ago | (#30091176)

Something that keeps tripping me up with GL/SLANG is that it's close enough to C that I keep forgetting that it's not C. Fortunately, when I write SLANG code in Quartz Composer, the compilation happens instantaneously as I type, so I can't go too far wrong before I know there's a problem.


Re:Tricky language to get your head around. (0)

Anonymous Coward | more than 4 years ago | (#30091340)

"The "OpenGL Shading Language" (also called the Orange Book because of its orange cover)"

Oh no, you spoiled it - you'll be telling me there is no Sanity Clause next.

Re:Tricky language to get your head around. (1)

Mastadex (576985) | more than 4 years ago | (#30091440)

I personally prefer using NVidia's CgFX framework. It combines the syntax of GLSL and the awesome Effects framework from DirectX. It's merely a personal preference.

Re:Tricky language to get your head around. (1)

ScoLgo (458010) | more than 4 years ago | (#30092422)

"Power is like uranium: let too much of it accumulate in once place, and Bad Things Happen."

Sorry to reply to a .sig but... I first read that as "Power is like urine :..."

Hmmm... I guess that doesn't really negate the statement tho, does it... ;-]

Re:Tricky language to get your head around. (1)

quadelirus (694946) | more than 4 years ago | (#30095148)

I'm learning GLSL right now and I would like to use it with Quartz Composer but I've never really worked with Quartz. Do you know of any tutorials related to using Quartz Composer that specifically deal with using GLSL?

Re:Tricky language to get your head around. (1)

jcr (53032) | more than 4 years ago | (#30097272)

Not sure about the tutorials, but if you want to write SLANG code in QC, just use the "GLSL Shader" patch. The code is edited in the "settings" pane of the inspector panel.


OpenGL 3.2 promises big changes (0, Funny)

Anonymous Coward | more than 4 years ago | (#30091224)

This will be the first version of the API with support for shading objects other than teapots.

Re:OpenGL 3.2 promises big changes (2, Funny)

Bill, Shooter of Bul (629286) | more than 4 years ago | (#30092150)

Great more API bloat. Everyone knows you can represent any given object with a series of differently shaped teapots. Why, just take a look at thease examples:
  1. []
  2. []
  3. []
  4. []
  5. []

there are more, but some of the were not safe for work...

How Much Does (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#30091316)

Slashdot get for pushing books on topics of which 99% of
Slashdot readers are aware?

A better use of Slashdot would be a discussion of How U.S. Pays Taliban To Protect Its Truck [] .

Yours In Yaznogorsk,
K. Trout

I'll pass (2, Informative)

WilyCoder (736280) | more than 4 years ago | (#30091358)

Almost the end of 2009 and no geometry shaders in this book?

I'll pass...

Re:I'll pass (2, Informative)

Mastadex (576985) | more than 4 years ago | (#30091406)

You can always pick up a book that deals with OpenGL extensions. The GL_NV_gpu_program4 shading extension is just one of the geometry extensions you can use.

Re:I'll pass (3, Interesting)

GenP (686381) | more than 4 years ago | (#30091554)

Almost at the end of 2009 and no viable OpenGL 3.2 reference implementation...

Re:I'll pass (1, Informative)

Anonymous Coward | more than 4 years ago | (#30091936)

Geometry Shaders are implemented as extensions and thus, are not part of the base language, which is what this book focuses on. you thought it was by accident that its not been part of the book all these years???

Re:I'll pass (3, Interesting)

WilyCoder (736280) | more than 4 years ago | (#30092194)

I've been writing GL code for 6 years now. My original post was more of a frustration with the ARB/Khronos' sluggish adoption of the extensions. Yes, I know its always been that way. But still...

Re:I'll pass (0)

Anonymous Coward | more than 4 years ago | (#30093606)

Almost everything interesting in OpenGL is extensions, including the entire shader system. Geometry shaders are ARB now, which makes them very much official. It just may not have been in time for the book to go to print. The orange and red books are only de facto official references, but they're not the complete spec by any means. It's a regrettable omission for a book that's supposed to be the definitive reference, but then again a lot about the OpenGL process is regrettable these days.

THIS is a real domain specific language. (2, Interesting)

Anonymous Coward | more than 4 years ago | (#30091392)

We hear Rubyists and Lispers trumpet on about "domain specific languages" a lot. DSLs, they call them. Their so-called "languages" are nothing more than function or class libraries.

This, on the other hand, is an actual domain specific language.

Re:THIS is a real domain specific language. (0)

Anonymous Coward | more than 4 years ago | (#30095230)

There is no difference...

Re:THIS is a real domain specific language. (1)

DaVince21 (1342819) | more than 4 years ago | (#30097386)

The difference is that this language is written specially to be used in the domain of video hardware.

Re:THIS is a real domain specific language. (0)

Anonymous Coward | more than 4 years ago | (#30098478)

Okay, I'll bite.

First, screw Ruby.

Now for the second part: GLSL is transformed by a compiler into binary code. The code will pass through various states of representation: list of tokens, AST, ASM, etc. Lisp's dynamic runtime system lets you tap into those transformations. You can write a parser that translates GLSL into a Lisp program that can you can compile at run-time. With Lisp, it doesn't matter if the DSL is expressed in the host language's syntax or not. It's a little bit easier if it is, because then you can use macros to do the translation. If not, a parser can turn the program into a tree of s-expression. What you do from there on is your decision, but calling "nothing more than function [sic] or class libraries" is like calling an operating systems a collection of functions. Misguided and not really contributing to the discussion.

Say hello to third edition... (5, Informative)

perrin (891) | more than 4 years ago | (#30091506)

...which is exactly the same as the second edition. Almost. But not quite as painfully obvious a reprint as the OpenGL book that usually accompanies it (the Red Book). It just had some warnings that OpenGL 3 is, like, totally different, and saying that we are not going to bother with any of that, despite announcing that prominently on the cover of the book. Nothing on, for example, how to do transforms without all the old pipeline commands. Lots on, say, display lists, instead. Display lists that have been unofficially deprecated now for about a decade. Oh, well.

And for those not in the know, the Orange Book and the Red Book together form the unofficially official documentation for OpenGL.

Someone really needs to step up to produce quality documentation for the new lean and mean non-backward-compatible profile of OpenGL 3 if that is to make any headway. Or maybe that lets-make-the-API-even-more-low-level approach was wrong to begin with, and people are just afraid to say that out aloud like Mark Kilgard of NVIDIA recently did [] (see slide 35).

Anyway, if you are going to work with OpenGL, you need to read those two books. But you can just as well buy the previous edition.

Re:Say hello to third edition... (1)

TheRaven64 (641858) | more than 4 years ago | (#30091666)

Those slides just say that nVidia isn't going to remove or stop accelerating the deprecated bits of OpenGL any time soon because their customers are still using them. It also says that rewriting existing code not to use them is more effort than it's worth (for now), although for new code it's worth avoiding them. Not sure where you got the idea they he said the approach with OpenGL 3.x is wrong. Maybe he said more in person, but your claim is not backed up by the slides.

Re:Say hello to third edition... (2, Interesting)

Hurricane78 (562437) | more than 4 years ago | (#30091782)

I'm a game designer, and not a game developer or graphics designer. But I think I'm a fairly good programmer. But I have trouble getting to that level that is a decade past display lists. What do you recommend for someone who learned OpenGL 1.2 back then, and wants to get up to a top notch experienced professional level in the fastest possible way (meaning with the highest compression of information that is at all possible)!

(I loathe those 600-800 page tomes where every 100 page chapter could be condensed to 10 pages without any loss of information. To get a feeling on my preferred level of information compression, look at the Haskell Report. ^^)

Re:Say hello to third edition... (3, Insightful)

perrin (891) | more than 4 years ago | (#30093444)

If you do not have a passion for low-level graphics programming, I would strongly recommend using a higher level library like OpenSceneGraph or Ogre rather than programming directly at the nuts and bolts level of OpenGL. You get more done that way and leverage other people's experience instead of reinventing so many wheels yourself.

Re:Say hello to third edition... (1)

Hurricane78 (562437) | more than 4 years ago | (#30095058)

That's the thing: I have a passion for high-level physics programming. Meaning I would have my own non-graphics scene graph, and render out the actual scene from that one. But I don't want to put up with all that stupid special trickery. Like manually rendering shadows, instead of them being a natural result of lack of photon radiation. Or the "set of empty hulls" approach, instead of it being real materials with a volume. Etc.

All those standard packages exclusively use those things. And none of them seems no separate the actual rendering from the scene graph representation itself. Which is what I would need:
A library that just does the low-level graphics stuff for me, while leaving the world management (scene, collision, physics, etc) to me.

I could simply create the scene graph of such a complete engine package out of my internal scene graph. But those engines are not made for re-creating the entire scene-graph on every frame. (Which is what I would have to do in that case.) They are made to load a map, and then call commands/scripts to modify things in it.

Re:Say hello to third edition... (0)

Anonymous Coward | more than 4 years ago | (#30094594)

It sounds like graphics programmers had better get the latest editions, before the next edition comes out and strips out all the deprecated (but still viable) APIs, perhaps relegating them to a PDF download.

i'll wait for the 4th (3, Funny)

AP31R0N (723649) | more than 4 years ago | (#30091710)

The grappling rules in 3rd Edition are bitch.

Re:i'll wait for the 4th (0)

Anonymous Coward | more than 4 years ago | (#30097518)

THAC0 calculates collision *not* geometry deformation!!

Orange Book eh? (0)

Anonymous Coward | more than 4 years ago | (#30091766)

Does it say that Thou shalt not make a machine in the likeness of a human mind?

I wanna program for devices small and large... (2, Interesting)

Dr. Manhattan (29720) | more than 4 years ago | (#30091876)

...and I wanna use OpenGL. I know there's OpenGL ES, and there's full-fledged OpenGL. Is there a practical common subset? Are there techniques that scale?

Re:I wanna program for devices small and large... (0)

Anonymous Coward | more than 4 years ago | (#30092110)

Do you have to submit a comment for every story on /.?
Anyways, if you were serious about "I wanna use openGL", you would know whether you needed openGL or the ES variant. I mean, seriously?

Re:I wanna program for devices small and large... (2, Informative)

RAMMS+EIN (578166) | more than 4 years ago | (#30092268)

``I know there's OpenGL ES, and there's full-fledged OpenGL. Is there a practical common subset?''

Depends on which versions you're talking about. As this page about OpenGL ES [] nicely illustrates, there is some overlap, but nothing that works across all four of OpenGL 1.x, OpenGL 2.x, OpenGL ES 1.x and OpenGL ES 2.x.

The differences are in the supported shader models and in the support of fixed-point arithmetic.

OpenGL 1.x has floating point arithmetic and fixed shaders.
OpenGL ES 1.x is sort of an extended subset of OpenGL 1.x, removing features and adding fixed-point arithmetic.

OpenGL 2.x supports everything OpenGL 1.x supports, but adds programmable shaders.
OpenGL ES 2.x is like OpenGL 2.x, except fixed shaders are not supported, and fixed-point arithmetic has been added.

This means that programmable shaders are not in OpenGL 1.x and OpenGL ES 1.x, and fixed shaders are not in OpenGL 2.x. So, no matter which kind of shader you use, there is some flavor of OpenGL that doesn't support it.

Also, note that the non-ES versions of OpenGL don't support fixed-point arithmetic. So if you want full compatibility, you will have to use floating-point arithmetic. That would be fine if it wasn't for the fact that many devices that support OpenGL ES (1.x or 2.x) only support fixed-point arithmetic.

So, basically: no, there is no common subset of all the OpenGL flavors that you can program in and have your program be compatible with all implementations.

mod do39n (-1)

Anonymous Coward | more than 4 years ago | (#30092230)

Assholes, as they and as BSD sinks else up their asses pallid bodies and

New to open GL (2, Interesting)

BlowHole666 (1152399) | more than 4 years ago | (#30092352)

I am new to any open GL or Direct X for that matter. Lets say I wanted to learn open GL, the latest version from the ground up, what would you guys recommend?

Re:New to open GL (1)

ASBands (1087159) | more than 4 years ago | (#30093286)

Don't learn OpenGL, learn graphics and software engineering first. Assuming you want to learn OpenGL for games, I would recommend David Eberly's 3D Game Engine Design [] . It is extremely comprehensive and presents an incredibly well-designed engine, WildMagic (which has inspired many other engines, like jMonkey), for which you are given the full source on CD. If you're not looking for games, then you probably don't need to know the latest OpenGL stuff, because scientific visualization usually doesn't require it. And if you DO need the latest stuff from OpenGL, you're probably not actually doing graphics and you probably shouldn't use OpenGL, but CUDA or some other platform (CUDA = awesome).

In any case, you need to know that OpenGL is just a specification, so you rely on other multiplatform libraries like GLUT, GLFW or SDL. I would personally recommend SDL, since it is awesome. GLFW is nice, easier to use than SDL, but harder to tweak the small things for performance. GLUT development died many years ago, so don't use it.

Re:New to open GL (1)

physburn (1095481) | more than 4 years ago | (#30094688)

I concur. This is very specialised programming, they are ownly a few teams in the world making 3D game engines, once built, like the Unreal engine they tend to sell the engine to other game companies to be used. So only a very elite few progammers will every use OpenGL, unless you'll hoping for a job at ID or Epic games, its probably not worth learning OpenGL.


3D Graphics [] Feed @ Feed Distiller []

Re:New to open GL (2, Informative)

vlakkies (107642) | more than 4 years ago | (#30093390)

OpenGL: A Primer by Edward Angel is very readable and a thin little book that is also inexpensive. I use in my class where I teach OpenGL. The Red Book and others are great references, but Angel is the best way to get your feet wet.

Re:New to open GL (1)

kestasjk (933987) | more than 4 years ago | (#30093738)

Don't :-) Well okay google a guide to GLUT (there are many out there), try and build something and make it more and more detailed. Once you reach a point of diminishing returns, and if you like it, you can browse for a book that'll take it to the next level.

Re:New to open GL (2, Informative)

SplashMyBandit (1543257) | more than 4 years ago | (#30094084)

JoGL is a quite a nice (Java) wrapper for OpenGL. Lets you do the windowing stuff in Java (nice n easy) and then the OpenGL calls translate almost exactly to their documented C equivalents described at: []

DirectX is good for games on the PC and XBox360. OpenGL is good for games (eg. IL2) and engineering on the PC, PS3, iPhone/iTouch, cellphones, military avionics, professional movie rendering, scientific visualization, Solaris/Unix etc. The only platform you can't develop for using OpenGL is the Xbox (less than 1% of computable devices out there), with OpenGL you can use it almost everywhere else (including using software rendering with Mesa on headless platforms). Also, OpenGL changes more slowly than DirectX (which game developer's hate but the rest of us quite like stability and protection of our investment in our existing code - it is too expensive for larger pieces of software to keep getting re-written unlike games which are maintained for a couple of years at most). Your call which way you'd like your career to head.

Unlike an earlier poster I would not suggest learning graphics algorithms first (I guess that person was a computer scientist, this is the kind of thing they recommend). It is like saying you ought to learn assembly language rather than learning how to make shippable programs in something more widely (commerically) used like Java. I would suggest learning OpenGL using something free and easy to start with like the JoGL plugin for Netbeans (syntax highlights GLSL shader language). If you really do have a passion for graphics after you've learned OpenGL then I would say learning the underlying algorithms is an excellent idea and will make you a better graphics developer. But IMHO it is worth learning to be basically productive before trying to learn at an expert level.

People Use GLSL? (0)

Anonymous Coward | more than 4 years ago | (#30092482)

Not to troll, but seriously -- people actually use GLSL? I mean, Cg works with both DirectX (HLSL), OpenGL (GLSL), PS3GL, and there are compilers to scale back to software. It has a cleaner syntax (IMO), a sophisticated effect system, better documentation and more literature. What the hell advantage does GLSL give you over Cg? The fact that you have to repeat yourself due to the lack of #include statements? The lack of arbitrary and automatic parameter connecting? Restriction to OpenGL?

I'm also going to re-state that I'm not trying to troll, since this reads like a troll post. GLSL is seriously lacking in a great number of ways and GLSL 3 fixes many of them (they finally have geometry shaders in 3.2, but that's more of a general GL thing), but it still sucks.

Re:People Use GLSL? (0)

Anonymous Coward | more than 4 years ago | (#30094566)

You can use #include's in GLSL - though you do get error warnings...

Re:People Use GLSL? (1)

quadelirus (694946) | more than 4 years ago | (#30095168)

I'm new to this, so forgive the ignorance, but isn't Cg an NVIDIA technology? Does it run on ATI?

Re:People Use GLSL? (0)

Anonymous Coward | more than 4 years ago | (#30097514)

The language was developed by nVidia and Microsoft, but it works for almost any graphics card and in DirectX or OpenGL in every operating system. Posting AC because nobody on /. would believe that MS would do such a thing.

Re:People Use GLSL? (1)

quadelirus (694946) | more than 4 years ago | (#30098508)

Sweet deal. I'll be checking that out, thanks.

MIckey (0)

Anonymous Coward | more than 4 years ago | (#30093206)

Yet another library (app, tool, etc) ported to Windoze that was built on UNIX.

How many libs have been developed the other way (from MickeySoft to UNIX/OSX/etc)?

in the meantime may I comment (1)

icepick72 (834363) | more than 4 years ago | (#30101692)

I meanwhile haven't read the book yet but am sure it lives up meanwhile to the review considering previous title produced meanwhile by the same publisher.
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?