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

> 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:

>
> > ...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

> 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