> Ken <tyl### [at] pacbellnet> wrote in article

> >   Do you mean to tell me that it is possible to use an
> > ambient value higher than 1. If this is so why wasn't
> > I informed. I don't remember getting a memo !

Ken - We all voted not to tell you, in your own best interest.
Unfortunately, you have stumbled on our secret, so now you must die!

------------------------------
I hit on it by accident (a typo that parsed okay, but gave unexpected
results) and found it was useful when I was looking for a good way to
emulate a "candy-apple red" for something like a custom car paint job.

Here's a bit of it (from an early version): 

pigment {colour rgb <1.6, 0.4, 0.1 >}  // note high red, low blue
components
finish {
      ambient <0.2, -0.3, 2.0>       // note low red, high blue
component
      diffuse 0.5
      reflection 0.10
      specular 1.0
      roughness 0.001
      brilliance  3
      } 

The resulting effect is that whatever is directly illuminated by the
light_source comes out as a nice bright warm red hot-spot; everything
else (ie. the shaded areas) is given a slightly purple tinge, and still
looks fairly bright without the glow-in-the-dark effect of a high
ambient.
 
The high red component in the pigment is countered by the low red value
in the ambient, and vice-versa for the blue

A traditional trick in painting (oil, acrylic, etc) is to use a
complementary colour on the shaded side of objects. This trick is
something like that. My other option was to use a carefully scaled and
rotated gradient, but that scheme would fall apart as soon as a second
light_source is used.

It was also during this project that I realized that you can use a
multiplier with a colour vector, as in 

    colour rgb 0.9*<1.6, 0.4, 0.1 >   
or
    ambient 1.2*<0.2, -0.3, 2.0>

And, I was really surprised to see that this parsed:

    reflection (0.01 + 0.4*(<0.5, 0.15, 0.4 >))

It's all like using the visual equivalent of a graphic equalizer with a
series amplifier. If it evaluates to something greater than 1.0, then
you get "clipping" of the over-driven signal, which is what a fuzz-box
does.

one drawback is that if I want to change the base color, I have to go
through and "rotate" the components in each vector, to shift the colors.

Hmmm... now that I think of it, I could probably come up with a scheme
that uses sin or cos functions, and a "colour phase" variable, just like
in an NTSC video signal. change one #declare statement, and all of the
colour vectors shift. Once I get pleasing results, then I go through and
substitute calculated values (from a spreadsheet), so as to save a bit
of rendering time... hmmm... so crazy, it just might work.

-jr- 

**********************************************
* Delete "spamBgone." to get my real address *
**********************************************

Post a reply to this message