POV-Ray : Newsgroups : povray.binaries.animations : radiosity in animation-- a partial solution to 'flicker' : Re: radiosity in animation-- a partial solution to 'flicker' Server Time
15 Apr 2024 02:21:26 EDT (-0400)
  Re: radiosity in animation-- a partial solution to 'flicker'  
From: William F Pokorny
Date: 7 Dec 2020 13:46:02
Message: <5fce786a$1@news.povray.org>
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 

Bill P.

Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.