The yuqk fork returned to truly random jitter where the default of 
jitter is off rather than the official V3.7 onward POV-Ray code where 
antialiasing (AA) methods 1 and 2 jitter is always on - and any 
randomness is predictive, but not purely gridded.

Further, it allows the jitter-ing to bounce outside the pixel - or bleed 
into adjacent pixels - where the jitter amounts are >1.0. This ability 
has thus far been called 'big jitter'.

I've now had some years playing with the 'improved jitter' in the yuqk 
fork and while the yuqk fork is certainly more flexible, the results are 
not always better depending upon the measure of goodness.

Using the Pursuit Curve code from Kurtz le pirate which was recently 
posted on the POV-Ray forums, I've made an attempt to better formalize 
some rough AA rules for using random/big jitter. See those rules below.

I've added to my yuqk fork to do list some ability to specify a minimum 
recursive AA depth in addition to the maximum one. Thinking the options 
and flag would be Antialias_Min_Depth=n and +RMn, respectively.

The 'lines' in the attached image have been fattened with a big jitter 
rather than by increasing the radius of the cylinders. I believe this 
will lead to better looking thumbnails for images of this type - FWIW.

Bill P.

==============================

October 31, 2023

1)
--

Shooting more rays and scaling smaller almost always leads to better 
looking images. This can be accomplished by rendering much larger images 
and scaling them down, or one can force more rays to be shot with AA, by 
setting the threshold to 0.0.

2)
--

Though random / big jitter only applies to AA methods 1 and 2, All three 
AA methods in v3.8 and beyond lack a means to force a minimum 'depth' or 
number of rays be shot - prior to invoking adaptive AA. This is a 
serious shortcoming where resolving detail is the measure of goodness. 
In modes 1 & 2 you can set the AA threshold to 0.0, but then the 
recursion depth is all that limits the number of rays shot.


3)
--

If trying to 'see' fine detail, where using, say, '+a0.01 +am2 +r3' it 
is the case that dropping back one recursive depth with zero threshold, 
'+a0.0 +am2 +r2', is often a win in both performance and result. This AA 
depth fall back with a zero threshold, typically, works sooner in 
resolving detail (at less depth), with random / big jitter.

4)
--

Using yuqk's random / big jitter will frequently see fine detail at 
lower AA recursion depths - if the AA threshold is 0.0 (if a minimum 
number of rays beyond the initial 'sample corners' is shot). However, at 
low recursive depths the overall result is noisier due some of those 
rays also more often missing the detail. In other words, at lower 
recursive depths (minimum number of rays shot) the intensity of the fine 
detail will more universally fluctuate.

5)
--

Where the number of rays is higher the random / big jitter leads to 
better images faster than just rendering large with AA modes not having 
random / big jitter. As the number of rays shot grows still more, having 
a random / big jitter capability matters less and less. Aside: There is 
a slight dimming of detail as the number of rays grows for mostly the 
same reason the fluctuation in intensity shows up in (4).

6)
--

There are recommended maximum big jitter amounts for methods 1 and 2 
depending on recursion depth. Using a big jitter value (jitter > 1.0), 
but smaller than this recommended maximum, somewhat often, leads to a 
better result with respect to resolving detail and the smoothness of the 
resultant detail.

7)
--

There are a non-trivial number of reasons AA might quit earlier than 
we'd like due used features having their own adaptive mechanisms.

8)
--

Big jitter allows for additional effects beyond more traditional AA.

9)
--

Depending on the particular scene, alignment of pixels with detail - and 
desired results - the rules above will apply more, or less well. YMMV.

Post a reply to this message

Attachments:
Download 'courbesdepoursuite_c.jpg' (281 KB)

Preview of image 'courbesdepoursuite_c.jpg'

On 11/1/23 06:07, William F Pokorny wrote:
> The 'lines' in the attached image have been fattened with a big jitter 
> rather than by increasing the radius of the cylinders. I believe this 
> will lead to better looking thumbnails for images of this type - FWIW.

:-) Well, my thinking there was certainly not as right as I'd hoped with 
respect to the POV-Ray web site's thumbnail mechanism!

Bill P.

Post a reply to this message

On 11/1/23 06:07, William F Pokorny wrote:
> I've added to my yuqk fork to do list some ability to specify a minimum 
> recursive AA depth in addition to the maximum one. Thinking the options 
> and flag would be Antialias_Min_Depth=n and +RMn, respectively.

Added Antialias_Min_Depth=n ini / +RMn flag option for antialias methods 
2 and 3(a). It can be thought of as a way to implement initial 
non-adaptive AA sampling - better at resolving detail - prior to 
adaptive AA. Will be available in R11 v0.6.5.0.

The attached image shows method 2 in the left column and method 3 in the 
right column. The top row is what we get today without the ability to 
initially force a minimum number of samples. The bottom row uses a 
Antialias_Min_Depth of two and the results are substantially better for 
both methods 2 and 3.

Method 2
--------
yuqk hmmAA.pov +w400 +h400 +am2 +a0.035      +r6 +j3.33
yuqk hmmAA.pov +w400 +h400 +am2 +a0.035 +rm2 +r6 +j3.33

Method 3
--------
yuqk hmmAA.pov +w400 +h400 +am3 +a0.035 +ac0.9      +r6 +ss12345
yuqk hmmAA.pov +w400 +h400 +am3 +a0.035 +ac0.9 +rm2 +r6 +ss12345


Credit Ton for the test scene from an issue report some years ago.

Aside: Method 1 is not adaptive so there is no point in specifying a 
minimum Antialias depth. The depth value is the number of steps in x and y.

(a) - Reminder the yuqk fork has method 3 fixes which are not in any 
official POV-Ray release. Fixes which in part prevent the implementation 
from sometimes running in a non-adaptive manner; Where results look 
good, but at the expense of the maximum number of samples specified by 
+r being taken.

Post a reply to this message

Attachments:
Download 'antialias_min_depth.png' (129 KB)

Preview of image 'antialias_min_depth.png'

William F Pokorny <ano### [at] anonymousorg> wrote:

Nice results :)

This reminded me of something I stumbled upon, and maybe it will help you come
up with some more sophisticated methods.

https://bgolus.medium.com/the-best-darn-grid-shader-yet-727f9278b9d8

http://iquilezles.org/articles/filtering/
https://iquilezles.org/articles/filterableprocedurals/
https://iquilezles.org/articles/checkerfiltering/


- BW

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> Added Antialias_Min_Depth=n ini / +RMn flag option for antialias methods
> 2 and 3(a). It can be thought of as a way to implement initial
> non-adaptive AA sampling - better at resolving detail - prior to
> adaptive AA. Will be available in R11 v0.6.5.0.

This sounds like a great feature for official POV!

> Aside: Method 1 is not adaptive so there is no point in specifying a
> minimum Antialias depth. The depth value is the number of steps in x and y.

Method 1 is adaptive in a minimal way:  If a pixel is not determined to require
anti-aliasing, it is not sub-sampled at all.  That is, unless this was changed
in POV-Ray 3.7, and the reference manual had not been updated to reflect the
change.  I did notice that 3.7 does a better job of method 1 anti-aliasing than
3.6 did, but it still doesn't appear to sub-sample every pixel.

Perhaps +AM1 +RMn can specify the sub-sampling depth for any pixel that is not
selected for anti-aliasing under the old algorithm.

Post a reply to this message

On 1/11/24 11:08, Bald Eagle wrote:
> Nice results 🙂
> 
> This reminded me of something I stumbled upon, and maybe it will help you come
> up with some more sophisticated methods.

Thanks - and thanks for the links. :-)

Bill P.

Post a reply to this message

On 1/11/24 15:48, Cousin Ricky wrote:
> Method 1 is adaptive in a minimal way:  If a pixel is not determined to require
> anti-aliasing, it is not sub-sampled at all.  That is, unless this was changed
> in POV-Ray 3.7, and the reference manual had not been updated to reflect the
> change.  I did notice that 3.7 does a better job of method 1 anti-aliasing than
> 3.6 did, but it still doesn't appear to sub-sample every pixel.
> 
> Perhaps +AM1 +RMn can specify the sub-sampling depth for any pixel that is not
> selected for anti-aliasing under the old algorithm.

Hmm... Yeah. I guess up front I was thinking if folks wanted to force 
the sub-sampling with method 1 they could specify a threshold of 0. I'll 
ponder & perhaps play with your idea in code.

I confess to seldom using method 1 due the left / top directional bias.

Bill P.

Post a reply to this message

On 1/11/24 17:22, William F Pokorny wrote:
> I'll ponder & perhaps play with your idea in code.

Well, I'm surprised. Your idea works well for somewhat complicated 
reasons(a) over just setting the threshold to 0.0 in method 1 - where we 
need to force more samples(b). Thanks for the prompt!

(a) - My guess is we might be a little more exposed to left top 
directional artifacts on using min depth.

(b) - In scenes where we were almost always sub-sampling already the use 
of +rm is slightly slower because we sometimes force sampling where the 
threshold alone wouldn't have / didn't need to.

Attached more or less equivalent images (less random jitter) both using 
method 1. Th difference image shown on the right. The left column image 
is using:

yuqkB hmmAA.pov +w400 +h400 +d +p +am1 +a0.035 +rm4 +r6 +j1.33

and the samples / pixel come in at: 19.05

The middle column image is using:

yuqkB hmmAA.pov +w400 +h400 +d +p +am1 +a0.0 +r6 +j1.33

and the samples / pixel come in at: 33.80

I'm a little tired to finish off the commit and documentation tonight. I 
plan to tackle it tomorrow - extending the AA min depth option to method 
1 as well.

Bill P.

Post a reply to this message

Attachments:
Download 'meth1_rm4_r6.jpg' (77 KB)

Preview of image 'meth1_rm4_r6.jpg'