 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm currently implementing a new UberPOV feature that allows bypassing
the caching of radiosity samples, effectively resulting in purely
stochastic unbiased Global Illumination computation. (See recent
discussion on povray.unofficial.patches.)
The first image shows the cornell.pov radiosity sample scene, with
slight modifications to the radiosity settings to eliminate artifacts.
The scene rendered at 3018 pps on my machine. Anti-aliasing was set to
+am2 +a0.3.
The second image shows virtually the same scene, but with radiosity
caching disabled, the radiosity count parameter set to a much lower
value, and rendered with UberPOV's oversampling ("anti-aliasing") mode 3
with settings chosen to render in about the same time; speed was 3076
pps in this case. Oversampling was set to +am3 +a0.056 +ac0.9.
The third image shows exactly the same scene as the second one, but with
+a0.01 (in mode 3, this specifies the accepted noise level). Render
quality has obviously indreased, but so has render time: With these
settings, the scene rendered at only 229 pps.
It should be noted that relatively simple scenes with plenty of even
surfaces are easy prey for the radiosity algorithm, so it is no surprise
that this new feature's performance compares quite poor with this scene.
Some benefits of this approach over radiosity:
- Much lower memory footprint especially at high-quality settings.
- Much fewer interdependent quality settings to mess around with.
- No systematic limitations to quality; the result can always be
improved simply by using more aggressive oversampling.
- Unlike radiosity, the algorithm does not require any communication
between threads, and will therefore scale effortlessly in a distributed
rendering environment.
- It is well-suited for a "keep investing render time until I like the
output" mode of operation.
Post a reply to this message
Attachments:
Download 'cornell_rad.png' (77 KB)
Download 'cornell_st.png' (313 KB)
Download 'cornell_st01.png' (226 KB)
Preview of image 'cornell_rad.png'
Preview of image 'cornell_st.png'
Preview of image 'cornell_st01.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.07.2014 01:27, schrieb clipka:
> It should be noted that relatively simple scenes with plenty of even
> surfaces are easy prey for the radiosity algorithm, so it is no surprise
> that this new feature's performance compares quite poor with this scene.
The radiosity3.pov sample scene, for instance, already shows some
weaknesses of radiosity; at 800x600 pixels, it takes a good deal of
tweaking to get reasonable quality. For recursion_limit 2, I ended up
with settings that gave a rendering speed of 5517 pps.
The other image shows what the new UberPOV patch can do without any
serious tweaking at 5714 pps.
Post a reply to this message
Attachments:
Download 'radiosity3_rad.png' (158 KB)
Download 'radiosity3_st.png' (451 KB)
Preview of image 'radiosity3_rad.png'
Preview of image 'radiosity3_st.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The second image shows virtually the same scene, but with radiosity
> caching disabled, the radiosity count parameter set to a much lower
> value, and rendered with UberPOV's oversampling ("anti-aliasing") mode 3
> with settings chosen to render in about the same time; speed was 3076
> pps in this case. Oversampling was set to +am3 +a0.056 +ac0.9.
Looks very good. What is the keyword needed to disable radiosity caching
and what does the +ac value mean?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.07.2014 09:37, schrieb scott:
>> The second image shows virtually the same scene, but with radiosity
>> caching disabled, the radiosity count parameter set to a much lower
>> value, and rendered with UberPOV's oversampling ("anti-aliasing") mode 3
>> with settings chosen to render in about the same time; speed was 3076
>> pps in this case. Oversampling was set to +am3 +a0.056 +ac0.9.
>
> Looks very good. What is the keyword needed to disable radiosity caching
> and what does the +ac value mean?
To disable caching, just add the keyword "no_cache" to the radiosity
block. Make sure to not set the "count" parameter too high - a value as
low as 10 is perfectly ok for this approach.
As for the mode 3 oversampling, this mode is driven by a stochastic
algorithm, similar to focal blur; the +a parameter specifies the
/variance/, and the +ac parameter specifies the /confidence/.
In layman's terms, the mode 3 is all about estimates: While it renders
pixels over and over again, it estimates (A) the colour of the pixel,
(B) the error in the estimated colour, i.e. how much it still differs
from the actual value, and (C) the reliability of the error estimate.
The +a parameter specifies the maximum estimated error you are willing
to accept, while the +ac parameter specifies the minimum reliability you
demand for that error estimate.
In even simpler terms, the +a parameter affects the amount of general
noise in the resulting image, while the +ac parameter affects the amount
of speckle artifacts.
(Last not least, the +r parameter puts a hard maximum on the number of
samples per pixel. The effective limit is 4 to the power of the
parameter value, making it approximately the same as for a worst-case
scenario in anti-aliasing mode 2.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> To disable caching, just add the keyword "no_cache" to the radiosity
> block. Make sure to not set the "count" parameter too high - a value as
> low as 10 is perfectly ok for this approach.
>
> As for the mode 3 oversampling, this mode is driven by a stochastic
> algorithm, similar to focal blur; the +a parameter specifies the
> /variance/, and the +ac parameter specifies the /confidence/.
>
> In layman's terms, the mode 3 is all about estimates: While it renders
> pixels over and over again, it estimates (A) the colour of the pixel,
> (B) the error in the estimated colour, i.e. how much it still differs
> from the actual value, and (C) the reliability of the error estimate.
> The +a parameter specifies the maximum estimated error you are willing
> to accept, while the +ac parameter specifies the minimum reliability you
> demand for that error estimate.
>
> In even simpler terms, the +a parameter affects the amount of general
> noise in the resulting image, while the +ac parameter affects the amount
> of speckle artifacts.
>
> (Last not least, the +r parameter puts a hard maximum on the number of
> samples per pixel. The effective limit is 4 to the power of the
> parameter value, making it approximately the same as for a worst-case
> scenario in anti-aliasing mode 2.)
Thanks, I look forward to having a play. I will have to dig out my
original scene of a TV stand that just refused to work with radiosity
and led me to MCpov in the first place.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/24/2014 04:27 AM, clipka wrote:
> Am 24.07.2014 09:37, schrieb scott:
>>> The second image shows virtually the same scene, but with radiosity
>>> caching disabled, the radiosity count parameter set to a much lower
>>> value, and rendered with UberPOV's oversampling ("anti-aliasing") mode 3
>>> with settings chosen to render in about the same time; speed was 3076
>>> pps in this case. Oversampling was set to +am3 +a0.056 +ac0.9.
>>
>> Looks very good. What is the keyword needed to disable radiosity caching
>> and what does the +ac value mean?
>
> To disable caching, just add the keyword "no_cache" to the radiosity
> block. Make sure to not set the "count" parameter too high - a value as
> low as 10 is perfectly ok for this approach.
Hmmm ... I'm getting an error
File 'Work.pov' line 86: Parse Error: No matching } in 'radiosity',
undeclared
identifier 'no_cache' found instead
Fatal error in parser: Cannot parse input.
Render failed
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
>> To disable caching, just add the keyword "no_cache" to the radiosity
>> block. Make sure to not set the "count" parameter too high - a value as
>> low as 10 is perfectly ok for this approach.
>
> Hmmm ... I'm getting an error
>
> File 'Work.pov' line 86: Parse Error: No matching } in 'radiosity',
> undeclared
> identifier 'no_cache' found instead
> Fatal error in parser: Cannot parse input.
> Render failed
Hmmm works OK here - are you sure you're running the latest executable?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 07/24/2014 05:29 AM, scott wrote:
>>> To disable caching, just add the keyword "no_cache" to the radiosity
>>> block. Make sure to not set the "count" parameter too high - a value as
>>> low as 10 is perfectly ok for this approach.
>>
>> Hmmm ... I'm getting an error
>>
>> File 'Work.pov' line 86: Parse Error: No matching } in 'radiosity',
>> undeclared
>> identifier 'no_cache' found instead
>> Fatal error in parser: Cannot parse input.
>> Render failed
>
> Hmmm works OK here - are you sure you're running the latest executable?
>
relatively sure ... i already had git repo defined so all i had to do
was: git pull develop develop to update. make was showing the same
warnings that I reported in "Perfect Polish" thread, and version shows:
UberPOV 1.37-dev
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> relatively sure ... i already had git repo defined so all i had to do
> was: git pull develop develop to update. make was showing the same
> warnings that I reported in "Perfect Polish" thread, and version shows:
> UberPOV 1.37-dev
Oh ok, I just took the windows binary, that might explain it.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 24.07.2014 11:42, schrieb James Holsenback:
> On 07/24/2014 05:29 AM, scott wrote:
>>>> To disable caching, just add the keyword "no_cache" to the radiosity
>>>> block. Make sure to not set the "count" parameter too high - a value as
>>>> low as 10 is perfectly ok for this approach.
>>>
>>> Hmmm ... I'm getting an error
>>>
>>> File 'Work.pov' line 86: Parse Error: No matching } in 'radiosity',
>>> undeclared
>>> identifier 'no_cache' found instead
>>> Fatal error in parser: Cannot parse input.
>>> Render failed
>>
>> Hmmm works OK here - are you sure you're running the latest executable?
>>
>
> relatively sure ... i already had git repo defined so all i had to do
> was: git pull develop develop to update. make was showing the same
> warnings that I reported in "Perfect Polish" thread, and version shows:
> UberPOV 1.37-dev
"UberPOV 1.37-dev" can be virtually anything; I suggest fetching the
official v1.37.0.0-beta.6 sources.
(Or pull the develop branch again... it so happens that I hadn't pushed
the latest changes to that branch yet, just the master branch. Whoops.)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
