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

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