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

"Kenneth" <kdw### [at] gmailcom> wrote:

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

Let me re-word that, so it hopefully makes better sense...

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's DIFFUSE color from
exceeding .7*<.3,.5,.7> (as if NO radiosity is used)--depending of course on the
angle-of-incidence of the light source hitting the object? Or does my diffuse
setting need to be manually reduced, to keep the color from washing out to, say,

       .7*<.3 + 1.0,.5 + 1.0,.7 + 1.0>  or maybe  (1.0 + .7)*<.3,.5,.7>

....DUE TO THE ADDITION OF RADIOSITY LIGHT. Or am I still clueless about what
'automatic balancing' means? :-O

Post a reply to this message

Am 18.03.2018 um 21:31 schrieb Kenneth:

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

No, it shouldn't require tweaking.

(In v3.7 there's still /some/ tweaking to be done to balance reflections
vs. highlights. But stuff is improving.)


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

If you want realism, take what the proper settings give you.

If you want pure art, tweak as tweak can.

If you want art based on realism, render with proper settings, then
post-process to taste. (Inbuilt tonemapping featureas are on the agenda,
BTW.)


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

`pigment { rgb Cp } finish { diffuse D }` means that /any/ incoming
light of brightness/colour Ci will be diffusely reflected for an
effective brightness/colour of Ci*Cp*D*F, where F is a factor that
solely depends on geometry (surface normal, incoming light direction and
outgoing light direction) and (if finish-level fresnel is enabled) the
refractive index of the material.

Point light sources, photon mapping and radiosity are all just methods
of computing which point on an object surface receives how much incoming
light from which direction, and they complement each other: The point
light source algorithm only takes into account light paths directly from
classic light sources to the observed surface (and not traversing photon
targets); the photon algorithm only takes into account light paths
refracted by photon targets; and the radiosity algorithm only takes into
account light paths where the light is bounced off other objects, or
where the light is emitted by another object (or a sky sphere) rather
than a classic light source.

There is no "washing out" caused by the radiosity algorithm itself: If
you replaced the sky sphere with a gazillion point light sources all
coloured in accordance with the image, you'd get pretty much exactly the
same result.


The surface of an object with pigment rgb <.3,.5,.7> will always have an
effective apparent colour of <.3,.5,.7>*Brightness, provided all the
light sources are "white" (R=G=B) and there is no specular reflection
nor specular highlights, nor "ambient" nor emission. (And no intervening
media or some such, of course.)

Note however that sky tends to be blue in hue, which might cause red and
yellow hues to appear more washed out; on the other hand, blue hues will
get more pronounced. To counteract this, make sure to tune your "sun"
light source to a yellowish hue, which by the way is also realistic.
(HDR sky spheres should normally already account for this effect.)

Post a reply to this message

Am 18.03.2018 um 22:02 schrieb Kenneth:

> Let me re-word that, so it hopefully makes better sense...
> 
> 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's DIFFUSE color from
> exceeding .7*<.3,.5,.7> (as if NO radiosity is used)--depending of course on the
> angle-of-incidence of the light source hitting the object? Or does my diffuse
> setting need to be manually reduced, to keep the color from washing out to, say,
> 
>        .7*<.3 + 1.0,.5 + 1.0,.7 + 1.0>  or maybe  (1.0 + .7)*<.3,.5,.7>
> 
> .....DUE TO THE ADDITION OF RADIOSITY LIGHT. Or am I still clueless about what
> 'automatic balancing' means? :-O

If you disable radiosity, your result image will have

    .7*Fc*<.3,.5,.7>

where Fc is a scalar (depending on angle of incidence and such stuff),
i.e. colour neutral.

If you enable radiosity and the sky colour is grey with a brightness of
.5, your result image will have:

    .7*Fc*<.3,.5,.7> + .5*Fr*<.3,.5,.7>

where Fr is also a scalar (again depending on angle of incidence and
such stuff), i.e. colour neutral; so in total you'll get:

    (.7*Fc+.5*Fr) * <.3,.5,.7>

So no washing out there - just more brightness.

Things get different if your sky sphere isn't colour neutral, but the
same would be true for a non-colour-neutral point light source.


But maybe instead of your colours getting "washed out", what you really
mean is that your colours are getting "burned" - the effect that you get
when one or two colour components exceed the dynamic range of the LDR
output file format and is thus clipped, effectively desaturating the colour.

If that is what you get, the proper solution is to tune down the
brightness of /both/ the sun and the sky (which, as noted before, isn't
the same as tuning down the radiosity brightness setting).

Post a reply to this message

On 18/03/2018 20:31, Kenneth wrote:
> My desire to increase the contrast of a rad scene-- if I feel that it's
> necessary--

That's the main reason I don't use radiosity. So I am following this 
thread with interest.
When rating entries in TC-RTC I would lower the gamma in PSP 9 to get an 
image that did not look washed out to my eyes.

-- 

Regards
     Stephen

Post a reply to this message