Am 06.04.2019 um 21:09 schrieb Tamas Gunda:
> I created 3D cube images with Povray - spherical images assembled from 6 images,
> each of the images corresponding to one face of a cube. Without using radiosity
> there are no problems. However, if radiosity is turned on, the six images do not
> fit exactly, there are differences in brightness of the faces. The code is the
> exactly the same for all faces, only the camera is rotated by 90 degs. Seems
> that the result of rendering with radiosity turned on depends on the camera
This is to be expected to some degree.
What happens is that radiosty takes a couple of samples of indirect
lighting, and interpolates between those. The location of those samples
is determined pseudo-randomly, with a heavy influence from the camera
perspective (as well as other factors).
The interpolation between samples introduces subtle artifacts (very low
"frequency" and thus difficult to see under normal circumstances); the
camera-dependent pseudo-randomness causes the artifacts to differ
significantly between renders, even with only minor variations in camera
perspective or radiosity settings. This means that in a 1:1 comparison,
or when stitching images without soft blending between them, the
artifacts will become evident.
In official POV-Ray, the only way to solve this is to use either very
high-quality radiosity settings, or somehow introduce high-"frequency"
noise, so that enough samples are taken that the accuracy of the image
gets high enough for the seams to remain within the limits of human
perception or "drowns" in noise.
In UberPOV, you could choose radiosity settings such that instead of
interpolating between a limited number of samples it would compute
indirect lighting for each surface point separately. This changes the
type of artifacts to high-frequency noise, which will automatically hide
the seams, and arbitrary trade-offs between quality and render time can
easily be made via stochastic anti-aliasing. However, this also
increases render time significantly, especially so if you aim to reduce
the noise below the threshold of human perception. Another drawback is
that UberPOV only supports v3.7.0 syntax, not that of v3.8.0-alpha
currently in development.
Another alternative would be to use MCPov, but it is more difficult to
set up (you probably need to tamper with the scene itself, not just
global settings), has a systematic error in brightness computations that
needs working around, is limited to v3.6 syntax, and does not support
multi-core operation "out of the box". The approach would be more or
less the same as with UberPOV, but it may be able to achieve the same
quality with less CPU time.
Post a reply to this message