Cousin Ricky <ric### [at] yahoocom> wrote:

> The 1 should have been promoted to <1, 1, 1, 1, 1>.

Well, this is the danger with code, stems in general, and expectations.

"We would have _expected_ the 1 to be promoted to <1, 1, 1, 0, 0>."
But it did not.

> This would be
> consistent with previous behavior and with other contexts where a scalar
> appears in the same expression as a color or vector.

Right, which is what I was expecting, and what was throwing me off.

> > Totally logical, yet totally unexpected!
>
> Logic can give you wrong answers if a premise (in this case, the
> promotion of the scalar) is wrong.
>
> P.S. Not that it makes a difference here, but colors.inc defines `White`
> as `rgb 1`, which means it does not need promotion.  It already has the
> value <1, 1, 1, 0, 0>.

But it DOES make a difference.
White is _rgb_ 1.  NOT rgbft1.
That only happens on the fly when it needs to be compared to 1, which gets
promoted on the fly to rgbft.

That warning about f&t in the light source being ignored tells you it got
promoted, whereas a "normal" scene with rgb 1 would not issue such a warning.

This will take a lot of looking into to find out WHY it does what it does.
I'm just very thankful that no such thing took place when I was working out the
vector / scalar typing/differentiation!

- BE

Post a reply to this message