William F Pokorny <ano### [at] anonymousorg> wrote:
> On 11/24/20 2:10 PM, Kenneth wrote:

> D) This uses TWO initial saved radiosity files, one made at the camera's
> start position and one made at the end (with different file names, of
> course!). Those files can be opened and inspected in POV-ray-- they are
> just text/data files of some kind-- then I simply copied-and-pasted the
> complete contents of the 2nd file onto the end of the 1st file, which is
> then re-saved. This 'composite' rad file is then used for the animation.

> Cool idea and demo! Not positive, but I think if you both loaded and
> saved the radiosity samples the "new" ones would get appended to the
> file by POV-Ray (no need to edit). If so, it should be you could run a
> sampling of the total frames where you let POV-Ray keep adding to the
> radiosity file...

Yes, you're right; I didn't think to try that easy trick until after I posted
here.  I had assumed that the two file-appending schemes *might* produce
different results, but they are the same.

Taking that idea to its logical conclusion, the following scheme is a
nicely-efficient way to generate the 'composite' saved radiosity file from
multiple camera viewpoints (for 'overlapping' rad data). Say you want a 50-frame
animation where the camera moves like
  <-3 + 6*clock,5,0>.
To create the composite rad file, the *initial* position would be  <-3,5,0>--
and the initial .INI file-saving settings need to be:
Radiosity_File_Name="RAD data" (or whatever name)
Radiosity_To_File=on
(animation turned OFF temporarily)

Then, to create the *full* saved composite file (the required interim process):
Radiosity_File_Name="RAD data"
Radiosity_To_File=on (to append more data to it)
Radiosity_From_File=on
Final_Frame=50
Subset_Start_Frame=2 (because frame 1 already has  its data saved)
Frame_Step=4 (or some other value-- because it is probably not necessary to save
rad data for *every* animation frame/camera position)

Then, to render the FINAL animation-with-radiosity:
Radiosity_File_Name="RAD data"
Radiosity_From_File=on
Final_Frame=50
.... along with the radiosity block's pretrace_start and pretrace_end both
changed to 1.0.

From experiments I've done, this works quite well-- with almost no flickering
rad-light patches.

Here's something interesting, though: For typical still-image renders, others
here have mentioned that a small-size (faster) initial radiosity render can be
made, while saving that data file for a *larger* render. This scheme works
reasonably OK for still images more or less, although there is a kind of 'lack
of radiosity detail' from the smaller render, and the saved file size is
correspondingly small as well, with fewer data entries. But this small-to-large
render scheme doesn't work well for creating a composite *animation* rad file--
there are still too many 'dancing light patches' in the final larger-size
animation. The only way the composite-saved-file idea works is to pre-render the
frames at their final intended pixel size, a slow process (while saving the
frame-to-frame data of course.)
>
> I've not been following the radiosity discussions closely, but there is
> since v3.7 a +HR or High_Reproducibility option. Have you tried this? As
> far as I know, it still works only with radiosity though its initial aim
> was broader.

So far, I have not gotten to that point in my experiments ;-) And I've been
running tests all week!
>
> IIRC, what it does is change the seed to the render block "number" so
> even with multiple threads (SMP) you get the same random numbers (and so
> radiosity ray samples - at least by ordering) in any given block. The
> render image size and render block size would need to stay constant too
> of course.

That's an interesting suggestion about render block size, that I had not thought
about; I need to experiment with that as well.
>
> Another option which obviously helps with reproducibility is running
> with one thread.
>

From initial experiments I've done on my lowly Windows 7 computer (with its 2
threads or cores or whatever), changing POV-Ray's Works_Threads setting in my
..INI file from 2 to 1 does not *seem* to affect the animation results re: the
look or placement of the radiosity light patches. I should probably do some more
tests though.

Post a reply to this message