Beta
×

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 2nd Edition

samzenpus posted more than 7 years ago | from the making-better-shadows dept.

52

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.

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.

cancel ×

52 comments

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

shade my language a deep blue color (0, Flamebait)

Sexual Asspussy (453406) | more than 7 years ago | (#14778539)

like the color I painted Kathleen Malda's eyesocket with a rain of fists

Computer graphics are a fuckin fad and add BLOAT (-1, Flamebait)

Anonymous Coward | more than 7 years ago | (#14778557)

We should all go back to plain text mode consoles to keep the stupid normals away from OUR COMPUTERS.

Re:Computer graphics are a fuckin fad and add BLOA (0)

Anonymous Coward | more than 7 years ago | (#14778888)

Go back to your cave with your charcoal graphics Luddite!

Re:Computer graphics are a fuckin fad and add BLOA (1)

Jerry Coffin (824726) | more than 7 years ago | (#14779411)

We should all go back to plain text mode consoles...

I think we should go one further -- I really miss the times on the Control Data mainframe, with its 6-bit character codes, so (at least in the "scientific" character set) you didn't have to deal with that mamby-pamby lower-case text either. Hollerith cards and fan-fold printouts -- now that's programming!

To really upgrade your graphics experience, replace your ASR-33 with a DECWriter LA-20 and watch those frame rates soar!

GLSL compiler (2, Interesting)

ardor (673957) | more than 7 years ago | (#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 (3, Informative)

Anonymous Coward | more than 7 years ago | (#14778680)

it allows the driver to do optimisations related to the card's architecture

Re:GLSL compiler (1)

larry bagina (561269) | more than 8 years ago | (#14781295)

according to the "java is not slow!" folks, that's also possible with bytecode.

Re:GLSL compiler (5, Informative)

AKAImBatman (238306) | more than 7 years ago | (#14778685)

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.

Re:GLSL compiler (1)

p3d0 (42270) | more than 8 years ago | (#14789959)

Uh, not really. It depends what your bytecode looks like. It can be much easier to analyze bytecode than source code.

Re:GLSL compiler (0)

Anonymous Coward | more than 7 years ago | (#14778828)

Typical F/OSS person's answer: "You're too stupid to understand! MORON!"

Re:GLSL compiler (0)

Anonymous Coward | more than 8 years ago | (#14783909)

What I don't understand was why they use irregular C-like _syntax_. Well, I do understand why from a human-issues perspective, but a scheme or lisp -like syntax would have been rather more technically appropriate and immensely easier to use as an intermediate language.

PS3? (3, Interesting)

Anonymous Coward | more than 7 years ago | (#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? (3, Insightful)

mikael (484) | more than 7 years ago | (#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).

Re:PS3? (1)

execom (598566) | more than 7 years ago | (#14779033)

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? (4, Informative)

SlayerDave (555409) | more than 7 years ago | (#14779116)

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? (2, Insightful)

jinzumkei (802273) | more than 7 years ago | (#14779251)

Yup makes no difference if you learned GLSL, Cg, or HLSL you should have no problem using any.

Re:PS3? (3, Informative)

sysrpl (740738) | more than 7 years ago | (#14779037)

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

Ah, so that's why! (0)

Anonymous Coward | more than 7 years ago | (#14778707)

also called the Orange Book because of its orange cover
Thanks for clarifying that. Otherwise I'd have naturally assumed it was called the Orange Book because nothing rhymed with it.

You can't call any orange book "The Orange Book"! (0, Flamebait)

j-tull (201124) | more than 7 years ago | (#14778765)

Who decided to call this The Orange Book? I had always known the US Department of Defense Trusted Computer System Evaluation Criteria [dynamoo.com] as The Orange Book.
We can't just make up titles. What if I started a new political party with a green flag as our symbol? Can we be the Green Party too?

Re:You can't call any orange book "The Orange Book (0)

Anonymous Coward | more than 7 years ago | (#14778947)

The "Red Book" is the official book on OpenGL itself, and it's red.

Re:You can't call any orange book "The Orange Book (4, Funny)

razvedchik (107358) | more than 7 years ago | (#14779144)

The "Red Book" is the official book on OpenGL itself, and it's red.

I thought the "Little Red Book" was the official book on the GPL. Oh bother, I get so confused.

Re:You can't call any orange book "The Orange Book (2, Informative)

AKAImBatman (238306) | more than 7 years ago | (#14778993)

This is pretty common among standardized technologies. Must I remind you of the CDROM drive?

Yellow Book (Format)
Red Book (Audio)
Green Book (Multimedia)
Orange Book (RO/RW)
White Book (VCD)
Blue Book (Graphics)
Beige Book (Photo)
Purple Book (Double Density)
Scarlet Book (Super Audio?)

That's why it's so important to add which technology you're talking about. e.g. "Orange Book Security", "Orange Book CD Rewritables", and "OpenGL Orange Book".

Re:You can't call any orange book "The Orange Book (1)

d_jedi (773213) | more than 7 years ago | (#14779546)

Not sure if this post was supposed to be in jest (not modded as funny, so maybe not..), but the OGL Programming guide is called the "Red book" and the Reference is called the "blue book" (because of their respective covers) and have been for years. It only made sense when they added shaders to OGL to refer to the book in the same way.

The term "Blue Book" ... (0)

Anonymous Coward | more than 8 years ago | (#14783474)

has been used for some hundreds of years to denote a book of useful facts about some organisation or service.

So I suppose any colour will do for a range of advice documentation.

Maybe someone will research where the original 'Blue Book' came from - I wouold not be suprised to find it is from mediaeval times (or earlier). You will probably find that Cheops' architects issued 'Yellow Books' (or papyri)to the overseers of the quarrying and transport gangs, detailing general principles of working with sandstone, break times, where the first-aid post was, etc.

       

Re:You can't call any orange book "The Orange Book (1)

shrubya (570356) | more than 8 years ago | (#14786627)

Sorry, but ALL of you in this thread are wrong. The REAL Orange Book [google.com] is FDA's list of approved drugs. Even Google agrees.

Flaimbait. (1)

j-tull (201124) | more than 8 years ago | (#14819890)

Dear Mods,

I'm sorry that my "flaimbait" was not able to attract more (read: any) flames. Perhaps you will choose a different brand of "flaimbait" on your next phishing trip.

Regards,
WTF

Vista and OpenGL/GLSL (0)

Mundocani (99058) | more than 7 years ago | (#14778834)

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?

Re:Vista and OpenGL/GLSL (0)

Anonymous Coward | more than 7 years ago | (#14778926)

At the minimum when running accelerated OpenGL the card driver would temporarily stop AeroGlass (so the shut-off is automatic). That means no visible difference for full-screen games :)

More advanced drivers (from major players like Nvidia, ati..) could let AeroGlass run in parallel.

Re:Vista and OpenGL/GLSL (3, Insightful)

ardor (673957) | more than 7 years ago | (#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.

Re:Vista and OpenGL/GLSL (1)

Overly Critical Guy (663429) | more than 7 years ago | (#14780333)

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 want to extend the Windows monopoly after seeing the rising success of the console market, and game quality be damned...so we get XBox360 commercials espousing the wonders of sweat on a basketball player instead of good gameplay).

Re:Vista and OpenGL/GLSL (0, Redundant)

ardor (673957) | more than 8 years ago | (#14783742)

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.

Re:Vista and OpenGL/GLSL (2, Informative)

PhrostyMcByte (589271) | more than 7 years ago | (#14779038)

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

firs7 4ost (-1, Offtopic)

Anonymous Coward | more than 7 years ago | (#14779080)

standards should Moan5 and groans ProjeCt. Today, as towel under the or chair, return Then disappeared

Save some money by buying the book here! (0)

pmc257cool (956059) | more than 7 years ago | (#14779229)

Save yourself some money by buying the book here: OpenGL Shading Language 2nd Edition [amazon.com] . And if you use the "secret" A9.com Instant Reward discount [amazon.com] , you can save an extra 1.57%!

Re:Save some money by buying the book here! (0)

Anonymous Coward | more than 8 years ago | (#14787106)

Wow! I save a whole 0% if I buy it from Amazon. Thanks, buddy!

Orange Book (-1, Flamebait)

this great guy (922511) | more than 7 years ago | (#14779366)

(also called the Orange Book because of its orange cover)

Hey smart ! Who would have guessed ?

Design the language with the application in mind! (1)

ralejs (779782) | more than 7 years ago | (#14779816)

<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 should be reflected in the shading language as well. Design the language so that it is suitable for its application! It is a truism that functional languages are much better suited in modelling these kinds of mathematical equations that C or Ada (although C and Ada both have their merits as well in other areas).
</rant>
OK. Well I just needed to get that off my chest. I feel much better already.

Re:Design the language with the application in min (1)

JourneyExpertApe (906162) | more than 7 years ago | (#14780083)

Graphics programmers are more likely to be familiar with procedural programming than functional programming because they need to have a lot of control over how the code executes. C is probably the most widely known programming language. New procedural languages are often described as having a C-like syntax to make it sound less intimidating, even if it's actually more similar to another language.

Re:Design the language with the application in min (1)

ralejs (779782) | more than 8 years ago | (#14781070)

Yes, I know. Your point is entirely valid. I just wish there weren't so much inertia in the field of programming languages. Programmers could start learning languages with a syntax different from C and with a funkier (more powerful) semantics. It will make them better programmers. But I guess I just have to keep on dreaming about this.

Re:Design the language with the application in min (1)

Watson Ladd (955755) | more than 7 years ago | (#14780435)

And when the guy with the BFG comes sneeking up, you get a garbage collection. No thanks

Re:Design the language with the application in min (1)

ralejs (779782) | more than 8 years ago | (#14781085)

There is nothing that says that a functional language needs to have automatic memory management (such as garbage collection). The kind of language design I have in mind would not.

Re:Design the language with the application in min (1)

nagora (177841) | more than 8 years ago | (#14789214)

And when the guy with the BFG comes sneeking up, you get a garbage collection.

Only turn on the GC when the inventory screen is up or during a cut scene.

TWW

Re:Design the language with the application in min (1)

Oscaro (153645) | more than 8 years ago | (#14791224)

And when the guy with the BFG comes sneeking up, you get a garbage collection

There is no dynamic memory allocation in shaders.

Re:Design the language with the application in min (0)

Anonymous Coward | more than 7 years ago | (#14780846)

> Shading computations are inherently functional

Nothing prevents you from writing a functional shader language, but it won't make the hardware understand types or referential transparency or higher order functions or whatever. Cg is just a bit friendlier than an assembler, and since there isn't a single underlying architecture, something higher-level had to be made standard.

Re:Design the language with the application in min (0)

Anonymous Coward | more than 8 years ago | (#14782119)

I'm sorry, but how much do you know about shaders and their hardware implementation? Taking a quick glance in wikipedia, *none* of the attributes of functional programming are present in them. Shader hardware is *very* restricted, which also helps give it a more traditional 'one way in, one way out' look. They're meant for parallel programming, for the FSM's sake!

Re:Design the language with the application in min (1)

ingvar (66436) | more than 8 years ago | (#14783604)

So write a compiler from functional-language-of-choice to GLSL (or Cg or HLSL or...) and be done with it.

It's not *that* hard...

Re:Design the language with the application in min (1)

bensch128 (563853) | more than 8 years ago | (#14785090)

Thats a really cool idea.
  I wonder what the ideal semantics for such a language would be.
Maybe like Mathimetica or Matlab?

Cheers,
Ben

Any way to get just the update? (0)

Anonymous Coward | more than 7 years ago | (#14780131)

I have the 1.0 version of the book. Is there any way to get just the update?

using shaders to do *everything*? (1)

Speare (84249) | more than 8 years ago | (#14781264)

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 presenting highly capable scene graphs with a lot of really nice and popular shading effects.

Just showing that you can implement PAC-MAN using Excel macros does not particularly give the reader a good understanding of making the fastest-possible PAC-MAN game, nor the most robust actuarial financial model.

Scene graphs? (1)

Musc (10581) | more than 8 years ago | (#14781377)

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.

GLSL under Linux with Geforce 5800 (0)

Anonymous Coward | more than 8 years ago | (#14783270)

Will I be able to use this on my Linux machine with a GF 5800 card?
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>