RL is keeping me quite busy these days, but I've been able to make some progress
on the radiosity code nonetheless:

- I seem to be getting closer to the causes of the slowdown in the beta.30-rad1,
so I hope soon to be able to sort that one out.

- I've been able to come up with a solution that allows for 100% reproducable
shots with multiprocessing, at a performance cost of only 10%-20%.

The basic idea is to re-use samples only if they were taken during a previous
pretrace step, or for the same "tile". However, with higher recursion depths
this would almost certainly lead to loads of duplicate samples taken during the
first pretrace step, so I modified this a bit.

During the first pretrace step, I force all the tiles to be rendered one at a
time in a default order, so I can safely allow re-use of any samples taken
during the same pretrace step. Due to the typically low resolution this is
still acceptably fast to do single-threaded, and already gives a decent
coverage at higher recursion depths without any duplicates.

During the second, pretrace step, I split up the tiles in two sets, each of
which again is to be rendered one at a time in a default order, so samples
taken during the same pretrace step can still safely be re-used within the same
set of tiles. Typically, resolution will still be low enough to render
reasonably fast with reduced thread count; dupes at higher recursion depths are
reduced both by the samples already gathered during first pretrace step as well
as the still limited thread count, so some dupes may be gathered, but no
triples or quadruples.

The approach can be continued during the whole pretrace, repeatedly splitting up
the tiles into ever more sets.

Note that thread count can actually be lower than the number of tile set. Tiles
can be safely assigned to any thread, as long as only one tile per set is being
processed at any time, so the approach works with any arbitrary thread count
lower or equal to the number of tile sets.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> - I've been able to come up with a solution that allows for 100% reproducable
> shots with multiprocessing, at a performance cost of only 10%-20%.

Exhaustive test results are as follows:

- Most scenes I tested show a perfect match between file output of consecutive
renders, or sparse stray pixels typically differing by 1/255. Occasionally,
individual pixels differ by as much as 2/255. There is no clear structure to
the occurence of these differences, making analysis difficult. The absence of
banded structures indicate that sample placement is a perfect match, and
current assumption is that the differences are caused by rounding effects in
conjunction with different ordering of samples in the sample cache. Given the
small order of magnitude, these differences are probably not enough of an issue
to really bother about them.

- Some Low-quality scenes show areas of uniform difference of 1/255, with a
structure indicating that sample placement may not be matching perfectly, for
yet unexplained reason. However, this is only a guess, and the structure may
have other causes; given that these differences are of minor order of magnitude
as well, and only occur in low-quality shots, they don't seem worth bothering
about either.

However, three scenes deverse special mention:

- In the "balcony.pov" and "cornell.pov" scenes, output file pixel values differ
by up to 80/255 and 16/255, respectively, in the partially shadowed areas; there
is reason to assume that these differences are due to jittered area lights in
both cases. In fully shadowed or unshadowed areas, only individual stray pixels
of 1/255 difference could be observed.

- In my almost-closed-door scene, pixel values differ by up to 21/255 (the
maximum differences being in the bright corner of the room, which is an
artifact). The differences show as grainy splotches, indicating both slight
differences in the brightness of individual samples, but at the same time a
perfect match in their placement. Again, these differences could be caused by
rounding effect differences, due to variations in the ordering of samples in
the sample cache. The comparatively high order of magnitude may be due to the
exceptionally bright illumination used for the shot.

- The "balcony.pov" scene could not be compared yet, because in one of the two
runs it once again crashed with a segfault (at address 0x00000000 this time).

Rendering time increases by close to 40% in a single case, but mostly stays
within an added 10%-20%. Measured over my whole batch of test scenes, "wall
clock" time increases by 10.8%. Only a small portion of this increase is due to
idle cores; in fact, CPU time increases by 10.5% as well.

As I can well imagine that some people might prefer speed over reproducability,
I suggest adding a special command line parameter to switch on or off any
mechanisms that improve reproducability at the cost of speed.

Post a reply to this message

"clipka" <nomail@nomail> wrote:
> - In the "balcony.pov" and "cornell.pov" scenes, output file pixel values differ
....
> - The "balcony.pov" scene could not be compared yet, because in one of the two
> runs it once again crashed with a segfault (at address 0x00000000 this time).

Duh. Watch me posting nonsense... :P

To clarify this messup: A third run succeeded while I was writing that post. You
can probably imagine the rest.

Post a reply to this message

clipka <nomail@nomail> wrote:
> In fully shadowed or unshadowed areas, only individual stray pixels
> of 1/255 difference could be observed.

  I assume that's without using "area_illumination"?-)

  One could wonder that even if an area light is jittered, why couldn't it
be always jittered in the same way from render to render? This could be
beneficial in animations.

-- 
                                                          - Warp

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> > In fully shadowed or unshadowed areas, only individual stray pixels
> > of 1/255 difference could be observed.
>
>   I assume that's without using "area_illumination"?-)

Um... yes, I guess so.

>   One could wonder that even if an area light is jittered, why couldn't it
> be always jittered in the same way from render to render? This could be
> beneficial in animations.

In case of a non-adaptive area light that should be rather easy to implement,
but for the typical circular adaptive orient area light it quickly gets
non-trivial I guess.

Post a reply to this message

Hello,

rendering a room-scene I get a brighter image in 3.7b31 in compare with 3.6
In 3.6 I can see a structured wall and a T_Stone8 texture, but in 3.7b31 they
both appear almost white.

I used

  radiosity {
    pretrace_start 0.09
    pretrace_end   0.01
    count 100
    error_bound 1.8
    recursion_limit 10
    brightness 1
    normal on
  }

and a simple light:

light_source {
  <0, 0, 0>
  color rgb 1*<1, 1, 1>
  translate campos
}

Post a reply to this message

"Physiker" <nomail@nomail> wrote in message 
news:web.49a11d38a9104c116c3ac0cf0@news.povray.org...
> rendering a room-scene I get a brighter image in 3.7b31 in compare with 
> 3.6
> In 3.6 I can see a structured wall and a T_Stone8 texture, but in 3.7b31 
> they
> both appear almost white.

do you have assumed_gamma set in globals block?

do you have proper Display_Gamma set in the command-line dialog (win 
version)?

Jim

Post a reply to this message

"Jim Holsenback" <jho### [at] hotmailcom> wrote in message 
news:49a12372@news.povray.org...
>
> "Physiker" <nomail@nomail> wrote in message 
> news:web.49a11d38a9104c116c3ac0cf0@news.povray.org...
>> rendering a room-scene I get a brighter image in 3.7b31 in compare with 
>> 3.6
>> In 3.6 I can see a structured wall and a T_Stone8 texture, but in 3.7b31 
>> they
>> both appear almost white.
>
> do you have assumed_gamma set in globals block?

I should add shouldn't be for 3.7 ... in my globals block I have

#if (version < 3.7)
    assumed_gamma 1
#end

>
> do you have proper Display_Gamma set in the command-line dialog (win 
> version)?

Display_Gamma=2.2 is probably the setting here  it's between 1.8(MAC)  and 
2.5(PC)

Jim

Post a reply to this message

> >> rendering a room-scene I get a brighter image in 3.7b31 in compare with
> >> 3.6

> > do you have proper Display_Gamma set in the command-line dialog (win
> > version)?
>
> Display_Gamma=2.2 is probably the setting here  it's between 1.8(MAC)  and
> 2.5(PC)
>
> Jim


no, I tried
assumed_gamma 1.0
and ini-option display_gamma=1.0

- but with beta31 it's brighter

(system: w2k)

Post a reply to this message

"Physiker" <nomail@nomail> wrote in message 
news:web.49a180dca9104c116c3ac0cf0@news.povray.org...
>> >> rendering a room-scene I get a brighter image in 3.7b31 in compare 
>> >> with
> no, I tried
> assumed_gamma 1.0
> and ini-option display_gamma=1.0

maybe you should have a look at: section 3.1.2.3  Display Output Options in 
windows help

Here's what I do ....

In scene (.pov)  files I have:

global_settings {
 #if (version < 3.7)
   assumed_gamma 1
 #end
 }

In the command line box (top bar windows version) I have Display_Gamma=2.2 
.....

Cheers

Post a reply to this message