[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WEBGL_compressed_texture_s3tc_srgb



I think your proposal is important, but I'd like to comment on the other thing you said.

On Mon, Jun 13, 2016 at 9:46 PM, Christophe Riccio <christophe.riccio@unity3d.com> wrote:
This is pretty unfortunate because it makes supporting linear rendering more complicated than it should
 
All output ultimately written to gl_FragColor (when no framebuffer is bound) is in gamma space (which typically means sRGB gamma). You can gamma encode your colors prior to writing to gl_FragColor, and both simple gamma or sRGB are implementable in GLSL easily and the overhead on any device is negible. The one thing you cannot do in this fashion is blending  (which can take the form of alpha blending, additive blending, subtractive blending and blending due to anti-aliasing). Multiplicative blending is possible however (at least for simple gamma) because a = (b*c)^2 = b^2 * c^2.

Rendering to an sRGB (compressed or not) texture takes your rendering out of the frontbuffer and puts it in a framebuffer object. In the framebuffer object, you have no MSAA (at least in WebGL 1.0). So a source of blending artifacts (MSAA) falls away. That leaves other blending artifacts for which linear space might be beneficial, and for that it is a good choice. But you've still given up MSAA, which in the scheme of things, is probably the bigger loss than having blending artifacts.

In WebGL 2.0 you will not suffer from this, because you can instantiate a framebuffer object with MSAA. However, due to support levels, you will have to support WebGL 1.0 for a fairly long while, and so the problem for WebGL 1.0 remains. A possible solution would be to backport the necessary extensions to get MSAA'ed framebuffer objects in WebGL 1.0 (although their introduction is likely to also lag behind in implementation for most vendors, so it's dubious if the support level of such an extension would be any better than the support level of WebGL 2.0).

Regardless of these consideration, sRGB is not HDR (it's in fact slightly worse than LDR, too, because of narrow gamut clamping of that colorspace). In many use-cases of linear space rendering, you might have a need for an HDR color representation in a source or intermediate texture. The only form of HDR color representation that currently works with blending and anti-aliasing and in linear space artifact free are floating point textures (which may carry prohibitive bandwidth/performance impacts, especially on mobiles).

Alternatives to floating point are schemes such as LogLuv, RGBE, RGBM, etc. They vary in tradeoffs, but they all share the common characteristic that they have blending artifacts. What they also share with floating point textures is that they're not compressed. Although you can shove LDR content into compressed sRGB textures, this will not work well for HDR content, because the high dynamic range will make block-encodings much more visible.

What is currently completely lacking in any way, shape or form, both in WebGL 1 and WebGL 2, would be a format that can:
  • Do HDR
  • Is correctly blendable
  • Is correctly interpolatable
  • Can be rendered to
  • Can be compressed
  • Can be rendered to when compressed
  • Can have MSAA
I don't know what that should be, or how it would look, but I'd really like to have it :)