"Kenneth" <kdw### [at] gmailcom> wrote:
> 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.

Interesting tests, If I remember correctly, Mental ray used to have a way to do
this as well... or maybe it was just for geometry export, but some kind of
incremental feature for animation.


Anyway, to my rather profane user ears your idea sounds sane to keep initial
radiosity data and only compute necessary additions for each new frame. So
you're saying that this radiosity data file is human readable. If each sample is
clearly identifiable, and can be split on a per line basis then it's worth
trying some kind of script (even maybe a notepad++ macro if it could recognize
and operate on numbers?) to do the following:

-copy the first ("rad1") and second ("rad2") frame's radiosity data files
calling these copies say "radtemp1" "radtemp2"

-pick a (low) precision threshold (a small enough number of digits after the
decimal points)to truncate all numbers of "radtemp1" and "radtemp2" to this
precision, so that you can...

-...iterate while keeping counted index, through each line of truncated
"radtemp1", find any line that now has the same patch coordinates in "radtemp2"
store its index in a list.

-suppress all lines corresponding to these indices in the original "rad2"

-And finally merge "rad2" at the end of rad1" to get your incremented but more
optimized rad2

However I would not be surprised if POV was already supposed to do all that kind
of stuff or even better optimization internally?

Post a reply to this message