[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)