POV-Ray : Newsgroups : povray.binaries.images : More byproducts of the radiosity discussions... : Re: More byproducts of the radiosity discussions... Server Time
15 Nov 2024 00:18:15 EST (-0500)
  Re: More byproducts of the radiosity discussions...  
From: clipka
Date: 31 Dec 2008 06:30:00
Message: <web.495b56416422692f483cfa400@news.povray.org>
Warp <war### [at] tagpovrayorg> wrote:
>   I think it also deserves to be considered being implemented as an
> internal feature of POV-Ray. In other words, something which could be
> turned on to make POV-Ray do this automatically, and without the need
> for the save files.

The idea of doing a final pretrace step that does exactly the same as the main
render definitely deserves attention.

However, this would theoretically have to include all the bells & whistles, like
anti-aliasing or focal blur, diffraction etc., as these *may* have an impact.


I was also pondering the idea of avoiding radiosity sampling during the final
render in some other way, but haven't come up with a conclusive idea yet. The
problem is always the same: Once you "slipped off" an existing sample into
no-man's land, you'd need to use *some* other color - but whichever you choose
will possibly be different from that last nearby existing one, and give a
(comparatively) sharp edge - an artifact.

Theoretically it would be possible to just keep using the nearest sample, but
this has drawbacks as well:

- Speed: The sample lookup algorithm is designed around the expected maximum
radius of influence of a particular sample. Searching for samples further away
than their expected radius of influence would be a hassle.

- Artifacts: When moving further away from a sample, there would be a moment
when the closest sample would switch to another one, potentially causing yet
another jump in color.

- Geometry: Some samples just don't fit, e.g. because they're on the other side
of a comparatively thin object.


POV already provides (theoretically) good tools for addressing this issue: The
reuse_count (together with always_sample off), forcing more samples to be
collected during pretrace than will be needed during final render, reducing the
risk of any spot being missed completely, and the low_error_factor, allowing
samples to be re-used at greater distance during final render.

There were a lot of design flaws in 3.6 acting against these mechanisms. Let's
see how things work when these flaws have been eliminated.


Post a reply to this message

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