"nemesis" <nam### [at] gmailcom> wrote:
> It seems this feature, while a nice optimization trick, is what prevents one
> from reusing a full saved rad file to render a file from a different angle
> without taking any more samples and probably also the root cause of not being
> able to simply break an image into sections, render them separately and simply
> merge the final renders into a single image later.  Each instance do not know
> they should be taking samples from areas not seen in their particular view.
>
> Perhaps this optimization was powerful then, but not quite as fitting in an era
> of multicore processors and parallel processing.  Would it be possible to
> simply remove this view-dependent constraints and allow for full view
> independence in the current implementation?  How bad would performance drop?

If you have a scene containing a complete 10-storey house, and you only want to
render a single room - it'll kill.

It's an extreme example, but it shows that (a) your question cannot be answered
without knowing the scene, and how much of it is actually visible, and (b)
processing power has not increased so much to just go for plain brute force.

In fact, instead of spending the processing power to speed up *potential* later
renders of other parts of the scene, I'd rather see the added power invested in
(a) more detail, (b) higher quality and (c) faster results.

Actually, in an ideal world, the view-based approach of Ward's algorithm should
still prove superior to a pre-render of the whole scene, regardless of scene
size. It would be as follows:

- First image is pretraced, producing all necessary samples for the first shot
- First image is rendered, no additional samples are needed
- Second image is pretraced, re-using what the first pretrace produced, and
adding what is missing
- Second image is rendered, no additional samples are needed
- ...

The only problems here are...
(a) that the pretraces often do *not* produce all the necessary samples for some
reason;
(b) that the settings do not produce good enough quality; so the quality
increases from shot to shot (because for some parts they have more samples
available than they would actively collect themselves), but people think the
algorithm just produces randomly different results (partly because it is not
easy to asses which picture is actually more accurate);
(c) that the pretrace step may be done wrong, if a separate render is used; for
example, if you use micronormals, it is actually a bad idea to disable them for
the pretrace, because it causes the pretrace to collect less (and insufficient)
samples; likewise, reducing the recursion depth during pretrace may cause
additional samples to be required during the main render. Probably the only
quality setting that can safely be disabled is area light resolution (though
this could cause artifacts if additional samples are required during main
render for other reasons).

Post a reply to this message