Am 23.12.2015 um 08:00 schrieb Sven Littkowski:

> PS: not the shape of the round cupolas become boxish, but their textures
> on the edges. Even in this relatively plain test file code, if you look
> into their shadow areas, you will see this again.

Ah - now I guess I get your point. I've cropped a portion of the image
and increased the contrast to highlight what I /think/ you mean.

Those look like typical radiosity artifacts. What happens is this:

- What POV-Ray's radiosity algorithm tries to answer is the question how
much light any given point on given surface receives from other objects
(as opposed to dedicated light sources).

- Doing this for every point over and over again would require lots of
calculations; therefore, POV-Ray's radiosity algorithm takes advantage
of the fact that this indirect illumination typically changes only
gradually. Before the actual render, the algorithm therefore computes
the indirect illumination for "a few" chosen sample points on the
surface; that's the so-called "radiosity pretrace". In the actual
render, for each surface point the algorithm then just interpolates the
indirect illumination from any samples taken nearby.

- During the main render however, the algorithm will occasionally hit a
surface point for which it nas no nearby samples that would satisfy the
quality criteria defined in the scene's radiosity block. In that case,
the algorithm will take an additional sample during the main render.

- For pixels rendered earlier, this additional sample wasn't yet
available, so their radiosity interpolations were done without it.
Pixels rendered later, however, /will/ use the new sample in their
interpolation -- and may get a different result than if they didn't.

- If the new sample made a big difference, then where the regions of
"earlier" and "later" pixels meet there will be a noticeable border
between those two regions.

- Due to POV-Ray 3.7.0 using multiple threads, and each thread working
on different square regions of the image, such borders will be block-ish
in appearance, with the vertical borders always coinciding with the
32x32 pixel render job grid. In POV-Ray 3.6, which progressed line by
line through the image, the borders would instead always be horizontal.


There are three ways to get around the problem:

(A) Make POV-Ray compute more samples during the pretrace. Reduce
"pretrace_end" for this purpose.

(B) Make POV-Ray be more relaxed about the quality of samples during the
main render. Use "low_error_factor" for this purpose; a good traditional
value is 0.5. According to the docs this should be the default, but I'm
not sure right now whether it really is.

Both of the above reduce the ratio of samples gathered during the main
render vs. the samples gathered in total. In my experience, a ratio of
50% has always been enough to prevent artifacts. See the message pane
for post-render diagnostics of how well you did.

(C) Make sure any samples computed are as accurate as possible, in order
to reduce the chance that additional samples computed during the main
render will make too much of a difference. Increase "count" for this
purpose. Note however that there are situations where an increased count
doesn't help.

Post a reply to this message

Attachments:
Download 'untitled-3.png' (43 KB)

Preview of image 'untitled-3.png'