 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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] edouard info> 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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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.
Of course, now I have a few questions. (So what else is new?!)
In light of this info, I did a radiosity scene test (nothing really complex), to
try and understand what difference(s) the temporary .rca file *stored* on disk
makes to a final *non*-aborted radiosity render. (The only way I know of to
judge any difference is either visually, or through the total parse/render time
of the scene.) In other words, here's what I did--three different images of the
same scene, all run with radiosity (in v.3.6.1--I know things have changed since
then!)
1) Run the scene, but abort it before the radiosity pass is finished. This
produces the temp .rca file and stores it. Then re-run the scene again, letting
it go until finished. (Which *uses* the stored .rca file in some way, as
mentioned, but wipes it off the disk afterward.) This produces image #1.
2) Repeat the same thing as in 1), but DELETE the temp .rca file that's
produced, before running the scene again until it finishes. This produces image
#2
3) Run the scene all the way through, *without* aborting it. This produces image
#3.
What I see is that there is NO difference at all between the renders, either
visually (image quality) or in render time. (I compared them in Photoshop, using
the 'difference' blend mode there.)
My little test may not be definitive; but it seems to me that the temp .rca file
isn't doing much! *If* that's also the case in the *betas* (with its newer
radiosity code), it leads me to ask: Is the temp .rca file stored on disk really
necessary? (That is, for an aborted render?) The only thing I see it doing is
taking up disk space--and it can be a whoppingly large file. (There are
instances in the past where I've aborted a rad run, then put the scene away for
awhile--which leaves that temp .rca file intact, necessitating hand removal.) If
any of my reasoning or results are valid, it seems to me that the file should be
erased even after an aborted run. Comments?
Ken
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Am 29.04.2010 14:59, schrieb Kenneth:
> My little test may not be definitive; but it seems to me that the temp .rca file
> isn't doing much! *If* that's also the case in the *betas* (with its newer
> radiosity code), it leads me to ask: Is the temp .rca file stored on disk really
> necessary? (That is, for an aborted render?) The only thing I see it doing is
> taking up disk space--and it can be a whoppingly large file. (There are
> instances in the past where I've aborted a rad run, then put the scene away for
> awhile--which leaves that temp .rca file intact, necessitating hand removal.) If
> any of my reasoning or results are valid, it seems to me that the file should be
> erased even after an aborted run. Comments?
I don't know for sure whether the temp .rca file really ever worked as
intended in 3.6.
Note that in order for the temp .rca data to be re-used, you'll have to
start the second render in abort-continue mode.
Furthermore, 3.6 only stored "top-level" radiosity samples, i.e. those
produced at recursion depth 1. If you choose a higher recursion depth
and POV-Ray decides that it needs more samples in the final render than
are available in the cache, it will have to re-compute quite a lot of
"deeper" samples.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
