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

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