 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
image is a comparison of the tracetask.cpp fix that bill ask us to
try... working with 3.8.0-alpha.10064268. saved aside before and after
images and did a compare:
Post a reply to this message
Attachments:
Download 'am3diff.png' (3254 KB)
Preview of image 'am3diff.png'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/24/20 2:31 PM, Ash Holsenback wrote:
> image is a comparison of the tracetask.cpp fix that bill ask us to
> try... working with 3.8.0-alpha.10064268. saved aside before and after
> images and did a compare:
>
>
Thanks.
Did you happen to capture the CPU times for the two renders?
Did you use -j, +ss and +wt1 on both renders?
Were you using area lights?
---
Your compare image rekindles thinking about color / intensity and AA
approaches; Rendering large and scaling down vs AA or in combination.
The aa +ag flag/setting. A big pile of subtle trade-offs.
Where the previous am3 implementation was sort of working / stopping on
the threshold test (and not the sample limit) there was too a probable
color result change due the uberpov to v3.8 threshold test change.
Further, that test could get done after a conversion to grey scale
(luminosity) instead - which might work better for what it's trying to
do at the expense of CPU time in the threshold test. I'm not sure what
impact to the render due sampling depth such a change would have.
All said. Let me play devil's advocate for a bit with anti-aliasing
methods. I took the biscuit scene and played with am3 until I thought it
was rendering the the ridges on the biscuits well.
Now I do these three renders with my current v3.8 based povr:
--- am3
povr2 biscuit.pov +am3 +a0.015 +ac0.9 +r5 +w450 +h450
438.641
Pixels: 202500 Samples: 37917505 Smpls/Pxl: 187.25
--- am2
povr2 biscuit.pov +am2 +a0.015 +r5 +w450 +h450
413.702
Pixels: 216225 Samples: 48143226 Smpls/Pxl: 222.65
--- am1
povr2 biscuit.pov +am1 +a0.0 +r9 +w450 +h450
133.385
Pixels: 216000 Samples: 16402500 Smpls/Pxl: 75.94
Attached is an image comparing am1 to am3 in the top row; multiplying
the differences by 5. In the bottom row comparing am2 to am3; again
multiplying differences by 5.
What does it all mean? Lots of things I guess. I am comforted that the
updated scenes match well for color and intensity across all three
methods with the am3 fix.
I also tried v3.8 at commit 74b3ebe for grins expecting a really long
run time (maybe with a color shift to explain yours). Instead I got:
p380 biscuit_v38.pov +am3 +a0.015 +ac0.9 +r5 +w450 +h450
408.578s (The posted fix costs time)
Pixels: 202500 Samples: 0 Smpls/Pxl: 0.00
I didn't use +ss but still the images compare well fixed to non-fixed.
What this confirms is the pre-fix code was 'sometimes' working (no
domain errors).
I looked at the code at commit 551338 (your release) and it matches that
at 74b3ebe - also not an explanation for your color difference.
Extra credit to those of you asking why only am3 gets the image pixel
count right...
Bill P.
Post a reply to this message
Attachments:
Download 'storyaamult005.jpg' (587 KB)
Preview of image 'storyaamult005.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/25/20 9:00 AM, William F Pokorny wrote:
> On 9/24/20 2:31 PM, Ash Holsenback wrote:
>> image is a comparison of the tracetask.cpp fix that bill ask us to
>> try... working with 3.8.0-alpha.10064268. saved aside before and after
>> images and did a compare:
>>
>>
>
> Thanks.
>
> Did you happen to capture the CPU times for the two renders?
stock povray rendered it at 9 min 24 sec... lol the fix did it at 9:22
>
> Did you use -j, +ss and +wt1 on both renders?
indeed
>
> Were you using area lights?
not this time... i'll be getting to that eventually because that's
exactly how i'm using am3... adaptive 0 on the area lights and rely on
am3 to do the rest
>
> ---
> Your compare image rekindles thinking about color / intensity and AA
> approaches; Rendering large and scaling down vs AA or in combination.
> The aa +ag flag/setting. A big pile of subtle trade-offs.
>
> Where the previous am3 implementation was sort of working / stopping on
> the threshold test (and not the sample limit) there was too a probable
> color result change due the uberpov to v3.8 threshold test change.
i think that might explain the results i was seeing in my compare image
>
> Further, that test could get done after a conversion to grey scale
> (luminosity) instead - which might work better for what it's trying to
> do at the expense of CPU time in the threshold test. I'm not sure what
> impact to the render due sampling depth such a change would have.
after your comment here i've done some digging... thanks for the nudge
>
> All said. Let me play devil's advocate for a bit with anti-aliasing
> methods. I took the biscuit scene and played with am3 until I thought it
> was rendering the the ridges on the biscuits well.
>
> Now I do these three renders with my current v3.8 based povr:
>
> --- am3
> povr2 biscuit.pov +am3 +a0.015 +ac0.9 +r5 +w450 +h450
> 438.641
> Pixels: 202500 Samples: 37917505 Smpls/Pxl: 187.25
your am3 settings are similar to what i'm using
>
> --- am2
> povr2 biscuit.pov +am2 +a0.015 +r5 +w450 +h450
> 413.702
> Pixels: 216225 Samples: 48143226 Smpls/Pxl: 222.65
>
> --- am1
> povr2 biscuit.pov +am1 +a0.0 +r9 +w450 +h450
> 133.385
> Pixels: 216000 Samples: 16402500 Smpls/Pxl: 75.94
>
> Attached is an image comparing am1 to am3 in the top row; multiplying
> the differences by 5. In the bottom row comparing am2 to am3; again
> multiplying differences by 5.
>
> What does it all mean? Lots of things I guess. I am comforted that the
> updated scenes match well for color and intensity across all three
> methods with the am3 fix.
>
> I also tried v3.8 at commit 74b3ebe for grins expecting a really long
> run time (maybe with a color shift to explain yours). Instead I got:
>
> p380 biscuit_v38.pov +am3 +a0.015 +ac0.9 +r5 +w450 +h450
> 408.578s (The posted fix costs time)
> Pixels: 202500 Samples: 0 Smpls/Pxl: 0.00
hmmmm... i didn't see much time diff between fixed and not. i wonder if
it that's tied to the fact that i never could reproduce the issue that
Ton brought up... fwiw i'm dual core intel g2120 i believe. running leap
15.1
>
> I didn't use +ss but still the images compare well fixed to non-fixed.
> What this confirms is the pre-fix code was 'sometimes' working (no
> domain errors).
>
> I looked at the code at commit 551338 (your release) and it matches that
> at 74b3ebe - also not an explanation for your color difference.
if someone could add to this and maybe explain... i'm lost on that one
>
> Extra credit to those of you asking why only am3 gets the image pixel
> count right...
inquiring minds wanna know
>
> Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/26/20 8:03 AM, Ash Holsenback wrote:
> On 9/25/20 9:00 AM, William F Pokorny wrote:
...
>> Did you happen to capture the CPU times for the two renders?
>
> stock povray rendered it at 9 min 24 sec... lol the fix did it at 9:22
>
Thanks. If you see much lower times with no AA (set threshold negative),
It's likely for your scene '+am3' was running previously too. I suspect
for some who previously got good results, method 3 was running to a stop
at max samples and not the threshold. What run times these renders had
would depend mostly on +r depth - something which can still sort of
(confidence setting in play) happen, if the threshold is set small
enough.
...
>> Were you using area lights?
>
> not this time... i'll be getting to that eventually because that's
> exactly how i'm using am3... adaptive 0 on the area lights and rely on
> am3 to do the rest
>
I know there is an odd interplay between area lights and AA, but I have
never gotten my head around what's really happening.
Two adaptive algorithms fighting for what they think is right?
Why do you think am3 will behave better for such situations?
...
>
> hmmmm... i didn't see much time diff between fixed and not. i wonder if
> it that's tied to the fact that i never could reproduce the issue that
> Ton brought up...
>
Probably. Why your render works could be the compiler, settings when
compiling, hardware. I don't know and don't plan to burn more time on
it.
>>
>> I looked at the code at commit 551338 (your release) and it matches
>> that at 74b3ebe - also not an explanation for your color difference.
>
> if someone could add to this and maybe explain... i'm lost on that one
>
The release at which you run - 3.8.0-alpha.10064268 - is in fact git
commit 551338. The release name is just a name (a git tag). I run v3.8,
and base povr off of a later commit. On seeing your color change, I
thought maybe Christoph had made some change after 551338 which might
explain it. He'd not - at least not in the method 3 core code.
>>
>> Extra credit to those of you asking why only am3 gets the image pixel
>> count right...
>
> inquiring minds wanna know
>
...
I don't myself know! :-) It's been this way since v3.7 at least and it's
a question of which I'm occasionally reminded.
I vaguely recall methods 1 & 2 doing stuff like always taking 4 pixels
initially or throwing center samples away. Don't remember exactly, but
these might be the cause. But then, I ask myself why should these pixels
be counted with the base pixel count and not as additional pixels due
the sampling method... It probably blurs the samples per pixel calculation.
Anyone know why the different base pixel counts on activating am1 or
am2?
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/27/20 9:15 AM, William F Pokorny wrote:
> I vaguely recall methods 1 & 2 doing stuff like always taking 4 pixels
> initially or throwing center samples away. Don't remember exactly, but
> these might be the cause. But then, I ask myself why should these pixels
> be counted with the base pixel count and not as additional pixels due
> the sampling method... It probably blurs the samples per pixel calculation.
Just hit me it does mess up the samples/pixel calc. That am1 test I did:
--- am1
povr2 biscuit.pov +am1 +a0.0 +r9 +w450 +h450
133.385
Pixels: 216000 Samples: 16402500 Smpls/Pxl: 75.94
Should have a samples/pixel value of >= 81. (9x9)
Anyway...
Bill P.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On 9/27/20 9:15 AM, William F Pokorny wrote:
>>> Were you using area lights?
>>
>> not this time... i'll be getting to that eventually because that's
>> exactly how i'm using am3... adaptive 0 on the area lights and rely on
>> am3 to do the rest
>>
>
> I know there is an odd interplay between area lights and AA, but I have
> never gotten my head around what's really happening.
>
> Two adaptive algorithms fighting for what they think is right?
>
> Why do you think am3 will behave better for such situations?
not sure that it is .... the issue that was found just reminded me that
am3 probably needed more of a test drive.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
