I was trying out the technique of saving the rad data and loading them for
use in an animation.
To save the rad data I used a 270degree fisheye camera located between the 4
spheres and looking down and rendered at 500x500 with these settings:

    radiosity{
      pretrace_start 0.08
      pretrace_end   0.01
      count 1200
      nearest_count 20
      error_bound 0.5
      recursion_limit 3
      low_error_factor .5
      minimum_reuse 0.0001
      brightness 1.5
      adc_bailout 0.00001
    }

for the animation, I relocated the camera and rendered each frame at 160x120
(I wanted quick results)
The initial settings took about an hour to render and the resulting
animation of 72 frames took about an hour as well. (BTW the original images
look tons smoother than the animation)

-tgq

Post a reply to this message

Attachments:
Download 'AniRad.mpg' (292 KB)

Sorry, could you explain this a bit more? I want to use rad in an
animation - are you saying that your method accelerated the render and
improved the quality? If so, could you run this past me step by step?
Thanks,
D.

"TinCanMan" <Tin### [at] hotmailcom> wrote in message
news:3d10a73d@news.povray.org...
> I was trying out the technique of saving the rad data and loading them for
> use in an animation.
> To save the rad data I used a 270degree fisheye camera located between the
4
> spheres and looking down and rendered at 500x500 with these settings:
>
>     radiosity{
>       pretrace_start 0.08
>       pretrace_end   0.01
>       count 1200
>       nearest_count 20
>       error_bound 0.5
>       recursion_limit 3
>       low_error_factor .5
>       minimum_reuse 0.0001
>       brightness 1.5
>       adc_bailout 0.00001
>     }
>
> for the animation, I relocated the camera and rendered each frame at
160x120
> (I wanted quick results)
> The initial settings took about an hour to render and the resulting
> animation of 72 frames took about an hour as well. (BTW the original
images
> look tons smoother than the animation)
>
> -tgq
>
>
>
>
>
>

Post a reply to this message

> Sorry, could you explain this a bit more? I want to use rad in an
> animation - are you saying that your method accelerated the render and
> improved the quality? If so, could you run this past me step by step?

I believe the method he used was:

1. render a still image of the scene with radiosity, saving the radiosity.
Make sure you can see as much of the surface area of objects as possible.

2. Render the animation, loading the saved radiosity data for each frame,
with always_sample off. Don't change the radiosity file at all while
rendering the animation.

This method, I assume, only works for scenes where the camera is moving, but
not if the objects are moving.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

Hmm, there are some definite lines along the edges of the spheres. I assume
this is because the original camera couldn't see enough of them.

Next time, try placing some mirrors around the scene with no_shadow in order
to see all the surfaces.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

"Slime" <slm### [at] slimelandcom> wrote in message
news:3d113ee4$1@news.povray.org...
> Hmm, there are some definite lines along the edges of the spheres. I
assume
> this is because the original camera couldn't see enough of them.
>
> Next time, try placing some mirrors around the scene with no_shadow in
order
> to see all the surfaces.
>
>  - Slime
> [ http://www.slimeland.com/ ]

Good point, I'll maybe try that.  This was actually my first time using
save_file and load_file with radiosity so I was just pleased at the results
in general.

-tgq

Post a reply to this message

> > Sorry, could you explain this a bit more? I want to use rad in an
> > animation - are you saying that your method accelerated the render and
> > improved the quality? If so, could you run this past me step by step?
>
> I believe the method he used was:
>
> 1. render a still image of the scene with radiosity, saving the radiosity.
> Make sure you can see as much of the surface area of objects as possible.
>

Yes, this is what I did as suggested in some previous posts.  I placed a
camera between the four balls looking straight down using the fisheye camera
type in order to see as much as possible.  (As suggested by Slime, I
should've added some no shadow mirrors behind the balls to see more surface)
The idea here is to be able to see as much of the scene as possible from one
camera view so that radiosity data is calculated for as much of the scene as
possible (rad data is only calculated for what can be seen).
Also render with as high quality settings as you can at a larger resolution
to get the best, smoothest results
(the original render was 500x500, the scenes rendered for animation were
160x120).
The original render used to save the settings took ~1h (I can't remeber the
actual time).
Rendering the anim scenes with loaded data took about 50s each for 72 frames
about 1h total
For comparison, calculating the rad for each scene at 160x120 rather than
loading the rad data would've taken about 13m 35s each for a whopping 16h
18m total for 72 frames, plus , because the rad was calculated for each
frame the results wouldn't have blended smoothly from frame to frame and you
would see some flickering in the animation.



> 2. Render the animation, loading the saved radiosity data for each frame,
> with always_sample off. Don't change the radiosity file at all while
> rendering the animation.
>
> This method, I assume, only works for scenes where the camera is moving,
but
> not if the objects are moving.

Yes, this method only works with stationary objects and a moving camera.

-tgq

Post a reply to this message

Nice looking, but I wonder if this scene does not put the
spottiness-of-radiosity-in-animation to its full test...

Post a reply to this message

"Greg M. Johnson" <gregj:-)565### [at] aolcom> wrote in message
news:3d131a9a$1@news.povray.org...
> Nice looking, but I wonder if this scene does not put the
> spottiness-of-radiosity-in-animation to its full test...
>

Probably not. This was done with a moving camera and stationary objects
which can take advantage of th load_file and save_file options.  The problem
lies with moving objects where the radiosity has to be calculated for every
scene to get proper results, but due to the nature of the way radiosity is
calculated, the results will 1) take considerably longer and 2) probably not
be able to avoid the spotiness or flickering problem (without ridiculously
high settings, see 1)

-tgq

Post a reply to this message