Hi - I guess this is the right place to ask questions about radiosity in 3.7,
right?

I rendered a scene overnight that saved the radiosity data to a cache using the
+RFO flag, then went to do some more renders this morning loading that cached
data with +RFI.

I can lower several settings in the "global_settings { radiosity { ... } }"
block, and the render still looks as good as the previous overnight one, which
indicates POV is reading the cache data and using it.

That's great, but the renders are still really really slow. The overnight one
was about 7 hours, and the ones with low radiosity settings, but reading the
cache, look like they will take several hours themselves.

If I turn off the reading of the cache, the renders go very fast (about 2
minutes) but look pretty bad (which I expected).

Are there some settings in the global_settings { radiosity { ... } }" block that
would let me have a fast render by mostly using the cached data? Or is the
amount of data in the cache file from the high quality pass the bottleneck (the
cache file is about 88MB)?

My renders are 1280x720 with AA turned off. I do move the camera a little bit
each render (the same as focal blur in POV would do).

Sorry if I'm missing any information in this post to help with an answer - I
guess I'm not really sure how the radiosity cache works in POV enough to know
exactly what to ask...

Cheers,
Edouard.

Post a reply to this message

Am 28.04.2010 03:32, schrieb Edouard:

> That's great, but the renders are still really really slow. The overnight one
> was about 7 hours, and the ones with low radiosity settings, but reading the
> cache, look like they will take several hours themselves.
>
> If I turn off the reading of the cache, the renders go very fast (about 2
> minutes) but look pretty bad (which I expected).
>
> Are there some settings in the global_settings { radiosity { ... } }" block that
> would let me have a fast render by mostly using the cached data? Or is the
> amount of data in the cache file from the high quality pass the bottleneck (the
> cache file is about 88MB)?

It's probably the high-quality cached samples that kill your render time.

While /taking/ samples can be a pretty time-consuming process depending 
on the quality setting, /looking up/ samples is not trivial either.

The most important factor there is the "overlap" of samples: A high 
number of re-usable samples for a given point is the worst-case scenario 
when it comes to sample lookup. You can reduce this by using a lower 
nearest_count and/or a higher low_error_factor in the sample-taking 
pass. (Of course both /may/ reduce quality.)

You can also speed up sample lookup of already taken samples by using a 
lower error_bound value in the final pass, but this is less effective 
than increasing low_error_factor during sample-taking, despite having 
the same effect on image quality.

Note that a high number of samples /per se/ is not necessarily fatal to 
lookup speed. Using a very low error_bound in both passes, while 
drastically increasing total sample /count/, will typically not change 
sample /density/ (as it also reduces sample /size/), and therefore 
should only have a rather benign impact on sample lookup speed.

Post a reply to this message

> I rendered a scene overnight that saved the radiosity data to a cache
> using the +RFO flag, then went to do some more renders this morning
> loading that cached data with +RFI.
>
> I can lower several settings in the "global_settings { radiosity { ... }
> }" block, and the render still looks as good as the previous overnight
> one, which indicates POV is reading the cache data and using it.
>
> That's great, but the renders are still really really slow. The
> overnight one was about 7 hours, and the ones with low radiosity
> settings, but reading the cache, look like they will take several hours
> themselves.

   Did you remember to use always_sample off on the reading pass? Also, from
my experience, it is best to make sure you have the same nearest_count,
error_bound and recursion_limit. If you want it even faster, try reducing
count on the second pass: I found that 1/10 of the count on the first pass,
renders very quick without losing much quality.

   BTW, I'm just testing this new load/save mechanism, and I'm missing a way
to know within the SDL if I'm loading or saving, to automatically adapt
textures and other details... anyone knows if this is possible?


-- 
Jaime Vives Piqueres

http://www.ignorancia.org

Post a reply to this message

> Did you remember to use always_sample off on the reading pass? Also, from
> my experience, it is best to make sure you have the same nearest_count,
> error_bound and recursion_limit. If you want it even faster, try reducing
> count on the second pass: I found that 1/10 of the count on the first
> pass, renders very quick without losing much quality.
>

   ...also set pretrace_start and pretrace_end to 1 for the second pass, of
course!

   Regards,


-- 
Jaime Vives Piqueres

http://www.ignorancia.org

Post a reply to this message

"Edouard" <pov### [at] edouardinfo> wrote:

> Are there some settings in the global_settings { radiosity { ... } }" block that
> would let me have a fast render by mostly using the cached data?

Thanks for asking this question; the same slowness has always puzzled me too (in
v3.6.)

And thanks to Clipka for the explanation. I didn't know that using the cached
data also took time and was non-trivial. I always thought I was doing something
basically wrong when loading a rad file; now I understand.

BTW, in v3.6.1 on Windows, when radiosity is used, it seems that a rad file(?)
is saved to disc even when it isn't asked to be. (The file has the extension
..rca with the scene's default file name.) Has this been corrected? (When
*purposely* saving a rad file, the file shows up without the .rca extension.)

Also, when purposely saving a rad file in v3.7 or the betas, does a file type
need to be added to the file name? As in, save_file "my_rad_file.*something*? In
v3.6, it didn't seem to be necessary, but the docs have always been unclear
about this.

Ken

Post a reply to this message

"Kenneth" <kdw### [at] earthlinknet> wrote:

> BTW, in v3.6.1 on Windows, when radiosity is used, it seems that a rad file(?)
> is saved to disc even when it isn't asked to be. (The file has the extension
> ..rca with the scene's default file name.) Has this been corrected?

OK, something's odd--this behavior has happened dozens of times in the past
(including tonight, with a test scene); but now, I can't seem to reproduce it
consistently.  Don't know what to say... :-[

Ken

Post a reply to this message

> "Kenneth"<kdw### [at] earthlinknet>  wrote:
>
>> BTW, in v3.6.1 on Windows, when radiosity is used, it seems that a rad
>> file(?) is saved to disc even when it isn't asked to be. (The file has
>> the extension ..rca with the scene's default file name.) Has this been
>> corrected?
>
> OK, something's odd--this behavior has happened dozens of times in the
> past (including tonight, with a test scene); but now, I can't seem to
> reproduce it consistently.  Don't know what to say... :-[

   That's an internal rad file, and it is deleted when the render finishes
properly... :)



-- 
Jaime Vives Piqueres

http://www.ignorancia.org

Post a reply to this message

Am 28.04.2010 10:51, schrieb Kenneth:

> BTW, in v3.6.1 on Windows, when radiosity is used, it seems that a rad file(?)
> is saved to disc even when it isn't asked to be. (The file has the extension
> ..rca with the scene's default file name.) Has this been corrected? (When
> *purposely* saving a rad file, the file shows up without the .rca extension.)

That's a temporary file that is deleted after a successful render, but 
left on disk if you abort, to be loaded automatically when you continue 
the aborted render, so that the radiosity cache data doesn't get lost.

> Also, when purposely saving a rad file in v3.7 or the betas, does a file type
> need to be added to the file name? As in, save_file "my_rad_file.*something*? In
> v3.6, it didn't seem to be necessary, but the docs have always been unclear
> about this.

File extension doesn't matter. ".rca" would be the default, but you can 
use anything you like (including no extension at all).

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:

> That's a temporary file that is deleted after a successful render, but
> left on disk if you abort, to be loaded automatically when you continue
> the aborted render, so that the radiosity cache data doesn't get lost.
>

And Jaime wrote:
> That's an internal rad file, and it is deleted when the render finishes
> properly... :)

Well I'll be damned! :-) So *that's* why it was there and then not there.
Mystery solved! Thanks, to both of you.

Ken

Post a reply to this message

>> Did you remember to use always_sample off on the reading pass? Also, from
>> my experience, it is best to make sure you have the same nearest_count,
>> error_bound and recursion_limit. If you want it even faster, try reducing
>> count on the second pass: I found that 1/10 of the count on the first
>> pass, renders very quick without losing much quality.
>>
>
> ...also set pretrace_start and pretrace_end to 1 for the second pass, of
> course!
>
> Regards,
>
>
If you want to suppress the pretrace, set pretrace_end LARGER than 
pretrace_start. I found that by mistakenly setting pretrace_end to the 
wrong value.

So, only set pretrace_end 1 while leaving pretrace_start untouched will 
completely avoid any pretrace.



Alain

Post a reply to this message