i wonder why is mosaic preview for "radiosity" important. 

would the quality of the computed picture be poor
without the (smooth) mosaic preview?

or would the speed of the "radiosity" significantly
increase without mosaic preview?

or are there any side effects in the smooth mosaic preview 
code without which the "radiosity" simply would not run?

i'm using pov-ray 3.02. are there any significant changes
to the "radiosity" code in pov-ray 3.1*?

	y.

Post a reply to this message

On Thu, 16 Sep 1999 17:00:31 +0200, Tomas Plachetka wrote:
>i wonder why is mosaic preview for "radiosity" important. 

Because the radiosity calculations require a well-distributed
set of sample points.  Mosaic preview goes over the entire scene,
so the points that are created as it samples the coarser grid 
approximate the ones that will be needed when it computes at the 
finer resolution.

>i'm using pov-ray 3.02. are there any significant changes
>to the "radiosity" code in pov-ray 3.1*?

None that I know of.

Post a reply to this message

Ron Parker wrote:
> 
> On Thu, 16 Sep 1999 17:00:31 +0200, Tomas Plachetka wrote:
> >i wonder why is mosaic preview for "radiosity" important.
> 
> Because the radiosity calculations require a well-distributed
> set of sample points.  Mosaic preview goes over the entire scene,
> so the points that are created as it samples the coarser grid
> approximate the ones that will be needed when it computes at the
> finer resolution.

thanks for your quick reply. yes, you are right (when 
looking around here i see you always are  :-)

however, i'm more interested in what would happen if the
mosaic preview were not used. would the radiosity code
still work? would it just run slower? would the quality 
of the rendering suffer?

my questions concern the screen parallelisation of pov-ray. 
making the "radiosity" code work in parallel is imho a 
nontrivial task. mosaic preview is just one of the problems 
i'm aware of, there are more difficult ones. pvmpov seems 
not to care about them. (each of the slave processes builds 
its own "radiosity" octree; the octrees are never merged and 
could not be saved; etc. i'm not sure whether the slaves do 
the mosaic preview on their chunks or not - i can only see 
the pvmpov patch file now, which is a little inconvenient to 
read.)

	y.

p.s.happy birthday!

Post a reply to this message

On Thu, 16 Sep 1999 18:37:29 +0200, Tomas Plachetka wrote:
>however, i'm more interested in what would happen if the
>mosaic preview were not used. would the radiosity code
>still work? would it just run slower? would the quality 
>of the rendering suffer?

I think it would just run more slowly.  As far as I can tell, the
main purpose of the mosaic preview is to seed the cache with some 
good candidates for later lookups.  

However, I'm betting that removing the mosaic preview step would
still not solve the discontinuities you get when you render in
parallel.  I'm not sure I see any way to eliminate those.  You 
could eliminate half of them by making every other band render
from bottom to top, but that would probably make the other half
worse.  

Using a mosaic preview of the entire scene on one machine to build 
a cache which you would then send to all the rendering processes
when they start might help, but it still wouldn't be perfect.

The problem is that each process builds its own cache over time, 
and they tend to diverge over time if the processes are doing work 
that varies too much.  The discontinuities at band edges are thus
due to the fact that the process that rendered the first band had a
much larger cache to work from when it rendered the last row of that
band.  One possible solution is to use much smaller bands, on the 
order of a single row of pixels.  Better would be to do that, plus
make all of the running processes share a single cache somehow.
I suspect you'd still get discontinuities that got worse toward the
right edge of the image, though, particularly if you used vastly
different processors or if one or more tasks had much less work to
do.

Post a reply to this message

Ron Parker wrote:
> 
> On Thu, 16 Sep 1999 18:37:29 +0200, Tomas Plachetka wrote:
> >however, i'm more interested in what would happen if the
> >mosaic preview were not used. would the radiosity code
> >still work? would it just run slower? would the quality
> >of the rendering suffer?
> 
> I think it would just run more slowly.  As far as I can tell, the
> main purpose of the mosaic preview is to seed the cache with some
> good candidates for later lookups.

I also have such a feeling. I'll try skipping the mosaic 
preview in the sequential POV-Ray version soon.

> However, I'm betting that removing the mosaic preview step would
> still not solve the discontinuities you get when you render in
> parallel.  I'm not sure I see any way to eliminate those.  You
> could eliminate half of them by making every other band render
> from bottom to top, but that would probably make the other half
> worse.

I agree, this does not sound well at all.

> Using a mosaic preview of the entire scene on one machine to build
> a cache which you would then send to all the rendering processes
> when they start might help, but it still wouldn't be perfect.

This would be just postponing the bad things.

> The problem is that each process builds its own cache over time,
> and they tend to diverge over time if the processes are doing work
> that varies too much.  The discontinuities at band edges are thus
> due to the fact that the process that rendered the first band had a
> much larger cache to work from when it rendered the last row of that
> band.  One possible solution is to use much smaller bands, on the
> order of a single row of pixels.  Better would be to do that, plus
> make all of the running processes share a single cache somehow.
> I suspect you'd still get discontinuities that got worse toward the
> right edge of the image, though, particularly if you used vastly
> different processors or if one or more tasks had much less work to
> do.

Smaller bands increase communication, as well as a shared
cache. (I was/am actually thinking about sharing the cache.) 
The problem of ray tracing parallelisation seems to nested 
when it comes to Monte Carlo. The troubles with a shared 
cache are not unlike the troubles with sharing the workload 
between slaves. Even worse, there is a correlation between
them.

Btw, are there any more intelligent parallel implementations 
of POV-Ray which tackle the "radiosity" (and/or antialiasing, 
etc.) problem?

	y.

"Nothing is perfect," sighed the fox.
  -- A. de Saint-Exupery

Post a reply to this message

In povray.advanced-users Ron Parker <parkerr@fwi.com> wrote:
: I think it would just run more slowly.  As far as I can tell, the
: main purpose of the mosaic preview is to seed the cache with some 
: good candidates for later lookups.  

  That may be right because you know a lot more about povray than I do, but
I have the feeling that the precalculation part (which we see as "mosaic
preview") is essential and that the radiosity method implemented by
povray would not be possible without it.
  Why do I think this way? Let's see the documentation:

> How does POV-Ray calculate the ambient term for each point? By sending out
> more rays, in many different directions, and averaging the results. A
> typical point might use 200 or more rays to calculate its ambient light
> level correctly.

> Now this sounds like it would make the ray-tracer 200 times slower. This
> is true, except that the software takes advantage of the fact that
> ambient light levels change quite slowly (remember, shadows are calculated
> separately, so sharp shadow edges are not a problem). Therefore, these
> extra rays are sent out only once in a while (about 1 time in 50), then
> these calculated values are saved and reused for nearby pixels in the
> image when possible.

  From this we can see that the 200 sample rays are not shot for each pixel
but only once in a while. The rest is just interpolated from previous values.
  Now, how can you interpolate previous values if you don't have them? You
have previous values from the left and up of the image but not from the
right and specially from down.
  Just think about the first two pixels of the image. Ok, the ambient level
of the first one would be fully calculated. How about the second one? You
don't want to calculate its ambient level also but interpolate it. How can
you do that when you only have one previous sample?
  But we have a precalculated grid of ambient values so we can use them to
interpolate.
  This is why I think that the precalculation step is mandatory.

  I may be wrong, though.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

Niemenin Juha wrote:
> In povray.advanced-users Ron Parker <parkerr@fwi.com> wrote:
> : I think it would just run more slowly.  As far as I can tell, the
> : main purpose of the mosaic preview is to seed the cache with some 
> : good candidates for later lookups.  
> 
>   That may be right because you know a lot more about povray than I do, but
> I have the feeling that the precalculation part (which we see as "mosaic
> preview") is essential and that the radiosity method implemented by
> povray would not be possible without it.

I tried commenting out the mosaic preview. No, the mosaic preview 
is not essential - at least not for the "radiosity" code to run.
I ran both versions - with and without mosaic preview on a randomly
chosen scene. I cannot judge the quality of the picture yet. All I 
can say is that the .rca files (octrees with ambient illumination) 
do differ. But this is something what one could expect. :-)
The tracing times are (surprisingly?) almost the same.

>   Why do I think this way? Let's see the documentation:
<snip>

I rather believe the code. This is not to say that I'm the 
smartiest guy under the sun (I'm not), nor to criticise the 
quality of POV-Ray great documentation! What I mean is that 
reading the POV-Ray code is usually self-explanatory and 
instructive (well, the "radiosity" piece is an exception :-). 
No documentation, however good, can cover all the subtleties 
hidden in the code.

>   From this we can see that the 200 sample rays are not shot for each pixel
> but only once in a while. The rest is just interpolated from previous values.
>   Now, how can you interpolate previous values if you don't have them? You
> have previous values from the left and up of the image but not from the
> right and specially from down.
>   Just think about the first two pixels of the image. Ok, the ambient level
> of the first one would be fully calculated. How about the second one? You
> don't want to calculate its ambient level also but interpolate it. How can
> you do that when you only have one previous sample?
>   But we have a precalculated grid of ambient values so we can use them to
> interpolate.
>   This is why I think that the precalculation step is mandatory.
>   I may be wrong, though.

The interpolation is not dependent on any pixels, only on
previously computed ambient (illuminance) values stored in 
an octree (3D). When an ambient value for an intersection 
point is needed, the algorithm tries to reuse an already 
known value (or more ones) from the neighbourhood. If there 
is no known value in the neighbourhood, then the Monte Carlo 
shooting is performed.

The only reason for the mosaic preview seems to be a more
uniform initial distribution of the samples (as Ron says).

	y.

Post a reply to this message

Tomas Plachetka <pla### [at] uni-paderbornde> wrote in message
news:37E11CC9.C73E06DB@uni-paderborn.de...
> Ron Parker wrote:
> >
> > On Thu, 16 Sep 1999 17:00:31 +0200, Tomas Plachetka wrote:
> > >i wonder why is mosaic preview for "radiosity" important.
> >
> > Because the radiosity calculations require a well-distributed
> > set of sample points.  Mosaic preview goes over the entire scene,
> > so the points that are created as it samples the coarser grid
> > approximate the ones that will be needed when it computes at the
> > finer resolution.

    Which reminds me of something I thought of a while ago that ought to be
easy enough but I haven't done anything about it yet (my Copious Free Time
does not stretch to figuring out how to compile POV on BCPP5 right now).
With mosaic preview it ought to be possible to get more feeedback on how the
'trace is going.  In fact, even without, it ought to be possible...

    Right now WinPOV gives a speed indication that appears to be average
pixelhertz from start to right now. It would be nice also to have as command
line/menu options:

    (a) an instantaneous speedometer giving how many pixels were rendered in
the last second

    (b) an "ETR" (Estimated Time of Render) computed from the mosaic
preview. This could even be an interval estimate, based on the amount of
variation found so far [preferably nonparametric, as the distribution can be
very skewed.] A  trickier process would be accounting for anti-aliasing...
that would mean doing a small amount of AA at the specified setting ahead of
time, separate from the . One might want that to be separately switchable,
or assume that anybody using AA is up for a bit of a waitand won't mind an
extra ten seconds to get their forecast.

    (c) a *small* render-time-histogram window, open during render. Well, it
could be set large but one wouldn't usually want to. Some sort of log scale
so that speeds over many powers of 10 can be shown would be nice & easy to
implement.  It would, of course, share the mosaic pattern if that was in
use.

    It would be natural to combine the instantaneous & average speedometers,
and the ETR and elapsed time displays,into controls sharing scales.

    -Robert Dawson

Post a reply to this message

In article <37f4b0b2@news.povray.org>, "Robert Dawson"
<Rob### [at] stmarysca> wrote:
>    (b) an "ETR" (Estimated Time of Render) computed from the mosaic
>preview. This could even be an interval estimate, based on the amount of
>variation found so far [preferably nonparametric, as the distribution can be
>very skewed.] A  trickier process would be accounting for anti-aliasing...
>that would mean doing a small amount of AA at the specified setting ahead of
>time, separate from the . One might want that to be separately switchable,
>or assume that anybody using AA is up for a bit of a waitand won't mind an
>extra ten seconds to get their forecast.

I've found that pre-rendering an extremely tiny version gives a quite
accurate estimate of the time to trace the large version; when doing a
really long render, I'll usually render a 32x24 pixel version first, and
multiply the trace time by, say, 625 to estimate the amount of time the
800x600 version will take.

Jerry

Post a reply to this message

Robert Dawson wrote in message <37f4b0b2@news.povray.org>...
>
>Tomas Plachetka <pla### [at] uni-paderbornde> wrote in message
>news:37E11CC9.C73E06DB@uni-paderborn.de...
>    Which reminds me of something I thought of a while ago that ought to be
>easy enough but I haven't done anything about it yet (my Copious Free Time
>does not stretch to figuring out how to compile POV on BCPP5 right now).
>With mosaic preview it ought to be possible to get more feeedback on how
the
>'trace is going.  In fact, even without, it ought to be possible...
>
>    Right now WinPOV gives a speed indication that appears to be average
>pixelhertz from start to right now. It would be nice also to have as
command
>line/menu options:
>
>    (b) an "ETR" (Estimated Time of Render) computed from the mosaic
>preview. This could even be an interval estimate, based on the amount of
>variation found so far [preferably nonparametric, as the distribution can
be
>very skewed.] A  trickier process would be accounting for anti-aliasing...
>that would mean doing a small amount of AA at the specified setting ahead
of
>time, separate from the . One might want that to be separately switchable,
>or assume that anybody using AA is up for a bit of a waitand won't mind an
>extra ten seconds to get their forecast.


I'm working on a pseudorandom drawing order option for POV-Ray that will
trace pixels in random order, causing the image to 'develop' over the course
of the trace.  This will allow the user to accurately calculate the time
remaining from the percentage completed and the speed in %/second or
pixels/second.  The problem I'm running into is massively increased
rendering times when using antialiasing.

Mark

Post a reply to this message