clipka <ano### [at] anonymousorg> wrote:
> Am 13.03.2018 um 20:12 schrieb Kenneth:
>
> > I guess the safest bet right now is: Don't set rad 'brightness ' below .021!
> > Which nobody would normally do anyway ;-)
>
> Actually, the safest bet is: Don't set radiosity brightness to
> /anything/ other than 1.0 in the first place! It wrecks realism anyway.
>

Interesting. My (apparently outdated) philosophy of reducing brightness comes
from v3.6.2 days-- when things were a bit screwy all around, in hindsight ;-)
Thanks.

re: the slowdown...
> But alas! Those measures suffer from precision problems: One value that
> should be /at least/ adc_bailout + EPSILON is passed around with the
> same precision as colour values (i.e. single precision, as opposed to
> double precision like most math stuff), causing it to be rounded,
> sometimes ending up /smaller than/ adc_bailout.

Ah, that ol' single-precision vs. double-precision devil. (Uh, as if I know what
I'm talking about, ha.) Glad to see that you were able to figure out how to
'exorcise the demon' !  Nice detective work.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>
> Actually, the safest bet is: Don't set radiosity brightness to
> /anything/ other than 1.0 in the first place! It wrecks realism anyway.
>
> (A reasonable case can be made for brightness values slightly _above_
> 1.0, when recursion_limit is set particularly low (2 or even 1), to
> compensate for the fact that this reduces the overall brightness of the
> scene a bit. But brightness values below 1.0 are of the devil. Don't go
> near them.)

Thinking about this further: I assume you mean, when using a HDR light probe for
the sky and no other lights in the scene? A brightness value of 1.0 would make
sense.

Whereas, when using a typical LDR sky photo, and a (single) light in the scene
for the 'Sun', a rad brightness value of 1.0 could be too bright, for various
reasons.

Given that the objects in the scene have  finish {diffuse 1.0 emission 0} --
with ambient turned off automatically-- and a light_source of rgb 1 (or more
likely less than that), it would *seem* natural to turn down rad's brightness
below 1.0. So that any object surfaces never exceed a surface brightness of 1.0
max; otherwise, there's a danger of washing out the object colors. It would all
depend on how bright the single light_source is: if it's set to rgb 0.6, then
rad brightness should not exceed 0.4, according to my theory.

Of course, this all depends on light_source/surface brightness and rad
brightness being simply additive (i.e., the combination can go beyond 1.0.)
That's what I've always assumed, anyway.

However, I do see a major problem with my argument: The parts of the scene in
*shadow* are only receiving the rad lighting-- and such shadow illumination
would *vary* depending on my light_source brightness. Not very logical, I admit.
(Or more specifically, not 'realistic.')  So I guess such a lighting scenario
is, by default, not 'realistic'  at all, but just an attempt to make the scene
'pleasing to the eye.'  I.e., balancing 'Sunlight' brightness against shadow
brightness, just to prevent any colors from being washed out.

Post a reply to this message

Le 18-03-16 à 15:17, Kenneth a écrit :
> clipka <ano### [at] anonymousorg> wrote:
>>
>> Actually, the safest bet is: Don't set radiosity brightness to
>> /anything/ other than 1.0 in the first place! It wrecks realism anyway.
>>
>> (A reasonable case can be made for brightness values slightly _above_
>> 1.0, when recursion_limit is set particularly low (2 or even 1), to
>> compensate for the fact that this reduces the overall brightness of the
>> scene a bit. But brightness values below 1.0 are of the devil. Don't go
>> near them.)
> 
> Thinking about this further: I assume you mean, when using a HDR light probe for
> the sky and no other lights in the scene? A brightness value of 1.0 would make
> sense.
> 
> Whereas, when using a typical LDR sky photo, and a (single) light in the scene
> for the 'Sun', a rad brightness value of 1.0 could be too bright, for various
> reasons.
> 
> Given that the objects in the scene have  finish {diffuse 1.0 emission 0} --
> with ambient turned off automatically-- and a light_source of rgb 1 (or more
> likely less than that), it would *seem* natural to turn down rad's brightness
> below 1.0. So that any object surfaces never exceed a surface brightness of 1.0
> max; otherwise, there's a danger of washing out the object colors. It would all
> depend on how bright the single light_source is: if it's set to rgb 0.6, then
> rad brightness should not exceed 0.4, according to my theory.
> 
> Of course, this all depends on light_source/surface brightness and rad
> brightness being simply additive (i.e., the combination can go beyond 1.0.)
> That's what I've always assumed, anyway.
> 
> However, I do see a major problem with my argument: The parts of the scene in
> *shadow* are only receiving the rad lighting-- and such shadow illumination
> would *vary* depending on my light_source brightness. Not very logical, I admit.
> (Or more specifically, not 'realistic.')  So I guess such a lighting scenario
> is, by default, not 'realistic'  at all, but just an attempt to make the scene
> 'pleasing to the eye.'  I.e., balancing 'Sunlight' brightness against shadow
> brightness, just to prevent any colors from being washed out.
> 
> 
> 
> 

The best way to go when a light probe is to bright or dark is to adjust 
it's emission down or up respectively. Don't play with brightness.

Next, you can adjust the diffuse part of your textures. Most of the 
time, the default of 0.7 is correct, but at times, you may need to use a 
slightly smaller value. It don't get bumped up to diffuse 1 when you use 
radiosity, only ambient get turned off.
With radiosity scenes, default is :
finish{diffuse 0.7 ambient 0 emission 0}

Alain

Post a reply to this message

Am 16.03.2018 um 20:17 schrieb Kenneth:
> clipka <ano### [at] anonymousorg> wrote:
>>
>> Actually, the safest bet is: Don't set radiosity brightness to
>> /anything/ other than 1.0 in the first place! It wrecks realism anyway.
>>
>> (A reasonable case can be made for brightness values slightly _above_
>> 1.0, when recursion_limit is set particularly low (2 or even 1), to
>> compensate for the fact that this reduces the overall brightness of the
>> scene a bit. But brightness values below 1.0 are of the devil. Don't go
>> near them.)
> 
> Thinking about this further: I assume you mean, when using a HDR light probe for
> the sky and no other lights in the scene? A brightness value of 1.0 would make
> sense.
> 
> Whereas, when using a typical LDR sky photo, and a (single) light in the scene
> for the 'Sun', a rad brightness value of 1.0 could be too bright, for various
> reasons.

No, I mean, literally, NEVER EVER set radiosity brightness below 1.0 (if
you want realistic renders).

The reason is that the radiosity brightness parameter is /not/ applied
to the end result of radiosity computations, but /at each level of depth/.

Consider a scene where one area (A) receives direct light from a classic
light source; another area (B) is placed such that it does not receive
any direct light, but diffuse light from (A); and yet another area (C)
is placed such that it does not receive any direct light nor diffuse
light from (A), but diffuse light from (B).

In such a scene, POV-Ray will scale the brightness of (B) by the
radiosity brightness setting, but it will scale the brightness of (C) by
the /square/ of the radiosity brightness setting. Thus, tampering with
the radiosity brightness setting will skew the relative brightness of
areas B and C (and also areas A and B).

The algorithm is designed such that it gives most realistic results at a
radiosity brightness setting of 1.0 (if it wasn't for recursion_limit
and adc_bailout, which both cause the algorithm to underestimate the
diffuse illumination, so to compensate, radiosity brightness should be
slightly higher than 1.0).


If you really think your scene gets too bright with radiosity enabled,
it's your light sources (light_source and sky sphere) which are to blame.

> Given that the objects in the scene have  finish {diffuse 1.0 emission 0} --
> with ambient turned off automatically-- and a light_source of rgb 1 (or more
> likely less than that), it would *seem* natural to turn down rad's brightness
> below 1.0. So that any object surfaces never exceed a surface brightness of 1.0
> max; otherwise, there's a danger of washing out the object colors. It would all
> depend on how bright the single light_source is: if it's set to rgb 0.6, then
> rad brightness should not exceed 0.4, according to my theory.

I see your point, but you're mistaken: Radiosity isn't an /alternative/
way of lighting things - it accounts for paths of illumination that
would otherwise be /missing/ from classic light source computations.

So in a sense it's not /activating/ radiosity that screws up your scene
brightness - it's /de-activaing/ radiosity that does.


If you're worried about the balance between direct and indirect
illumination and/or the total brightness of your scene, the proper knobs
to tweak are the brightness levels of the light sources and the sky sphere.


> However, I do see a major problem with my argument: The parts of the scene in
> *shadow* are only receiving the rad lighting-- and such shadow illumination
> would *vary* depending on my light_source brightness. Not very logical, I admit.
> (Or more specifically, not 'realistic.')  So I guess such a lighting scenario
> is, by default, not 'realistic'  at all, but just an attempt to make the scene
> 'pleasing to the eye.'  I.e., balancing 'Sunlight' brightness against shadow
> brightness, just to prevent any colors from being washed out.

You /can/ use the radiosity brightness setting for artistic purposes, to
emphasize shadows; however, my point remains: If you want /realistic/
renders, you should never ever set it below 1.0.

The problem with that kind of artistic tweaking is that you're depriving
yourself of any means to design your materials and light sources based
on physical principles, which means you're stuck with tweaking and
re-tweaking.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
>
> No, I mean, literally, NEVER EVER set radiosity brightness below 1.0 (if
> you want realistic renders).
[snip]

I had to give this info (and Alain's comments) some deep thought-- because until
now, I've always varied radiosity's brightness to 'balance' the scene lighting
and look. I've always 'tweaked' it -- reduced it --just to get the scene to have
the contrast I want. Keeping the rad brightness at 1.0 is a new paradigm shift
for me(!)

I now understand the 'technical' need to do so, although it initially gave me
some worries about the many(?) changes I might have to make to my non-HDR scenes
that use a light_source. But there's a simple and easy workaround: I can use TWO
identical image_mapped sky domes or spheres (a trick that has probably been
mentioned in the newsgroups) along with rad brightness 1.0:

1)  the sphere for RADIOSITY lighting only:
       no_shadow
       no_image
       no_reflection
       finish{ emission *my choice*}  // to get the contrast I want

2) the sphere for the VISIBLE sky image (and for reflections in objects):
      no_shadow
      no_radiosity
      finish{emission 1.0} // for an accurate reproduction of the image_map, as
     // seen in the render

This probably still amounts to 'tweaking'-- but unless there's a remaining
technical problem, it works for me.

And THANKS for correcting my long-held misconceptions.

Post a reply to this message

Le 18-03-17 à 10:39, Kenneth a écrit :
> clipka <ano### [at] anonymousorg> wrote:
>>
>> No, I mean, literally, NEVER EVER set radiosity brightness below 1.0 (if
>> you want realistic renders).
> [snip]
> 
> I had to give this info (and Alain's comments) some deep thought-- because until
> now, I've always varied radiosity's brightness to 'balance' the scene lighting
> and look. I've always 'tweaked' it -- reduced it --just to get the scene to have
> the contrast I want. Keeping the rad brightness at 1.0 is a new paradigm shift
> for me(!)
> 
> I now understand the 'technical' need to do so, although it initially gave me
> some worries about the many(?) changes I might have to make to my non-HDR scenes
> that use a light_source. But there's a simple and easy workaround: I can use TWO
> identical image_mapped sky domes or spheres (a trick that has probably been
> mentioned in the newsgroups) along with rad brightness 1.0:
> 
> 1)  the sphere for RADIOSITY lighting only:
>         no_shadow
>         no_image
>         no_reflection
>         finish{ emission *my choice*}  // to get the contrast I want
> 
> 2) the sphere for the VISIBLE sky image (and for reflections in objects):
>        no_shadow
>        no_radiosity
>        finish{emission 1.0} // for an accurate reproduction of the image_map, as
>       // seen in the render
> 
> This probably still amounts to 'tweaking'-- but unless there's a remaining
> technical problem, it works for me.
> 
> And THANKS for correcting my long-held misconceptions.
> 
> 
> 
> 
> 
> 
If you are using that model, you can use a lower resolution, highly 
blured, version of the light probe for the radiosity part.
But, you don't need to use that method. A single sphere is very good. 
Generaly, if the light probe is to bright for the radiosity, then, it's 
also probably to bright for the reflections. I've seen that case. The 
usual solution is to reduce the global emission value for the probe.

Post a reply to this message

Alain <kua### [at] videotronca> wrote:
> >
> If you are using that model, you can use a lower resolution, highly
> blured, version of the light probe for the radiosity part.
> But, you don't need to use that method. A single sphere is very good.
> Generaly, if the light probe is to bright for the radiosity, then, it's
> also probably to bright for the reflections. I've seen that case. The
> usual solution is to reduce the global emission value for the probe.

I was actually referring to a typical (or old-school?) LOW-dynamic-range image,
for the sky sphere(s). Plus a single light_source in the scene to mimic the Sun,
or whatever. But for an HDR light probe, your suggestions are good-- no 2nd
sphere required.

And using a low-resolution image for the *radiosity* sky is a useful idea in
either scenario. Other than saving memory, though, I'm wondering if a low-rez
blurry image takes less time-- or fewer computations-- when POV-Ray processes
the radiosity light.... instead of using a higher-rez or more 'detailed' image.

Post a reply to this message

Am 17.03.2018 um 15:39 schrieb Kenneth:

> 1)  the sphere for RADIOSITY lighting only:
>        no_shadow
>        no_image
>        no_reflection
>        finish{ emission *my choice*}  // to get the contrast I want
> 
> 2) the sphere for the VISIBLE sky image (and for reflections in objects):
>       no_shadow
>       no_radiosity
>       finish{emission 1.0} // for an accurate reproduction of the image_map, as
>      // seen in the render
> 
> This probably still amounts to 'tweaking'-- but unless there's a remaining
> technical problem, it works for me.

It remains tweaking indeed: This approach still breaks some (realistic)
brightness balance - namely that between radiosity and specular reflections.

Post a reply to this message

Am 17.03.2018 um 22:32 schrieb Kenneth:

> I was actually referring to a typical (or old-school?) LOW-dynamic-range image,
> for the sky sphere(s). Plus a single light_source in the scene to mimic the Sun,

If only the sun is overexposed, that's ok; for realism, use the sky
sphere as-is, plus a classic light source to model the portion of the
sun that exceeds the image's dynamic range.

The sky sphere will be picked up by radiosity and reflections, while the
classic light source sun will be picked up by classic diffuse and
highlights.

Radiosity and diffuse are mutually balanced automatically (if you don't
tamper with radiosity brightness ;)); reflections and highlights must be
mutually balanced manually, which is tricky in 3.7 and earlier.


> And using a low-resolution image for the *radiosity* sky is a useful idea in
> either scenario. Other than saving memory, though, I'm wondering if a low-rez
> blurry image takes less time-- or fewer computations-- when POV-Ray processes
> the radiosity light.... instead of using a higher-rez or more 'detailed' image.

It generally allows you to get away with a lower number of samples, as
small bright light sources like the sun get spread out over a wider
region and are therefore easier to hit with fewer rays.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 17.03.2018 um 15:39 schrieb Kenneth:

> > This probably still amounts to 'tweaking'-- but unless there's a remaining
> > technical problem, it works for me.
>
> It remains tweaking indeed: This approach still breaks some (realistic)
> brightness balance - namely that between radiosity and specular reflections.

:-(   As the old Yiddish saying says, "Oy Vey!"  :-P

I'm beginning to think that the only way to get a truly 'realistic' radiosity
render is to use an HDR light probe for the sky, with no additional light
sources... in which case, POV-Ray itself works with all the correct values(?)
and in the correct way.

Otherwise, it seems that using a LOW-dynamic-range sky + light_source(s)
requires *some* kind of tweaking (of one subtle thing or another).. yet which
still works against the radiosity mechanism, if only in a technical sense.

My desire to increase the contrast of a rad scene-- if I feel that it's
necessary-- looks like a no-win situation (except in the HDR light probe case).
Unless I simply postpone that step, and do it later as a post-processing effect
in another graphics app.

> Radiosity and diffuse are mutually balanced automatically (if you don't
> tamper with radiosity brightness...

*That* is a key insight that I've been wondering about. I hope I understand it
(as it relates to a LOW-dynamic-range sky set-up):

Given:
radiosity{brightness 1.0}
light_source{rgb .7}
object{... pigment{rgb <.3,.5,.7> finish{diffuse 1.0}}

Does the 'automatic balancing' keep the object surface color at <.3,.5,.7>
(depending of course on the angle-of-incidence of the light source hitting it)?
Or does my diffuse setting need to be manually reduced, to keep the color from
washing out to, say, <.6,1.0,1.2> (just as a conceptual idea, not real math). Or
am I still clueless about what 'automatic balancing means? :-O

Post a reply to this message