![](/i/fill.gif) |
![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Edouard" <pov### [at] edouard info> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Kenneth" <kdw### [at] earthlink net> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Christian Froeschlin
Subject: Re: POV 3.7 metals.inc; post your textures here
Date: 2 Apr 2009 15:30:36
Message: <49d5125c$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Christian Froeschlin
Subject: Re: POV 3.7 metals.inc; post your textures here
Date: 2 Apr 2009 15:45:47
Message: <49d515eb$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Zeger Knaepen
Subject: Re: POV 3.7 metals.inc; post your textures here
Date: 2 Apr 2009 17:17:47
Message: <49d52b7b$1@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Christian Froeschlin" <chr### [at] chrfr de> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
From: Christian Froeschlin
Subject: Re: POV 3.7 metals.inc; post your textures here
Date: 2 Apr 2009 18:21:46
Message: <49d53a7a@news.povray.org>
|
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
clipka nous illumina en ce 2009-04-02 07:15 -->
> Warp <war### [at] tag povray org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Christian Froeschlin <chr### [at] chrfr de> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
"Zeger Knaepen" <zeg### [at] povplace com> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
Alain <ele### [at] netscape net> wrote:
> clipka nous illumina en ce 2009-04-02 07:15 -->
> > Warp <war### [at] tag povray org> 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
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |
|
![](/i/fill.gif) |
| ![](/i/fill.gif) |
|
![](/i/fill.gif) |