stbenge wrote:
> 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. 

But you realize that it was broken in the sense that it just plain did not 
work anything like it should or did in 3.6? I certainly know because I 
amputated the code originally for 3.7. So really there is no pre-beta30rad1 
radiosity!!!

	Thorsten

Post a reply to this message

"TomAust" <aus### [at] aust-manufakturde> wrote:
> The whole rendering shows the complete building and has a resolution of
> W4500xH3000.
>...
> the rendertime was 23min with Beta29/30
> and 220min with Beta30rad1.
>

Just finished the comparing renderings with same settings but in lower
resolution at W1500xH1000.
And now the rendertimes are
6min 35sec with beta29/30
and just
16min 49sec with beta30rad1 !

Perhaps a helpful note ?

TomAust

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> But you realize that it was broken in the sense that it just plain did not
> work anything like it should or did in 3.6? I certainly know because I
> amputated the code originally for 3.7. So really there is no pre-beta30rad1
> radiosity!!!

Hm... if you amputated it, someone must have brought it to life again -
partially - before or at beta 29: It did a few things wrong, but it *did*
something, radiosity-wise.

Post a reply to this message

"TomAust" <aus### [at] aust-manufakturde> wrote:
> > the rendertime was 23min with Beta29/30
> > and 220min with Beta30rad1.
> >
>
> Just finished the comparing renderings with same settings but in lower
> resolution at W1500xH1000.
> And now the rendertimes are
> 6min 35sec with beta29/30
> and just
> 16min 49sec with beta30rad1 !
>
> Perhaps a helpful note ?

It is at least *some* hint on what might be going on.

It is very strange however why a 9-fold number of pixels to calculate should
result in a 12-fold effort. Reason says that in the 9-fold number of pixels
shot and with the pretrace resolution defined relative to the total resolution,
we should expect to have about 9-fold the number of rays to trace, 9-fold the
number of radiosity lookups to do, and at most 9-fold the number of radiosity
samples to collect (in fact we should expect less increase, as some areas
should have sufficient coverage at the 1500x1000 resolution already). So that
should be at most 9-fold the rendering time. Well, plus a little bit of
additional overhead as various data structures grow. They're designed to have
sublinear access times though.

Did you keep any stats output?


In any case, this smells like severe performance issues with some data structure
that grows to larger size in the 4500x3000 shot.

Looking up radiosity cache data? No dramatic changes there. Fixed the level at
which a sample is "hooked in", potentially resulting in about 4-fold the number
of samples per node, but that just brought samples per node back to the order of
magnitude seen in 3.6.1.

Creating new sample data blocks? Hm... made a bit of a change there regarding
the locking; I'd actually expect that to speed things up instead, but I better
check.

Creating new nodes in the sample tree? Made significant changes there to change
the locking strategy as well; maybe I messed up something there.

Post a reply to this message

Thorsten Froehlich wrote:
> stbenge wrote:
>> 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. 
> 
> But you realize that it was broken in the sense that it just plain did 
> not work anything like it should or did in 3.6? I certainly know because 
> I amputated the code originally for 3.7. So really there is no 
> pre-beta30rad1 radiosity!!!

Yes, I understand that 3.7.b radiosity isn't as good as 3.6, but I'm 
willing to live with it until it is improved. At this point I haven't 
felt the need to go back to 3.6, since only the new beta versions 
support multi-threading. Really, I can get some nice radiosity renders 
out of 3.7. Smooth shading, small details. The quality of enclosed areas 
is still a bit dodgy, but it's not too bad.

I just hope that in the end 3.7's radiosity will still render at a good 
clip :)

Sam

Post a reply to this message

clipka wrote:
> 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.

That's steep, to be sure.

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

Well, if things go wrong I can always stock old versions of POV and head 
for the bunker :)

Sam

Post a reply to this message

clipka wrote:

> It is very strange however why a 9-fold number of pixels to calculate should
> result in a 12-fold effort.

With antialiasing, you'd expect the time to be sub-linear in the number of pixels,
assuming higher resolution images are smoother (not true with fractals).

Post a reply to this message