William F Pokorny <ano### [at] anonymousorg> wrote:
> - Puzzling to me - some of the dark grid lines on the screen flicker in
> and out of existence during the render...? Unsure why this would happen
> unless perhaps using method 3 anti aliasing? If using method 3 remember
> you need to specify the seed used (can't recall the ini/command line
> option +ss maybe?) to keep results consistent render to render.
That would be Stochastic_Seed= -some number-, or +SSn. I was wondering about
those dark grid lines too; maybe a result of the animation's render size as
well? I would imagine that a larger render would keep the lines intact.
> - With respect to blotchiness frame to frame, remember, v3.7 introduced
> the radiosity high reproducibility option. Use High_Reproducibility /
> +HR on the command line or in the ini file. A more reliable alternative
> is to use single threads for each frame (+wt1)...
I tried this single-thread experiment in the past and still saw flickering
radiosity color patches during animation-- but that was probably because I
mistakenly used a moving camera.
But it does indeed completely eliminate the flicker! (Neither high-quality rad
settings nor the 'high reproducibility' switch can do that so well, according to
my own tests.) The only restriction is that the scene has to be completely
static (like m@b's here)-- no moving objects or camera. Even the moving
waveform on the oscilloscope could cause some tiny amount of flickering on
other objects, although it would probably be unnoticeable.
Some interesting facts when using this single-thread idea:
My machine has 8 cores/16 threads. Using just 1 thread, my own animation test
was only about 3 times slower-- not 16 times or even 8 times, which is what I
was expecting. That's good news!
But the statictics in the 'messages' pane are,
Radiosity Time: ... using 2 threads
Trace Time: ... using 1 thread"
Two threads for the radiosity?
This flickering effect of rad during animation would seem to come from one of
two sources: Either the SMP nature of multi-threading, or the random nature of
the light patches themselves from frame to frame (i.e., chosen from different
locations in the scene for each new frame.) Currently, there is no 'switch' to
lock-in those locations-- which would be kind of similar 'in concept' to the
newer antialiasing/jitter mechanism of AA Sampling_Method 3 and Stochastic_Seed,
which eliminates otherwise-random AA jitter during animation:
"(By default,) the corresponding pseudo-random number generators are seeded with
a value derived from the current date and time. If the Stochastic_Seed=n or +SSn
option is specified, the seed will instead be derived from the specified value,
allowing to produce exactly the same output each time by specifying that same
A similar concept for radiosity would be really helpful.
My guess is that running an *animation* with radiosity was never taken into
account when rad was first added to POV-ray...possibly because it took so long
to render even a single image then!
Post a reply to this message