From: Renk T. <tho...@jy...> - 2012-11-11 12:41:42
|
> I suspect the difference in light intensity > (dynamic range) doesn't fit in an 8-bit 3-component color. It sure doesn't, but I think you're thinking way too complex. We don't want to render physical light intensity, we want to render perceived light intensity, and there the Weber Fechner law is relevant, and that says that we roughly want to render the log of the physical light intensity. For instenace, full daylight has 10,000 lux, and a very dark overcast day has 100 lux - yet if you multiply the sun (rgb) = (1,1,1) which works fine for a sunny day with 0.01, you don't get an overcast day - 0.6 is more the factor you need, i.e. every factor 10 reduction in luminous flux is about -0.2 from the base light. A full moon has about 0.1 - 1 lux, so we get (rgb) values of ~(0.1..0.2) in the light vector - which works visually just fine (I've been using vec3 moonLightColor = vec3 (0.095, 0.095, 0.15) * moonlight * scattering; for the pics) - which gives imo a decent visual appearance. For the same reason, I don't see why we shouldn't be able to render sun glare with 8bit colors. All it takes is to store the light intensity in a separate variable and post-process the rgb output with a light-intensity dependent filter. My problem is not coming up with the filter, my problem is rather to determine if I should be blinded by the sun or if it's obscured by a panel. Btw. - I noticed that yesterday - are we by any chance doing any rendering tricks at night? Immediately after dusk, the moonlight renders fine, but after a while when it gets really dark, it suddenly snaps to a circle of illumination around me and everything else is pitch black. Is there any old code assigning a trivial ambient and diffuse material to faraway scenery to speed up rendering hidden somewhere, or should I look for a very exotic shader bug? Cheers, * Thorsten |