 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hello everybody,
when I use am3 (stochastic anti-aliasing) in the latest version (10064738), it
is about 5 times slower then in uberpov:
Persistence of Vision(tm) Ray Tracer Version 3.8.0-x.10064738.unofficial (g++ 7
@ x86_64-pc-linux-gnu)
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 20 minutes 4 seconds (1204.944 seconds)
using 4 thread(s) with 4542.093 CPU-seconds total
UberPOV Raytracer Version 1.37.1.0-beta.10 (g++ 7 @ x86_64-pc-linux-gnu)
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 3 minutes 52 seconds (232.382 seconds)
using 4 thread(s) with 907.615 CPU-seconds total
Command line is:
povray +d +p +q9 +am3 +a0.1 +ac0.9 +r6 AntiAliasingTest.pov
uberpov +d +p +q9 +am3 +a0.1 +ac0.9 +r6 AntiAliasingTest.pov
Does anybody have a clue why povray is so much slower?
Cheers
Ton
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/14/20 4:42 AM, Ton wrote:
> Hello everybody,
>
> when I use am3 (stochastic anti-aliasing) in the latest version (10064738), it
> is about 5 times slower then in uberpov:
>
> Persistence of Vision(tm) Ray Tracer Version 3.8.0-x.10064738.unofficial (g++ 7
> @ x86_64-pc-linux-gnu)
> Render Time:
> Photon Time: No photons
> Radiosity Time: No radiosity
> Trace Time: 0 hours 20 minutes 4 seconds (1204.944 seconds)
> using 4 thread(s) with 4542.093 CPU-seconds total
>
> UberPOV Raytracer Version 1.37.1.0-beta.10 (g++ 7 @ x86_64-pc-linux-gnu)
> Render Time:
> Photon Time: No photons
> Radiosity Time: No radiosity
> Trace Time: 0 hours 3 minutes 52 seconds (232.382 seconds)
> using 4 thread(s) with 907.615 CPU-seconds total
>
> Command line is:
> povray +d +p +q9 +am3 +a0.1 +ac0.9 +r6 AntiAliasingTest.pov
> uberpov +d +p +q9 +am3 +a0.1 +ac0.9 +r6 AntiAliasingTest.pov
>
> Does anybody have a clue why povray is so much slower?
>
> Cheers
> Ton
>
Are the results more or less similar?
I know uber differs in code structure. I've myself run across an am3
case in v3.8 where the run time - on a solid color change - increased
100x. Not yet dug into the latter. Beyond that, no idea.
If the AntiAliasingTest.pov scene is relatively small and self
contained, could you post a copy? I'll at least put it in my issues
directory, though who knows when I might take a look at it.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymous org> wrote:
>
> Are the results more or less similar?
>
> I know uber differs in code structure. I've myself run across an am3
> case in v3.8 where the run time - on a solid color change - increased
> 100x. Not yet dug into the latter. Beyond that, no idea.
>
> If the AntiAliasingTest.pov scene is relatively small and self
> contained, could you post a copy? I'll at least put it in my issues
> directory, though who knows when I might take a look at it.
>
> Bill P.
Wow, a hundred times slower, and I was complaining about 5 times!
Here is my little test file:
#version 3.7;
global_settings
{
assumed_gamma 1
noise_generator 2
}
background
{
color srgb <0, 0, 0>
}
union
{
#for (I, -25, 25, 1)
cylinder
{
<-20, 0, 0>, <20, 0, I>, 0.01
}
#end
pigment
{
color srgb<1, 1, 1>
}
}
light_source
{
<25, 8, 0>, rgb<1, 1, 1>
}
camera
{
location <25, 8, 0>
right <image_width / image_height, 0, 0>
look_at <12, 0, 0>
}
Cheers
Ton
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/14/20 12:35 PM, William F Pokorny wrote:
> On 9/14/20 4:42 AM, Ton wrote:
>> Hello everybody,
>>
>> when I use am3 (stochastic anti-aliasing) in the latest version
>> (10064738), it
>> is about 5 times slower then in uberpov:
>>
>> Persistence of Vision(tm) Ray Tracer Version
>> 3.8.0-x.10064738.unofficial (g++ 7
>> @ x86_64-pc-linux-gnu)
>> Render Time:
>> Photon Time: No photons
>> Radiosity Time: No radiosity
>> Trace Time: 0 hours 20 minutes 4 seconds (1204.944 seconds)
>> using 4 thread(s) with 4542.093 CPU-seconds total
>>
>> UberPOV Raytracer Version 1.37.1.0-beta.10 (g++ 7 @ x86_64-pc-linux-gnu)
>> Render Time:
>> Photon Time: No photons
>> Radiosity Time: No radiosity
>> Trace Time: 0 hours 3 minutes 52 seconds (232.382 seconds)
>> using 4 thread(s) with 907.615 CPU-seconds total
>>
>> Command line is:
>> povray +d +p +q9 +am3 +a0.1 +ac0.9 +r6 AntiAliasingTest.pov
>> uberpov +d +p +q9 +am3 +a0.1 +ac0.9 +r6 AntiAliasingTest.pov
>>
>> Does anybody have a clue why povray is so much slower?
>>
>> Cheers
>> Ton
>>
>
> Are the results more or less similar?
>
> I know uber differs in code structure. I've myself run across an am3
> case in v3.8 where the run time - on a solid color change - increased
> 100x. Not yet dug into the latter. Beyond that, no idea.
>
> If the AntiAliasingTest.pov scene is relatively small and self
> contained, could you post a copy? I'll at least put it in my issues
> directory, though who knows when I might take a look at it.
>
> Bill P.
i've been using the am3 anti-aliasing in POV-Ray 3.8.0-alpha.10064268 in
conjunction with area lights... i'm able to use adaptive 0 then use am3
to cleanup edges etc... so i'd appreciate you finding /some/ time to see
if some speed gains can be found
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ton" <ton### [at] gmailcom> wrote:
>
> Wow, a hundred times slower, and I was complaining about 5 times!
>
> Here is my little test file:
[snip}
on Windows 7...
I don't know if this is useful, but I ran your test scene in three different
version of POV-Ray, using your command-line switches. 800 X 600 render.
1) the experimental build you used (Windows version) which is the most recent--
v3.8.0x.10064738+av694
render time: 19 seconds
2) the latest development build-- v3.8.0-alpha.10064268+av691
render time: 23 seconds
3) v3.7.1-beta 9 (which isn't really useful as a comparison-- I had to delete
"ac0.9" from the command line, as this version didn't recognize it)
render time: 93 seconds
The two 3.8.0 versions produce relatively close render times in Windows... so it
seems that the LONG render time might be Linux-specific(?)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/15/20 6:20 PM, Kenneth wrote:
> "Ton" <ton### [at] gmailcom> wrote:
>
>>
>> Wow, a hundred times slower, and I was complaining about 5 times!
>>
>> Here is my little test file:
> [snip}
>
> on Windows 7...
> I don't know if this is useful, but I ran your test scene in three different
> version of POV-Ray, using your command-line switches. 800 X 600 render.
>
> 1) the experimental build you used (Windows version) which is the most recent--
> v3.8.0x.10064738+av694
>
> render time: 19 seconds
>
> 2) the latest development build-- v3.8.0-alpha.10064268+av691
>
> render time: 23 seconds
>
> 3) v3.7.1-beta 9 (which isn't really useful as a comparison-- I had to delete
> "ac0.9" from the command line, as this version didn't recognize it)
>
> render time: 93 seconds
>
> The two 3.8.0 versions produce relatively close render times in Windows... so it
> seems that the LONG render time might be Linux-specific(?)
>
>
>
>
linux POV-Ray 3.8.0-alpha.10064268 at 800 x 600 ... 16.116 seconds
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/15/20 7:38 PM, Ash Holsenback wrote:
> On 9/15/20 6:20 PM, Kenneth wrote:
>> "Ton" <ton### [at] gmailcom> wrote:
>>
>>>
>>> Wow, a hundred times slower, and I was complaining about 5 times!
>>>
>>> Here is my little test file:
>> [snip}
>>
>> on Windows 7...
>> I don't know if this is useful, but I ran your test scene in three
>> different
>> version of POV-Ray, using your command-line switches. 800 X 600 render.
>>
>> 1) the experimental build you used (Windows version) which is the most
>> recent--
>> v3.8.0x.10064738+av694
>>
>> render time: 19 seconds
>>
>> 2) the latest development build-- v3.8.0-alpha.10064268+av691
>>
>> render time: 23 seconds
>>
>> 3) v3.7.1-beta 9 (which isn't really useful as a comparison-- I had to
>> delete
>> "ac0.9" from the command line, as this version didn't recognize it)
>>
>> render time: 93 seconds
>>
>> The two 3.8.0 versions produce relatively close render times in
>> Windows... so it
>> seems that the LONG render time might be Linux-specific(?)
>>
>>
>>
>>
> linux POV-Ray 3.8.0-alpha.10064268 at 800 x 600 ... 16.116 seconds
when i change version to 3.8 (from 3.7) in the supplied test file...
it's consistently 3 seconds faster
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/14/20 5:26 PM, Ton wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
>>
>> Are the results more or less similar?
>>
>> I know uber differs in code structure. I've myself run across an am3
>> case in v3.8 where the run time - on a solid color change - increased
>> 100x. Not yet dug into the latter. Beyond that, no idea.
>>
>> If the AntiAliasingTest.pov scene is relatively small and self
>> contained, could you post a copy? I'll at least put it in my issues
>> directory, though who knows when I might take a look at it.
>>
>> Bill P.
>
> Wow, a hundred times slower, and I was complaining about 5 times!
>
> Here is my little test file:
...
>
Had to recompile my uberpov. The system libraries had changed since I
last compiled. Compiling uber now a bit of a pain as a good many code
and header updates are needed...
Whining ahead of my first morning coffee I guess. :-)
I'll post an image to binary.images, but answering my initial question -
the results are not similar. p380 is am3 working better with your flag
set than is uberpov. This I believe explains the run time difference(1).
Running compiles of the latest commit of both versions, I see the
following slow down uber to v3.8:
2.4 -> 13.02 ---> 442.50%
I also see a bug because in v3.8 we are getting the am3 stats:
...Samples: 0 Smpls/Pxl: 0.00
where we should see >0 samples and samples/pixel >1.0.
(Jim, I see a slight difference v3.7 to v3.8 scene version too 0.5% or
so - not sure what's up there. For performance I run single threaded.
I'd need to do runs forcing longer run times to be sure how real that
difference is I guess - another day perhaps)
Bill P.
(1) - I have a mental itch there was some difference in flag usage
between uberpov and the initial v3.8 implementation - but it's just not
coming to me. Anyone else recall something? Looking at the commit for
v3.8 where am3 came in, it did have additional changes to the base over
uberpov in planning for better interaction with other features like
media. What has or has not been done in that respect for am3 support I
do not know.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
in Windows 7--
I finally downloaded UberPOV from Github after all these years(!), to give it a
try-- the 'plug-in' version that runs within v3.7.0. But I'm running into
problems with Ton's test scene, specifically his command-line settings of
+d +p +q9 +am3 +a0.1 +ac0.9 +r6
The "+ac.0.9" command is not being recognized. (And yes, I specified #version
3.8 in the test scene itself, in global_settings). That seems strange, as Ton
gets his scene to work in UberPOV...at least in Linux.
The version of UberPOV I'm using is the 'latest' v1.37 (as of late 2016 I
think). Within v3.7.0, it actually shows up as "v3.8.0-alpha.9811560+av591"
But there is also a stand-alone version of UberPOV with its own installer that
Clipka created at an earlier date. I haven't tried that one yet.
Is there an operational difference between the plug-in version I'm using and the
stand-alone version, concerning the "ac0.9" command?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Le 2020-09-17 à 12:21, Kenneth a écrit :
> in Windows 7--
> I finally downloaded UberPOV from Github after all these years(!), to give it a
> try-- the 'plug-in' version that runs within v3.7.0. But I'm running into
> problems with Ton's test scene, specifically his command-line settings of
> +d +p +q9 +am3 +a0.1 +ac0.9 +r6
>
> The "+ac.0.9" command is not being recognized. (And yes, I specified #version
> 3.8 in the test scene itself, in global_settings). That seems strange, as Ton
> gets his scene to work in UberPOV...at least in Linux.
>
> The version of UberPOV I'm using is the 'latest' v1.37 (as of late 2016 I
> think). Within v3.7.0, it actually shows up as "v3.8.0-alpha.9811560+av591"
>
> But there is also a stand-alone version of UberPOV with its own installer that
> Clipka created at an earlier date. I haven't tried that one yet.
>
> Is there an operational difference between the plug-in version I'm using and the
> stand-alone version, concerning the "ac0.9" command?
>
>
>
The «plugin» version need to reside in a sub-folder of another
installation. It piggy back on another installed version.
The «stand alone» is similar but come with all the other files of a
standard version. As the stand alone version is older, it may contain
some bugs that where fixed in the later version, and lack some
optimizations and features.
You may want to install the standalone version, then, replace the
executable with the latest version.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Alain Martel <kua### [at] videotronca> wrote:
>
> The «plugin» version need to reside in a sub-folder of another
> installation. It piggy back on another installed version.
Yes, that is what I am currently doing-- the UberPOV v1.37 'plug-in' is
piggybacking on my v3.7.0 installation, as per Clikpa's old instructions.
UberPOV is actually a v3.8.0.alpha+xxx (in Windows, anyway); what is strange is
that the "+ac0.9" command is not recognizied there, whereas it *is* recognized
in the other 3.8.0xx versions I have.
Yet it DOES work for Ton in *his* UberPOV version.
>
> You may want to install the [UberPOV] standalone version, then, replace the
> executable with the latest version.
That's an interesting idea; I guess I could try that as a last resort.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Kenneth" <kdw### [at] gmailcom> wrote:
> Alain Martel <kua### [at] videotronca> wrote:
>
> >
> > The «plugin» version need to reside in a sub-folder of another
> > installation. It piggy back on another installed version.
>
> Yes, that is what I am currently doing-- the UberPOV v1.37 'plug-in' is
> piggybacking on my v3.7.0 installation, as per Clikpa's old instructions.
> UberPOV is actually a v3.8.0.alpha+xxx (in Windows, anyway); what is strange is
> that the "+ac0.9" command is not recognizied there, whereas it *is* recognized
> in the other 3.8.0xx versions I have.
>
> Yet it DOES work for Ton in *his* UberPOV version.
>
> >
> > You may want to install the [UberPOV] standalone version, then, replace the
> > executable with the latest version.
>
> That's an interesting idea; I guess I could try that as a last resort.
My version of uberpov is from https://github.com/UberPOV/UberPOV, the last
version, dated 10 February 2015.
My version of povray 3.8 is from https://github.com/POV-Ray/povray/tags, the
last version, v3.8.0-x.10064738, dated 19 February 2019.
Povray 3.7 doesn't have the stochastic rendering mode am3, that's probably why
your plugin on version 3.7.0 doesn't work, but I don't have any experience with
the piggy back.
BTW Uberpov out of the box doesn't compile right now, because the
boost-libraries have changed. I wouldn't mind checking my modified files in into
Uberpov, but I need permission to do that, and I don't want to create another
fork of povray. It's complicated and confusing with all those forks as it is.
Cheers
Ton.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/17/20 6:48 PM, Ton wrote:
...
> My version of uberpov is from https://github.com/UberPOV/UberPOV, the last
> version, dated 10 February 2015.
FWIW. That version will be missing the following commit in the uber branch:
commit 0d7ee74f74ec87c5fc93a4d17843491fc193a525
Author: Christoph Lipka <c-l### [at] usersnoreplygithubcom>
Date: Thu Sep 1 21:54:35 2016 +0200
Fixed bug in anti-aliasing mode 3.
This commit compensates for changes in official POV-Ray that caused
the image to be shifted by half a pixel in anti-aliasing mode 3.
---
This doesn't explain the performance difference as I compiled and ran:
commit 0333f9b5a8461aa7adb7fb8adea3b0eb1780caac (HEAD -> UberPOVdev,
UberPOV/develop)
Author: Christoph Lipka <c-l### [at] usersnoreplygithubcom>
Date: Mon Nov 21 03:42:43 2016 +0100
which includes the commit/fix above. I see the performance difference
you see with your flag settings. One I believe is due the v3.8
implementation doing more work (a better job) at any identical set of
flags.
Why? I don't know. Does it much matter? In the end we're after a result.
If I play a while running Uberpov aiming to match consumed cpu time(1),
when I get to 16.97s for v3.8 and 16.2 seconds for Uberpov, the images
are not identical - but the results are now quite similar.
To get these nearly matching image results and times I used:
povray +d +p +q9 +am3 +a0.1 +ac0.9 +r6 AntiAliasingTest.pov
uberpov +d +p +q9 +am3 +a0.035 +ac0.9 +r6 AntiAliasingTest.pov
I have a vague memory something with flag handling was different uberpov
to v3.8 as stated 'somewhere' by Christoph. I cannot clearly remember or
find it.
A wild guess would be something like one implementation getting the
internal anit-alias gamma handling right and other not, but - wild guess.
(1) - If the samples/pixel stats were working we could align these
counts of cpu time consumed.
I don't think we have a fat rabbit to chase here.
Of course run time improvements with am3 would be welcome. I have on my
list to do some profiling with parametrics. Might take a side look at
am3 too while I've got those compiles about. I've got the color shift
issue to replicate and run down someday too. Hmm, wonder if I can
trigger it with your simpler test cast Ton.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/18/20 6:36 AM, William F Pokorny wrote:
...
>
> I don't think we have a fat rabbit to chase here.
>
> Of course run time improvements with am3 would be welcome. I have on my
> list to do some profiling with parametrics. Might take a side look at
> am3 too while I've got those compiles about. I've got the color shift
> issue to replicate and run down someday too. Hmm, wonder if I can
> trigger it with your simpler test cast Ton.
>
We can indeed! All one needs do is change:
background { color srgb <0, 0, 0> }
to:
#declare Acajou = srgb <0.29804,0.18431,0.15294>;
background { color Acajou }
and the cpu time jumps.
16.918 -> 3443.029 ---> 20251.28%
Plus the results are to my eye not as good.
Does uberpov has the same behavior:
16.172 -> 3512.926 ---> 21622.27%
A fat rabbit.
Bill P.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
William F Pokorny <ano### [at] anonymousorg> wrote:
> >
> > Hmm, wonder if I can
> > trigger it with your simpler test cast Ton.
> >
>
> We can indeed! All one needs do is change:
>
> background { color srgb <0, 0, 0> }
>
> to:
>
> #declare Acajou = srgb <0.29804,0.18431,0.15294>;
> background { color Acajou }
>
> and the cpu time jumps.
>
> 16.918 -> 3443.029 ---> 20251.28%
>
> Plus the results are to my eye not as good.
>
> Does uberpov has the same behavior:
>
> 16.172 -> 3512.926 ---> 21622.27%
>
WOW! That's incredible. Excellent detective work, Bill.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Ton" <ton### [at] gmailcom> wrote:
> My version of uberpov is from https://github.com/UberPOV/UberPOV, the last
> version, dated 10 February 2015.
OK. I downloaded the Windows 64-bit version of this-- I *think* it's the correct
'stand-alone' version-- dated one day earlier on the Github page: UberPOV
v1.37.1.0.beta10
> Povray 3.7 doesn't have the stochastic rendering mode am3, that's probably why
> your plugin on version 3.7.0 doesn't work...
Apparently you're correct; this earlier(!) version of UberPOV DOES recognize the
"+ac0.9" command. That seems strange to me; I would have thought that the
(later) piggyback version for 3.7.0 would also have that ability already
built-in to its binary, thus 'overriding' 3.7.0's limitation. Anyway, it does
work. Thanks.
[William wrote...}
> Hmm, wonder if I can trigger it with your simpler test cast Ton.
>
> We can indeed! All one needs do is change:
> background { color srgb <0, 0, 0> }
> to:
> #declare Acajou = srgb <0.29804,0.18431,0.15294>;
>background { color Acajou }
> and the cpu time jumps...
[snip]
In the Windows version of UberPOV beta 10 (the version I downloaded, as above),
the render times for Ton's scene are identical, with or without this
background/color change-- a quick 4 seconds at 800X600. But the visual results
indicate that AA is not working at all, or very minimally. And, as you mentioned
earlier, the render statistics say:
Antialiasing...on (Method 3, Threshold 0.100, Depth 6, Jitter 1.00, Gamma 2.50)
samples: 0 Smpls/Pxl: 0.00
-----------
[off-topic]
This UberPOV beta 10 'stand-alone'(?) installation was an interesting
experience. Unpacking it in 7-zip, it unzips as a 'application'. I thought this
would be an 'installer'-- but no, clicking on it launches UberPOV itself...with
scenes present that I had already opened in some other version of POV-ray. It
makes me wonder what assets this version is automatically using; maybe from
within my 3.7.0 folder(s)?
Another odd thing:
Running Ton's test scene the first time in this version, there was a fatal
error... in his camera declaration, of all places!
camera
{
location <25, 8, 0>
right <image_width / image_height, 0, 0>
look_at <12, 0, 0>
}
The fatal error was at the 2nd line-- ""Expected numneric expression, / found
instead". Huh?!
So I changed that line to the more standard syntax,
right x*image_width/image_height
..... but that triggered a *different* fatal error...
"No matching } in 'camera', * found instead". Huh?!
I finally got it to work by using
right <1.3333,0,0>
Very strange...especially since my own more complex scenes run perfectly OK with
the 'problem' syntax. (Although, in my scenes, I never put the camera
declaration as the last item. Maybe that's the culprit?)
It's a good thing that I have a sense of humor; otherwise, these crazy errors
would drive me insane ;-)
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/18/20 7:22 AM, William F Pokorny wrote:
> On 9/18/20 6:36 AM, William F Pokorny wrote:
> ...
>>
>> I don't think we have a fat rabbit to chase here.
>>
>> Of course run time improvements with am3 would be welcome. I have on
>> my list to do some profiling with parametrics. Might take a side look
>> at am3 too while I've got those compiles about. I've got the color
>> shift issue to replicate and run down someday too. Hmm, wonder if I
>> can trigger it with your simpler test cast Ton.
>>
>
> We can indeed! All one needs do is change:
>
> background { color srgb <0, 0, 0> }
>
> to:
>
> #declare Acajou = srgb <0.29804,0.18431,0.15294>;
> background { color Acajou }
>
> and the cpu time jumps.
>
> 16.918 -> 3443.029 ---> 20251.28%
>
> Plus the results are to my eye not as good.
>
> Does uberpov has the same behavior:
>
> 16.172 -> 3512.926 ---> 21622.27%
>
> A fat rabbit.
>
> Bill P.
tried changing my am3 test file like above ... cannot duplicate issue
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/18/20 10:47 AM, Kenneth wrote:
> "Ton" <ton### [at] gmailcom> wrote:
>
>> My version of uberpov is from https://github.com/UberPOV/UberPOV, the last
>> version, dated 10 February 2015.
>
> OK. I downloaded the Windows 64-bit version of this-- I *think* it's the correct
> 'stand-alone' version-- dated one day earlier on the Github page: UberPOV
> v1.37.1.0.beta10
>
>> Povray 3.7 doesn't have the stochastic rendering mode am3, that's probably why
>> your plugin on version 3.7.0 doesn't work...
>
> Apparently you're correct; this earlier(!) version of UberPOV DOES recognize the
> "+ac0.9" command. That seems strange to me; I would have thought that the
> (later) piggyback version for 3.7.0 would also have that ability already
> built-in to its binary, thus 'overriding' 3.7.0's limitation. Anyway, it does
> work. Thanks.
>
> [William wrote...}
>> Hmm, wonder if I can trigger it with your simpler test cast Ton.
>>
>> We can indeed! All one needs do is change:
>> background { color srgb <0, 0, 0> }
>> to:
>> #declare Acajou = srgb <0.29804,0.18431,0.15294>;
>> background { color Acajou }
>> and the cpu time jumps...
> [snip]
>
> In the Windows version of UberPOV beta 10 (the version I downloaded, as above),
> the render times for Ton's scene are identical, with or without this
> background/color change-- a quick 4 seconds at 800X600. But the visual results
> indicate that AA is not working at all, or very minimally. And, as you mentioned
> earlier, the render statistics say:
>
> Antialiasing...on (Method 3, Threshold 0.100, Depth 6, Jitter 1.00, Gamma 2.50)
>
> samples: 0 Smpls/Pxl: 0.00
>
> -----------
> [off-topic]
> This UberPOV beta 10 'stand-alone'(?) installation was an interesting
> experience. Unpacking it in 7-zip, it unzips as a 'application'. I thought this
> would be an 'installer'-- but no, clicking on it launches UberPOV itself...with
> scenes present that I had already opened in some other version of POV-ray. It
> makes me wonder what assets this version is automatically using; maybe from
> within my 3.7.0 folder(s)?
>
> Another odd thing:
> Running Ton's test scene the first time in this version, there was a fatal
> error... in his camera declaration, of all places!
>
> camera
> {
> location <25, 8, 0>
> right <image_width / image_height, 0, 0>
> look_at <12, 0, 0>
> }
>
> The fatal error was at the 2nd line-- ""Expected numneric expression, / found
> instead". Huh?!
>
> So I changed that line to the more standard syntax,
> right x*image_width/image_height
>
> ..... but that triggered a *different* fatal error...
> "No matching } in 'camera', * found instead". Huh?!
>
> I finally got it to work by using
> right <1.3333,0,0>
>
> Very strange...especially since my own more complex scenes run perfectly OK with
> the 'problem' syntax. (Although, in my scenes, I never put the camera
> declaration as the last item. Maybe that's the culprit?)
>
> It's a good thing that I have a sense of humor; otherwise, these crazy errors
> would drive me insane ;-)
i've not followed uber for a bit now ... but in version povray
3.8.0-alpha.10064268 you don't even have to set the right vector
anymore: http://wiki.povray.org/content/Reference:Camera#Aspect_Ratio
... so i'm not sure where the uber you're using is at ... just a thought.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Ash Holsenback <no### [at] spamcom> wrote:
>
> i've not followed uber for a bit now ... but in version povray
> 3.8.0-alpha.10064268 you don't even have to set the right vector
> anymore: http://wiki.povray.org/content/Reference:Camera#Aspect_Ratio
Thanks; I didn't know about that change.
> ... so i'm not sure where the uber you're using is at ...
All of the versions that I could find are here:
https://github.com/UberPOV/UberPOV/releases
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
Ash Holsenback <no### [at] spamcom> wrote:
> On 9/18/20 7:22 AM, William F Pokorny wrote:
> > On 9/18/20 6:36 AM, William F Pokorny wrote:
> > ...
> >>
> >> I don't think we have a fat rabbit to chase here.
> >>
> >> Of course run time improvements with am3 would be welcome. I have on
> >> my list to do some profiling with parametrics. Might take a side look
> >> at am3 too while I've got those compiles about. I've got the color
> >> shift issue to replicate and run down someday too. Hmm, wonder if I
> >> can trigger it with your simpler test cast Ton.
> >>
> >
> > We can indeed! All one needs do is change:
> >
> > background { color srgb <0, 0, 0> }
> >
> > to:
> >
> > #declare Acajou = srgb <0.29804,0.18431,0.15294>;
> > background { color Acajou }
> >
> > and the cpu time jumps.
> >
> > 16.918 -> 3443.029 ---> 20251.28%
> >
> > Plus the results are to my eye not as good.
> >
> > Does uberpov has the same behavior:
> >
> > 16.172 -> 3512.926 ---> 21622.27%
> >
> > A fat rabbit.
> >
> > Bill P.
>
> tried changing my am3 test file like above ... cannot duplicate issue
fwiw, same here, also alpha.10064268. in fact the coloured bg version is
faster,
edited transcript:
Script started on Fri 18 Sep 2020 20:58:43 BST
jr@crow:1:tmp$ c### [at] ngtonpov
#version 3.8;
global_settings {
assumed_gamma 1
noise_generator 2
}
#ifndef (global.N)
#declare N = 0;
#end
#if (N)
background {color srgb <.29804,.18431,.15294>}
#else
background {color srgb 0}
#end
union {
#for (I, -25, 25, 1)
cylinder {
<-20, 0, 0>, <20, 0, I>, 0.01
}
#end
pigment {
color srgb<1, 1, 1>
}
}
light_source {
<25, 8, 0>, rgb<1, 1, 1>
}
camera {
location <25, 8, 0>
right <image_width / image_height, 0, 0>
look_at <12, 0, 0>
}
jr@crow:2:tmp$ pov38 ngton.pov +d +p +q9 +am3 +a0.1 +ac0.9 +r6
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10064268.unofficial
(g++ 4.8.2 @ x86_64-slackware-linux-gnu)
...
Support libraries used by POV-Ray:
ZLib 1.2.8, Copyright 1995-2012 Jean-loup Gailly and Mark Adler
LibPNG 1.4.20, Copyright 1998-2012 Glenn Randers-Pehrson
LibJPEG 8, Copyright 1991-2016 Thomas G. Lane, Guido Vollbeding
LibTIFF 3.9.7, Copyright 1988-1997 Sam Leffler, 1991-1997 SGI
Boost 1.54, http://www.boost.org/
OpenEXR 1.7.1 and IlmBase 1.0.3, Copyright (c) 2002-2011 Industrial Light &
Magic.
Dynamic optimizations:
CPU detected: Intel,SSE2,AVX
Noise generator: avx-intel (hand-optimized by Intel)
Parser Options
Input file: ngton.pov
Remove bounds........On
Split unions.........Off
Library paths:
/home/jr/.local/povray/include
/usr/local/share/povray-3.8/extra
/usr/local/share/povray-3.8/include
/usr/share/fonts/local
Clock value: 0.000 (Animation off)
Image Output Options
Image resolution.....960 by 720 (rows 1 to 720, columns 1 to 960).
Output file..........ngton.png, 24 bpp PNG
Dithering............Off
Graphic display......On (gamma: sRGB transfer function)
Mosaic preview.......Off
Continued trace......Off
Information Output Options
All Streams to console..........On
Debug Stream to console.........On
Fatal Stream to console.........On
Render Stream to console........On
Statistics Stream to console....On
Warning Stream to console.......On
==== [Parsing...] ==========================================================
----------------------------------------------------------------------------
Parser Statistics
----------------------------------------------------------------------------
Finite Objects: 51
Infinite Objects: 0
Light Sources: 1
Total: 52
----------------------------------------------------------------------------
Parser Time
Parse Time: 0 hours 0 minutes 0 seconds (0.001 seconds)
using 1 thread(s) with 0.000 CPU-seconds total
Bounding Time: 0 hours 0 minutes 0 seconds (0.000 seconds)
using 1 thread(s) with 0.000 CPU-seconds total
----------------------------------------------------------------------------
Render Options
Quality: 9
Bounding boxes.......On Bounding threshold: 3
Antialiasing.........On (Method 3, Threshold 0.100, Depth 6, Jitter 1.00,
Gamma 2.50)
==== [Rendering... Press p to pause, q to quit] ============================
----------------------------------------------------------------------------
Render Statistics
Image Resolution 960 x 720
----------------------------------------------------------------------------
Pixels: 691200 Samples: 0 Smpls/Pxl: 0.00
Rays: 5249224 Saved: 0 Max Level: 1/5
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Cone/Cylinder 123247827 1250084 1.01
Bounding Box 187640060 147701275 78.72
----------------------------------------------------------------------------
Shadow Ray Tests: 1226634 Succeeded: 0
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 0 minutes 11 seconds (11.444 seconds)
using 2 thread(s) with 22.876 CPU-seconds total
==== [Paused... Press p to resume] =========================================
Press p, q, enter or click the display to continue...
POV-Ray finished
jr@crow:3:tmp$ pov38 ngton.pov +d +p +q9 +am3 +a0.1 +ac0.9 +r6 declare=N=1
Persistence of Vision(tm) Ray Tracer Version 3.8.0-alpha.10064268.unofficial
(g++ 4.8.2 @ x86_64-slackware-linux-gnu)
...
----------------------------------------------------------------------------
Render Statistics
Image Resolution 960 x 720
----------------------------------------------------------------------------
Pixels: 691200 Samples: 0 Smpls/Pxl: 0.00
Rays: 2283041 Saved: 0 Max Level: 1/5
----------------------------------------------------------------------------
Ray->Shape Intersection Tests Succeeded Percentage
----------------------------------------------------------------------------
Cone/Cylinder 51037867 472363 0.93
Bounding Box 77941671 61111153 78.41
----------------------------------------------------------------------------
Shadow Ray Tests: 463586 Succeeded: 0
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Render Time:
Photon Time: No photons
Radiosity Time: No radiosity
Trace Time: 0 hours 0 minutes 5 seconds (5.006 seconds)
using 2 thread(s) with 9.995 CPU-seconds total
==== [Paused... Press p to resume] =========================================
Press p, q, enter or click the display to continue...
POV-Ray finished
'pov38' is a BASH alias for 'nice -n 19 povray'.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"jr" <cre### [at] gmailcom> wrote:
> Ash Holsenback <no### [at] spamcom> wrote:
> > On 9/18/20 7:22 AM, William F Pokorny wrote:
> > > On 9/18/20 6:36 AM, William F Pokorny wrote:
> > > ...
> > > and the cpu time jumps.
> > > ...
> fwiw, ...
no sleep. :-( so, if you (WFP)/anyone is interested, I can add to the ..
mystery.
I have the same alpha.10064268 installed on two machines, and I mean the same.
both built from the same tarball using nearly identical package build scripts.
on one machine, as posted, I see a decrease in time by (just) better than 50%
for the coloured background. on the other, the alpha behaves as you describe,
time up from seconds to over a quarter of an hour. wow. I also tried two older
3.8.0-alphas (9893777 and 9945627) on a third box, they too run faster by around
50% when colour is used. one thing I noticed is that where time decreases, on
the older boxes, the "CPU detected" reads "Intel,SSE2,AVX", whereas for the ..
misbehaving alpha (newer box) it's "Intel,SSE,AVX,AVX2,FMA3". no idea whether
that is relevant, still, it'd be interesting to know what CPU flags others see.
anyway, as Kenneth intimated, computing, eh? -- all good fun.
regards, jr.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/18/20 8:21 PM, jr wrote:
> "jr" <cre### [at] gmailcom> wrote:
...
>
> no sleep. :-( so, if you (WFP)/anyone is interested, I can add to the ..
> mystery.
>
> I have the same alpha.10064268 installed on two machines, and I mean the same.
> both built from the same tarball using nearly identical package build scripts.
> on one machine, as posted, I see a decrease in time by (just) better than 50%
> for the coloured background. on the other, the alpha behaves as you describe,
> time up from seconds to over a quarter of an hour. wow. I also tried two older
> 3.8.0-alphas (9893777 and 9945627) on a third box, they too run faster by around
> 50% when colour is used. one thing I noticed is that where time decreases, on
> the older boxes, the "CPU detected" reads "Intel,SSE2,AVX", whereas for the ..
> misbehaving alpha (newer box) it's "Intel,SSE,AVX,AVX2,FMA3". no idea whether
> that is relevant, still, it'd be interesting to know what CPU flags others see.
> anyway, as Kenneth intimated, computing, eh? -- all good fun.
>
>
Jim, and all thanks for the data. And jr, especially, for picking up the
"Intel,SSE,AVX,AVX2,FMA3" bit. It is what I see here for run time
optimization. I've hit a few other cases where - for whatever reasons -
that run time CPU optimization isn't faster for me, though usually it
is. Nothing previously was anywhere as dramatic a slow down.
I've never looked over Christoph's am3 code. Guess I'll go take a peek.
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/19/20 8:22 AM, William F Pokorny wrote:
...
>
> I've never looked over Christoph's am3 code. Guess I'll go take a peek.
>
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;
I think in povr I've fixed the stats - so your line counts might be a
little different.
I hacked the up front confidence array (as vector) to something simpler
so my b/w runs in about 2 seconds and my color one in 34s. Stats now
show for the two renders:
Pixels: 360000 Samples: 609399 Smpls/Pxl: 1.69
and
Pixels: 360000 Samples: 9511337 Smpls/Pxl: 26.42
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
hi,
William F Pokorny <ano### [at] anonymousorg> 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
|
|
| |
| |
|
|
|
|
| |
|
|
