"Tim Attwood" <tim### [at] anti-spamcomcastnet> wrote:
>       ambient 0.50

Yuck! :P

Post a reply to this message

Bill Pragnell wrote:
> This is just what I was thinking of. Are you willing to share these,
> or just the colour data? :) 

Sure. But I have only four more metal materials and here they are:


...snip
/--------------------------------------------------

#macro MaterialBronze(Polish, Dents)
   material {
     texture {
       pigment {rgb <0.5568, 0.3484, 0.1528>}
       N_Pattern(Polish, Dents)
       finish {
         ambient 0  diffuse 1-0.3768
         specular 0  brilliance 2
         reflection {0.0  1.0 fresnel on metallic}
         conserve_energy
       }
     }
     interior {ior 3.1}
   }
#end


#macro MaterialBrass(Polish, Dents)
   material {
     texture {
       pigment {rgb <0.5709, 0.3356, 0.1491>}
       N_Pattern(Polish, Dents)
       finish {
         ambient 0  diffuse 1-0.3702
         specular 0  brilliance 3
         reflection {0.0 1.0 fresnel on metallic}
         conserve_energy
       }
     }
     interior {ior 8.0}
   }
#end


#macro MaterialSteel(Polish, Dents)
   material {
     texture {
       pigment {rgb <0.4412, 0.4137, 0.3727>}
       N_Pattern(Polish, Dents)
       finish {
         ambient 0  diffuse 1-0.4163
         specular 0  brilliance 2.8
         reflection {0.0 1.0 fresnel on metallic}
         conserve_energy
       }
     }
     interior {ior 8.6}
   }
#end


#macro MaterialChrome(Polish, Dents)
   material {
     texture {
       pigment {rgb <0.9310, 0.9265, 0.9221>}
       N_Pattern(Polish, Dents)
       finish {
         ambient 0  diffuse 1-0.9642
         specular 0 brilliance 3
         reflection {0.0 1.0 fresnel on metallic}
         conserve_energy
       }
     }
     interior {ior 15}
   }
#end

/--------------------------------------------------
...snip


Feel free to use them in any way you like. (Note, the diffuse setting is 
quite important in combination with the color itself).


I do not claim there is something "physically" accurate with them - 
especially with the way I did handle the fresnel reflection. In the 
"real world" metals have fresnel reflection but in the "real world" the 
IOR is a complex number and for metals the imaginary part of the IOR is 
the important one. To do some tests with POV is since quite a while on 
my "to do"-list... oh well, if only the "real life" would not need most 
of my time :)


> To be honest, I wasn't even thinking of anything this ambitious - just a basic
> polished finish, maybe some dents, really just to get the basic colours
> consistent and believable. Great work!
> 

BTW, the colors from "metals.inc" in the POV contribution are not so 
bad, I think. The problem is, all of them (and this is also true for 
colors.inc, woods.inc and so on) are created in the early days of 
POV-Ray when everybody used assumed gamma 2.2 (or even assumed gamma was 
not yet introduced, POV simply did work with gamma 2.2). But we had a 
kind of paradigm change regarding the gamma handling and the new beta 
enforces a linear gamma. So to use them they all have to be inverse 
gamma corrected. And wrong gamma correction makes colors not only darker 
or brighter, it changes also the hue.

-Ive

Post a reply to this message

Ive <"ive### [at] lilysoftorg"> wrote:
> For "radiosity-lit-only" scenes (or MCPov for that matter) it would even
> mean "specular 0" and "phong 0".

That's not necessary, as without classic light sources these values don't have
any effect anyway (well, maybe a *tiny* bit more computing time).

They should definitely be non-zero for materials to work in non-radiosity-lit
scenes, as they will have to simulate highlights from the classic lights, which
we can't see otherwise.


Ideally, there should be *some* connection between these values and the
reflectivity of the material (and likewise between the roughness or
corresponding phong parameter, and the blurriness of reflectivity in case
micronormals are used), though I'm not sure how exactly these should be
related.

Post a reply to this message

Ive wrote:
> ambient 0 in the finish statement, otherwise it would emit light.

  That's what #default { finish { ambient 0 } } is for.

  What happens if you *want* the texture to have an ambient value >0?

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.


>   What happens if you *want* the texture to have an ambient value >0?
Well, in a radiosity scene - thats what I was talking about - this means 
you are going to define a metal (remember, this thread is about metal 
textures) with a temperature of lets say 4500° Kelvin. But I guess you 
know that too ;)


-Ive

Post a reply to this message

clipka wrote:
> Ive <"ive### [at] lilysoftorg"> wrote:
>> For "radiosity-lit-only" scenes (or MCPov for that matter) it would even
>> mean "specular 0" and "phong 0".
> 
> That's not necessary, as without classic light sources these values don't have
> any effect anyway (well, maybe a *tiny* bit more computing time).
> 
> They should definitely be non-zero for materials to work in non-radiosity-lit
> scenes, as they will have to simulate highlights from the classic lights, which
> we can't see otherwise.
> 

Well, I did see it the other way round. If you define a texture that 
looks great with nice specular/phong highlights you might be 
disappointed how it looks if used in a radiosity only lit scene, because 
all highlights are gone.

-Ive

Post a reply to this message

clipka nous illumina en ce 2009-04-01 04:52 -->
> Ive <"ive### [at] lilysoftorg"> wrote:
>> For "radiosity-lit-only" scenes (or MCPov for that matter) it would even
>> mean "specular 0" and "phong 0".
> 
> That's not necessary, as without classic light sources these values don't have
> any effect anyway (well, maybe a *tiny* bit more computing time).
> 
> They should definitely be non-zero for materials to work in non-radiosity-lit
> scenes, as they will have to simulate highlights from the classic lights, which
> we can't see otherwise.
> 
> 
> Ideally, there should be *some* connection between these values and the
> reflectivity of the material (and likewise between the roughness or
> corresponding phong parameter, and the blurriness of reflectivity in case
> micronormals are used), though I'm not sure how exactly these should be
> related.
> 
> 
Any bluring will have an effect on the tightness of the highlights. The tighter 
the highlight, the more visible the effect.

Low reflectivity goes with weak highlights. Ether use a multiple of the 
reflection value or something like the square root of the reflection value. The 
highlights tend to look as if it increase faster than the perceived reflection 
for low reflection.

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you have ever gotten in a flame 
war over various rendering softwares.
Stephan Ahonen

Post a reply to this message

Warp nous illumina en ce 2009-04-01 10:41 -->
> Ive wrote:
>> ambient 0 in the finish statement, otherwise it would emit light.
> 
>   That's what #default { finish { ambient 0 } } is for.
> 
>   What happens if you *want* the texture to have an ambient value >0?
You just add finish{ambient YourValue} and it will override that defined elsewhere.

If you provide a texture that is INTENDED as having some ambient, just add a 
comment to that effect to your texture. Make it clear that that texture will 
then illuminate it's surrounding in any radiosity scene.

-- 
Alain
-------------------------------------------------
John' First Law of Software Developer Productivity:

"A program written by someone who does not work for you will be done when it is 
done."

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> > ambient 0 in the finish statement, otherwise it would emit light.
>
>   That's what #default { finish { ambient 0 } } is for.

Not with material to place in a lib. Those should have all parameters set, just
to be sure. After all, you never know what the user sets his defaults to.

>   What happens if you *want* the texture to have an ambient value >0?

Then you're screwed with radiosity...

Post a reply to this message

Ive <"ive### [at] lilysoftorg"> wrote:
> Well, I did see it the other way round. If you define a texture that
> looks great with nice specular/phong highlights you might be
> disappointed how it looks if used in a radiosity only lit scene, because
> all highlights are gone.

(As a matter of fact, I think the material definitions should get some overhaul,
too, so that specular highlights and specular reflection are automatically "in
sync", so you don't have to worry about such issues)

Post a reply to this message

clipka wrote:

> Warp <war### [at] tagpovrayorg> wrote:

>>   What happens if you *want* the texture to have an ambient value >0?

> Then you're screwed with radiosity...

include files could use a #define such as RADIOSITY_TEXTURES
to provide two versions of a texture depending on whether the
#define is set before #including. For textures which just use
a different ambient value that would be no extra effort to
write using a simple macro for ambient.

#macro AMBIENT(ambient_value)
#ifdef RADIOSITY_TEXTURES
   ambient 0
#else
   ambient ambient_value
#end
#end

#declare T_SOME_TEXTURE = texture
{
   pigment {...}
   normal  {...}
   finish  {... AMBIENT(0.15)}
}

Post a reply to this message

Ive <"ive### [at] lilysoftorg"> wrote:
> Kenneth wrote:

> > Sorry to be so brain-challenged, but: radiosity compatibility? I've seen that
> > term mentioned several times lately, and have no clue what it means re:
> > textures.  I must have missed something somewhere. Please explain?

>
> ambient 0 in the finish statement, otherwise it would emit light.
>
> For "radiosity-lit-only" scenes (or MCPov for that matter) it would even
> mean "specular 0" and "phong 0".
>

Got it. (Although the specular and phong stuff is new--I need to do some
experiments to see.)

Here's an 'old pitted iron texture' that I dug out of one of my scenes (I
actually started with one of the stones.inc pigments, and modified it)...

#declare old_pitted_iron_texture =
texture {
        pigment{
                granite  // AGATE works well for this too.
                color_map {

                        [0.000 rgb .8*<.4, .4, .380>]
                        [0.153 rgb .4]
                        [0.398 rgb .5*<0.7, 0.4, 0.25>]
                        [0.398 rgb .2*<0.7, 0.7, 0.7>]
                        [1.000 rgb <0.545, 0.380, 0.345>]
                          }

               }
        finish{
              ambient .2 // 0 for radiosity
              diffuse 1
              phong .6
              phong_size 24
        }
        normal {granite .7 scale 9}
    }

KW

Post a reply to this message

Attachments:
Download 'old_pitted_iron.jpg' (52 KB)

Preview of image 'old_pitted_iron.jpg'

Ive wrote:
> 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'"?

  The former doesn't fix the ambient, so you can later change it to
whatever you want with #default. The latter fixes it and you can't
change it without modifying the texture code.

Post a reply to this message

Alain wrote:
> Warp nous illumina en ce 2009-04-01 10:41 -->
>> Ive wrote:
>>> ambient 0 in the finish statement, otherwise it would emit light.
>>
>>   That's what #default { finish { ambient 0 } } is for.
>>
>>   What happens if you *want* the texture to have an ambient value >0?
> You just add finish{ambient YourValue} and it will override that defined
> elsewhere.

  Wouldn't it simply be easier if the texture didn't define any ambient
at all? Then you can use #default to set it to whatever you want.

Post a reply to this message

clipka wrote:
> Warp <war### [at] tagpovrayorg> wrote:
>>> ambient 0 in the finish statement, otherwise it would emit light.
>>   That's what #default { finish { ambient 0 } } is for.
> 
> Not with material to place in a lib. Those should have all parameters set, just
> to be sure.

  Just to be sure of what?

  Why shouldn't the ambient term of a texture be definable with a
#default block, even if the texture is in a library?

>>   What happens if you *want* the texture to have an ambient value >0?
> 
> Then you're screwed with radiosity...

  That didn't answer my question.

Post a reply to this message

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.

Post a reply to this message

Ive <"ive### [at] lilysoftorg"> wrote:
> 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.

That's true.

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.

KW

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:
> Ive <"ive### [at] lilysoftorg"> wrote:
> > 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.
>
> That's true.
>
> 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.
>
> KW

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...

Post a reply to this message

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

> > ...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.
> >
> > KW
>
> 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...

Hmm, that's bad! :-O   You're right, it certainly isn't applicable in all cases.

KW

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> 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.

I agree. Most times, I create a texture with no real thought of how it might
appear using radiosity--because I don't use that feature on a regular basis.
How it looks under classical lighting is my foremost thought.  I save rad for
special occasions--and then I'll go back and re-work the texture (which will
look somewhat 'different' anyway, in radiosity lighting.)

KW

Post a reply to this message

"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

Warp wrote:

> 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 just question your honorable assumption that all POV-Ray users are
so enlightened that they would never ever dream of using ambient > 0
to tweak a texture to make it look better unless they also want it to
glow in the dark should someone dare use it in a radiosity scene ;)

Post a reply to this message

clipka wrote:

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

that sounds like the correct solution. Although by default,
ambient probably needs to remain emissive as well for backward
compatibility. Radiosity scenes using "emission" can then set
ambient_light to 0 without losing their light sources.

Post a reply to this message

"Christian Froeschlin" <chr### [at] chrfrde> wrote in message 
news:49d515eb$1@news.povray.org...
> clipka wrote:
>
>> If I'm asked, there should be a separate "emission" parameter, with the 
>> whole
>> "ambient" mechanism turned off in radiosity scenes.
>
> that sounds like the correct solution. Although by default,
> ambient probably needs to remain emissive as well for backward
> compatibility. Radiosity scenes using "emission" can then set
> ambient_light to 0 without losing their light sources.

how about making the default value for emission the same as the 
ambient-value?
Also, I don't think emission should have any meaning when not used with 
radiosity.

So, finish {ambient 1 diffuse 0} results in an unshaded emissive texture, 
finish {ambient 0 diffuse 1 emission 1} results in a texture that looks like 
finish {ambient 0 diffuse 1} but for radiosity-calculations acts like finish 
{ambient 1 diffuse 1} does now.  And finish {ambient 1 diffuse 0 emission 0} 
results in a texture that looks unshaded and emissive, but doesn't emit any 
light in a radiosity-scene.

It might not be realistic to have a normally shaded object to emit light, 
but this way is IMHO the most versatile way, and also the easiest to use, 
because most of the time you wouldn't even have define an emission-value 
(and it's completely backward-compatible).

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

Zeger Knaepen wrote:

> how about making the default value for emission the same as the 
> ambient-value?

yes that should work nicely

> And finish {ambient 1 diffuse 0 emission 0} 
> results in a texture that looks unshaded and emissive, but doesn't emit any 
> light in a radiosity-scene.

I don't know how radiosity is implemented in detail, it may
be a problem to have an object which is bright but should not
radiate away light. But a radiosity scene could then treat
ambient as 0 if emissive is present.

Post a reply to this message

clipka nous illumina en ce 2009-04-02 07:15 -->
> 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...
> 
> 
The original purpose of ambient_lights in the global_settings section is to 
gives a shade to the ambient part of the finish.
Want all parts of the scene in the shadows to be bluish, put:

ambient_lights rgb<0.3, 0.5, 1>

and every shadow gets a blue cast.

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you start wishing you were 
actually in that futuristic mandelbrotian landscape you just rendered.
     -- fish-head

Post a reply to this message

Christian Froeschlin <chr### [at] chrfrde> wrote:
> that sounds like the correct solution. Although by default,
> ambient probably needs to remain emissive as well for backward
> compatibility. Radiosity scenes using "emission" can then set
> ambient_light to 0 without losing their light sources.

I didn't think of that, but yes - of course. That's the solution to maintaining
backward compatibility.

Add a deprecation warning if ambient_light is set to anything other than 0 in a
radiosity scene, to encourage people shifting to the "emission" mechanism.


BTW, I also suggest adding an "emission" statement to the sky_sphere, so the
brightness of e.g. a HDR light probe can be tweaked without resorting to a
"real" sphere.

Post a reply to this message

"Zeger Knaepen" <zeg### [at] povplacecom> wrote:
> how about making the default value for emission the same as the
> ambient-value?

No, definitely not. In a radiosity scene, only very, very few textures are
typically intended to emit light. But in a non-radiosity scene, you probably
want many, many textures to have an ambient term, in order to approximate
"ambient illumination" (i.e. illumination by light scattered diffusely from
other objects).

So the typical use case would be to have ambient X emission 0.


> Also, I don't think emission should have any meaning when not used with
> radiosity.

I disagree.

In a radiosity-only scene, of course you want emission to have an effect,
because there'd be no other way to get light into the scene (except for a sky
sphere).

When lighting the same scene classically, you probably want the same thing to
look similar when directly visible in the scene. For this, it will have to
emit, too.


Christian's idea to leave ambient fully functional in radiosity scenes for
compatibility, and expecting the user to actively turn it off by setting
ambient_light to 0, seems the most viable solution to me.

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> clipka nous illumina en ce 2009-04-02 07:15 -->
> > 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...
> >
> >
> The original purpose of ambient_lights in the global_settings section is to
> gives a shade to the ambient part of the finish.
> Want all parts of the scene in the shadows to be bluish, put:
>
> ambient_lights rgb<0.3, 0.5, 1>
>
> and every shadow gets a blue cast.

Yup, this is my point: It is the global ambient_light that is the thing
originally intended to tweak the ambient of textures globally, not the #default
ambient.

Post a reply to this message

clipka wrote:
> Yup, this is my point: It is the global ambient_light that is the thing
> originally intended to tweak the ambient of textures globally, not the #default
> ambient.

  "Originally" is the same thing thing as "correct"?

  And how is it in any way relevant what was the original meaning of
ambient_light with respect to what is the best way of designing textures
currently?

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> clipka wrote:
> > Yup, this is my point: It is the global ambient_light that is the thing
> > originally intended to tweak the ambient of textures globally, not the #default
> > ambient.
>
>   "Originally" is the same thing thing as "correct"?

If there is any doubt about what is "correct", then yes, "originally" is what I
think does tip the scale.

>   And how is it in any way relevant what was the original meaning of
> ambient_light with respect to what is the best way of designing textures
> currently?

In the same way as *any* original meaning of something is of relevance to what
is the best way today: If you can't come up with something significantly
better, better stick to the original because it is prone to be "more" standard.

Post a reply to this message

"clipka" <nomail@nomail> wrote in message 
news:web.49d5dcd34ee6dd4ef708085d0@news.povray.org...
> "Zeger Knaepen" <zeg### [at] povplacecom> wrote:
>> how about making the default value for emission the same as the
>> ambient-value?
>
> No, definitely not. In a radiosity scene, only very, very few textures are
> typically intended to emit light. But in a non-radiosity scene, you 
> probably
> want many, many textures to have an ambient term, in order to approximate
> "ambient illumination" (i.e. illumination by light scattered diffusely 
> from
> other objects).
>
> So the typical use case would be to have ambient X emission 0.

this would completely break older scenes.  If the default emission-value is 
the same as the specified ambient-value, then older scenes will render 
exactly the same as they used to.

>> Also, I don't think emission should have any meaning when not used with
>> radiosity.
>
> I disagree.
>
> In a radiosity-only scene, of course you want emission to have an effect,
> because there'd be no other way to get light into the scene (except for a 
> sky
> sphere).
>
> When lighting the same scene classically, you probably want the same thing 
> to
> look similar when directly visible in the scene. For this, it will have to
> emit, too.

They will look exactly the same when directly visible, since only ambient 
(and not emission) would affect the look of the texture itself.
So finish {ambient 1 emission .5} and finish {ambient 1 emission 5} will 
look the same in a non-radiosity scene, but will affect their environment 
different in a radiosity-scene... but even there the texture itself will 
look exactly the same

> Christian's idea to leave ambient fully functional in radiosity scenes for
> compatibility, and expecting the user to actively turn it off by setting
> ambient_light to 0, seems the most viable solution to me.

as already stated, that wouldn't work in a scene without convention 
light_sources

I'm all for an emission-value in the finish-statement, but only if it
a) doesn't just duplicate the effect of ambient (it has to have a different 
meaning than ambient) and
b) doesn't break old scenes (older scenes have to render exactly the same as 
they do now)
and the only way, IMHO, to satisfy both conditions, is to let emission (and 
only emission) only have effect in radiosity-lighting and to let the default 
emission-value be the same as the specified ambient-value.

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

"Zeger Knaepen" <zeg### [at] povplacecom> wrote:
> > So the typical use case would be to have ambient X emission 0.
>
> this would completely break older scenes.  If the default emission-value is
> the same as the specified ambient-value, then older scenes will render
> exactly the same as they used to.

I don't see how setting emission to 0 would break older scenes. Not with
Christian's suggestion for keeping backward-compatibility.

To recap the combined suggestion:

- Ambient works as it has always done. It's just deprecated to be used for
anything that is supposed to look like it's actively emitting light (as opposed
to things that are supposed to look like they're passively illuminated by
indirect light).

- For things that are supposed to look like they're actively emitting light, it
will be recommended to use the new "emission" keyword instead, which does
exactly the same as ambient except that it is not affected by the ambient_light
setting. (If both are used, the effects add up.)

- In non-radiosity scenes, nothing else changes to the current situation.

- In radiosity-only scens, it will be recommended to set ambient_light to 0; any
other value will only be accepted for backward compatibility, and generate a
deprecation warning. It will be expected that the emission mechanism is used to
generate light sources, instead of the ambient mechanism.

- In combined scenes, too, it will be recommended to set ambient_light to 0, and
any other value generate a deprecation warning. For such scenes, it will be
expected that the emission mechanism without a classic light source is used to
generate visible light sources, but otherwise classic light sources are used.

For this approach to work, clearly emission must default to 0.

> > When lighting the same scene classically, you probably want the same thing
> > to
> > look similar when directly visible in the scene. For this, it will have to
> > emit, too.
>
> They will look exactly the same when directly visible, since only ambient
> (and not emission) would affect the look of the texture itself.

Ah, so this is where you're misunderstanding things (or have different
expectations): You expect "emission" to only affect radiosity, and not the way
the thing looks when directly visible in the shot.

I can tell you that (a) I wouldn't want it that way (because after all, the
directly visible glow of an object *is* emission, not ambient illumination, so
it would be right to control both with the "emission" statement, and (b) it
would also be more difficult to implement, because without additional
programming effort, radiosity generally "sees" what the observer sees as well.


So both ambient *and* emission would have a directly visible effect, and both
would affect radiosity. It's just that in radiosity scenes the one would be
suggested to be turned off, while the other would remain effective.


Now you may wonder, "but what if I want my texture to have that slight ambient
term in radiosity scenes, too?"

Well, you just wouldn't. Ambient illumination as modeled with the "ambient" and
"ambient_light" mechanism is just an approximation of what radiosity does
automatically and better; with radiosity, that mechanism is simply just in the
way. You don't need it to model realistic textures for radiosity scenes. To the
contrary: You *can't* model realistic (non-glowing) textures for radiosity
scenes that have any ambient term.


> > Christian's idea to leave ambient fully functional in radiosity scenes for
> > compatibility, and expecting the user to actively turn it off by setting
> > ambient_light to 0, seems the most viable solution to me.
>
> as already stated, that wouldn't work in a scene without convention
> light_sources

That would depend on the approach used; with the approach Christian and I have
in mind, it would work perfectly.


> I'm all for an emission-value in the finish-statement, but only if it
> a) doesn't just duplicate the effect of ambient (it has to have a different
> meaning than ambient) and

It will - if only due to the fact that it will be independent of the
ambient_light, which can then be used to switch off all ambient terms globally,
while leaving a mechanism to model glowing objects.

And (likewise important if I'm asked), despite all similarities in effect, it
will have a totally different *meaning* - thank you for the word.

The "ambient" term will state - in line with its original intention - that an
object receives ambient illumination from somewhere, and needs therefore to be
non-black even in shadows. The very same thing radiosity computes automatically
and at much better quality.

The "emission" term will state that an object emits light by itself regardless
of other illumination sources; "ambient" has been mis-used for this purpose in
the past in lack of a separate mechanism, but this is the very reason why
ambient has become a problem.


> b) doesn't break old scenes (older scenes have to render exactly the same as
> they do now)

Doesn't happen with my idea, when combined with Christian's suggestion.


> and the only way, IMHO, to satisfy both conditions, is to let emission (and
> only emission) only have effect in radiosity-lighting and to let the default
> emission-value be the same as the specified ambient-value.

IYHO. I disagree, for multiple reasons:

(1) Semantics: Passive ambient illumination *is* something different in the real
world than active emission of light; while in the approach you have in mind,
neither "ambient" nor "emission" would properly describe what the things do
(because neither would have any real-world equivalent, taken on its own).

(2) Ease of use: With the approach proposed by Christian and me, the bulk of
existing textures would be immediately radiosity-ready. No need to change
anything, unless the texture is *intended* to glow - just set ambient_light to
0 and render; and making full use of that approach in future scenes would be
virtually no more difficult than it is now: Just throw in an "emission"
statement for every texture *intended* to glow, and do the others as usual.

With your approach, the bulk of existing textures would have to be explicitly
equipped with "emission 0" statements to make them radiosity-ready - and future
scenes would of course require that statement, too, to make the best use of the
approach. Worse yet: A significant portion of textures will continue to be
created non-radiosity-ready, because scene designers typically not using
radiosity will often just not bother adding that "emission 0" statement.

(3) Ease of implementation: Any surface feature that should "look" different to
radiosity than it does to the observer requires extra implementation effort.


To sum it up: I don't think the approach you had in mind is really viable.

Post a reply to this message

I almost completely disagree with your post, but I'm to tired for a 
discussion now :)

cu!
-- 
#macro G(b,e)b+(e-b)*C/50#end#macro _(b,e,k,l)#local C=0;#while(C<50)
sphere{G(b,e)+3*z.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1;
#end#end _(y-x,y,x,x+y)_(y,-x-y,x+y,y)_(-x-y,-y,y,y+z)_(-y,y,y+z,x+y)
_(0x+y.5+y/2x)_(0x-y.5+y/2x)            // ZK http://www.povplace.com

Post a reply to this message

clipka nous illumina en ce 2009-04-03 05:54 -->
> "Zeger Knaepen" <zeg### [at] povplacecom> wrote:
>> how about making the default value for emission the same as the
>> ambient-value?
> 
> No, definitely not. In a radiosity scene, only very, very few textures are
> typically intended to emit light. But in a non-radiosity scene, you probably
> want many, many textures to have an ambient term, in order to approximate
> "ambient illumination" (i.e. illumination by light scattered diffusely from
> other objects).
> 
> So the typical use case would be to have ambient X emission 0.
> 
> 
>> Also, I don't think emission should have any meaning when not used with
>> radiosity.
> 
> I disagree.
> 
> In a radiosity-only scene, of course you want emission to have an effect,
> because there'd be no other way to get light into the scene (except for a sky
> sphere).
> 
> When lighting the same scene classically, you probably want the same thing to
> look similar when directly visible in the scene. For this, it will have to
> emit, too.
> 
> 
> Christian's idea to leave ambient fully functional in radiosity scenes for
> compatibility, and expecting the user to actively turn it off by setting
> ambient_light to 0, seems the most viable solution to me.
> 
> 
Setting ambient_lights 0 is definetly NOT a viable solution. As you said, it 
effectively turn OFF any and all ambient, for every finish, even those you WANT 
to have an ambient value and emit light.

-- 
Alain
-------------------------------------------------
   I knew a girl so ugly that she was known as a two-bagger. That's When you put 
a bag over your head in case the bag over her head comes Off.
	Rodney Dangerfield

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> To recap the combined suggestion:
>
> [snip]

Even though my novice vote should not count for much, I just want to
chip in to say that I am in favour of clipka's and Cristian's combined
suggestion. I agree that the meaning of the ambient and emmision statement is
clearly distinct, and both meanings are easy to comprehend. Also, I cannot see
anything awkward in using old textures, defining textures that work in normal
rendered scenes as well as radiosity-rendered scenes, re-rendering old scenes,
etc when this approach would be implemented.

Cheers,
Erwin

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> > Christian's idea to leave ambient fully functional in radiosity scenes for
> > compatibility, and expecting the user to actively turn it off by setting
> > ambient_light to 0, seems the most viable solution to me.
> >
> Setting ambient_lights 0 is definetly NOT a viable solution. As you said, it
> effectively turn OFF any and all ambient, for every finish, even those you WANT
> to have an ambient value and emit light.

.... which is *exactly* what we'd have the "emission" statement for, so no
problem.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> .................

Really an interesting approach, clipka.
But *emission* keyword can be confusing to the *emission* media?
(only in terms of keywords, obviously)

--
Carlo

Post a reply to this message

"Carlo C." <nomail@nomail> wrote:
> Really an interesting approach, clipka.
> But *emission* keyword can be confusing to the *emission* media?
> (only in terms of keywords, obviously)

Indeed; so far, I considered the keyword only a kind of "working draft", and I
wasn't sure about it either.

On the other hand, using this particular keyword may actually be of benefit: You
put "emission COLOR" in a media, and the object's interior glows; you put
"emission COLOR" in a surface, and that surface glows. Sounds reasonably
straightforward to me.

Post a reply to this message

Carlo C. nous illumina en ce 2009-04-04 03:39 -->
> "clipka" <nomail@nomail> wrote:
>> .................
> 
> Really an interesting approach, clipka.
> But *emission* keyword can be confusing to the *emission* media?
> (only in terms of keywords, obviously)
> 
> --
> Carlo
> 
> 
If you have a media with emission in a radiosity scene with media on, that media 
will emit light that will illuminate it's surrounding.

So, the proposed use of emission in a finish have the same meaning and purpose.

-- 
Alain
-------------------------------------------------
You know you've been raytracing too long when you see something in the real 
world and you think, "Hey! How did they get that effect?"

Post a reply to this message

Alain <ele### [at] netscapenet> wrote:
> >
> >
> If you have a media with emission in a radiosity scene with media on, that media
> will emit light that will illuminate it's surrounding.
>
> So, the proposed use of emission in a finish have the same meaning and purpose.
>
> --
> Alain
> -------------------------------------------------
> You know you've been raytracing too long when you see something in the real
> world and you think, "Hey! How did they get that effect?"


True, now I have things more clear. ;-)
Thanks Alain, and thanks Clipka.

--
Carlo

Post a reply to this message