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

On Sat, 2 Oct 1999 00:29:45 -0400, "Mark Wagner"
<mar### [at] gtenet> wrote:

>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

Several months ago I suggested an alternate way of doing anti-aliasing
but no one seemed to like it enough to code it :) The idea is to have
the supersampling pass _after_ the image has been rendered. Another
option is to anti-alias an already rendered image (provided you have
the code, of course :) ). So if you have a powerful computer you can
render it with higher anti-aliasing settings or even re-render at a
higher resolution with a great save on render time. I think this would
be a nice feature to add to POV. Do you?



Peter Popov
ICQ: 15002700

Post a reply to this message

Peter Popov wrote in message ...
>On Sat, 2 Oct 1999 00:29:45 -0400, "Mark Wagner"
><mar### [at] gtenet> wrote:
>
>>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
>
>Several months ago I suggested an alternate way of doing anti-aliasing
>but no one seemed to like it enough to code it :) The idea is to have
>the supersampling pass _after_ the image has been rendered. Another
>option is to anti-alias an already rendered image (provided you have
>the code, of course :) ). So if you have a powerful computer you can
>render it with higher anti-aliasing settings or even re-render at a
>higher resolution with a great save on render time. I think this would
>be a nice feature to add to POV. Do you?


Sounds interesting.  I'll add that to my list of things to work on.

Mark

Post a reply to this message

In povray.advanced-users Peter Popov <peter.popov@usa.net> wrote:
: Several months ago I suggested an alternate way of doing anti-aliasing
: but no one seemed to like it enough to code it :) The idea is to have
: the supersampling pass _after_ the image has been rendered.

  This would mean that you have to keep the entire image in memory?

  Randomizing the order of tracing needs keeping an image-sized buffer
of coordinates in memory anyways. The fastest way to trace in random order
is to have a buffer of coordinates, shuffle them (ie. change the first one
with a random one, then the second one with a random one and so on) and use
them to get the next pixel coordinate to trace.
  Since each coordinate needs at least 2x16 bits (supposing that we don't
want to support images greater than 65536x65536 pixels), for an image
sized, let's say 1024x768 we would need 1024x768x4 bytes = 3 Megabytes.
Since we also have to keep the entire image on memory because we can't
save it in parts, it would require 1024x768x3 bytes = 2.25 Megabytes, ie.
a total of 5.25 Megabytes is required for the process. If we are outputting
to a PNG with 16 bits per color component and alpha channel (ie. 8 bytes
per pixel), things get worse: It would require 1024x768x8 bytes = 6 Megabytes
for the image; the total would then be 9 Megabytes.

  Quite memory consuming, I think. Also accessing 9 Megabytes of memory at
random is slow...

-- 
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

In article <37f865a9@news.povray.org> , Nieminen Juha <war### [at] cctutfi>  
wrote:

>   Since each coordinate needs at least 2x16 bits (supposing that we don't
> want to support images greater than 65536x65536 pixels), for an image
> sized, let's say 1024x768 we would need 1024x768x4 bytes = 3 Megabytes.

There are useful pseudo-random number generators out there that don't repeat
numbers until all numbers in the set of produced numbers have been generated
once (sorry, no idea how to put that in nice, short English).
So you wouldn't need to store coordinates. And you can even go with a small
pregenerated (built-in) set of random numbers, say 256 and then repeat that
pattern. It would still be "random" enough. Of course a bitmap to store
which pixels have been rendered can also be used.  No need for 3 MB, just
use a better algorithm :-)

> Quite memory consuming, I think. Also accessing 9 Megabytes of memory at
> random is slow...

Compared to a scene that consumes 20 MB and whose data is accessed very
frequently?  After all there would be only one memory access (write) per
pixel, not that much after all the accesses needed to generate that pixel!
And it would be stored in a row buffer anyway (also that might still be in
cache).


     Thorsten


____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

Thorsten Froehlich wrote in message <37f8d332@news.povray.org>...
>In article <37f865a9@news.povray.org> , Nieminen Juha <war### [at] cctutfi>
>wrote:
>
>>   Since each coordinate needs at least 2x16 bits (supposing that we don't
>> want to support images greater than 65536x65536 pixels), for an image
>> sized, let's say 1024x768 we would need 1024x768x4 bytes = 3 Megabytes.
>
>There are useful pseudo-random number generators out there that don't
repeat
>numbers until all numbers in the set of produced numbers have been
generated
>once (sorry, no idea how to put that in nice, short English).
>So you wouldn't need to store coordinates. And you can even go with a small
>pregenerated (built-in) set of random numbers, say 256 and then repeat that
>pattern. It would still be "random" enough. Of course a bitmap to store
>which pixels have been rendered can also be used.  No need for 3 MB, just
>use a better algorithm :-)


An appropriate random number generator should do the job.

>> Quite memory consuming, I think. Also accessing 9 Megabytes of memory at
>> random is slow...
>

POV-Win, at least, already appears to store the rendered image in memory, so
this wouldn't take much additional memory.  Also, it is possible, if slow,
to write each pixel to disk as it is rendered for most file formats.  If
necessary, the file can be saved uncompressed and then POV can compress it
after the scene has been rendered.

Mark

Post a reply to this message