POV-Ray : Newsgroups : povray.general : povray vs uberpov am3 : Re: povray vs uberpov am3 Server Time
28 Apr 2024 21:51:57 EDT (-0400)
  Re: povray vs uberpov am3  
From: William F Pokorny
Date: 18 Sep 2020 06:36:38
Message: <5f648db6$1@news.povray.org>
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

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.