Jump to content

  • Log In with Google      Sign In   
  • Create Account

Awesome job so far everyone! Please give us your feedback on how our article efforts are going. We still need more finished articles for our May contest theme: Remake the Classics

Hide differencesHistory of post edits

#ActualHodgman

Posted 12 February 2012 - 06:14 PM

N.B. this happens in forward renderers as well as deferred renderers. This isn't a problem of deferred VS forward renderers -- it's a problem of low-range VS HDR lighting.
e.g.given a forward-rendering pixel shader snippet like:
float3 result = (float3)0;
result += diffuse * nDotL0 * lightColor0;
result += diffuse * nDotL1 * lightColor1;
result += diffuse * nDotL2 * lightColor2;
return result;
if diffuse was white, color0 was pink(255,192,192), color1 was grey(128,128,128) and color2 was green(0,255,0), then the end result can be as high as (383,575,320), however when you output it to an 8-bit render target it gets clamped to white (255,255,255).
If your forward renderer used HDR, then after tone-mapping you would instead end up with a greenish-whiteish colour.


Another idea I had was to apply the light attenuation to a separate render texture, then use that texture as a mask to blend all lights in the scene at once, to avoid over-saturation. But that would involve another pass and wouldn't work very well for multi-colored lights.

This sounds a bit like "light pre pass" (or some call it "deferred lighting" instead of "deferred shading"). If you implemented this method with low-range (non-HDR) buffers, then when you place too many lights in one area, the result will look ok, but the artefact will be that your lights lose colour, because at some point they will clamp at white.

N.B. this happens in forward renderers as well as deferred renderers. This isn't a problem of deferred VS forward renderers -- it's a problem of low-range VS HDR lighting.
e.g.given a forward-rendering pixel shader snippet like:[code]float3 result = (float3)0;
result += diffuse * nDotL0 * lightColor0;
result += diffuse * nDotL1 * lightColor1;
result += diffuse * nDotL2 * lightColor2;
return result;[/code]if diffuse was white, color0 was pink(255,192,192), color1 was grey(128,128,128) and color2 was green(0,255,0), then the end result can be as high as (383,575,320), however when you output it to an 8-bit render target it gets clamped to white (255,255,255).
If your forward renderer used HDR, then after tone-mapping you would instead end up with a greenish-whiteish colour.


[quote name='Nairou' timestamp='1329064671' post='4912282']Another idea I had was to apply the light attenuation to a separate render texture, then use that texture as a mask to blend all lights in the scene at once, to avoid over-saturation. But that would involve another pass and wouldn't work very well for multi-colored lights.[/quote]This sounds a bit like "light pre pass" ([i]or some call it "deferred lighting" instead of "deferred shading"[/i]). If you implemented this method with low-range (non-HDR) buffers, then when you place too many lights in one area, the result will look ok, but the artefact will be that your lights lose colour, because at some point they will clamp at white.

#1Hodgman

Posted 12 February 2012 - 06:11 PM

N.B. this happens in forward renderers as well as deferred renderers. This isn't a problem of deferred VS forward renderers -- it's a problem of low-range VS HDR lighting.
e.g.given a forward-rendering pixel shader snippet like:
float3 result = (float3)0;
result += diffuse * nDotL0 * lightColor0;
result += diffuse * nDotL1 * lightColor1;
result += diffuse * nDotL2 * lightColor2;
return result;
if diffuse was white, color0 was pink(255,192,192), color1 was grey(128,128,128) and color2 was green(0,255,0), then the end result can be as high as (383,575,320), however when you output it to an 8-bit render target it gets clamped to white (255,255,255).
If your forward renderer used HDR, then after tone-mapping you would instead end up with a greenish-whiteish colour.

PARTNERS

Warning: include_once(RContent/redis.php) [function.include-once]: failed to open stream: No such file or directory in /var/www/gamedev/admin/applications_addon/ips/ccs/sources/pages.php(458) : eval()'d code on line 20642

Warning: include_once() [function.include]: Failed opening 'RContent/redis.php' for inclusion (include_path='/var/www/gamedev/ips_kernel/PEAR/') in /var/www/gamedev/admin/applications_addon/ips/ccs/sources/pages.php(458) : eval()'d code on line 20642