"Bill Pragnell" <bil### [at] hotmailcom> wrote:

>
> Does anyone know of any decent photographic reference table(s) that compare
> different metal colours? Even just jewellery metals would be a starting point.

There *is* a 'machinist's reference chart' for metal finishes (at least having
to do with the degree of polishing applied to metals, during manufacture of
various items), but it's actually a 'chip chart' of real metal samples. (I
don't have one; I just worked with it years ago.) I have to assume that there's
a photographic reference chart of various metals on the web *somewhere*; we'll
just have to keep looking! ;-)

KW

Post a reply to this message

Christian Froeschlin wrote:
> Warp wrote:
> 
>>   Why shouldn't the ambient term of a texture be definable with a
>> #default block, even if the texture is in a library?
> 
> because the designer of the texture might wish to specify
> the intended ambient value for use with classical lighting.

  Can you tell me an example of a texture where the author wants to
control the ambient term of the finish, and for which you want to turn
the ambient term off for a radiosity scene?

  I would think that if the author wants to set the ambient term of the
texture, there's a *reason* for that. For example, it could be a glowing
texture. If you then go and turn the ambient term off (for radiosity)
then the texture is not glowing anymore, and it basically becomes a
different texture.

  If the author wants a texture which is lighted "normally" by whatever
scene settings are currently in place, then he naturally should not
define any ambient term at all. That way the texture will use the
default ambient, which can be set in the scene with #default.

Post a reply to this message

Warp wrote:

>>> Ive wrote:
>>>> ambient 0 in the finish statement, otherwise it would emit light.
>>>   That's what #default { finish { ambient 0 } } is for.
>> This does not work if the texture already has a finish with ambient > 0.
>> But I'm pretty sure you know that.
> 
>   Then wouldn't the correct suggestion be "don't put an 'ambient' term
> in the finish of the texture" rather than "use 'ambient 0'"?


Seems like a rhetorical question to me so here is one for you:

Wouldn't this have implied that I agree with your opinion what the 
"correct suggestion" is?

I just did say that 'radiosity compatible' in relation to textures has 
to do with the ambient term. I did never rule out your suggestion (it 
obviously also contains a finish statement), all I wanted was to make 
Kenneth (the OP) aware of this issue and how he 'solves' it should be up 
to him - I think. Now call me a dumb liberal.

-Ive

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> Actually there's already a very easy way to turn off ALL ambient light settings
> in a scene: global_settings{ambient_light 0}
>
> It's really a multiplier (which is why it's set up as <1,1,1> by default); a
> very useful little on/off ambient-light switch for running radiosity scenes.

*Not* of any use for radiosity-*only* scenes: After all, you need it to model
light sources there.

Post a reply to this message

"Edouard" <pov### [at] edouardinfo> wrote:
> I find that even worse - in a radiosity scene, you often want some objects to
> give out light via an ambient term. Specifically with lightprobes, you need the
> lightprobe image to be ambient X and diffuse 0. Radiosity based lightprobe
> scenes often have no actual lights - all the lighting originates from the
> lightprobe. Setting the global ambient multiplier to 0 turns off the lightprobe
> in those cases, and your scene ends up black...

A kludge is to set ambient_light to something like 0.001, and the lightprobe to
ambient 1000*X

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> Hmm, that's bad! :-O   You're right, it certainly isn't applicable in all cases.

I've been thinking for quite some time now that the use of the ambient term in
radiosity-only scenes is no good. When one wants to create a light source in a
radiosity-only scene, technically the classic lighting's ambient mechanism does
the required thing, but the intention is *far* away from the concept implied by
that parameter's name. And it keeps causing trouble.

If I'm asked, there should be a separate "emission" parameter, with the whole
"ambient" mechanism turned off in radiosity scenes.

After all, the original intention of the ambient term, and its most common use
in non-radiosity scenes, is to approximate diffuse illumination - which is
*exactly* what radiosity is intended to model more realistically.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   If the author wants a texture which is lighted "normally" by whatever
> scene settings are currently in place, then he naturally should not
> define any ambient term at all. That way the texture will use the
> default ambient, which can be set in the scene with #default.

Guess what the intended purpose of the global ambient_light setting is...

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "Kenneth" <kdw### [at] earthlinknet> wrote:
> > Hmm, that's bad! :-O   You're right, it certainly isn't applicable in all cases.
>
> I've been thinking for quite some time now that the use of the ambient term in
> radiosity-only scenes is no good. When one wants to create a light source in a
> radiosity-only scene, technically the classic lighting's ambient mechanism does
> the required thing, but the intention is *far* away from the concept implied by
> that parameter's name. And it keeps causing trouble.
>
> If I'm asked, there should be a separate "emission" parameter, with the whole
> "ambient" mechanism turned off in radiosity scenes.
>
> After all, the original intention of the ambient term, and its most common use
> in non-radiosity scenes, is to approximate diffuse illumination - which is
> *exactly* what radiosity is intended to model more realistically.

Aha - that sounds like exactly the correct solution to this morass! Brilliant!

Cheers,
Edouard.

Post a reply to this message

"Edouard" <pov### [at] edouardinfo> wrote:
> "clipka" <nomail@nomail> wrote:

> > If I'm asked, there should be a separate "emission" parameter, with the whole
> > "ambient" mechanism turned off in radiosity scenes.
> >
> > After all, the original intention of the ambient term, and its most common use
> > in non-radiosity scenes, is to approximate diffuse illumination - which is
> > *exactly* what radiosity is intended to model more realistically.
>
> Aha - that sounds like exactly the correct solution to this morass! Brilliant!

I'm in complete agreement; clipka's suggestion for a new keyword or parameter is
the oh-so-obvious answer. (As I envision it--probably the same way as others
here--this 'emission' parameter should be applied to individual finishes--to
set which ones actually 'illuminate' the rad scene, the others being
automatically turned off. OR, just let the global{ambient_light 0} term suffice
for that--which could be invoked or not, at the discretion of the artist. Of
course, by not invoking it, the new 'emission'-like keyword becomes
superfluous--ALL ambient finishes would then glow, as they do now. But having
that 'switch' available--rather than an automatic ambient cut-off--would give
us *options*, and even guarantee backward compatibility.)

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> the oh-so-obvious answer. (As I envision it--probably the same way as others
> here--this 'emission' parameter should be applied to individual finishes--to
> set which ones actually 'illuminate' the rad scene, the others being
> automatically turned off.

Yes, I guess we're talking about the same.

To make it even clearer, I'd define the new parameter in such a way that, for
example, the following three finishes would give identical results in a
non-radiosity scene:

    #declare A = finish { ambient 0.0 emission 1.0 }
    #declare B = finish { ambient 0.5 emission 0.5 }
    #declare C = finish { ambient 1.0 emission 0.0 }

However, in a radiosity-enabled scene (whether it would be classically-lit or
not), only A would glow at full intensity (of course "more than full" intensity
would be possible as well), while B would glow at half intensity and C would not
glow at all.

Post a reply to this message