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