Radiosity in animation suffers from a kind of jitter or flicker problem, even
with high-quality settings... a result of the random nature of the rad 'light
patches' from frame to frame. Using a SAVED radiosity file, from an initial
camera viewpoint, would seem to solve that issue, but it's only partially
successful: As the camera moves-- and the scene's objects move as well-- the
saved radiosity file is no longer adequate to produce an expected smooth effect.

I came up with an interesting solution to part of this problem, at least for
POV-ray v3.8xx and maybe 3.7 too, which is more easily explained in an animation
test.

In my test scene, there are no actual light sources; the lighting is from pure
radiosity, from a skydome that has a cloudy-sky photo. I purposely chose BAD
radiosity quality settings to make the effect of the radiosity light patches
more obvious.

settings...
radiosity{
brightness 1.0
count 1
recursion_limit 1
error_bound 0.9
minimum_reuse .0009
maximum_reuse .0117
pretrace_start .08
pretrace_end .01
always_sample off
(all the others at their defaults)
}

The camera just moves from left to right...
location <0 + 5*clock,5,0>

Referring to the animation...
A) This is what typical radiosity light patches do in an animation, from frame
to frame-- completely random patch placement. Of course, this raw look would be
much less obvious with higher-quality rad settings, but it would still be there,
as a sort of minor noisy flicker in the animation.

B) This uses a saved radiosity file, made from a still image at the camera's
starting position. The animated scene's rad settings as kept as they are. As the
camera moves, there are a few extra rad samples created for the objects-- but
the initial 'unseen' parts of the scene require NEW patches, to fill in the
apparenty blank radiosity areas. They are like 'shadow areas' behind objects, as
seen from the initial camera position.

C) This is the same set-up as B, using the same saved rad file, but I changed
radiosity's pretrace_start and pretrace_end to 1.0 in the scene. This prevents
any 'new' rad samples from being created for most of the objects. It's an
improvement, but the 'rad shadows' are still being filled in with new patches.

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. In effect, the two different files, from
two vantage points, have overlapped and filled in the missing radiosity areas
seen in C). Again, pretrace_start and pretrace_end are both changed to 1.0 for
this final animation. There are still a few small areas that are not filled in
by this trick; they could be left as is-- or a *3rd* camera viewpoint could be
chosen to make a 3rd initial saved file...maybe from a vantage point above the
scene. The end result is smooth radiosity lighting during at least most of the
animation.

The only difficulty I see is when lots of objects move in the scene; perhaps
creating even more initial rad files could improve on that somewhat. But the
only way I can see to create a 'perfect' final rad file in such a case would be
to save a new file for every animation frame, then combine them *all* into one
final file! Not very efficient, of course; and the file would be HUGE.

For the entire time that I've been working with POV-ray, I assumed that a saved
radiosity file was a 'global' light map-- that is, creating a full 3-D map of
all areas of the scene, whether seen by the camera or not. That's not the case--
and I see now that such a map would usually be grossly inefficient and a waste
of RAM, for typical still-image renders which have only one camera viewpoint.
There is usually no need for light patches to 'fill in' the unseen parts of a
scene, such as behind opague objects...but animations could make use of such a
concept, if it was possible.

Here's a thought which I haven't tried yet: For a single saved rad file, I could
make all of the objects in the scene temporarily semi-transparent, so that at
least *some* light patches would be created everywhere in the scene. But at this
stage of my experimenting, I don't yet know how radiosity deals with
semi-transpartent objects.

Post a reply to this message

Attachments:
Download 'radiosity_in_animation_a_11_2020.mp4.mpg' (3382 KB)

On 11/24/20 2:10 PM, Kenneth wrote:
> Radiosity in animation suffers from a kind of jitter or flicker problem, even
> with high-quality settings... a result of the random nature of the rad 'light
> patches' from frame to frame. Using a SAVED radiosity file, from an initial
> camera viewpoint, would seem to solve that issue, but it's only partially
> successful: As the camera moves-- and the scene's objects move as well-- the
> saved radiosity file is no longer adequate to produce an expected smooth effect.
> 
> I came up with an interesting solution to part of this problem, at least for
> POV-ray v3.8xx and maybe 3.7 too, which is more easily explained in an animation
> test.
> 
...
> 
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. This would be an initial pass for the purposes of 
creating the "all-frames" sample file used then for the all frames 
renders. Your file size concerns, still a worry, but...

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.

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.

Another option which obviously helps with reproducibility is running 
with one thread.

Bill P.

Post a reply to this message

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

"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

"Mr" <nomail@nomail> wrote:

>
> ...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:
>
> ...find any line that now has the same patch coordinates in "radtemp2"
> store its index in a list.
>
> ...And finally merge "rad2" at the end of rad1" to get your incremented but more
> optimized rad2
>

It would indeed be useful to optimize the final saved data file, if possible; my
animation test for *today*, with a moving camera, has a saved 'composite'
radiosity file with 47000+ lines of data! Here's a sample of what it looks like,
opened in POV-ray...

C1 6.40944 0 10.2727 7ffe7f 0.5393 0.5634 0.6627 0.0673439 2.02194 13b2aa
C1 5.07783 0 9.9777 7ffe7f 0.2932 0.2820 0.3779 0.0626854 19990.9 94c3e8
C2 4.67263 2.28262 10.8619 fd7f6d 0.2772 0.0367 0.0002 0.123517 2.80274 c81887
C1 5.22191 0 9.92912 7ffe7f 0.3809 0.2062 0.1807 0.0629131 2.52627 63f2ae
C1 5.40516 0 9.95757 7ffe7f 0.5724 0.6442 0.7586 0.0635047 19991.6 90cde2
C1 5.59453 0 9.99461 7ffe7f 0.4496 0.4617 0.5039 0.0641466 1.52217 33bfce

......etc. etc. Each line starts with C1 or C2. (And there's no obvious 'order'
to
the entries.) I have no idea what the data actually means.

Unfortunately, not a single line of that data seems to repeat; I tried hard to
find at least one repetition, with no luck. So my guess is that, as the *camera*
moves during the animation, totally-new 'coordinates' (or whatever) are
generated, with somewhat overlapping 'rad light patches'. I haven't yet tried a
test where the camera is static; maybe there *would* be duplicate entries that
could be eliminated.

BTW: From what I can tell so far, this 'additive' rad-data scheme (for the final
saved file) adds new light patches that sometimes overlap previous ones,
sometimes not. In effect, it seems to be adding to radiosity's COUNT value. So
it might be possible to 'relax' that value-- like, changing COUNT 200 to some
lower value-- to still get the original expected visual result. I haven't yet
tested the idea though.

Post a reply to this message

On 12/4/20 9:06 AM, Kenneth wrote:
> "Mr" <nomail@nomail> wrote:
> 
...
> 
> C1 6.40944 0 10.2727 7ffe7f 0.5393 0.5634 0.6627 0.0673439 2.02194 13b2aa
> C1 5.07783 0 9.9777 7ffe7f 0.2932 0.2820 0.3779 0.0626854 19990.9 94c3e8
> C2 4.67263 2.28262 10.8619 fd7f6d 0.2772 0.0367 0.0002 0.123517 2.80274 c81887
> C1 5.22191 0 9.92912 7ffe7f 0.3809 0.2062 0.1807 0.0629131 2.52627 63f2ae
> C1 5.40516 0 9.95757 7ffe7f 0.5724 0.6442 0.7586 0.0635047 19991.6 90cde2
> C1 5.59453 0 9.99461 7ffe7f 0.4496 0.4617 0.5039 0.0641466 1.52217 33bfce
> 
> ......etc. etc. Each line starts with C1 or C2. (And there's no obvious 'order'
> to
> the entries.) I have no idea what the data actually means.
> 

I dug up the source code not too long ago and made these notes:

---
C seems to stand for color. (There are other unused classifications)
The number after the D is depth. I've only ever seen 1 or 2 - maybe if
recursion depth increased?

The next three float values are the location.

The text string in position 5 is the normal encoded for +-(2 byte 
value/254) it looked.

Positions 6,7 and 8 are the three color channel values at the point.

In field 9 we have the harmonic mean. The inverse of the mean of the 
inverses of distances to all samples used to set a point's "radiosity 
view." This read as a double (long float) but later used in calculations 
as a float.

In field 10 the nearest sample distance found is recorded.

Field 11, like the normal field, is a string representing 3 x,y,z values 
pointing, roughly in the direction where the nearest distance sample was 
taken.

---
The floats are all read/scanned as doubles, but the file representation 
seems to be float. The internal usage in calculations is sometimes 
(always?) cast to float. Expect this means not too much difference 
between binary file encoding (as doubles) and current text encoding. 
However, if internally stored as all doubles and all only used as floats 
- the internal representation could probably be better?

FWIW.

... Yeah, hacking the radiosity file for effects is not something I 
recall anyone doing. It could be interesting. Color shifts. By global 
locations increase or decrease intensities. Insertion of samples by 
interpolation from existing ones? Completely contrived radiosity files
with gradients or whatever...

Aside: I suspect, there are some similarities to the saved photons file, 
but I've not gotten to even a first look at it...

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/4/20 9:06 AM, Kenneth wrote:
> > "Mr" <nomail@nomail> wrote:
> >
> ...
> >
> > C1 6.40944 0 10.2727 7ffe7f 0.5393 0.5634 0.6627 0.0673439 2.02194 13b2aa
> > C1 5.07783 0 9.9777 7ffe7f 0.2932 0.2820 0.3779 0.0626854 19990.9 94c3e8
> > C2 4.67263 2.28262 10.8619 fd7f6d 0.2772 0.0367 0.0002 0.123517 2.80274 c81887
> > C1 5.22191 0 9.92912 7ffe7f 0.3809 0.2062 0.1807 0.0629131 2.52627 63f2ae
> > C1 5.40516 0 9.95757 7ffe7f 0.5724 0.6442 0.7586 0.0635047 19991.6 90cde2
> > C1 5.59453 0 9.99461 7ffe7f 0.4496 0.4617 0.5039 0.0641466 1.52217 33bfce
> >
> > ......etc. etc. Each line starts with C1 or C2. (And there's no obvious 'order'
> > to
> > the entries.) I have no idea what the data actually means.
> >
>
> I dug up the source code not too long ago and made these notes:
>
> ---
> C seems to stand for color. (There are other unused classifications)
> The number after the D is depth. I've only ever seen 1 or 2 - maybe if
> recursion depth increased?
>
> The next three float values are the location.
>
> The text string in position 5 is the normal encoded for +-(2 byte
> value/254) it looked.
>
> Positions 6,7 and 8 are the three color channel values at the point.
>
> In field 9 we have the harmonic mean. The inverse of the mean of the
> inverses of distances to all samples used to set a point's "radiosity
> view." This read as a double (long float) but later used in calculations
> as a float.
>
> In field 10 the nearest sample distance found is recorded.
>
> Field 11, like the normal field, is a string representing 3 x,y,z values
> pointing, roughly in the direction where the nearest distance sample was
> taken.
>
> ---
> The floats are all read/scanned as doubles, but the file representation
> seems to be float. The internal usage in calculations is sometimes
> (always?) cast to float. Expect this means not too much difference
> between binary file encoding (as doubles) and current text encoding.
> However, if internally stored as all doubles and all only used as floats
> - the internal representation could probably be better?
>
> FWIW.
>
> ... Yeah, hacking the radiosity file for effects is not something I
> recall anyone doing. It could be interesting. Color shifts. By global
> locations increase or decrease intensities. Insertion of samples by
> interpolation from existing ones? Completely contrived radiosity files
> with gradients or whatever...
>
> Aside: I suspect, there are some similarities to the saved photons file,
> but I've not gotten to even a first look at it...
>
> Bill P.

Why not, ! Radiosity filters ! with that some inbuilt effect could be done like
the recent tests done for paint effect by Kenneth with his circular lights...
Back on initial topic, This is axactly the kind of data I hoped: So yes, the
radiosity algorithm is supposed to do unique samples to avoid wasting
computation, that is precisely why I mentioned to truncate the precision : so
that the samples closest would thus falsely appear as duplicates but the lines
suppressed in the initial data would rather be considered merged by that
(truncation) threshold criteria. Does that naive approach make sense to someone
more experienced than me, or am I missing something?

Post a reply to this message

"Kenneth" <kdw### [at] gmailcom> wrote:
>
> It would indeed be useful to optimize the final saved data file, if possible...
>
> Unfortunately, not a single line of [the saved data] data seems to repeat;
> I tried hard to find at least one repetition, with no luck...
> I haven't yet tried a test where the camera is static; maybe there *would*
> be duplicate entries that could be eliminated.
>

In all my animation/radiosity tests so far, I've used a moving CAMERA (and no
moving scene objects) to create the composite rad-data file. That seemed a
logical way to proceed; but I just did a 'static' camera test-- which produced
some interesting results:

Saving/appending 3 identical radiosity renders, with identical rad settings,
seems to be enough to prevent any 'new' rad light patches from being created
when running the final animation (assuming pretrace_start and pretrace_end are
changed to 1.0 for the final run; and assuming that the camera remains static.)
I would call it a '3-pass' technique. There are still a *few* stray patches
created, but they are very hard to spot. Of course, this doesn't take into
account any moving OBJECTS in the scene; I haven't gotten that far yet ;-)

As for the data file itself and its possible duplicated entries: I decided to
render and save a *tiny* radiosity file-- 4X3 pixels(!)-- made with a static
camera, and using the 3-pass trick. The final saved file is a 'composite' of the
3 renders and their data. The first 'pass' produced 108 saved data lines; the
2nd added only 9 lines; the third, 9 more. Then I tried to find duplicated data
lines among the total, but again no luck. So it *seems* that POV-ray
automatically removes any redundant data from an appended radiosity file.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> I dug up the source code not too long ago and made these notes:

Fascinating! Thanks for taking the time to do this, and for posting your info.
>
> ---
> C seems to stand for color. (There are other unused classifications)
> The number after the D is depth. I've only ever seen 1 or 2 - maybe if
> recursion depth increased?

Yes, you're right, it's recursion_limit. (In my tests so far, I had set it to
2.) I ran another test with somewhat high-quailty settings (to produce a LARGE
saved rad file), and cranked resursion_limit up to 20. Now I see data lines
starting with C3,C4 etc. Interestingly, they 'top out' at about C8-- with fewer
entries too-- which agrees with the documentation about higher recursion_limit
settings having less and less of a visual effect on the render.
>
> The next three float values are the location...
> ...
>
> In field 10 the nearest sample distance found is recorded.
>
> Field 11, like the normal field, is a string representing 3 x,y,z values
> pointing, roughly in the direction where the nearest distance sample was
> taken.

From my animation tests with a moving camera, I assume that the x,y,z
values/direction vectors have something to do with CAMERA's viewpoint as well
(whatever it happens to be.) That is, if I understand your description
correctly.
>
>
> Aside: I suspect, there are some similarities to the saved photons file,
> but I've not gotten to even a first look at it...
>

IMO, there does seem to be a similarity:

I did an odd radiosity test, using a sky dome photo for the rad emitter, a gray
ground plane, and a perfectly-relective sphere for a scene object...
    (ambient 0 emission 0 diffuse 0 reflection 1.0)
... except that I cranked up its reflection to 8.0-- just an arbitrarily HIGH
value. I also added a normal to it. The result is that the sphere actually
reflects the incoming radiosity light.. and produces crude 'radiosity caustics'
on the plane, no photons required! I didn't realize that radiosity light could
be reflected, without using photons in some way. It seems that the two methods
do operate in a somewhat similar(?) way.

Post a reply to this message

On 12/4/20 11:43 AM, Mr wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
... the
> radiosity algorithm is supposed to do unique samples to avoid wasting
> computation, that is precisely why I mentioned to truncate the precision : so
> that the samples closest would thus falsely appear as duplicates but the lines
> suppressed in the initial data would rather be considered merged by that
> (truncation) threshold criteria. Does that naive approach make sense to someone
> more experienced than me, or am I missing something?
> 
Expect quite a few things in play. There is some initial sampling 
density relative the the scene depending on numerous things for any 
given frame. If we change one or more of the dependencies enough, 
additional samples will be shot. Of those "perhaps" some will be added 
to the saved file.

In the moving camera case I think it likely new, duplicate or very 
nearby lines (samples) don't get added after a point because the some 
criteria (error, distance, ?) kicks in on seeing local context for the 
existing samples - and any in hand, "duplicate," potential sample is 
tossed in the bit bucket - but, I'm guessing.

---
I wonder if anyone has tried creating a radiosity file at a resolution 
larger than the final frame/scene?

I'm not aware of a way to force a stop immediately after photon / 
radiosity sample file creation. Is there one?

It would be handy to avoid the cost of the final pass render, saving of 
other intermediate and output files when just creating the larger 
radiosity file for the actual final frame/scene renders.

Bill P.

Post a reply to this message

On 12/4/20 11:46 AM, Kenneth wrote:
> "Kenneth" <kdw### [at] gmailcom> wrote:
...
> 2nd added only 9 lines; the third, 9 more. Then I tried to find duplicated data
> lines among the total, but again no luck. So it *seems* that POV-ray
> automatically removes any redundant data from an appended radiosity file.
> 
See my response to Mr as to why redundant (or near redundant) samples 
might not be getting added to the file.

Bill P>

Post a reply to this message

On 12/4/20 12:49 PM, Kenneth wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:
...
>> ---
>> C seems to stand for color. (There are other unused classifications)
>> The number after the D is depth. I've only ever seen 1 or 2 - maybe if
>> recursion depth increased?
> 
> Yes, you're right, it's recursion_limit. (In my tests so far, I had set it to
> 2.) I ran another test with somewhat high-quailty settings (to produce a LARGE
> saved rad file), and cranked resursion_limit up to 20. Now I see data lines
> starting with C3,C4 etc. Interestingly, they 'top out' at about C8-- with fewer
> entries too-- which agrees with the documentation about higher recursion_limit
> settings having less and less of a visual effect on the render.

Thanks. Good to know.

>>
>> The next three float values are the location...
>> ...
...
> 
>  From my animation tests with a moving camera, I assume that the x,y,z
> values/direction vectors have something to do with CAMERA's viewpoint as well
> (whatever it happens to be.) That is, if I understand your description
> correctly.

I think only to the extent the camera rays set where the code will look 
to take samples. Nearly positive, the stored sample coordinates are 
locations in global scene space. Most, excepting media ones, on 
surfaces. Normals, distance and direction information would all be 
relative to the surface(1).

(1) - Wonder what happens with normals in media...

> 
> IMO, there does seem to be a similarity:
> 
(Interesting experiment - ie reflection 8)

On similarity between photons and radiosity, I was speaking mostly about 
saved file formats.

Photons and radiosity start in fundamentally different ways. Photons 
shoot rays (forward) from light sources into the scene to create photon 
samples. Radiosity traces backward in the more traditional ray tracing 
way and it might find light sources or not depending on the ray tracing 
bend/bounce depth.

Both types of samples are gathered and merged in with the usual ray 
tracing results for each ray to give a final result.

(One more thought. If there is no way to stop after the radiosity file 
is updated, we should be sure options like AA are off to save that time 
- if you are not already doing this.)

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
>
> C seems to stand for color. (There are other unused classifications)
> The number after the D is depth [recursion_limit]...
>
> The next three float values are the location.
> ...
> Field 11, like the normal field, is a string representing 3 x,y,z values
> pointing, roughly in the direction where the nearest distance sample was
> taken.

Do you happend to know how those string representations can be 'decoded'? They
are written as
  7ffe7   ,  11ba94 , etc.

Is it hexadecimal, perhaps? (Sorry, I'm no longer familiar with hex, from my
university days long ago; I'm way out of practice with it.)

>
> I'm not aware of a way to force a stop immediately after...
> radiosity sample file creation. Is there one?

I have not yet found a way either; it seems that *some* new radiosity samples
are always created when using a saved radiosity file, regardless of
always_sample on/off or pretrace_start/pretrace_end being changed to 1.0.
(Changing any of radiosity's other settings has unintended and unexpected
results, from my tests *so far*.)

About 'hacking' the saved radiosity file:
It's an interesting idea, but will probably not work as intended. Here's an
example of why:
1) I rendered a typical still-image radiosity scene, while saving the rad data
to a file.
2) I re-rendered the scene using the saved data, with always_sample off and
pretrace_start/end changed to 1.0. At this point, I cannot tell how many 'new'
radiosity light patches have been created (without doing a 'difference'
comparison in Photoshop); probably more than what is in the saved file.
3) I then opened the file in POV-ray and *erased* 90+ percent of the data lines
there(!), then re-saved the file.
4) I re-rendered the scene again with the 'new' file-- and there are just as
many radiosity light patches as before, except that most are now
randomly-placed.

I had *assumed* that this new file would greatly reduce the number of light
patches, but that's not the case.

Apparently,POV-ray is always trying to add new light patches when there are 'not
enough' (?), or something like that. So, editing/hacking the file may not
produce the intended results.

Post a reply to this message

Le 2020-12-04 à 12:49, Kenneth a écrit :

> I did an odd radiosity test, using a sky dome photo for the rad emitter, a gray
> ground plane, and a perfectly-relective sphere for a scene object...
>      (ambient 0 emission 0 diffuse 0 reflection 1.0)
> ... except that I cranked up its reflection to 8.0-- just an arbitrarily HIGH
> value. I also added a normal to it. The result is that the sphere actually
> reflects the incoming radiosity light.. and produces crude 'radiosity caustics'
> on the plane, no photons required! I didn't realize that radiosity light could
> be reflected, without using photons in some way. It seems that the two methods
> do operate in a somewhat similar(?) way.
> 
> 
> 

The same also happen with transparent objects. A lens can project an 
image of what is in front of it on a surface behind it.

I first experience it with the woodbox scene modified to use radiosity 
and adding a light probe.

Post a reply to this message

Alain Martel <kua### [at] videotronca> wrote:
> Le 2020-12-04 à 12:49, Kenneth a écrit :
>
> > ...The result is that the sphere actually
> > reflects the incoming radiosity light.. and produces crude 'radiosity
> > caustics' on the plane, no photons required!
>
> The same also happen with transparent objects. A lens can project an
> image of what is in front of it on a surface behind it.
>

I suspected that the radisoity light patches might do that as well, although I
haven't tried it yet. And I guess that using HDR lighting would show a *much*
better and more pronounced effect than my typical LDR tests.

Post a reply to this message

[Just a reminder: I'm currently running the latest v3.8 Windows develpment
build, which piggybacks on v3.7.0]

POV-ray's real-time-raytracing feature for animation (since v3.7.0?) is
something I use from time to time, so I decided to make a radiosity test with
it. I had seen some promising results years ago, but I never followed up-- my
computer at the time was too slow. And it only works with a moving camera, not
with moving scene objects.

I've posted the test here; you might or might not recognize my on-going 'city
buildings' scene. I used BAD radiosity settings again, to clearly show the
rad-light patches. No actual light_source is in the scene...and NO saved
radiosity file was used.

  +kla +rtr   are the command-line settings. POV-ray does not output the
resulting image files, so I automatically  'captured'  the preview-window
screenshots with a free app called Automatic Screenshotter. .. with a lot of
tedious per-frame editing in Avidemux to remove duplicated images. What a chore!
 (I downloaded the screenshot app only yesterday, so I haven't learned its finer
points yet.)

The animation here is blown up 150% from the original render size, using
Avidemux. It is 300 frames long, so    +kla +rtr   used 300 cameras/positions,
generated in a #while loop.

[BTW, this is my first time using the 'new' antialias method 3 and
Stochastic_Seed for a full animation-- which did not mess up or alter the
radiosity light patches in any detrimental way. The render took about 4 hours...
not exactly 'real-time', but that was mostly due to the AA.]

Comparing this real-time-raytracing render with my original post's animation
method and video, this is *extremely* smooth. From what I see, there are NO
extra radiosity patches produced from frame to frame, just a bit of noise from
video encoding (and possibly a minor change from frame 1 to frame 2). As the
animation pregresses, there could be a  few patches that *slightly* change as
the building faces are uncovered to the camera, but those changes might simply
be video compression artifacts. Or my imagination?

For the animation's radiosity , I used
always_sample off
pretrace_start 1.0
pretrace_end 1.0

....but none of those seem to matter when using real-time-raytracing. I did an
alternate short test with always_sample on, pretrace_start .32, and pretrace_end
..01, and there were still no extra light patches; same result as this posted
animation.

So real-time-raytracing must be doing 1 of 2 things with radiosity:
1) creating a truly global 3D light 'map' of the entire scene before rendering
(unlike  regular animation-with-radiosity-- see my original animation)
OR...
2) As each new animation frame/camera position is rendered, POV-ray
saves/appends that new position's rad data to an internal file-- similar(?) to
my own multi-camera-position file saving scheme mentioned earlier.

.... and automatically turns OFF any new patch creation(?)

Those are the only two schemes I can think of; but whatever the complex method
is, it creates a really smooth result, superior to the other methods I've tried.
It would be great if just the 'radiosity part' of this process could be applied
to 'standard' animation.

BTW, real-time-raytracing automatically uses only 1 thread, as far as I can tell
from POV-ray's message pane. *Maybe* this has the effect of keeping new patches
from being created? Possibly; but I'm still not convinced of that (yet!), from
my earlier 1-thread-vs-multiple-threads tests. But my machine has only 2
threads, so I really don't know...  :-(

Post a reply to this message

Attachments:
Download 'radiosity_with_real_time_raytracing_12_6_20.mp4.mpg' (3544 KB)

On 12/6/20 3:48 PM, Kenneth wrote:
> William F Pokorny <ano### [at] anonymousorg> wrote:

> 
> Do you happend to know how those string representations can be 'decoded'? They
> are written as
>    7ffe7   ,  11ba94 , etc.
> 

Probably, but not sure off the top of my head. Let's see if I can find 
the code. Yep. Decoding shown below:

// normals aren't very critical for direction precision,
// so they are packed

sscanf(normal_string, "%02x%02x%02x", &tx, &ty, &tz);
normal[X] = ((double)tx * (1./ 254.))*2.-1.;
normal[Y] = ((double)ty * (1./ 254.))*2.-1.;
normal[Z] = ((double)tz * (1./ 254.))*2.-1.;
normal.normalize();

sscanf(to_nearest_string, "%02x%02x%02x", &tx, &ty, &tz);
to_nearest[X] = ((double)tx * (1./ 254.))*2.-1.;
to_nearest[Y] = ((double)ty * (1./ 254.))*2.-1.;
to_nearest[Z] = ((double)tz * (1./ 254.))*2.-1.;
to_nearest.normalize();

> Is it hexadecimal, perhaps? (Sorry, I'm no longer familiar with hex, from my
> university days long ago; I'm way out of practice with it.)
> 
...
> 
> About 'hacking' the saved radiosity file:
> It's an interesting idea, but will probably not work as intended. Here's an
> example of why:
> 1) I rendered a typical still-image radiosity scene, while saving the rad data
> to a file.
> 2) I re-rendered the scene using the saved data, with always_sample off and
> pretrace_start/end changed to 1.0. At this point, I cannot tell how many 'new'
> radiosity light patches have been created (without doing a 'difference'
> comparison in Photoshop); probably more than what is in the saved file.
> 3) I then opened the file in POV-ray and *erased* 90+ percent of the data lines
> there(!), then re-saved the file.
> 4) I re-rendered the scene again with the 'new' file-- and there are just as
> many radiosity light patches as before, except that most are now
> randomly-placed.
> 
> I had *assumed* that this new file would greatly reduce the number of light
> patches, but that's not the case.
> 
> Apparently,POV-ray is always trying to add new light patches when there are 'not
> enough' (?), or something like that. So, editing/hacking the file may not
> produce the intended results.
> 

Yeah. I'm not sure what might work and what might not. I suspect we 
would at least be able to do things like shift hues by mangling the 
saved colors, but time will tell.

Bill P.

Post a reply to this message

On 12/6/20 6:58 PM, Kenneth wrote:
> [Just a reminder: I'm currently running the latest v3.8 Windows develpment
> build, which piggybacks on v3.7.0]
> 
> POV-ray's real-time-raytracing feature for animation (since v3.7.0?) is
> something I use from time to time, so I decided to make a radiosity test with
> it. 

Using RTR for animations & radiosity. Another cool idea.

While the rtr / kla option is not available by default on unix based 
systems I've updated povr to run it. Thanks to Jerome, povr also 
supports x11 display and I looked briefly at the x windows dump 
capability to dump at the end of each camera render. Ran into some 
encoding / conversion issues from that format into something more usable 
- and dropped the effort.

Letting a 60 frame render loop at least 500 frames.

[17.7767 FPS]
-cc -fn -a0.3 -am2 +r2 -j2 +wt2 +w80 +h200 +rtr +kla -y x11

[17.6482 FPS]
-cc +fn -a0.3 -am2 +r2 -j2 +wt2 +w80 +h200 +rtr +kla -y x11

What the -fn to +fn slow down hints at is the internal structures needed 
for file output are being updated position to position. This means 
another and better option besides the x window dump would be trigger the 
usual output mechanism on the change to a new camera.

  [ 8.34761 FPS]
-cc -fn -a0.3 +am2 +r2 -j2 +wt2 +w80 +h200 +rtr +kla -y x11

Showing that AA costs.

My animation set up is different than your fly by camera positions. In 
my set up the camera is at the center and rotates.  At each of 60 
positions, it points to a different version of at scene. In this way 
stuff other than camera position can change.

When I turn on radiosity:

[ 8.46870 FPS]
-cc -fn -a0.3 +am2 +r2 -j2 +wt2 +w80 +h200 +rtr +kla -y x11

I do see flickering frame to frame. I think what's happening is we are 
getting an initial set of in scene samples, with rtr, but these don't 
get updated camera move to camera move - IF, there are already
enough samples.

Further, what I see in my real time set up on adding

  Radiosity_File_Name="RadSamples" +rfo +rfi

is an empty radiosity file getting additions on each camera position to 
camera position change until it hits frame 60. The saved file sample 
count is unchanged once the camera positions are revisited - until I 
break out of the animation loop at which point another burst of samples 
amounting to about 6% of the initial 60 camera position total is added.

If I then start a rtr cylic render up again with radiosity and the file 
of samples as input, I immediately get another 6% addition to the 
samples but then the sample count holds until I break out of the 
rendering loop when I get another 5.6%

FWIW. I don't completely understand what is going on. Seems like the 
preview part of radiosity only happens once on cyclic start. If I lower
the error_bound and low_error_factor I can get additional camera to 
camera samples 60 frame loop to 60 frame loop. Makes me think these are 
tied to the actual global space geometry in some way - which would mean 
they should be adjusted for each scene's scale...

Oh, at least in my environment, I see all processors used.

Lastly, I tried the larger render size idea and it changes a little the 
sample count, but not a lot. What changes I think is due the preview 
start / end windows being a little different. It must be the decisions 
on whether to add additional samples is all happening in the global 
scene coordinate space. See error_bound and low_error_factor comments 
above.

Bill P.

Post a reply to this message

William F Pokorny <ano### [at] anonymousorg> wrote:
> On 12/6/20 6:58 PM, Kenneth wrote:
> BTW, real-time-raytracing automatically uses only 1 thread, as far as I can
> tell from POV-ray's message pane.
>
> Oh, at least in my environment, I see all processors used.
>

Hey, you are correct! The Windows version's message pane is returning the wrong
values; RTR *is* using both of my Win 7 machine's 2 threads. (I did a test to
confirm this, changing v3.8's Work_Threads from my default of 2 to 1, and a
complete loop of the first RTR animation proceeds twice as fast.)

The message pane reports only this info, regardless of the Work_Threads setting:
       Parse time... using 1 thread
       Bounding time...using 1 thread

Thanks for the tip. Now, I can do some RTR/radiosity light-patch 'quality' tests
comparing 1 vs 2 threads-- which is not exactly a *definitive* test set-up,
compared to a really *multi*-threaded computer like a Core i7,etc...

Post a reply to this message

Le 2020-12-08 à 21:16, Kenneth a écrit :
> William F Pokorny <ano### [at] anonymousorg> wrote:
>> On 12/6/20 6:58 PM, Kenneth wrote:
>> BTW, real-time-raytracing automatically uses only 1 thread, as far as I can
>> tell from POV-ray's message pane.
>>
>> Oh, at least in my environment, I see all processors used.
>>
> 
> Hey, you are correct! The Windows version's message pane is returning the wrong
> values; RTR *is* using both of my Win 7 machine's 2 threads. (I did a test to
> confirm this, changing v3.8's Work_Threads from my default of 2 to 1, and a
> complete loop of the first RTR animation proceeds twice as fast.)
> 
> The message pane reports only this info, regardless of the Work_Threads setting:
>         Parse time... using 1 thread
>         Bounding time...using 1 thread
> 

Can't be otherwise. Parsing and bounding are strictly sequential, single 
thread, operations.
Photons shooting IF multiple lights or target, radiosity pretrace and 
render are the steps that can use all of your cores.

Post a reply to this message

Alain Martel <kua### [at] videotronca> wrote:
> Le 2020-12-08 à 21:16, Kenneth a écrit :
> >
> > The message pane reports only this info, regardless of the Work_Threads setting:
> >         Parse time... using 1 thread
> >         Bounding time...using 1 thread
> >
>
> Can't be otherwise. Parsing and bounding are strictly sequential, single
> thread, operations.
> Photons shooting IF multiple lights or target, radiosity pretrace and
> render are the steps that can use all of your cores.

Ah, good to know. So I guess POV-ray's Windows GUI/CODEMAX message pane is
leaving out any info about the number of threads used for *radiosity*.

BTW, thanks for the tip (in another discussion in the newsgroups here) about
radiosity light not having an effect on scattering MEDIA; I didn't know that.

Post a reply to this message