Quick question. Let's say I have a room full of computers. Using all of
these computers to render non-radiosity images is pretty easy. However, is
there some way to render radiosity-based images in parallel somehow? The
times I've tried, the image looks wrong after being stitched together. I
can't seem to find it in a faq or anything similar.

Post a reply to this message

jhu nous apporta ses lumieres en ce 09/07/2006 12:46:
> Quick question. Let's say I have a room full of computers. Using all of
> these computers to render non-radiosity images is pretty easy. However, is
> there some way to render radiosity-based images in parallel somehow? The
> times I've tried, the image looks wrong after being stitched together. I
> can't seem to find it in a faq or anything similar.
> 
> 
Use a two pass method.
First pass: set pretrace_end to a low value. It can help to use a low value for
low_error_factor to 
collect some extra data. You want to collect as much radiosity data as possible so you
will have 
less sampling to do during the final render. Save the radiosity values collected.
Second pass, parallel pass, you need to set always_sample to no. Load the previously
saved radiosity 
data. Set pretrace_start 1 pretrace_end 1.

-- 
Alain
-------------------------------------------------
Everyone has a photographic memory. Some just don't have film.

Post a reply to this message

Can the radiosity data be collected in parallel or does one computer have to
calculate it for the entire scene?

Alain <ele### [at] netscapenet> wrote:
> jhu nous apporta ses lumieres en ce 09/07/2006 12:46:
> > Quick question. Let's say I have a room full of computers. Using all of
> > these computers to render non-radiosity images is pretty easy. However, is
> > there some way to render radiosity-based images in parallel somehow? The
> > times I've tried, the image looks wrong after being stitched together. I
> > can't seem to find it in a faq or anything similar.
> >
> >
> Use a two pass method.
> First pass: set pretrace_end to a low value. It can help to use a low value for
low_error_factor to
> collect some extra data. You want to collect as much radiosity data as possible so
you will have
> less sampling to do during the final render. Save the radiosity values collected.
> Second pass, parallel pass, you need to set always_sample to no. Load the previously
saved radiosity
> data. Set pretrace_start 1 pretrace_end 1.
>
> --
> Alain
> -------------------------------------------------
> Everyone has a photographic memory. Some just don't have film.

Post a reply to this message

jhu wrote:
> Can the radiosity data be collected in parallel

   No.

Post a reply to this message

Warp wrote:
> jhu wrote:
>> Can the radiosity data be collected in parallel
>   No.

Out of curiousity, is this a technical limitation or a theoretical one? 
I.e., would it be possible for someone with enough knowlege to recode 
the same basic algorithm but make it distributable? Or is the algorithm 
inherently only serial?

-- 
   Darren New / San Diego, CA, USA (PST)
     This octopus isn't tasty. Too many
     tentacles, not enough chops.

Post a reply to this message

I'm curious about this as well. Since v3.7 has multi-threading capabilities,
does that only apply to actual rendering subsequent to calculating radiosity
data?

Darren New <dne### [at] sanrrcom> wrote:
> Warp wrote:
> > jhu wrote:
> >> Can the radiosity data be collected in parallel
> >   No.
>
> Out of curiousity, is this a technical limitation or a theoretical one?
> I.e., would it be possible for someone with enough knowlege to recode
> the same basic algorithm but make it distributable? Or is the algorithm
> inherently only serial?
>
> --
>    Darren New / San Diego, CA, USA (PST)
>      This octopus isn't tasty. Too many
>      tentacles, not enough chops.

Post a reply to this message

Darren New wrote:
> Warp wrote:
>> jhu wrote:
>>> Can the radiosity data be collected in parallel
>>   No.
> 
> Out of curiousity, is this a technical limitation or a theoretical one?
> I.e., would it be possible for someone with enough knowlege to recode
> the same basic algorithm but make it distributable? Or is the algorithm
> inherently only serial?

If using the exact same algorithm, it is not possible. However, (complex)
variations of the algorithm do not necessarily have to depend on certain
serial requirements. The serial aspect is related to the data structure used
to store gathered samples, which at the same time are used as feedback for
later samples (i.e. if to gather or reuse samples). naturally, this depends
on the order of insertions in the current algorithm.

	Thorsten

Post a reply to this message

Darren New wrote:
> Warp wrote:
>> jhu wrote:
>>> Can the radiosity data be collected in parallel
>>   No.
> 
> Out of curiousity, is this a technical limitation or a theoretical one? 

   I understood the question as "is it possible with pov3.6 to collect
radiosity in parallel?" and the answer is a clear "no".

   (Btw, even though povray calls it "radiosity", this shouldn't be
confused with the algorithm (used mostly in scanline rendering) called
radiosity which is completely different. What povray calculates is a
stochastic inter-reflection between surfaces, but I'll call it
global illumination (which is the most generic term) for short.)

   In theory it is possible to collect global illumination data in
parallel, but either there needs to be a data container with
multithreading support shared between all the nodes (possible but
not trivial, and increases drastically the amount of communication
between the nodes) or they could be calculated separately and then
merged (which would cause considerable overlapping, ie. needless
calculations).

   The problem in distributing the stochastic algorithm used by
povray is that values already stored in the spatial data container
are used to speed up further calculations. This is naturally done for
speed, but it has the side-effect that changing rendering parameters
even a bit can cause visible differences in the end result (eg. just
changing the starting line of the rendering can change the
illumination). This is why separate threads/processes/computers cannot
calculate global illumination of different parts of the scene
separately without visible differences in illumination appearing.
All the calculations would need to be synchronized in order to get
an uniform result.

   I actually don't know how the pov-team intends to correct this
problem because it is a rather difficult one. (I actually don't know
how the current pov3.7 beta does it, but it looks to me as if it used
just one thread when radiosity is used.)

Post a reply to this message