I've made an excessive test last evening/night:
All of my Radiosity-Images I am currently uploading
to my website for Radiosity-Explanation and Experience
Sharing make use of a two pass method that originates
from Gilles Tran (hm, come to think about it, I realize
that I haven't mentioned that on my website yet...).
What it does is use an error_bound of 0.1 in the first
pass and save the data, then use an error_bound of
either 0.4 or 0.8 (depending on what is sufficient for
smooth radiosity-lighting) when loading it. To ensure
that these settings are used, low_error_factor is set
to 1, thus disabling a reset of error_bound during
pretrace/first pass.

Point is: Rendering a 640x480 image for both
passes required somewhat around half to one
hour, total.

Now, I figured that low_error_factor could be used
for the same: it lowers error_bound during the pretrace
and sets it back to normal on the final/actual trace.

So, setting error_bound to 0.8 and low_error_factor
to 0.125 I assumed I'd get an error_bound of 0.1 for
the pretraces (as 0.8 * 0.125 = 0.1), but render it at
error_bound 0.8.

And the results were catastrophic (not on image quality,
but rendering times): 14 hours and 15 minutes!!
And the results are the same.

Now, I'd like to know: does low_error_factor do
something else than what the documentation says,
or have I misunderstood it? I've read section
"6.11.11.2.7 low_error_factor" and it plainly says
that it drops error_bound on the pre-final passes
and sets it back on the final trace...

Any comments on that?

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights



---
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:
> 
> [...]
> 
> Now, I'd like to know: does low_error_factor do
> something else than what the documentation says,
> or have I misunderstood it? I've read section
> "6.11.11.2.7 low_error_factor" and it plainly says
> that it drops error_bound on the pre-final passes
> and sets it back on the final trace...

low_error_factor does exactly what the docs say, it reduces error_bound
during final pretrace step.  Very long render times probably have
different reasons.  Make sure you use exactly the same settings for the
renders you compare.

Doing such comparisons is often very interesting but you should not forget
that they strongly depend on the scene used.  Creating an universal
radiosity test scene is quite impossible.

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

The scenes are exactly the same. I would
agree that when using different scenes, this
could be a problem. But all I did was either
use error_bound .1 explicitly on the first
pass and error_bound .8 explicitly on the
second pass, OR I used error_bound .8 with
low_error_factor set to .125. On both
occasions, the amount of pretraces were the
same, as I didn't touch those settings. Only
for the second pass, it just loads the data
and renders that, no pretrace, but that's just
what I'd expect the other method to do: when
finally tracing the image, use error_bound .8
with the data POV-Ray has.

I would understand some dozen minutes difference,
as overhead etc are probably different, but half
a day seems somewhat too much. Thats an increase
of about 1200%!

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights


>
>
> "Tim Nikias v2.0" wrote:
> >
> > [...]
> >
> > Now, I'd like to know: does low_error_factor do
> > something else than what the documentation says,
> > or have I misunderstood it? I've read section
> > "6.11.11.2.7 low_error_factor" and it plainly says
> > that it drops error_bound on the pre-final passes
> > and sets it back on the final trace...
>
> low_error_factor does exactly what the docs say, it reduces error_bound
> during final pretrace step.  Very long render times probably have
> different reasons.  Make sure you use exactly the same settings for the
> renders you compare.
>
> Doing such comparisons is often very interesting but you should not forget
> that they strongly depend on the scene used.  Creating an universal
> radiosity test scene is quite impossible.
>
> 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

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.. !
Hmm, so there's something I don't get with low_error_factor neither :)


As a side note here is a little trick to render radiosity scenes with the
2-pass approach, using animation options :

// +w300 +h300 +KFF2

#if (frame_number=1)
      pretrace_start 0.08
      pretrace_end 0.02
      error_bound 0.2
      save_file "rad.data"
#else
      pretrace_start 1
      pretrace_end 1
      error_bound 0.6
      always_sample off
      load_file "rad.data"
#end

works nicely but you can't have different antialiasing/resolution options
for each pass

M

Post a reply to this message

Why didn't I think of checking that? But that explains
it all, doesn't it. Its either more data, more overhead, I
don't know. Perhaps issueing more space to store the
extra amount of samples due to low_error_factor isn't
as efficient as when POV-Ray knows right from the
beginning to use error_bound .1, and stay with that...

Doesn't really matter. But its good to know that there
is something going on, sadly, I'm no programming expert
to actually do something about it. I'm also unsure if
there's actually need or possibility to actually do so...

-- 
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.. !
> Hmm, so there's something I don't get with low_error_factor neither :)
>
>
> As a side note here is a little trick to render radiosity scenes with the
> 2-pass approach, using animation options :
>
> // +w300 +h300 +KFF2
>
> #if (frame_number=1)
>       pretrace_start 0.08
>       pretrace_end 0.02
>       error_bound 0.2
>       save_file "rad.data"
> #else
>       pretrace_start 1
>       pretrace_end 1
>       error_bound 0.6
>       always_sample off
>       load_file "rad.data"
> #end
>
> works nicely but you can't have different antialiasing/resolution options
> for each 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

"Tim Nikias v2.0" <tim### [at] gmxde> a écrit dans le message de news:
3f1545be@news.povray.org...
> from Gilles Tran (hm, come to think about it, I realize
> that I haven't mentioned that on my website yet...).

Don't mention me. It has been around for a while. All the following is IIRC
(the posts are buried in p.b.i) : Kari Kivisalo came up with the 2-pass
method because JRG was stuck with a rad scene involving glass. Jaime Vives
Piqueres discovered that having a first pass at a smaller resolution didn't
harm. Ingo also played with this for creative purposes etc.

G.

--

**********************
http://www.oyonale.com
**********************
- Graphic experiments
- POV-Ray and Poser computer images
- Posters

Post a reply to this message

Hm, okay. I'll update it then and state that it
has been a newsgroup-approven technique. :-)

Thanks for your honesty, though I wouldn't expect
any different from you...

Regards,
Tim

-- 
Tim Nikias v2.0
Homepage: http://www.digitaltwilight.de/no_lights


> > from Gilles Tran (hm, come to think about it, I realize
> > that I haven't mentioned that on my website yet...).
>
> Don't mention me. It has been around for a while. All the following is
IIRC
> (the posts are buried in p.b.i) : Kari Kivisalo came up with the 2-pass
> method because JRG was stuck with a rad scene involving glass. Jaime Vives
> Piqueres discovered that having a first pass at a smaller resolution
didn't
> harm. Ingo also played with this for creative purposes etc.
>
> G.
>
> --
>
> **********************
> http://www.oyonale.com
> **********************
> - Graphic experiments
> - POV-Ray and Poser computer images
> - Posters
>
>


---
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

> 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

Post a reply to this message

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