Glen Berry <7no### [at] ezwvcom> wrote in message
<9QoXOX81ZhACXmHd2iIS2wGK67Tm@4ax.com>...
>On 8 May 2000 09:44:15 -0400, ron### [at] povrayorg (Ron Parker)
>wrote:
>
>>I believe a fundamental part of its function is that it
>>generates pixels in completely random order.
>
>Would this be completely impossible to meld with POV-Ray? I know it
>would certainly be a complication, but it still might be possible. I
>guess the main questions are whether this technique is so much better
>in either quality or speed to make it worth the extra trouble.


I've been working on getting POV to render images in random order, and the
problems I've run into are:

1) Antialiasing method 1:  Random order means that the program can't compare
the color of the current pixel to the colors of the neighboring pixels when
it is rendered.  The solution I'm going to use is to do an antialiasing pass
through the image after the first rendering pass is complete.

2) Antialiasing method 2:  Random render order means it will be difficult to
re-use the data from previously-rendered pixels, slowing rendering down.

3) Saving in any of the compressed file formats:  All of the supported
compressed formats expect pixel data to be provided in top-to-bottom,
left-to-right order.  The workaround I plan to use is to save the file in
uncompressed TGA, then compress the file into the final format once
rendering is completed.

4) Continued tracing:  POV normally determines where to continue rendering
from by finding the first line in the image file that ends with a black
pixel.  With a random rendering order, many lines will end with black
pixels.  My solution is to record which pixel was rendered last in the image
file.  This pixel is then used to determine which pixel to render next.

Mark

Post a reply to this message