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