 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
But with low_error_factor, it lowers the error_bound
during the pretrace. In effect, when using low_error_factor
0.125 with error_bound 0.8, it should be doing the same
as using error_bound 0.1 in the first place. The only
difference is that it will interpolate amongst more samples
in the final trace, as a higher error_bound has a larger
gathering radius for the samples.
If my two-pass method uses error_bound 0.1 in the
first pass, and 0.8 in the second, it should theoretically
be the same as using error_bound 0.8 with low_error_factor
0.125.
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
> > I've made a quick test with a scene :
> >
> > 1st render :
> > pretrace_start 0.08
> > pretrace_end 0.02
> > error_bound 0.1
> > low_error_factor 1
> > always_sample off
> > save_file "rad1.data"
> >
> > and 2nd render :
> > pretrace_start 0.08
> > pretrace_end 0.02
> > error_bound 0.8
> > low_error_factor .125
> > always_sample off
> > save_file "rad2.data"
> >
> > and rad1.data is 3 times bigger than rad2.data.. !
>
> Ok, I think this is because in the 1st render, even with "always_sample
off"
> we can have new gather locations on the final trace, when povray don't
find
> *any* samples to reuse (For "always_sample on" we have more gathering if
the
> number of samples to reuse is < nearest_count). With an error_bound of 0.1
> it's not surprising that it finds places with no samples to reuse,
compared
> to error_bound 0.8 for which it has probably at least 1 sample it can
reuse
> from pretrace and so don't need more gathering.
>
> M
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.501 / Virus Database: 299 - Release Date: 14.07.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Nikias v2.0" wrote:
>
> But with low_error_factor, it lowers the error_bound
> during the pretrace. In effect, when using low_error_factor
> 0.125 with error_bound 0.8, it should be doing the same
> as using error_bound 0.1 in the first place. The only
> difference is that it will interpolate amongst more samples
> in the final trace, as a higher error_bound has a larger
> gathering radius for the samples.
Well if you still can't find the reason for the differences i suggest you
take a look at the sample counts in the statistics of both versions.
BTW you of course have to use 'always_sample off' in the render with
'low_error_factor' as well to get comparable results.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 17 Jun. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
done your test with the cornell scene
2-pass method :
radiosity{
#if (frame_number=1)
pretrace_start 0.08
pretrace_end 0.02
error_bound 0.1
save_file "rad.data"
#else
pretrace_start 1
pretrace_end 1
error_bound 0.8
always_sample off
load_file "rad.data"
#end
low_error_factor 1
count 100
recursion_limit 3
nearest_count 10
}
Stats : 47411 samples , 1-pass in 4'18 total 6'52 (0 samples in 2-pass)
and the same but with "always_sample off" for the 1st pass
Stats : 20714 samples , 1-pass in 1'32 total 1'59 (0 samples in 2-pass)
Method with low_error_factor :
radiosity{
pretrace_start 0.08
pretrace_end 0.02
error_bound 0.8
low_error_factor .125
count 100
recursion_limit 3
nearest_count 10
}
Stats : 6655 samples 1'06
All this seems logical. More samples and more time with the 2-pass method
because it takes sample locations at full res. with error_bound 0.1 (even
with "always_sample off", see my previous post). For the low_error_factor
there is only gathering at error_bound 0.1 during pretrace (and i've not
used a small mosaic) (and maybe some more samples for error_bound 0.8 for
final), so less samples, less time.
Finally note that when you save radiosity data in a file you don't save all
the information (gradient are not saved, and only locations at bounce depth
= 1 are saved)
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> All this seems logical. More samples and more time with the 2-pass method
> because it takes sample locations at full res. with error_bound 0.1 (even
> with "always_sample off", see my previous post). For the low_error_factor
> there is only gathering at error_bound 0.1 during pretrace (and i've not
> used a small mosaic) (and maybe some more samples for error_bound 0.8 for
> final), so less samples, less time.
I can't follow you here.
If always_sample is off, radiosity will only calculate samples during the
pretrace,
right? So, for the two-pass method, I'm pretracing with error_bound 0.1, and
for the one-pass method, I'm pretracing at error_bound 0.8*0.125, which is
0.1.
Unless the radiosity takes into account that it's actually tracing with 0.1
error_bound,
but pretracing with 0.1 when using low_error_factor, it shouldn't have much
different
numbers of samples. If it does, to me this clearly indicates that
low_error_factor
has some other side-effects which aren't mentioned in the docs.
After all, the using always_sample off should switch off sampling during the
final
trace, and then its all pretrace that matters.
Additionally, have you checked if the resulting images were of same quality?
Of
course they aren't, if the one-pass uses less samples. But the question to
me is,
why ARE there less samples?!
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
> done your test with the cornell scene
>
> 2-pass method :
> radiosity{
> #if (frame_number=1)
> pretrace_start 0.08
> pretrace_end 0.02
> error_bound 0.1
> save_file "rad.data"
> #else
> pretrace_start 1
> pretrace_end 1
> error_bound 0.8
> always_sample off
> load_file "rad.data"
> #end
> low_error_factor 1
> count 100
> recursion_limit 3
> nearest_count 10
> }
>
> Stats : 47411 samples , 1-pass in 4'18 total 6'52 (0 samples in 2-pass)
> and the same but with "always_sample off" for the 1st pass
> Stats : 20714 samples , 1-pass in 1'32 total 1'59 (0 samples in 2-pass)
>
> Method with low_error_factor :
> radiosity{
> pretrace_start 0.08
> pretrace_end 0.02
> error_bound 0.8
> low_error_factor .125
> count 100
> recursion_limit 3
> nearest_count 10
> }
>
> Stats : 6655 samples 1'06
>
> All this seems logical. More samples and more time with the 2-pass method
> because it takes sample locations at full res. with error_bound 0.1 (even
> with "always_sample off", see my previous post). For the low_error_factor
> there is only gathering at error_bound 0.1 during pretrace (and i've not
> used a small mosaic) (and maybe some more samples for error_bound 0.8 for
> final), so less samples, less time.
>
>
> Finally note that when you save radiosity data in a file you don't save
all
> the information (gradient are not saved, and only locations at bounce
depth
> = 1 are saved)
>
> M
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.501 / Virus Database: 299 - Release Date: 14.07.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Nikias v2.0" wrote:
>
> I can't follow you here.
> If always_sample is off, radiosity will only calculate samples during the
> pretrace,
> right?
No, it just sets nearest_count to 1 during final trace. You will see in
the statistics that in any case there will be samples taken during final
trace.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 17 Jun. 2003 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yeah, just noticed that as well. 15 samples on a second pass.
But 15 samples in relation to 5000 or even 50000 is not really
worth mentioning, so for the theory of low_error_factor and
its sampling one could neglect it (unless someone is using really
weird scene settings which shoots almost no samples in the
pretraces, but requires lots of em in the end).
So, question still remains why there are so much less samples?
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
>
>
> "Tim Nikias v2.0" wrote:
> >
> > I can't follow you here.
> > If always_sample is off, radiosity will only calculate samples during
the
> > pretrace,
> > right?
>
> No, it just sets nearest_count to 1 during final trace. You will see in
> the statistics that in any case there will be samples taken during final
> trace.
>
> Christoph
>
> --
> POV-Ray tutorials, include files, Sim-POV,
> HCR-Edit and more: http://www.tu-bs.de/~y0013390/
> Last updated 17 Jun. 2003 _____./\/^>_*_<^\/\.______
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.501 / Virus Database: 299 - Release Date: 14.07.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> So, question still remains why there are so much less samples?
the difference (between 6655 and 20714 samples ) is due to the final trace
full resolution at error_bound 0.1
I've re-done my first test, but this time with an abort of the render at the
end of pretrace and then compared the .rca (temporary radiosity save for
+C). This time, for both methods (2-pass and low_factor_error), the file
size is almost the same
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Hm. So the actual difference lies in the samples on the
final trace. If always_sample would really kill samples on
the final trace, then there'd be no difference, and the whole
two-pass issue would be possible with one-pass.
But we've already seen that always_sample doesn't prevent
samples from being taken 100% of the time.
Then there's only one final thing to check: when using the
two-pass method, where the first pass is done on, like,
80x60 image, and the second on 640x480, how big are
the difference in rendering/pretracing times? Cause if the
final trace is done on much lower resolution, there should
be less possibilities for new samples, as well as an increase
in rendering times. Perhaps this should also be tried with
much more extreme resolutions, like 40x30 compared to
1280x960.
And, of course, how is the quality then?
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
> > So, question still remains why there are so much less samples?
>
> the difference (between 6655 and 20714 samples ) is due to the final trace
> full resolution at error_bound 0.1
>
> I've re-done my first test, but this time with an abort of the render at
the
> end of pretrace and then compared the .rca (temporary radiosity save for
> +C). This time, for both methods (2-pass and low_factor_error), the file
> size is almost the same
>
> M
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.501 / Virus Database: 299 - Release Date: 14.07.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Hm. So the actual difference lies in the samples on the
> final trace. If always_sample would really kill samples on
> the final trace, then there'd be no difference, and the whole
> two-pass issue would be possible with one-pass.
I'm not sure but I think that the two-pass method works well precisely
because of the quite large number of samples disponibles (when averaged,
with the bigger error_bound, it smooths out possible errors). If you don't
have the samples from the final trace of the 1st pass you might loose the
benefit of the two-pass.
M
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
That's the point I concluded to as well, after all this.
Formerly, I just thought that the two-pass was better
because one could save time on the first pass and
then reuse it for second pass with larger resolution,
as well as smoothening errors. At the beginning, I
didn't know that low_error_factor was doing just
that.
Then, I found out about low_error_factor, and I
guess that I screwed something up somewhere, because
my latest experiments never took so long again...
But since always_sample only reduces sample-taking
on the final trace to a bare minimum, one could even
leave it switched on for the first pass, and switch it off
for the second pass.
To wrap it up: the two-pass method with increasing
resolution from first to second pass, shoots several more
samples than with low_error_factor alone and thus results
in better quality of image. I can't consider times, as my
experiments showed to be faster for the two-pass method,
but this is highly scene-dependant.
Additionally, one can tamper with several other settings
than just error_bound on the second pass as well, and
thus, one has more control. But that's the main idea of
doing several passes most of the time, isn't it?
But I'm glad that I've understood more now than in
the beginning. Shows me that it was worth it. :-)
Oh, and thanks Mael and Christoph, for the help
and suggestions!
Regards,
Tim
--
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights
> > Hm. So the actual difference lies in the samples on the
> > final trace. If always_sample would really kill samples on
> > the final trace, then there'd be no difference, and the whole
> > two-pass issue would be possible with one-pass.
>
> I'm not sure but I think that the two-pass method works well precisely
> because of the quite large number of samples disponibles (when averaged,
> with the bigger error_bound, it smooths out possible errors). If you don't
> have the samples from the final trace of the 1st pass you might loose the
> benefit of the two-pass.
>
> M
>
>
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.501 / Virus Database: 299 - Release Date: 14.07.2003
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
