Gilles Tran wrote:
> 
> Xplo Eristotle wrote:
> 
> > It's worth pointing out that the messier your scene naturally is (due to
> > texturing, or objects casting a lot of small shadows, or something), the
> > less perfect your radiosity has to be.
> 
> This is true, and particularly for flat surfaces. However, in my experience, small
> error_bound values are always needed to get accurate shadows below objects placed
> in radiosity-lit areas.

Yeah, but you can at least reduce the count if the artifacts won't be noticed.

-Xplo

Post a reply to this message

Gilles Tran wrote:
> 
> Xplo Eristotle wrote:
> 
> > It's been a while since I actually messed with pretrace parameters, but
> > IIRC, error_bounds > .1 benefit visually from a really precise pretrace
> > (although above .4 or so, the benefit may not be worth the time anyway),
> > whereas smaller error_bounds don't, so pretrace should be set to 1 to
> > save time. Don't take this as absolute gospel, though; these are
> > approximations off the top of my head, and not based on extensive testing.
> 
> My feeling too. My rule of thumb would be like this:
> [1] test renders with no quality requirement : pretrace 1 (saves time)
> [2] final renders with error_bound < 0.1 : pretrace 1 (saves time)
> [3] all other types of radiosity renders  : small pretrace values may save time
> and improve quality
> 

I have made some more test renders, available on the URL posted in the
other subthread.  The differences in speed are quite marginal and the
quality differences seem to diminish with lower error_bound, just like
Xplo said.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Gilles Tran wrote:

> BTW, I was too optimistic about my current test renders as the first one (with
> pretrace<1) is crawling at 150 points per minute. No answers (checking rule [2])
> until next Monday at best.

Much too optimistic... The second render just finished. The comparison was between a
pretrace_start/pretrace_end =1/1 render and a 0.08/0.01 one.
Note that the experiment was not scientific, because Povray was running in the
background with a low priority while I working with other CPU-consuming apps
(databases) during half of the renders. I also had to make a slight change on a
texture between the two renders (I guess with no effect on the render time).

- identical render times : 27h 46 min
- substracting the image shows some little differences (in the parts not touched by
the texture change) but final appearance could be said identical apart one
antialiasing problem with the 0.08/0.01 image.

Other rad params were :
count 400
error_bound 0.05
nearest_count 4
recursion_limit 1
low_error_factor 1
gray_threshold 0.15
minimum_reuse 0.015
brightness 1.5
adc_bailout 0.01/2
normal on

Attached: two PNG (extracts of the final images) of 58 kbu each.

G.



--

**********************
http://www.oyonale.com
**********************
Graphic experiments
Pov-ray gallery

Post a reply to this message

Attachments:
Download 'periph2.png' (58 KB) Download 'periph1.png' (58 KB)

Preview of image 'periph2.png'

Preview of image 'periph1.png'

AWESOME ROLEX! No really I can't believe this is rendered. Perhaps part of
it is the small size of the picture but I still say that is unbelievably
realistic.


"Gilles Tran" <tra### [at] inapginrafr> wrote in message
news:3B6914F7.5D8E369A@inapg.inra.fr...
> Gilles Tran wrote:
>
> > BTW, I was too optimistic about my current test renders as the first one
(with
> > pretrace<1) is crawling at 150 points per minute. No answers (checking
rule [2])
> > until next Monday at best.
>
> Much too optimistic... The second render just finished. The comparison was
between a
> pretrace_start/pretrace_end =1/1 render and a 0.08/0.01 one.
> Note that the experiment was not scientific, because Povray was running in
the
> background with a low priority while I working with other CPU-consuming
apps
> (databases) during half of the renders. I also had to make a slight change
on a
> texture between the two renders (I guess with no effect on the render
time).
>
> - identical render times : 27h 46 min
> - substracting the image shows some little differences (in the parts not
touched by
> the texture change) but final appearance could be said identical apart one
> antialiasing problem with the 0.08/0.01 image.
>
> Other rad params were :
> count 400
> error_bound 0.05
> nearest_count 4
> recursion_limit 1
> low_error_factor 1
> gray_threshold 0.15
> minimum_reuse 0.015
> brightness 1.5
> adc_bailout 0.01/2
> normal on
>
> Attached: two PNG (extracts of the final images) of 58 kbu each.
>
> G.
>
>
>
> --
>
> **********************
> http://www.oyonale.com
> **********************
> Graphic experiments
> Pov-ray gallery
>
>


----------------------------------------------------------------------------
----






----------------------------------------------------------------------------
----

Post a reply to this message