Breakdown of a Simple Ray Tracer
mrl.nyu.edu
mrl.nyu.edu
There's one thing I'm curious about - does anyone know why he's taking the square root of the color to produce the final pixel color?
Probably to approximate gamma correction without getting too involved.
Incidentally, I didn't know to do gamma correction until I came across [3], which explained why the output from my raytracers always looked a little off ;)
[0] http://stackoverflow.com/questions/10843321/should-webgl-sha...
[1] https://www.khronos.org/webgl/public-mailing-list/archives/1...
[2] https://www.shadertoy.com/view/Xdl3WM
[3] http://blog.johnnovak.net/2016/09/21/what-every-coder-should...
GL does have the capability to handle linear color space buffers correctly, but you have to enable SRGB, and initialize the framebuffer correctly with SRGB color space, and I'm not sure if GLES (WebGL) can do this.
I realize now that I can't fully answer your question, because I'm unsure whether WebGL implementations are supposed to respect color correction information in the image file format. But I'm pretty sure that the color space in WebGL "shader land" is always linear.
More info : http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html
I first saw this trick in writing in this article (by the co-creator of shader toy). http://www.iquilezles.org/www/articles/outdoorslighting/outd....
For reasons why linear space lighting is important read (http://http.developer.nvidia.com/GPUGems3/gpugems3_ch24.html) The gist of it is gamma space lighting tends to look unnatural and blown out, and it becomes more of a problem the more math you do in the lighting (adding specular, multiple lights, etc.)
intensity(pixel)=intensity(pixel illuminated by source 1)+intensity(pixel illuminated by source 2)+...
perceived_intensity(pixel)=pow(x,pow(1/x,perceived_intensity(pixel illuminated by source 1))+pow(1/x,perceived_intensity(pixel illuminated by source 2))+...)Since perception happens when you look at the image on your screen, applying an explicit "perception" step in rendering is actually counterproductive, since those nonlinearities would compound.
Gamma correction is used to allow for better contrast resolution for the brightness levels where the eye is most sensitive, when you have to compress your color values down to 8 bits per channel. The display then inverts this to produce ordinary linear space intensities.
But the point that remains today, is not the bits (as shaders work with floats internally), nor the response curve of a CRT (because almost nobody uses those any more), but the fact that the physics calculations of light operate on linear quantities (proportional to an amount of photons), so you better do those in linear space.
Then at the end you must convert to perceptual space, which can be done in a number of ways. I'm not sure how much of a win replacing one pow(color, 2.2) with a sqrt is, at the end of a fragment shader. Especially when the pow(color, 2.2) is already a quick approximation by itself, there are much fancier curves to convert to perceptual space (that don't desaturate the darks as much, for instance).
Although perception is nonlinear, the nonlinearity here specifically addresses hardware on standard sRGB displays. After all, as cited above, why would you apply a nonlinear correction for perception when it has that baked in?
What is missed by many, is that standard LCD technology, despite being inherently linear, has that low level hardware nonlinearity baked in. Typically, it is a flat 2.2 power function, although other displays or modes may use differing transfer functions.
The irony is that the nonlinear 2.2 function adopted into most imaging results in a closer-to-linear signal, that ends up further nonlinear based on tonemapping, SMPTE2084, or other such nonlinear adjustments for technical or aesthetic reasons. In the case of raytracing, a mere 2.2 adjustment is woefully worthless.
PS: The CIE1931 model, of which the RGB encoding model is effectively derived from, used visual energy. That is, it doesn't model "reality" so much as the psychophysical byproduct that happens in the brain. Luckily, the base model, XYZ, operates on a linear based model with some extremely nuanced caveats. Raytracing using RGB tristimulus models as a result, sort of work.
In general, you can produce a variety of interesting color-space transformations with simple math on the current fragment, as opposed to more complex methods that rely on sampling output, like HDR processing.
Here is a page on more advanced color space manipulation: http://filmicworlds.com/blog/linear-space-lighting-i-e-gamma...
varying vec3 vPos;
float sRGB(float x) {
if (x <= 0.00031308)
return 12.92 * x;
else
return 1.055 * pow(x, 1./2.4) - 0.055;
}
void main() {
float v = (vPos.y + 1.) / 2.;
if (vPos.x < -0.5)
gl_FragColor = vec4(pow(v, 1./2.2)); // 2.2 Gamma
else if (vPos.x < 0.0)
gl_FragColor = vec4(sRGB(v)); // sRGB
else if (vPos.x < 0.5)
gl_FragColor = vec4(sqrt(v)); // sqrt approximation
else
gl_FragColor = vec4(v); // unadjusted
}
The question of why your display doesn't just output linear colors is more interesting. Small differences in dark colors are more easily perceived than differences in lighter colors, so it's useful to spend more encoding space on the low end. With more bits, you could use linear colors throughout, but all color data would take up proportionally more memory. It ends up more efficient to just decode from sRGB, do your computation, and encode into sRGB again each time.
Modern graphics APIs can automate this sRGB coding for you by letting you specify an sRGB format for textures: each time you read from an sRGB texture, the system will decode the color into linear space, and all writes will automatically encode back into sRGB.
Should as in it does already and this sort of thing is unnecessary? Definitely not. Hence EXT_sRGB.
It's a common misconception that this is taken care of for you by <platform X>, but it basically never is. I'm positive this is the case for WebGL.
It is an attribute of a properly defined encoding model. Further, there are two forms of linear display linear and scene linear, which are fundamentally essential to grasp for rendering approaches.
See ISO 22028-1:2004 for a discussion of terms.
I never said so. I said it gives >> a << linear colorspace. There are many such color spaces. Some are linear in different aspects (better at close or far away colors), and some only preserve some aspects (linear in brightness, or chroma, etc). I didn't intend to fully go into color theory.
I'm not even certain how well defined the color space is, and how properly linear it is. I do know that it accounts for gamma correction though (at least on my machine).
Linear is not a colour space, as a properly defined colour space, as per the ISO specification, is:
- A well defined transfer function.
- Properly described primary light chromaticities.
- Properly defined white point colour.
Where you reference "there are many such color spaces" is the issue. Linear specifically relates to the first point, and even that doesn't properly describe whether one is speaking of display linear or scene linear.
The other points relate to perceptually uniform discussions, which would be a misuse of the term linear.
I agree that it is not a suitable forum for color theory. “Linear” however, is a much confused subject, worthy of explanation.
(Or it's just for tone mapping.)
Tangentially, there's always a bit of heartache when I use the text input in Steam's Big Picture mode, as I wish Perlin's innovative input modes saw wider usage (see the "pen input" section of the above link). Of course, I understand why not: it faces the same hurdle of teaching people a new input layout that dooms all non-traditional input methods.
Reminds a lot of MessagEase, which I use on every touch system that supports it.
I have so many questions regardless :) The struggle of a rookie goes as:
SECTION A
- why on earth do you take the square root of c? Is there a sane reason to do this?
SECTION B
- why normalize the vector? I'd love to see a detailed explanation. - why is vPos.xy the first two parameters? - is vPos.xy a constant value or is it evaluating as the shader script is executed pixel by pixel?
SECTION D
- V -= S.xyz; // what's going on here? Why use the -= operator? Is this something to do with the way shaders operate? - float B = 2. * dot(V, W); // what take the dot product? - float C = dot(V, V) - S.w * S.w; // Why take it again and substract a square? - return BB < 4. C ? 0. : 1.; // Why 4.? No other value seems to work
SECTION E
- "Improve raytrace to return distances of near and far roots." OK I admit that I'm totally lost at this point. Asking line-by-line explanation doesn't really help :)
SECTION H
- YAY, sin and cos!!! Finally I can mess around with something :)
(First day it went up, I wrote a ray tracer from scratch in C in two hours :-)
https://github.com/melling/ComputerGraphics/blob/master/ray_...
http://madebyevan.com/webgl-path-tracing/
and another, simpler one:
Vectors are not just for parallel computations, these small sized ones deserve to be a proper data type.
Good for you that you already know how ray tracers work, and so possibly this adds no value for you. I already knew how they work and I thought it was a nice clear demonstration.