Cousin Ricky <ric### [at] yahoocom> wrote:
> It's working exactly as it should. When you include the 50000 in the
> srgb statement itself, the 50000 is multiplied by the vector *before*
> the sRGB function is applied. Raise that to power 2.4, and you get a
> very big number.
Thanks for the #debug breakdown; I didn't think to try that. It's very obvious
that the numbers are as you say. I'm still trying to fully grasp the
mathematical results of srgb color multiplication-- even after re-reading Ive's
and Clipka's older newsgroup caveats about this subject! Your succinct
explanation has helped a lot.
But there's one aspect of my example that is still mysterious to me:
By pre-#declaring TEMP_COLOR=srgb <.5,.3,.7> and then plugging that into the
it would *appear* that the syntax result is again simply srgb <.5,.3,.7>*50000
-- or maybe a segregated (srgb <.5,.3,.7>)*50000 ? I'm not seeing the
essential difference that the #declare produces. So it looks like the parser
*is* making some kind of mathematical distinction, whatever that is.
(BTW, I tried various combinations of parentheses in the light's color itself,
before hitting on the idea of pre-#declaring the color. No combination worked;
some produced fatal errors.)
Here's what made me question whether or not fade_distance/fade_power were even
working with srgb colors: By simply removing those terms from the light, both
rgb <.5,.3,.7>*50000 and srgb <.5,.3,.7>*50000 produced blown-out lighting--
which is to be expected, of course! But the srgb result *with*
fade_distance/fade_power still looked blown out the same way. So I assumed that
the light-fading simply wasn't working. I was fooled :-(
The old scene I was revamping with srgb colors is a *really* complex combination
of #include files, regular lights, spotlights, light_groups etc. The first thing
I did was to change almost all of the scene's colors (and light colors) to srgb
versions, with no testing along the way. Only *then* did I notice the blown-out
super-bright lighting in the scene. I spent hours tracking down the cause-- a
single light with fade_distance/fade_power.
Post a reply to this message