On 19-3-2018 19:05, Stephen wrote:
> 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.
> 

I am not convinced that was caused by radiosity. My own 'obsession' with 
atmospheric media for instance, when it is not well balanced, gives some 
washout. I am struggling with it I confess (see my latest 'Cat Alley' 
for instance). To illustrate my point, look at my latest p.b.i. 
contribution "N". In both images radiosity was used and whether on the 
left hand image that may have led to washing out... I am not sure. In 
particular, I drastically changed my texturing of Poser model skins for 
instance.

-- 
Thomas

Post a reply to this message

On 20/03/2018 07:48, Thomas de Groot wrote:
> On 19-3-2018 19:05, Stephen wrote:
>> 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.
>>
> 
> I am not convinced that was caused by radiosity. My own 'obsession' with 
> atmospheric media for instance, when it is not well balanced, gives some 
> washout. I am struggling with it I confess (see my latest 'Cat Alley' 
> for instance). 

I may have jumped to conclusions with too few examples.

> To illustrate my point, look at my latest p.b.i. 
> contribution "N". In both images radiosity was used and whether on the 
> left hand image that may have led to washing out... I am not sure. In 
> particular, I drastically changed my texturing of Poser model skins for 
> instance.
> 

The brickwork looks more distinctive as do the plants.

-- 

Regards
     Stephen

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

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

Yes, that is what I meant-- and you explain it better than I did :-;
>
> 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).

I do see the reason for rad brightness 1.0 now; but it's the turning down of the
sky brightness that puzzles me.

Still assuming a low-dynamic-range setup, not HDR: If I use a sky photo of
clouds that looks nice-- set to emission 1.0, and which might actually appear in
the rendered scene-- turning down its brightness (i.e., emission value) will
cause it to have a 'dull' visual look in the render (what was once full white
now being a somewhat darker gray, for instance.) While that may indeed 'balance'
the radiosity lighting as far as color-clipping of object surfaces goes, the
visual appearance of the 'sky' itself is now dull. (That was my reasoning for
making two identical photo-mapped sky spheres-- where the *visible* sky is still
at emission 1.0)

So maybe my two spheres simply don't have the proper no_reflection tags (or etc)
in the right places? You may have alluded to this earlier; but which setting to
use where is still a little mysterious (so that all the rad 'numbers' again work
correctly behind-the-scenes.) Sorry to keep asking these odd questions; there's
only a *little* bit of mystery remaining ;-)

Post a reply to this message

Le 18-03-18 à 16:31, Kenneth a écrit :
> 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
> 
> 
> 
> 
> 

You always can use a sky_sphere or a large sphere enclosing your scene. 
You can use emission value larger than 1 if you want, or need.
You don't need to use HDRI, or even any image format at all for your sky.

To increase the contrast, and get better shadows, you can reduce the 
error_bound value. The default is correct when you also use some 
conventional light, but it need to be lowered for pure radiosity scenes.

In the example that you provide, you need to also take into account the 
diffuse part of your finish. It's diffuse 0.7 if you don't explicitly 
change it.
Here, the colour is, for a light perpendicular to the surface and that 
highly unrealistic diffuse of 1 :
rgb<0.3, 0.5, 0.7>*<0.7, 0.7, 0.7> = <0.21, 0.35, 0.49>
Next, if you use some colour picker, there is an additional gamma 
handling to take into account that will effectively change all channels 
in a non-linear way and thus change their relative values and reduce the 
saturation.

Don't forget that using diffuse 1 is NOT realistic. A very bright 
surface may have a diffuse as high as 0.95 or even 0.98, never 1.

Using diffuse 1 is a very good way to get washed out colours.


Alain

Post a reply to this message

Am 3/21/2018 um 0:00 schrieb Kenneth:
> I do see the reason for rad brightness 1.0 now; but it's the turning down of the
> sky brightness that puzzles me.
> 
> Still assuming a low-dynamic-range setup, not HDR: If I use a sky photo of
> clouds that looks nice-- set to emission 1.0, and which might actually appear in
> the rendered scene-- turning down its brightness (i.e., emission value) will
> cause it to have a 'dull' visual look in the render (what was once full white
> now being a somewhat darker gray, for instance.) While that may indeed 'balance'
> the radiosity lighting as far as color-clipping of object surfaces goes, the
> visual appearance of the 'sky' itself is now dull. (That was my reasoning for
> making two identical photo-mapped sky spheres-- where the *visible* sky is still
> at emission 1.0)
> 

Besides of what others have said I'd like to add that it is a common 
mistake to define the diffuse reflectance way too strong. E.g. a *white* 
piece of paper is something like rgb <0.5, 0.48, 0.42> with diffuse 0.6 
and as it happens I just measured (for some project of mine) some white 
silk and its diffuse reflectance is rgb <0.42, 0.40, 0.38>.
On the other hand light sources are not limited to rgb <1,1,1> and 
especially the value for sunlight should be much higher. This gives you 
(with proper radiosity use i.e. brightness = 1) easily a nice and 
realistic lighting with good contrast and - most important when you aim 
for realism - without any tweaking.

-Ive

Post a reply to this message

Alain <kua### [at] videotronca> wrote:
>
> Don't forget that using diffuse 1 is NOT realistic. A very bright
> surface may have a diffuse as high as 0.95 or even 0.98, never 1.
>
> Using diffuse 1 is a very good way to get washed out colours.
>

and Ive wrote...
> ...it is a common
> mistake to define the diffuse reflectance way too strong. E.g. a *white*
> piece of paper is something like rgb <0.5, 0.48, 0.42> with diffuse 0.6

Yes, I'm now understanding that concept as well, far better than I used to.

My prior assumption about a typical low-dynamic-range scene-- of almost always
using diffuse 1.0 for an object's surface-- was based on several factors
(assuming that both ambient and emission are at 0.0 for argument's sake, and NO
radiosity):  With a light_source set to rgb 1.0, and an object's color of
<.3,.5,.7> --with no additional phong or specular to complicate things-- my
understanding was that the very *brightest* color of the object's surface would
never exceed <.3,.5,.7> (but could  go below that, naturally.) That may still be
the case with a purely white light_source-- but the addition of anything else
(radiosity, colored light etc) naturally complicates things, so that
*something* in the scene needs to be tweaked (in brightness or whatever) to keep
any parts of the render from 'clipping' in brightness-- past the 1.0 maximum
pixel level for a LDR render, as Clipka mentioned.

From all that's been said so far, it appears that this tweaking needs to be done
*by eye*, to try and make sure that any clipping is kept to a minimum. Perhaps
the 'by eye' method is just a given-- and it's certainly what I had to do in
v3.6.x days (though with limited success.) *Which* parts to tweak can be ...
complicated, though. Even with POV-ray's up-to-date changes re: radiosity,
assumed_gamma etc, a successful/realistic render nevertheless appears to require
a *by eye* approach.

I don't have any complaints about that need; and I'm certainly open to being
corrected if I'm wrong ;-)

Post a reply to this message