THANKS Thomas and Ash for giving me the clues I needed; I got the loading of the
radiosity data to work, in an .INI file. Happy days! (But the +RFO and +RFI
comand-line terms simply don't work in the 3.8 version I am using.)

To SAVE the rad data to a file:
Radiosity_File_Name="RAD data" (or whatever name)
Radiosity_To_File=on

To LOAD the saved file:
Radiosity_File_Name="RAD data" [I didn't realize that this needed to be
specified again]
Radiosity_From_File=on

Simple! Although, I think the documentation could be a bit clearer about the
need for Radiosity_File_Name in *both* cases. BTW, I haven't yet tried this
syntax in v3.7.0. And the "RAD data" file , when loaded, apparently doesn't need
the .rad file extension, at least when used in an .INI file.

From experimenting, I agree with Thomas that a scene's radiosity settings should
be left as-is when loading the saved file, with no modifications. Here's why:

Given these original settings as an example...
Radiosity{
brightness 1.0
count 200
recursion_limit 3
minimum_reuse 0.0001
maximum_reuse 0.0013
pretrace_start 0.08
pretrace_end 0.01
always_sample off [the default]
}

....if I modify one or more of those terms, the re-rendered image with the saved
file shows a strange combination of settings. For example, changing COUNT from
200 to 1 creates a visual 'mix' of both counts, which is hard to describe. And
even stranger, changing RECURSION_LEVEL to 1 rather than 3 takes five times
longer to render than the initial scene(!). Normally, a lower recursion_level
will produce a *faster* render. Very strange.

The point is, changing any parameter seems to change the behavior and visual
result of the saved file, in unexpected ways. Some changes are obvious, some are
subtle. However, as Ash mentioned, changing PRETRACE_END to 1.0 (and maybe
PRETRACE_START as well?) has a useful effect: It apparently keeps any 'new'
radiosity samples from being taken. (I had to run some animation tests to see
this.) Even with ALWAYS_SAMPLE off, the original values for those two terms
produce a few more samples. That probably improves the quality of a still image,
but it adversely affects radiosity in *animations*, as I've discovered. Using
1.0 for both terms (along with the saved file) really helps to keep animation
from 'jittering'.

I've also discovered an interesting limitation in rad behavior that I didn't
know about, when used in animation. But I've come up with a useful solution-- to
keep the radiosity 'light patches' steady and unchanging, with no 'flicker'.
:-)   I'll save that for a separate post.

Post a reply to this message