A very small piece of advice which I don't see mentioned here: OpenGL works in linear RGB (which is very convenient), while your monitor displays sRGB (which gives you better colour resolution due to how eyes work). This means that outputting the result of OpenGL directly on your screen is wrong (a lot dimmer than it should be). Use this little fragment in all your shaders to convert the final output to sRGB:
Edit 2: And of course when you load textures you must tell OpenGL they're in sRGB colourspace (most probably they are, if you created them on a normal monitor), so it will do the reverse transformation when reading from the texture. All this trouble could have been avoided if monitors were 30bit linear RGB colourspace to begin with, but that's history now. C'est la vie.
So you're saying that in my shaders, as long as I have GL_FRAMEBUFFER_SRGB enabled, this conversion takes place automatically? Am I understanding the docs right?
I'm asking because I'm a mobile game developer using Unity3d, and we have a fair amount of custom shaders, and I've never heard about this sRGB vs RGB colorspace thing before so I want to investigate. There's not much on google for GL_FRAMEBUFFER_SRGB + Unity3d. Maybe it's handled automatically or it's not even possible with openGL ES 2.0.
Here's a bunch of shader code and examples for different tone-mapping operators. I really like the Hejl/Burgess-Dawson one as a simple Linear -> sRGRB-ish output function.
Better than calling it the pound symbol. It was always a source of minor confusion, as people used it rarely and had all sorts of different names for it.
In Australia (or maybe it was just me?!) we called it "hash" not "sharp"... so #! was "hashbang". The beauty of this system is that #| is "hashpipe", so it _must_ be correct.
I think it was because Toby Schachman couldn't think of good exercises on more advanced topics. I would guess this struggle influenced his later work - Shadershop:
This is awesome! As someone who just spent a ton of time navigating a patchwork of information about GLSL, this looks like an oasis :) (I can't seem to access all the chapters though, I guess its a work in progress).
This looks great. Is there a way to easily take it offline so I can read it on my Kindle? Also...
> If you are reading this book in a browser the previous block of code is interactive. That means you can click and change any part of the code you want to explore.
Kindle or on iPad Safari? I don't know about people in your vicinity but kids in my area are off Kindle completely. This is anecdotal evidence obviously.
The experience of reading books with lifeless text/images sounds like a retrogressive proposition to me. I think e-books will have to move up the tool chain, enter browser with alternative reading experiences.
Great work, it's apparent a lot of thought went into the presentation and teachings.
I'm guessing there are lots of developers out there who don't realize that shaders are quite accessible for simple tasks even without much of a math or graphics background and/or that power is now available is most web browsers.
Um... what? How does this in any way relate to 50 Shades, except for the word 'shade' being contained in 'shaders'? There doesn't even appear to be a reference to it in any of the text.
But going to a publishing platform could also earn his efforts some money for a work well done. Open a channel to receive donations (or sells). Supporting the book through economic means might motivate the author enough to see through its completion.
Edit 2: And of course when you load textures you must tell OpenGL they're in sRGB colourspace (most probably they are, if you created them on a normal monitor), so it will do the reverse transformation when reading from the texture. All this trouble could have been avoided if monitors were 30bit linear RGB colourspace to begin with, but that's history now. C'est la vie.