Hi,

this image shows a detail of a building rendered in Beta29/30 and Beta30rad1.
The whole rendering shows the complete building and has a resolution of
W4500xH3000.
Settings are equal except nearest_count and low_error_factor at the suggestion
of clipka:

radiosity
{
 pretrace_start 16/image_width
 pretrace_end 2/image_width
 count 500
 error_bound .1
 //nearest_count 1
 //low_error_factor 0.5
 recursion_limit 1
 normal on
 always_sample off
}

On Vista64
QuadCore @2.66GHz
the rendertime was 23min with Beta29/30
and 220min with Beta30rad1.

Another rendering from another side took 41min with Beta29/30
and 695min with Beta30rad1 (and was the reason why I hadn't enough patience to
use the XP32 machine with Core2Duo @2.4 ;). I've cancelled the process, after
making sure that the speedcomparison was as usual.)

As I mentioned in povray.beta-test the output looks better in b30rad1, if you
look for example into the opened window or under the roof.


Full of hope
TomAust

Post a reply to this message

Attachments:
Download 'beta30_beta30rad1.jpg' (574 KB)

Preview of image 'beta30_beta30rad1.jpg'

"TomAust" <aus### [at] aust-manufakturde> wrote:
> Hi,
>
> this image shows a detail of a building rendered in Beta29/30 and Beta30rad1.
> The whole rendering shows the complete building and has a resolution of
> W4500xH3000.
> Settings are equal except nearest_count and low_error_factor at the suggestion
> of clipka:
>
>  //nearest_count 1
>  //low_error_factor 0.5
>  recursion_limit 1
>
> On Vista64
> QuadCore @2.66GHz
> the rendertime was 23min with Beta29/30
> and 220min with Beta30rad1.

Are you aware that commenting-out the nearest_count setting gives you a default
value of 5?

Anyway, this starts to seriously bug me. From my test renders I had the
impresson that serious slowdown occured only at higher recursion_limit values,
not with single-bounce shots. Now all reports coming in seem to indicate
otherwise.

Blood-stained excrements of a male bovine.

I can imagine only one thing that could cause this difference in a single-bounce
shot: Effective trace depth.

What are your global trace_limit and adc_bailout values?

(Would you be willing to disclose the scene file so I could do some toying
around with it? If public posting is not an option, you might send it to
christoph <at> lipka-koeln <dot> de.)


> Full of hope
> TomAust

Yeah - I, too, hope to be able to find the cause of those slowdowns... obviously
they're more serious in practice than I expected, so the status quo is
unacceptable.


(BTW, the building looks strikingly familiar - I fancy that I've seen the
original somewhere in the south of Cologne... Zollstock maybe?)

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> "TomAust" <aus### [at] aust-manufakturde> wrote:
> > Hi,
> >
> > this image shows a detail of a building rendered in Beta29/30 and Beta30rad1.
> > The whole rendering shows the complete building and has a resolution of
> > W4500xH3000.
> > Settings are equal except nearest_count and low_error_factor at the suggestion
> > of clipka:
> >
> >  //nearest_count 1
> >  //low_error_factor 0.5
> >  recursion_limit 1
> >
> > On Vista64
> > QuadCore @2.66GHz
> > the rendertime was 23min with Beta29/30
> > and 220min with Beta30rad1.
>
> Are you aware that commenting-out the nearest_count setting gives you a default
> value of 5?
>

Of course, I commented out these two points only for the rendering with
Beta29/30, which was the last run.

> Anyway, this starts to seriously bug me. From my test renders I had the
> impresson that serious slowdown occured only at higher recursion_limit values,
> not with single-bounce shots. Now all reports coming in seem to indicate
> otherwise.
>

Oh, I really don't want to injure you, you are my hope! ;)

> Blood-stained excrements of a male bovine.
>

Hm, where is my dictionary?!

> I can imagine only one thing that could cause this difference in a single-bounce
> shot: Effective trace depth.
>
> What are your global trace_limit and adc_bailout values?
>

No special settings here, in fact not set at all, so they are default.

> (Would you be willing to disclose the scene file so I could do some toying
> around with it? If public posting is not an option, you might send it to
> christoph <at> lipka-koeln <dot> de.)
>

Yes, of course, but with many, many incs, declarations, macros, etc. and a bunch
of selfcreated fileendings - perhaps a reason for the slowdown?
So I should use your mailadress.


> (BTW, the building looks strikingly familiar - I fancy that I've seen the
> original somewhere in the south of Cologne... Zollstock maybe?)

The renderings are visualizations for a planned building in Bonn (so another
point to keep it in confidence) and mostly architects are pretty influenced by
mainstream... ;)
But what a coincidence, neighbour!
Greetings from Bickendorf, not as bad as its reputation!

Post a reply to this message

TomAust <aus### [at] aust-manufakturde> wrote:
> this image shows a detail of a building rendered in Beta29/30 and Beta30rad1.

  Why is everyone comparing the radiosity of Beta 30 with the newest
radiosity version?

  Unless I'm completely mistaken, the radiosity code in 3.7 beta
versions <= 30 was, by all intents and purposes, non-functional and
certainly not intended to be used for anything. The code was just
provisionally there to give *something* (rather than eg. just crashing
the program) but not as the intended functionality.

  What people should compare against is the radiosity in 3.6.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> TomAust <aus### [at] aust-manufakturde> wrote:
> > this image shows a detail of a building rendered in Beta29/30 and Beta30rad1.
>
>   Why is everyone comparing the radiosity of Beta 30 with the newest
> radiosity version?
>

Because Chris Cason asked for feedback about "integrated radiosity changes"
between b29/30 and b30rad1...?

TomAust

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
>   Why is everyone comparing the radiosity of Beta 30 with the newest
> radiosity version?
>
>   Unless I'm completely mistaken, the radiosity code in 3.7 beta
> versions <= 30 was, by all intents and purposes, non-functional and
> certainly not intended to be used for anything. The code was just
> provisionally there to give *something* (rather than eg. just crashing
> the program) but not as the intended functionality.
>
>   What people should compare against is the radiosity in 3.6.

Unfortunately, from what I've seen in my test renders is that there is no great
difference in speed between 3.6 and 3.7.0.beta.29 (at least when comparing pure
CPU time). This is because the radiosity code wasn't so dysfunctional after all
- it was just broken, but that didn't influence speed much.

So the drastic increase in reder time does worry me.

Post a reply to this message

I agree with Warp, since we are not only concerned with speed but the 
quality of the output. Being the last release build, 3.6 is the standard 
against which any changes should be measured.


"clipka" <nomail@nomail> wrote in message 
news:web.49722d4ebea0b42dd3a05d570@news.povray.org...
> Warp <war### [at] tagpovrayorg> wrote:
>>   Why is everyone comparing the radiosity of Beta 30 with the newest
>> radiosity version?
>>
>>   Unless I'm completely mistaken, the radiosity code in 3.7 beta
>> versions <= 30 was, by all intents and purposes, non-functional and
>> certainly not intended to be used for anything. The code was just
>> provisionally there to give *something* (rather than eg. just crashing
>> the program) but not as the intended functionality.
>>
>>   What people should compare against is the radiosity in 3.6.
>
> Unfortunately, from what I've seen in my test renders is that there is no 
> great
> difference in speed between 3.6 and 3.7.0.beta.29 (at least when comparing 
> pure
> CPU time). This is because the radiosity code wasn't so dysfunctional 
> after all
> - it was just broken, but that didn't influence speed much.
>
> So the drastic increase in reder time does worry me.
>
>

Post a reply to this message

Mike Hough <nos### [at] nospamcom> wrote:
> I agree with Warp, since we are not only concerned with speed but the 
> quality of the output. Being the last release build, 3.6 is the standard 
> against which any changes should be measured.

  If the speed (when rendering with one single thread) stays the same as
in 3.6 but the end result has less artifacts and higher quality, the
situation is a complete win.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> TomAust <aus### [at] aust-manufakturde> wrote:
>> this image shows a detail of a building rendered in Beta29/30 and Beta30rad1.
> 
>   Why is everyone comparing the radiosity of Beta 30 with the newest
> radiosity version?

On a personal level, I'm pretty happy with beta<=30 radiosity. I can see 
where it can be improved somewhat, of course. I would be very unhappy if 
the render times got higher and higher with each new release. I would be 
worried that it might stay slow :S

>   Unless I'm completely mistaken, the radiosity code in 3.7 beta
> versions <= 30 was, by all intents and purposes, non-functional and
> certainly not intended to be used for anything. The code was just
> provisionally there to give *something* (rather than eg. just crashing
> the program) but not as the intended functionality.

I don't think it's as dysfunctional as you say it is. There is an issue 
with render-block-sized squares showing up sometimes, but changing 
pretrace_end to a lower value makes those artifacts vanish. Black 
patches show up also, but lowering adc_bailout fixes that problem (as 
long as it's not caused by reflecting or refracting objects).

>   What people should compare against is the radiosity in 3.6.

The quality, the speed, or both? If I can still squeeze artifact-free 
radiosity out of pov.b.3.7, I'll be happy. As long as it doesn't take 
too long, of course.

I think if the POV-team is going to pursue a higher-quality radiosity 
implementation at the great expense of speed, there should be an option 
to use the old "broken" 3.7 radiosity if desired. But clipka seems to be 
concerned about the speed as well, so I probably have nothing to worry 
about :)

Sam

Post a reply to this message

stbenge <^@hotmail.com> wrote:
> But clipka seems to be
> concerned about the speed as well, so I probably have nothing to worry
> about :)

Rrrrright!

Radiosity is just about slow enough as it is (um, well, I mean, was in 3.6). I'd
have accepted a slowdown of something like factor 2 as a price for artifact-free
renders, because it would probably mean that old quality would be obtailable at
old speed by choosing different settings. But we're talking about factors of 10
or more.

I won't accept anything that looks like you can't get the same quality as 3.6 at
roughly the same speed.

Post a reply to this message