Well I finally found rad settings that improved the image and rendered in a
reasonable amount of time. I used an error_bound of 0.4 and decreased the
pretrace start to 0.01 and pretrace end to 0.0025. This is the version that
will become my poster.

Post a reply to this message

Attachments:
Download 'boxrad.JPG' (116 KB)

Preview of image 'boxrad.JPG'

"Thomas Lake" <tla### [at] homecom> wrote in message
news:3b5e4c11@news.povray.org...
> Well I finally found rad settings that improved the image and rendered in
a
> reasonable amount of time. I used an error_bound of 0.4 and decreased the
> pretrace start to 0.01 and pretrace end to 0.0025. This is the version
that
> will become my poster.

    Man, does JPeg ever kill this picture..

Post a reply to this message

"Povray" <tch### [at] ductapenet> wrote in message
news:3b5ef638@news.povray.org...

>     Man, does JPeg ever kill this picture..

Err.. no.


Andy

Post a reply to this message

> > reasonable amount of time. I used an error_bound of 0.4 and decreased
the
> > pretrace start to 0.01 and pretrace end to 0.0025. This is the version
> that
> > will become my poster.
>
>     Man, does JPeg ever kill this picture..

Hmm really? I tried to avoid that by using a relatively low compression
level, could you point out which parts of the image are affected by it?

Post a reply to this message

"Thomas Lake" <tla### [at] homecom> wrote in message
news:3b5e4c11@news.povray.org...
> Well I finally found rad settings that improved the image and rendered in
a
> reasonable amount of time. I used an error_bound of 0.4 and decreased the
> pretrace start to 0.01 and pretrace end to 0.0025. This is the version
that
> will become my poster.
>

    Have you tried a higher pretrace_start setting ? I've found whacking it
right up to 1.00 for final renders gets rid of ugly rad artifacts...

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

Scott Hill wrote:

> Have you tried a higher pretrace_start setting ? I've found whacking it
> right up to 1.00 for final renders gets rid of ugly rad artifacts...

Actually all I've been using for a while is pretrace_start = pretrace_end = 1
(in Megapov). The strangest thing is that I don't know what I'm losing doing
that.

G.

--

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

Post a reply to this message

"Gilles Tran" <tra### [at] inapginrafr> wrote in message
news:3B5F250E.276DA256@inapg.inra.fr...
> Scott Hill wrote:
>
> > Have you tried a higher pretrace_start setting ? I've found whacking it
> > right up to 1.00 for final renders gets rid of ugly rad artifacts...
>
> Actually all I've been using for a while is pretrace_start = pretrace_end
= 1
> (in Megapov). The strangest thing is that I don't know what I'm losing
doing
> that.
>

    Well, the way I understand it, the rad pretrace settings are similar to
the mosaic preview settings, i.e. they're expressed as a percentage of the
image width... So with start=end=1.00 you're saying "take one sample at the
image width and do no more"... I think... Yeah, I'm pretty sure this
correct - if you set pretrace_start to 1.00 and pretrace_end to 0.50 you'll
see the rad pretrace stage gets down to 'blocks' half the width of the image
before the final pass starts... 0.25 ends at blocks 1/4 of the width and so
on... So, it seems to follow that, for max rad quality you need to set
pretrace_start=1.00 and pretrace_end=1/imagewidth... Having said that, the
'blocks' start getting kind of blurry when they get to around 4x4pixels, no
matter what the pretrace_end setting is...

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

Yes, I'd buy that one when my boat comes in.

Alf

Post a reply to this message

> Yes, I'd buy that one when my boat comes in.

Hehe thanks:-) That will be 1,000,000$ please.

> Alf

Post a reply to this message

"Scott Hill" <sco### [at] innocentcom> wrote in message
news:3b5f5261@news.povray.org...
> "Gilles Tran" <tra### [at] inapginrafr> wrote in message
> news:3B5F250E.276DA256@inapg.inra.fr...
> > Scott Hill wrote:
> >
> > > Have you tried a higher pretrace_start setting ? I've found whacking
it
> > > right up to 1.00 for final renders gets rid of ugly rad artifacts...
> >
> > Actually all I've been using for a while is pretrace_start =
pretrace_end
> = 1
> > (in Megapov). The strangest thing is that I don't know what I'm losing
> doing
> > that.
> >
>
>     Well, the way I understand it, the rad pretrace settings are similar
to
> the mosaic preview settings, i.e. they're expressed as a percentage of the
> image width... So with start=end=1.00 you're saying "take one sample at
the
> image width and do no more"... I think... Yeah, I'm pretty sure this
> correct - if you set pretrace_start to 1.00 and pretrace_end to 0.50
you'll
> see the rad pretrace stage gets down to 'blocks' half the width of the
image
> before the final pass starts... 0.25 ends at blocks 1/4 of the width and
so
> on... So, it seems to follow that, for max rad quality you need to set
> pretrace_start=1.00 and pretrace_end=1/imagewidth... Having said that, the
> 'blocks' start getting kind of blurry when they get to around 4x4pixels,
no
> matter what the pretrace_end setting is...

Hmm this is an interesting discusion, I've been wondering what these
settings really do, the pov docs arn't much help here. I'll have to do some
testing to see how different settings affect different images, but I'm not
going to play with this image any more.

Post a reply to this message

Thomas Lake wrote:
> 
> Hmm this is an interesting discusion, I've been wondering what these
> settings really do, the pov docs arn't much help here. I'll have to do some
> testing to see how different settings affect different images, but I'm not
> going to play with this image any more.

In general lower pretrace_end leads to better quality, but very often
1/image_width is more than necessary.  It should correspond to
error_bound, there meaning a lower error_bound should have a lower
pretrace_end.  

Some suggested values are:

error_bound 3  => pretrace_end 0.08 
error_bound 1  => pretrace_end 0.02 
error_bound <1 => pretrace_end 0.01

but they only give a rough idea, for low error_bounds you will probably
have to try what leads to the best quality/speed ratio.

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

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3B5FC21F.DF935776@gmx.de...
> Thomas Lake wrote:
> >
> > Hmm this is an interesting discusion, I've been wondering what these
> > settings really do, the pov docs arn't much help here. >
> In general lower pretrace_end leads to better quality, but very often
> 1/image_width is more than necessary.  It should correspond to
> error_bound

    This is one of the aspects of radiosity that I just don't understand -
from reading the docs I don't see how or why error_bound and pretrace_end
are related...

--
Scott Hill.
Software Engineer.
E-Mail        : sco### [at] innocentcom
Pandora's Box : http://www.pandora-software.com

*Everything in this message/post is purely IMHO and no-one-else's*

Post a reply to this message

Scott Hill wrote:
> 
>     This is one of the aspects of radiosity that I just don't understand -
> from reading the docs I don't see how or why error_bound and pretrace_end
> are related...
> 

I don't have a precise technical explanation, but with high error_bound
lower pretrace_end values have no effect.  In other words, if you use
1/image_width, you will be on the safe side concerning quality, but the
last pretrace steps are totally unnecessary for the result.  

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

Christoph Hormann escribió:
> In general lower pretrace_end leads to better quality, but very often
> 1/image_width is more than necessary.  It should correspond to
> error_bound, there meaning a lower error_bound should have a lower
> pretrace_end.

  But, if so, how Gilles radiosity scenes look so nice? I my self tried
just now pretrace start and end to 1 with my current irtc entry, and the
result is a 30% faster than with the recommended settings. And,
strangely, the result seems to be more "natural" although it has some
artifacts. Perhaps for "dirty" scenes it adds some irregularity that
looks better to our "anti-perfectly-clean" minds. In any case, I would
stick to 1 at least for that concrete scene, cause it renders faster and
the result looks slightly better.

-- 
Jaime Vives Piqueres

La Persistencia de la Ignorancia
http://www.ignorancia.org/

Post a reply to this message

Jaime Vives Piqueres wrote:
> 
>   But, if so, how Gilles radiosity scenes look so nice? I my self tried
> just now pretrace start and end to 1 with my current irtc entry, and the
> result is a 30% faster than with the recommended settings.

Of course it's faster, but is it better?  It would be really nice to see
some samples for comparison.

There is also the opposite approach BTW:
low pretrace_end, always_sample off and using save_file / load_file.  

> And,
> strangely, the result seems to be more "natural" although it has some
> artifacts. Perhaps for "dirty" scenes it adds some irregularity that
> looks better to our "anti-perfectly-clean" minds. In any case, I would
> stick to 1 at least for that concrete scene, cause it renders faster and
> the result looks slightly better.

I always find this kind of 'dirt' quite confusing and unnatural. NTL, if
you have a nice example showing this effect i would be eager to see it.

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

Christoph Hormann escribió:
> Of course it's faster, but is it better?  It would be really nice to see
> some samples for comparison.

  Well, at least the increased time seems to not justify the little
quality added. I don't want to show my current entry now, but at the end
of the round I will post both versions. 

> I always find this kind of 'dirt' quite confusing and unnatural. NTL, if
> you have a nice example showing this effect i would be eager to see it.

  I've substracted both images and the difference is not really visible.
I had to highly  increase bright and contrast on the differenced image
to see which zones changed. At the eye, the only visible difference is
the behavoir of layered textures. With pretrace=1 it seems more like
without radiosity, while with the recommended setting the layers seems
to "blend" (obviously that must happen bcos more rays come trough,
isn't?), making the texture strange. Perhaps the problem is that we must
create the layered textures thinking on the later use of radiosity...


-- 
Jaime Vives Piqueres

La Persistencia de la Ignorancia
http://www.ignorancia.org/

Post a reply to this message

Jaime Vives Piqueres wrote:

>   But, if so, how Gilles radiosity scenes look so nice? I my self tried
> just now pretrace start and end to 1 with my current irtc entry, and the
> result is a 30% faster than with the recommended settings. And,
> strangely, the result seems to be more "natural" although it has some
> artifacts.

To be frank, it's very confusing. I just tested this and the truth is that I
don't have a proper answer. In one little test scene, using Christoph's rad
"IndoorHQ" settings, using pretrace values <1 is better than pretrace 1
values : slightly lower rendering times, slightly less artifacts (but
artifacts nonetheless).
Now I'm sure to have experienced the same speed boost as you just noticed,
which is why I've been using these settings for almost a year with no
visible problems (I think that it was Xplo who found this trick). Note that
this could also explain why I don't have artifacts when I stop and resume
radiosity scenes (something I've been doing systematically to save memory,
even with 640 Mb of RAM).
I guess we should test this on full scenes. I just launched one of these
(800*320) with pretrace activated, and will render it again without. I
should have some answers on Saturday...

G.

--

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

Post a reply to this message

Jaime Vives Piqueres wrote:
> 
>   Well, at least the increased time seems to not justify the little
> quality added. I don't want to show my current entry now, but at the end
> of the round I will post both versions.
> 

I have done some quick tests myself, not as valuable as testing in a real
scene, but it shows the effect in different situations:

http://www.schunter.etc.tu-bs.de/~chris/rad/radiosity_pretrace.html

Note that the times given are not extremely accurate.

It seems that in some situations differences in both quality and speed are
quite low, in other cases it's much faster without pretrace, but also much
lower quality.  

What seems interesting to me is that in the first sequence (without light
sources) the 'medium settings' (last picture) give the best quality of all
the three cases.

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:
> 
> Jaime Vives Piqueres wrote:
> 
> >   But, if so, how Gilles radiosity scenes look so nice? I my self tried
> > just now pretrace start and end to 1 with my current irtc entry, and the
> > result is a 30% faster than with the recommended settings. And,
> > strangely, the result seems to be more "natural" although it has some
> > artifacts.
> 
> To be frank, it's very confusing. I just tested this and the truth is that I
> don't have a proper answer. In one little test scene, using Christoph's rad
> "IndoorHQ" settings, using pretrace values <1 is better than pretrace 1
> values : slightly lower rendering times, slightly less artifacts (but
> artifacts nonetheless).
> Now I'm sure to have experienced the same speed boost as you just noticed,
> which is why I've been using these settings for almost a year with no
> visible problems (I think that it was Xplo who found this trick). Note that
> this could also explain why I don't have artifacts when I stop and resume
> radiosity scenes (something I've been doing systematically to save memory,
> even with 640 Mb of RAM).
> I guess we should test this on full scenes. I just launched one of these
> (800*320) with pretrace activated, and will render it again without. I
> should have some answers on Saturday...

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.

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. Those of you who like making
radiosity scenes where everything is apparently made out of smooth gray
plastic might do well to keep that in mind...

-Xplo

Post a reply to this message

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

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.

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

G.



--

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

Post a reply to this message

Attachments:
Download 'periphdetail6.jpg' (16 KB)

Preview of image 'periphdetail6.jpg'

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