>> Don't forget you can always use the "no_cache" option (I think uberPOV
>> only?) to get a "reference" image. See attached, that took about 25 mins
>> on my machine using "count 10" and "recursion_limit 3". You'd obviously
>> need higher settings to get rid of the graininess, but at least then
>> you'd have something to compare the radiosity version with.
>
> Though I know about "no_cache" feature, I am not sure I know what it does
> exactly.

It provides an "unbiased" result - meaning that (assuming you use enough 
samples) there is nothing in the algorithm used that will give rise to 
any error in each pixel value. Even with far too few samples (as in my 
image) the error is purely random noise in each pixel, there are no 
systematic errors possible like bright or dark splotches.

> The point /IS/ to get rid of /ALL/ graininess and splotched, at high
> resolution.

Use "no_cache" with a high number of samples and just let it run. With 
traditional radiosity, even after a lot of parameter tweaking, there is 
always the risk you have a bright/dark area somewhere that you don't 
notice is there. That's why I suggested using "no_cache" to generate a 
reference image to compare the traditional radiosity versions with. 
Doing a "difference" in a graphics package should make it obvious if 
there are any splotches of dark/light where there shouldn't be.

Post a reply to this message

scott <sco### [at] scottcom> wrote:
> >> Don't forget you can always use the "no_cache" option (I think uberPOV
> >> only?) to get a "reference" image. See attached, that took about 25 mins
> >> on my machine using "count 10" and "recursion_limit 3". You'd obviously
> >> need higher settings to get rid of the graininess, but at least then
> >> you'd have something to compare the radiosity version with.
> >
> > Though I know about "no_cache" feature, I am not sure I know what it does
> > exactly.
>
> It provides an "unbiased" result - meaning that (assuming you use enough
> samples) there is nothing in the algorithm used that will give rise to
> any error in each pixel value. Even with far too few samples (as in my
> image) the error is purely random noise in each pixel, there are no
> systematic errors possible like bright or dark splotches.
>
> > The point /IS/ to get rid of /ALL/ graininess and splotched, at high
> > resolution.
>
> Use "no_cache" with a high number of samples and just let it run. With
> traditional radiosity, even after a lot of parameter tweaking, there is
> always the risk you have a bright/dark area somewhere that you don't
> notice is there. That's why I suggested using "no_cache" to generate a
> reference image to compare the traditional radiosity versions with.
> Doing a "difference" in a graphics package should make it obvious if
> there are any splotches of dark/light where there shouldn't be.

Thanks for explanations. What is the relationship with other radiosity
parameters ?

Post a reply to this message

> Thanks for explanations. What is the relationship with other radiosity
> parameters ?

I tend to just use something like "count 10" and "recursion limit 3" and 
then use the AA command line options (+a +am +r) to control the 
graininess. Though I'm not sure whether it's more efficient to increase 
"count" or increase the AA settings.

Check the official notes below, but if you want any more detail then I 
suggest you ask clipka himself, the above is about the limit of my 
knowledge with this feature. I just use it because I have far more spare 
CPU time than brain time :-)

--
From: https://github.com/UberPOV/UberPOV/blob/master/changes.txt
--


Unbiased Diffuse Illumination:
------------------------------

   - UberPOV allows to disable the caching of radiosity samples, by 
using the
     following syntax in the global radiosity block:

         no_cache [BOOL]

     It also changes the way the secondary ray directions are chosen, and
     effectively turns the radiosity algorithm into a purely stochastic 
unbiased
     algorithm to compute diffuse illumination.

     Most radiosity settings are without effect in this mode, except for the
     following:

         adc_bailout FLOAT
         brightness FLOAT
         brilliance BOOL
         count FLOAT
         gray_threshold FLOAT
         media BOOL
         normal BOOL
         recursion_limit INT
         subsurface BOOL

     The current implementation does not translate classic radiosity 
settings
     into useful parameters for this mode of operation; it is therefore 
highly
     recommended to use a much lower setting for the "count" parameter than
     typical with standard radiosity.

     This syntax extension can be tested for using the #patch directive or
     patch() function with the patch name "upov-radiosity-no_cache"; the 
current
     implementation is version 0.1.

Post a reply to this message

Am 04.02.2016 um 15:15 schrieb scott:
>> Thanks for explanations. What is the relationship with other radiosity
>> parameters ?
> 
> I tend to just use something like "count 10" and "recursion limit 3" and
> then use the AA command line options (+a +am +r) to control the
> graininess. Though I'm not sure whether it's more efficient to increase
> "count" or increase the AA settings.

If uncached radiosity is the only thing in the scene that might generate
noise, it could indeed be more efficient to use a high "count".

Post a reply to this message

> "Bruno Cabasson" <bru### [at] cabassoncom> wrote:
>> Hello again.
>>
>> I revisited the patio_radio scene so as to try to reach perfection. For that
>> purpose, I perform my attempts on high resolution images (1600*1200).
>>
>> For this attempt #1, it still remains :
>>      -) some light areas in some corners
>>         (to the left, on the floor, under the arches)
>>      -) tiny splotchy zones by the arch half-rings,
>>         at the top right of the image
>>
>> The fringe under the balcony seems correct.
>>
>> Render time : 1 hour and 10 mn on a quad xeon @ 3.7GHz.
>>
>> B.
>
> Better with the image ...
>

One thing that I found that improve radiosity is to use the two 
parameters version of count:
count 37 15000

This will use 37 samples from a direction pool if 15000 directions.
It tend to reduce the dark and bright spots in the corners and some 
other artefacts.


Another thing is to reduce pretrace_end. In large renders, pretrace_end 
0.005 or 0.0025 give good results.
If you also use the two parameter for nearest_count, it will reduce the 
pretrace time, possibly considerably.
nearest_count 20 3

The last two are not used if the no_cache option is used as they 
controll how the cached samples are computed.

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 04.02.2016 um 15:15 schrieb scott:
> >> Thanks for explanations. What is the relationship with other radiosity
> >> parameters ?
> >
> > I tend to just use something like "count 10" and "recursion limit 3" and
> > then use the AA command line options (+a +am +r) to control the
> > graininess. Though I'm not sure whether it's more efficient to increase
> > "count" or increase the AA settings.
>
> If uncached radiosity is the only thing in the scene that might generate
> noise, it could indeed be more efficient to use a high "count".

Thank you both of you, scott and Christoph, for the explanations. Now it's time
for me to read more carefully UberPOV's release notes and documentation ...

I started a render with no_cache (at work, before I left). Result tomorrow
morning.

Post a reply to this message

Alain <kua### [at] videotronca> wrote:

> > "Bruno Cabasson" <bru### [at] cabassoncom> wrote:
> >> Hello again.
> >>
> >> I revisited the patio_radio scene so as to try to reach perfection. For that
> >> purpose, I perform my attempts on high resolution images (1600*1200).
> >>
> >> For this attempt #1, it still remains :
> >>      -) some light areas in some corners
> >>         (to the left, on the floor, under the arches)
> >>      -) tiny splotchy zones by the arch half-rings,
> >>         at the top right of the image
> >>
> >> The fringe under the balcony seems correct.
> >>
> >> Render time : 1 hour and 10 mn on a quad xeon @ 3.7GHz.
> >>
> >> B.
> >
> > Better with the image ...
> >
>
> One thing that I found that improve radiosity is to use the two
> parameters version of count:
> count 37 15000
>
> This will use 37 samples from a direction pool if 15000 directions.
> It tend to reduce the dark and bright spots in the corners and some
> other artefacts.
>
>
> Another thing is to reduce pretrace_end. In large renders, pretrace_end
> 0.005 or 0.0025 give good results.
> If you also use the two parameter for nearest_count, it will reduce the
> pretrace time, possibly considerably.
> nearest_count 20 3
>
> The last two are not used if the no_cache option is used as they
> controll how the cached samples are computed.

For both attempts, I used pretrace_end = 1/image_witdh in order to have pixel
acurracy. I don't know if it is relevant, but I noticed better results for small
details in scenes.

Post a reply to this message

On 2016-02-03 08:48 AM (-4), Bruno Cabasson wrote:
> I revisited the patio_radio scene so as to try to reach perfection. For that
> purpose, I perform my attempts on high resolution images (1600*1200).

I also experimented with patio-radio, last year, varying the 
recursion_limit.  Aside from recursion_limit, I didn't like that scene's 
radiosity options, so I used:

   radiosity
   { count 400
     error_bound 0.5
     pretrace_start 0.08
     pretrace_end 0.00125
   }

Post a reply to this message

Attachments:
Download 'patio-radio-rl1.jpg' (89 KB) Download 'patio-radio-rl2.jpg' (85 KB) Download 'patio-radio-rl3.jpg' (83 KB) Download 'patio-radio-rl4.jpg' (82 KB)

Preview of image 'patio-radio-rl1.jpg'

Preview of image 'patio-radio-rl2.jpg'

Preview of image 'patio-radio-rl3.jpg'

Preview of image 'patio-radio-rl4.jpg'

Here is the final render with no_cache, and command-line options "+am3 +a0.005
+ac0.99 +r4"

B.

Post a reply to this message

Attachments:
Download 'patio-radio_37_no_cache.png' (2011 KB)

Preview of image 'patio-radio_37_no_cache.png'

> Here is the final render with no_cache, and command-line options "+am3 +a0.005
> +ac0.99 +r4"

What was the render time?

Post a reply to this message