What is happening today:

yuqk play.pov -w1500 -h980 +p +am1 +a500.0 +r3 +wt1 +bs1500

........... Image ..... Render ... Added
........... Pixels .... Pixels ... Pixels
........... _______     _______    ______
Method 1 .. 1470000 --> 1472480 .. +0.17% . bs1500
(+am1) .... 1470000 --> 1562560 .. +6.30% . bs32
........... 1470000 --> 1838740 ..+25.08% . b8

Method 2 .. 1470000 --> 1472481 .. +0.17% . bs1500
(+am2) .... 1470000 --> 1564017 .. +6.40% . bs32
........... 1470000 --> 1861864 ..+26.66% . bs8

Method 3 .. 1470000 --> 1470000 .. +0.00% . bs1500
(+am3) .... 1470000 --> 1470000 .. +0.00% . bs32
........... 1470000 --> 1470000 .. +0.00% . bs8

It's a partial - if not complete - answer to questions I've been 
carrying in my head for a long time. Likely, it's led me to a few 
certain incorrect / too-harsh impressions too. For example:

1) Why don't the method 1 and 2 pixels and rays make sense?

2) Why does there seem to be an asymmetric AA bias that I've noticed 
this mostly with method 1 - and blamed it's up and left only threshold 
test.

3) Why does (a completely working) method 3 sometimes run faster than it 
really should compared to method's 1 and 2.

...

---
For those who wish to play at home, you cannot exactly duplicate (or 
even see) all of the result I get with my yuqk fork. You should be able
to do the following while paying attention to the 'Rays:  <count> ' 
rendering output.

Use the following scene:

//---
version 3.8;
global_settings { max_trace_level 1 assumed_gamma 1.0 }
background { rgb 1 }
//---

Then commands like  (I think +a1.0 is illegal in v3.7 -> 0.99) :

p380b2 v38.pov -w1500 -h980 +am1 -a1.0 +r3 +wt1 +bs1500
p380b2 v38.pov -w1500 -h980 +am1 +a1.0 +r3 +wt1 +bs1500
p380b2 v38.pov -w1500 -h980 +am1 +a1.0 +r3 +wt1 +bs8

The silver lining here is that I think we have a decent available 
performance improvement available to us - if, we can figure out how to 
avoid the extra pixels on the thread render block edges (method two has 
an additional corner pixel too). My guess is this comes from an attempt
to re-use already rendered pixels before taking an adaptive step. If 
true, I think this the wrong approach with method 2, for a start, where 
we should just shoot the four corner rays as soon as someone turns on AA 
(Yep, another old question has been: why isn't method 2 better at 
picking up detail than it is..).

Aside: Mixed in, is work clipka did after v3.7 to center the pixel 
positions. IIRC, when AA kicked in they were offset in v3.7 (earlier?) 
by half the pixel size.

Going to be a bit before I dig more here. Real life is keeping me busy 
and this bit a detour from a bunch of other in progress plays with yuqk 
I need to finish. I've got far too many old play/work items going...

Bill P.

Post a reply to this message