 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymous org> wrote:
> On 9/19/20 8:22 AM, William F Pokorny wrote:
> ...
> Hey jr, Given you have machine which shows the slow down and one which
> does not, would you be willing to add the following test in compiles for
> both machines? Then try white/black and white/color renders on both?
>
> In tracetask.cpp, at about line 764, insert code so things look like:
>
> double cf = confidenceFactor[neighborSamples-1];
> PreciseRGBTColour sqrtvar = Sqrt(variance);
>
> if (variance.red()<0)
> throw POV_EXCEPTION_STRING("kaboom");
>
> PreciseRGBTColour confidenceDelta = sqrtvar * cf;
sure, will find time in the next few days. (will I need line above and below
for context or is it "self-evident"? :-))
a specific "white/black and white/colour" test scene or are you referring to
Ton's code modified?
> ...
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/19/20 10:52 AM, jr wrote:
...
>> In tracetask.cpp, at about line 764, insert code so things look like:
>>
>> double cf = confidenceFactor[neighborSamples-1];
>> PreciseRGBTColour sqrtvar = Sqrt(variance);
>>
>> if (variance.red()<0)
>> throw POV_EXCEPTION_STRING("kaboom");
>>
>> PreciseRGBTColour confidenceDelta = sqrtvar * cf;
>
> sure, will find time in the next few days. (will I need line above and below
> for context or is it "self-evident"? :-))
The lines above and below the test and throw are provided for context.
> a specific "white/black and white/colour" test scene or are you referring to
> Ton's code modified?
Ton's code modified for color and not. What you were running on both
machines.
>
>> ...
>
Thanks. It's less a priority 4 hours later :-), but I would like to see
the results.
--------
Both implementations have the same basic problem. The occasional square
root of negative values (Domain errors). Both would kinda / sorta work
regardless. Due compiler versions, flag settings or maybe machine types
- seems, on the domain errors, you might not break on the color channel
threshold and instead only break on hitting the max samples check.
To fix those of you compiling at home can change the code in
tracetask.cpp to look like:
if (samples >= minSamples)
{
if (samples >= maxSamples)
break;
PreciseRGBTColour variance =
(neighborSumSqr - Sqr(neighborSum)/neighborSamples)
/ (neighborSamples-1); // Sometimes very slightly neg
variance = PreciseRGBTColour( // Fix
max(0.0,variance.red()), // Fix
max(0.0,variance.green()), // Fix
max(0.0,variance.blue()), // Fix
max(0.0,variance.transm()) // Fix
); // Fix
double cf = confidenceFactor[neighborSamples-1];
PreciseRGBTColour sqrtvar = Sqrt(variance);
PreciseRGBTColour confidenceDelta = sqrtvar * cf;
if (confidenceDelta.red() +
confidenceDelta.green() +
confidenceDelta.blue() +
confidenceDelta.transm() <= threshold)
break;
}
Ton, The reason you need smaller thresholds in v3.8 for equivalent
result in uberpov is the uberpov threshold test was:
if ((confidenceDelta.red() <= threshold) &&
(confidenceDelta.green() <= threshold) &&
(confidenceDelta.blue() <= threshold) &&
(confidenceDelta.transm() <= threshold))
break;
With the fix in povr I can get pretty good white on black, or white on
Acajou results in roughly 16 seconds and 18 seconds, respectively.
Similar quality white on black results took me nearly 20 minutes without
the fix above.
The command lines I used were:
povr2 +d +p +q9 +am3 +a0.05 +ac0.9 +ss123456 +r6 +w600 +h600 ...
povr2 +d +p +q9 +am3 +a0.025 +ac0.9 +ss123456 +r6 +w600 +h600 ...
The color threshold does need to be smaller for similar method3 result
and, on thinking about it, this makes sense. The absolute color
difference white to the background is reduced. I'll post an image of the
two results to povary.binaries.
Aside: There are comments in the code related to allowing a min sampling
of other than 1, which I think could be helpful, but I don't immediately
see how to implement it.
---------
So, all good right? Nope... We have an underlying problem at which I've
yet too look. We have a color template class with a Sqrt method that
doesn't handle negative color values. POV-Ray allows negative color
values. Do we update it to return negative square roots --> (sqrt(abs())
and flip result neg on neg inputs? What might changing this method mean
to the code base as whole? I don't know.
Suppose we might want a maxZero color vector method too - if that a
common need.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/19/20 10:52 AM, jr wrote:
> ...
> > sure, will find time in the next few days. (will I need line above and below
> > for context or is it "self-evident"? :-))
>
> The lines above and below the test and throw are provided for context.
>
> > a specific "white/black and white/colour" test scene or are you referring to
> > Ton's code modified?
>
> Ton's code modified for color and not. What you were running on both
> machines.
yeah, "white" being the line colour sunk in just after posting. :-)
>
> Thanks. It's less a priority 4 hours later :-), but I would like to see
> the results.
excellent. of course.
> ...
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Thanks Bill.
I modified the uberpov and povray sources with your modification, and expecially
povray renders a lot faster, from 235 seconds to 16. The resulting image, to me,
looks the same.
Once again thanks for your effort.
Cheers
Ton.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > On 9/19/20 10:52 AM, jr wrote:
> > ...
> > Thanks. It's less a priority 4 hours later :-), but I would like to see
> > the results.
>
> excellent. of course.
applied your fix on the newer machine, and now see (there, too) a decrease in
time of better than 50%; b/w - 16.105 cpu-seconds, c/w - 6.877 (res 960x720).
the other machine needs cleaning out (physically, runs hotter than I like)
before I get to patching POV-Ray, can post edited transcript of respective runs
in a few days, if you still want "full details".
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/21/20 5:27 PM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
...
> before I get to patching POV-Ray, can post edited transcript of respective runs
> in a few days, if you still want "full details".
>
We can let it go.
Good to see the performance improvements(1). I was still curious about
the color channel < 0 throw results on both machines. But, the
performance improvements from you and Ton I think pretty clearly
indicate the domain error is the start of the problem on all
machine/compiler/os combos and what happens after we can take as
implementation differences for undefined behavior.
(1) - After posting, I played with many renders at different settings
using Ton's test case. It's hard to get rid of the last little open bits
without taking more initial samples. Changes in the seed moves them
around and you could then merge multiple images, but that's ugly. The
only somewhat reliable way I could get there in POV-Ray was by rendering
a larger image. Adding the capability for min samples >1 to am3
necessary, I think, for a best fleshed out implementation. Someday...
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> wrote:
> On 9/21/20 5:27 PM, jr wrote:
> > "jr" <cre### [at] gmailcom> wrote:
> ...
> > before I get to patching POV-Ray, can post edited transcript of respective runs
> > in a few days, if you still want "full details".
>
> We can let it go.
>
> Good to see the performance improvements(1). I was still curious about
> the color channel < 0 throw results on both machines.
:-) I'll post post-patch results for both machines in the coming days. agree
though, a very worthwhile performance boost (and adding that single line was
easy to boot), thank you.
> .... The
> only somewhat reliable way I could get there in POV-Ray was by rendering
> a larger image. ...
yeah, learned that from NK's comments. :-)
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/22/20 5:50 AM, William F Pokorny wrote:
> <snip>
> Changes in the seed moves them
> around and you could then merge multiple images, but that's ugly.
http://wiki.povray.org/content/Reference:Tracing_Options#Stochastic_Seed
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
> > ...
> > Good to see the performance improvements(1). I was still curious about
> > the color channel < 0 throw results on both machines.
>
> :-) I'll post post-patch results for both machines in the coming days. ...
jr@swift:3:$ pov38 ngton.pov -d -p +q9 +am3 +a0.1 +ac0.9 +r6 +w800 +h600
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10064268.unofficial
(g++ 5.5.0 @ x86_64-slackware-linux-gnu)
...
----------------------------------------------------------------------------
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 0 minutes 2 seconds (2.984 seconds)
using 4 thread(s) with 11.797 CPU-seconds total
POV-Ray finished
jr@swift:4:$ pov38 ngton.pov -d -p +q9 +am3 +a0.1 +ac0.9 +r6 +w800 +h600
declare=N=1
...
----------------------------------------------------------------------------
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 0 minutes 1 seconds (1.317 seconds)
using 4 thread(s) with 5.157 CPU-seconds total
POV-Ray finished
jr@crow:2:$ pov38 ngton.pov -d -p +q9 +am3 +a0.1 +ac0.9 +r6 +w800 +h600 +wt4
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10064268.unofficial
(g++ 4.8.2 @ x86_64-slackware-linux-gnu)
...
----------------------------------------------------------------------------
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 0 minutes 6 seconds (6.728 seconds)
using 4 thread(s) with 26.678 CPU-seconds total
POV-Ray finished
jr@crow:3:$ pov38 ngton.pov -d -p +q9 +am3 +a0.1 +ac0.9 +r6 +w800 +h600 +wt4
declare=N=1
...
----------------------------------------------------------------------------
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 0 minutes 2 seconds (2.850 seconds)
using 4 thread(s) with 11.224 CPU-seconds total
POV-Ray finished
all run with 'nice -n 19 ...'. both compiled with '-O2', btw.
regards,jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/24/20 3:35 PM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
>> William F Pokorny <ano### [at] anonymousorg> wrote:
>>> ...
>>> Good to see the performance improvements(1). I was still curious about
>>> the color channel < 0 throw results on both machines.
>>
>> :-) I'll post post-patch results for both machines in the coming days. ...
>
...
>
> all run with 'nice -n 19 ...'. both compiled with '-O2', btw.
>
Thanks! Looks good in that the ratios bw to color are now nearly the
same on both of your machines and mine.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
