Alain <kua### [at] videotronca> wrote:

> > But I've run into a new snag: when I add soft shadows and depth of field, the
> > scene takes forever to render.  Based on the render time of the thumbnail, I
> > estimate that a full-sized render would take 46 hours on my system.  But I would
> > really like, at least, depth of field with the small scale of the subject
> > matter.
>
> Can't help for the depth of field, but, for the soft shadows, I can.
> You really need to use the adaptive option with as small a value as you
> can get away with. If you can use adaptive 0 without causing artefacts,
> do it. Hint : ALWAYS start with adaptive 0 for your area_light. Only use
> a larger value if you get artefacts such as illuminated spots into
> shadow or dark spots into illuminated areas.
> Even better, if you can somehow hide those, do it.
> Adaptive let you use very dense arrays for your area_light at a very
> small render time cost.
> area_light x,y, 257, 257 adaptive 0
> is almost as fast as
> area_light x,y 4 4 jitter
> for a much smoother result.

.... As you've already explained to me and others many times in the past.  I'm
using 5, 5 adaptive 0 jitter, which is plenty smooth for this scene.

> > Ordinarily, a 46 hour render would take a mere 46 hours, or a bit longer if I
> > 'nice' the render so the computer is usable for other tasks during that period.
> > But while my power source is a part time generator, I would have to attend the
> > computer during the entire render, and bring the system in and out of
> > hibernation as the generator is powered down and up, and as I leave the house
> > and return.  That would extend the *elapsed* time to a nerve-wracking 2 or 3
> > weeks--if the hibernation process doesn't fail, which it does frequently.  So
> > this release will have to wait until I'm plugged into the grid.
>
> Use the +c option to continue an interrupted render.
> If you use photons, be sure to save them to a file that you can reload
> when resuming your render.
> Add:
>     #if(file_exists ("myphotons.phot"))
>     load_file "myphotons.phot"
>     #else
>     save_file "myphotons.phot"
>     #end
> in your photons block.
> This allow you to bypass the photons shooting phase.
>
> You can do the same for radiosity data, but you need to use some command
> line options.

You misunderstand me.  I am refusing to put myself through such an ordeal.  I'm
going to wait until I can render it in one shot.

The demo file already has a radiosity save/load option (for 2-pass radiosity),
with .ini files included for the users' convenience, but the photons take less

not enough to bother saving, even if I were to restart an incomplete render
every day.

Does the -C option even work in 3.7?  I seem to recall problems with that even
after the 3.7.0 release, and I've avoided it like the plague ever since.  (On my
system, hibernation doesn't interrupt a render, although if the hibernation
process fails, I will be forced to shut down the computer, which obviously
*would* interrupt a render.)

> > In the meantime, I'm exploring reducing max_trace_level and dispersion_samples.
> > The latter looks promising; the former does not.
>
> You may also increase adc_bailout to something around 0.01 or maybe
> slightly more. Just don't overdo it.

I needed dispersion_samples 12 while I was testing the diamond, but with the
diamond as a smaller part of a complete scene, I can get away with the default

time to about 28 hours.

I haven't experimented with adc_bailout due to the rational for setting the
default value at 1/255.  I realized early on that with assumed_gamma 1.0
converted to a file gamma of 2.2 or sRGB, a value of 1/255 would exceed the
intervals between darker colors, so on that basis, even *that* value is too
large.  But rethinking this, it is better to consider visual effects rather than
byte values, so I will consider increasing adc_bailout.

Thanks for your input.

Post a reply to this message