For those building their own POV-Ray versions see:

https://github.com/wfpokorny/povray/tree/tune/mediaPerformanceAndSceneFiles

I'm working on other more complicated, longer term alternatives, but the 
commit for the scene changes and the commit for method 3 performance 
contained in this branch are simple, safe and reasonably well tested. 
Enough so that I think it worth considering this branch for adoption in 
release/v3.8.0. Opinions?

Bill P.

--- Details for those interested ---
For the usual Jitter=0 media the performance gain tops out at about 
5.5%. For (abs(Jitter))!=0 there the penalty for the conditional tops 
out at a performance loss of 1.5%.  Not possible at this point, but if 
we could dump the jitter option with method 3 we'd top out at a 7% 
performance gain for complex medias/densities.

Note: I recommend jitter alway be 0 given our current implementation 
unless a noisy, expensive to AA result is what you want.

Note: Performance is always better in my testing where method 3 is 
really used however many of our sample scenes will see less performance 
gain (1-1.5%) because they almost all use constant media (PLAIN_PATTERN 
densities) and so trigger a fast path into method 1 for part of the 
media evaluation. In other words many of our sample scenes partly bypass 
the method 3 code and so the change herein.

While I reformatted the functions 
MediaFunction::ComputeMediaAdaptiveSampling and 
MediaFunction::ComputeOneMediaSampleRecursive to the 120 character max, 
the code change for performance is quite small. Instead of doing the 
jitter calculattion on all ComputeOneMediaSample() calls it changes that 
parameter to:

(IMedia->Jitter==0.0 ? 0.0 : dd * IMedia->Jitter * 
(randomNumberGenerator() - 0.5))

or similar.  In addition the top of ComputeOneMediaSampleRecursive the 
jdist calc becomes:

     if(Jitter==0.0)
         jdist = d2;
     else
         jdist = d2 + Jitter * (d3 - d1) * (randomNumberGenerator() - 0.5);


Aside: It neatly happens the performance improvement here speeds up our 
benchmark scene in my testing almost enough to counter the 
FixedSimpleVector elimination degrade.

--- Scene file changes. Both fix artifacts/bugs/set-up issues.

1) media3.pov - Result looked really bad with existing samples setting 
so increased it until result looked good.

2) micro.pov - Was using "intervals 2" to no benefit.  It was also using 
an assumed_gamma of 1.5.  Changed that to 1.0 and updated the emitting 
media colors for I believe is a much better result.  The exact result 
here not mattering much in any case as just demonstrating technique.

Post a reply to this message

Sorry, I'm a bit late in replying to this one.

Am 18.02.2018 um 16:40 schrieb William F Pokorny:

> Note: I recommend jitter alway be 0 given our current implementation
> unless a noisy, expensive to AA result is what you want.

I'm a bit reluctant to throw jitter overboard entirely (even for an
individual sampling method, particularly the default one). When a scene
contains other sources of image noise anyway (such as subsurface light
transport, jittered area lights, blurred reflections or focal blur),
increasing media jitter may actually be a better choice performance-wise
than cranking up the media sampling quality parameters.

Post a reply to this message

On 04/06/2018 01:44 PM, clipka wrote:
> Sorry, I'm a bit late in replying to this one.
> 
> Am 18.02.2018 um 16:40 schrieb William F Pokorny:
> 
                                  s
>> Note: I recommend jitter alway  be 0 given our current implementation
>> unless a noisy, expensive to AA result is what you want.
> 
> I'm a bit reluctant to throw jitter overboard entirely (even for an
> individual sampling method, particularly the default one). 

Agree given it already exists as is and folks have likely used it in 
scenes. I have it still in my sandbox media branches.

> When a scene
> contains other sources of image noise anyway (such as subsurface light
> transport, jittered area lights, blurred reflections or focal blur),
> increasing media jitter may actually be a better choice performance-wise
> than cranking up the media sampling quality parameters.
> 

If rendering a non-uniform density accurately is your aim, I don't agree 
with the last of this sentence for method 3 jitter. Method 3 jitter is 
expensive noise.

Jitter tends to help 'resolve non-unform media densities' with methods 1 
& 2. Jitter often helps as an option implemented in other than media. In 
those cases jitter amounts to less uniform sampling toward a still 
accurate result. In method 3, jitter - as implemented today - acts 
against the sampling approach even aside from github issue(s): 
https://github.com/POV-Ray/povray/issues/348.

Elsewhere - or maybe only as a thought floating about my head - I've 
suggested a new method 3 aa_jitter feature might be useful. This a 
jitter with an effect more in line with jitter in the other two media 
methods. I wouldn't be free to method 3 performance of course...

Bill P.

Post a reply to this message