"Bald Eagle" <cre### [at] netscapenet> wrote:
> One other important thing that I had never thought of, but the ShaderToy folks
> have brought up:
> No values in the (s)rgb triplets should ever be zero.
> First, because there are almost never absolutely black objects in real life
> ("vanta black")
> and second, because there is no way to modify it with a multiplier.
> If you had a red value of one millionth, you could multiply that by a million to
> get 1. But anything multiplied by zero is always zero.
> So maybe we can set some min() threshold value that doesn't really register
> on a monitor (1/256).
> I changed every <0.000, 0.000, 0.000> to <0.004, 0.004, 0.004> (which
> corresponds to 1/256)
Those are interesting points from Bald Eagle, and I sense the logic behind them.
I agree with the first statement, that pure black is never seen in real life.
I'm guilty of that too when specifying something like rgb 0.0 for an object, so
I need to remember to change such colors to be more realistic-- like to at least
0.004 as Thomas mentions.
But here's a little monkey wrench that I'll throw into the second point ;-)
(because I'm honestly puzzled regarding the ShaderToy logic):
If I use a color in a scene like <0,.7,.7>, whether as rgb or srgb, it has no
'red' color at all (disregarding the unrealistic nature of such a color, except
perhaps in a scientific setting using purely-generated monochromatic colors.) By
multiplying or dividing that <0,.7,.7> by whatever value, the 'red' should still
be 0.0-- in other words, there's no red to begin with, so any increase or
decrease of the color vector should still have no red-- either mathematically
*or* visually. Whether of not that's a 'realistic' color is a different matter,
of course; but the total lack of red seems to be the logical outcome...with no
..004 'red' addition required (for example).
Or perhaps I'm misunderstanding what the ShaderToy reference means, and why it
cautions against a 0.0 value in a color vector being multiplied.
Post a reply to this message