[Public WebGL] WEBGL_compressed_texture_s3tc_srgb

Florian Bösch [email protected]
Tue Jun 14 00:06:00 PDT 2016


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 <
[email protected]> wrote:
>
> This is pretty unfortunate because it makes supporting linear rendering
> <http://docs.unity3d.com/Manual/LinearLighting.html> 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 :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://khronos.org/pipermail/public_webgl_khronos.org/attachments/20160614/bee8949a/attachment.html>


More information about the public_webgl mailing list