To give you an update of what's happening regarding radiosity:


* Pretrace Modifications:

A good pretrace is a key to splotch-free radiosity renders. Any radiosity sample
taken during final render will invariably cause smeared-splotch artifacts,
that's a given fact that - to all my knowledge - cannot be avoided in any
sensible way.

I am currently working on improvements of the pretrace, in hope to get top
quality in less time with easier-to-use settings. The key ideas are quite
simple: (a) Keep pretracing until we are quite confident that the main render
will have enough samples to work with (we can never be 100% sure, unless we
actually do the main render twice, which is probably a no-go for shots with
strong anti-aliasing or focal blur). (b) Limit the extra effort to areas of the
picture that seem to need more samples.

MegaPOV's adaptive pretrace does something like this. However, I see problems in
the approach, mainly because MegaPOV's decision whether to continue sampling is
based exclusively on one (at most two) traces for any area. An additional
problem is that this approach doesn't seem to lend itself to the idea I'm
pursuing regarding 100% reproducibility of render results. For that I'll need
clearly defined pretrace passes, between which interim results can be exchanged
between the "cells" processed by the different tasks.

I'm currently going for this approach:

- Have a number of pretrace passes, increasing in resolution as specified by the
scene designer, like in 3.6 (except that pretrace will not be performed on a
line-by-line basis, but split into "cells" and processed by different render
tasks). (After each such pretrace pass, there would be time to exchange the
render cells' interim results.)

- Within each pass, repeat pretracing each "cell" over and over at the same
resolition (with some jitter to make sure we're hitting different points in the
scene) until we find that the percentage of new samples taken during one such
iteration has dropped below a certain threshold (or we find that we're not
making any progress).

- The threshold will be exposed to the scene designer, to allow for fast test
render settings and exhaustive top-quality renders alike.


* Sample Sequence Randomization:

Some ugly splotches seen in corners seem to be directly connected to the fixed
sample ray sequence. I intend to add some mechanism to introduce a random or
pseudorandom element here, which I expect to help a lot with these artifacts.
Options I intend to investigate include:

- random rotation of the sequence around the normal, as used in MegaPOV

- using varying sub-sequences, especially for small sample ray counts; this
should be easy to achieve by starting the sample sequence at a random offset
instead of 0 for each sample. Alternatively, moving the start by a constant
prime for each new sample would probably do just as well. This may slightly
degrade the sample sequence quality, but shouldn't really hurt overall, and in
fact I expect superior results.


* Minor bufixes and improvements:

There are still some small bugs and impurities in the radiosity code popping up
now and then. Among these are:

- Sample quality depended on the "weight" (regarding ADC bailout) of the ray
that caused a sample to be taken, not taking into account that the sample may
be re-used by a "heavier" ray; I'm changing this to use a standard weight for
all samples.

- There is a mechanism that prevents samples to be re-used in certain
"problematic" constellations (for those with background knowledge: I'm talking
about "in-front" samples here); basically this is good and necessary; however,
this is currently implemented as a "go/no-go" decision, instead of some gradual
reduction of the "weight" for "borderline" cases. As a result, this may
introduce hard lines in the radiosity gradient.

- Stats are back in. They're quite detailed though, and I'm not sure whether the
POV team will integrate them into a release.

- There is a hard-coded setting that specifies the maximum spacing of samples
with respect to the distance from the camera, just like the minimum_reuse value
specifies the minimum spacing. I intend to introduce a "maximum_reuse" parameter
to expose this setting to the scene designer.

- Some minor changes "under the hood" that shouldn't change a thing for the end
user.


* Open issues:

- Saving / Loading of sample data is still not back yet. There's also
questionable code to be removed that prevents saving of "deep recursion"
samples; 3.6 only saves the "top-level" samples, so deeper recursion samples
must be re-computed all over again in case the render needs more than the saved
"top-level" samples. This may have been done to speed up sample lookup, but that
gain in speed may be achieved in a different way. Saving and loading time may
have been a reason as well, but I think they don't justify such a restriction.

- Results still cannot be reproduced 100% on every run. As I expect this feature
to reduce performance (though at the same time it might improve quality a bit),
I'd like to add a radiosity settings switch (or maybe an ini options), so that
everyone can decide for himself whether to pay this price in order to be able
to exactly reproduce the shots.

- One difficult nut to crack: Re-usability weighting for samples in corners is a
problematic issue, and might be the reason for some type of "cross-talk" through
walls. There is a mechanism in place that reduces re-usability radius in the
direction of the closest wall - but if there are two walls almost equally far
away, things get problematic with this approach.

Post a reply to this message