>> The mix function is an interpolation function that linearly interpolates between the two input colors using a blend factor between and ( in our case).
>> A mix function for two colors works the same way, except we mix the color components. To mix two RGB colors, for example, we’d mix the red, green, and blue channels.
WebGL/OpenGL doesn't use sRGB in the shaders. If you load an sRGB texture, or render to an sRGB surface, the API automatically applies the gamma- (or inverse gamma) curve, so the shader only ever sees the linear values.
Correct, it uses just numbers without any specific information about a colorspace being involved. Decoding and encoding sRGB happen during (texture) read and write stages.
I agree with the colorspace alert. Lerping red and blue in OKLAB or OKLCH colorspace produces a much nicer effect. Also, the article details linear interpolation, but I think there's a lot of fun to be had by introducing some easing functionality into the interpolation[1] - it's not difficult to achieve in code, even in shader code?
I do disagree with the article about the need to do such work in the WebGL space. Modern CPUs are insanely fast nowadays, and browsers have put in a lot of work over the past few years to make the Canvas 2D API as performant as possible - including moving as much work as possible into the GPU behind the scenes. With a bit of effort, gradients can be animated in 2D canvases in many interesting ways![2][3]
Quite right! I think if the values were linearized (~gamma 0.5) lerp might be mostly ok though, right?
And what about doing rgb->hsv, then lerp, then hsv->rgb? I'm unclear whether that also needs linearization, or whether the gamma can maybe just be done to the 'v' component before lerping?
Color is a surprisingly deep and fascinating topic, that's for sure! :)
Perceptual colors -- both sRGB and HSB -- are nonlinear, so you can't expect linear combinations to produce meaningful results (they often "interpolate through mud").
If you just want optical phenomena, you can just convert to luminescence -- WegGL and other modern graphics APIs actually does this internally when you load or render textures, so all shaders are handling optically-linear data, which is why the shader-produced images in the post look better than the javascript gradients.
Mixing of colors in an "objective" way like blur (lens focus) is a physical phenomenon, and should be done in linear color space.
Subjective things, like color similarity and perception of brightness should be evaluated in perceptual color spaces. This includes sRGB (it's not very good at it, but it's trying).
Gradients are weirdly in the middle. Smoothness and matching of colors are very subjective, but color interpolation is mathematically dubious in most perceptual color spaces, because √(avg(a+b)) ≠ avg(√(a) + √(b))
(1,0,0) and (0,0,1) are each twice as bright, in terms of photons, as (0.5,0,0.5).
If you quickly apply gamma=2 so the midpoint is (0.707,0,0.707) your gradient will look much better. Although other commenters suggested mixing in more complicated colour spaces.
Very cool, but by css-rotating (skewY(-6deg)) the canvas at the last moment, you introduced aliasing on the border between the canvas and the rest of the page which kills the vibe. The browser can't automatically blend the canvas with the rest of the page. It's noticeable even on a brand new retina display. Maybe you could keep your canvas square and introduce the skew in the shader.
The linked source code [0] doesn't seem to have any license attached to it. So how could I actually use this? Is it published as a package somewhere, like npm?
We need more articles as polished as this one. WebGL is a topic I wanted to get into for a while now but it's really difficult to find good content about it. Please keep sharing more experiments!
Could not agree more. Heard good things about https://webgl2fundamentals.org/, but I think it directly jumps into code without any background as such. At least that is what I felt. Not sure whether this is the only way to go about teaching WebGL.
Looks pretty nice. I think there'd be a way of computing the blurriness without the iterative approach and without the aliasing produced in the process.
The whole time I was expecting just a 2d height field ("terrain") with animated noise as z, overlooked from an angle by an isometric camera, it could imo produce a same effect in a much simpler way (and without need for expensive blur), right?
Thanks a lot! Yeah tons of work went into this post, I’ve been working on it since November. The shader itself was about 2-3 weeks of evenings to get the effect 90% of the way
This looks very smooth. Would this be in 10 bit colour if the display supports it? I can't see any banding even when zoomed in Safari or Brave on a MBP with HDR display.
reply