Am 10.01.2013 18:57, schrieb John:
> When I blur a sphere, it looks like HexGrid2Size is used regardless of
> camera.Blur_Samples (see tracepixel.cpp). That is, far enough out-of-focus I see
> only the first hexagonal pattern with a center defined by static const Vector2d
> HexGrid2[HexGrid2Size]. I would expect to see the 19 and 37 grids for
> blur_samples >= 19 and 37 respectively. With blur_samples 7, it looks correct,
> i.e. it's using HexGrid2Size. I don't think the huge-ish sphere distance makes
> any difference, i.e. you can see this with closer objects. I see this in
> 3.7.0RC6 Unofficial (Universal 64 bit) Dec 14 2012, but I think official 3.6
> Linux does it too. Here's a sample

The problem is that with the background being uniform, and your object 
very out-of-focus, POV-Ray's adaptive focal blur algorithm gets derailed.

Here's what happens for each pixel in general:

- POV-Ray does not always shoot the specified maximum number of sample 
rays. Instead, it shoots just an initial subset of them (7 in this case) 
to see how it fares, examining statistical properties of the sampled 
color values.

- If the samples vary significantly, POV-Ray shoots another batch of 
samples (6 in this case), then takes another look again at the 
statistical properties.

- If the statistical properties of the samples still indicate that more 
samples need to be taken, this process is repeated with more batches (of 
6, 4, 4, 4, 4 and 2 samples), until the resulting statistical properties 
indicate that enough samples have been taken.


And this is what happens in your special case:

- POV-Ray shoots the initial batch of 7 sample rays, which are spread 
apart so much that at most one (but typically none) of the rays can hit 
the sphere.

- If one ray does hit the sphere, POV-Ray will find a huge disagreement 
between this sample and the others, and will most likely shoot the 
specified maximum of 37 rays (and still be dissatisfied with the 
result). These are the regions where you see images of the sphere.

- However, if none of the initial 7 rays hit the sphere, POV-Ray will 
happily assume that the whole region shows only pitch black darkness, 
and decide to not waste any more computing time on this pixel. These are 
the regions where there /should/ be images of the sphere visible but aren't.


This is a problem that affects any scene with small, significantly 
out-of-focus structures among otherwise comparatively uniform areas.

Obviously this problem could easily be solved by forcing POV-Ray to take 
more samples initially, so that it has a fair chance of hitting the 
sphere in the first attempt. Unfortunately, POV-Ray 3.6 did not provide 
for such a mechanism.

This is where POV-Ray 3.7's two-parameter version of the blur_samples 
setting comes in:

     blur_samples MIN, MAX

where MIN specifies the minimum number of samples to take (actually 
POV-Ray may effectively use a slightly higher value), and MAX specifies 
the traditional parameter, the maximum number of samples (again POV-Ray 
may effectively use a slightly higher value).


Another approach would be to take into account neighboring pixels: If 
there's a huge difference between neighboring pixels, there's reason to 
examine both pixels more closely (and in the aftermath of this, yet more 
neighboring pixels may need to be re-examined as well.) But that's not 
available in POV-Ray yet. (I did some very promising experiments to use 
this as a generic anti-aliasing mechanism though, so it's very likely to 
find its way into some later 3.7.x release.)

Post a reply to this message