[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Public WebGL] Gamma correction and texImage2D/texSubImage2D
On Sun, Sep 5, 2010 at 3:39 PM, Brendan Kenny <firstname.lastname@example.org> wrote:
> On Sun, Sep 5, 2010 at 3:05 PM, Thatcher Ulrich <email@example.com> wrote:
>> This is corroborated by the GDC slides from John Hable (Naughty Dog,
>> EA) concerning the Uncharted 2 lighting.
>> There are a lot of slides there, but note especially:
>> * slide 26, showing egregious banding artifacts of using 8-bit linear color
>> * slide 30, showing the benefit of linear lighting
>> * slide 36, showing that you can explicitly linearize sRGB in your shader
>> * slide 37, saying that it's better if you get the hardware to do it
>> with D3DSAMP_SRGBTEXTURE and D3DRS_SRGBWRITEENABLE (the equivalents of
>> EXT_texture_sRGB and EXT_framebuffer_sRGB)
>> * slides 46-49 where he talks about which gamma to use for which kinds
>> of texture maps. (sRGB for Diffuse, linear for Normal Maps, linear or
>> sRGB for Specular and Ambient Occlusion)
>> Note that none of this implies that any manipulation of the color
>> components should be done by the graphics API in the PixelStore
>> pipeline. It is assumed that devs will feed the game engine the raw
>> data that the renderer is expecting to consume.
> Maybe I'm missing something, but looking at those slides it seems that
> he is suggesting that diffuse and (maybe) specular and ambient
> occlusion maps should be stored with gamma correction so that there is
> more data in the dark end (and so they're more easily edited by
> artists), but that when images are stored in "gamma-space" that they
> should *always* be sampled non-linearly (see slide 46).
> That could be done manually in the shader, but is also the equivalent,
> since all the images are being loaded by the browser, of converting
> them on import.
Sorry, it is not equivalent, in fact. The problem is that sampling
does always (always) need to be done non-linearly, but when done in a
shader the result is (usually, not sure about the full breadth of
hardware here) at least 16 bit floating point. If the image is just
converted to a linear 8-bit buffer, precision loss and banding on the
dark end will of course occur, as Thatcher noted.
You are currently subscribed to firstname.lastname@example.org.
To unsubscribe, send an email to email@example.com with
the following command in the body of your email: