Warp wrote:
> Slime <fak### [at] emailaddress> wrote:
> 
>>I find that as I work with 3.7 I miss being able to see my image appear one
>>line at a time. It would be nice if blocks were displayed as they rendered.
> 
>   How much overhead would this add to the rendering (especially when
> rendering long animations where each frame is very quick to render)?

Well, for anti-aliasing this is really easy to answer (assuming AA is needed 
for all pixels):
Border pixels need to be sampled in each block.  As the rectangle with the 
shortest border is a square, you can compute the additional work needed by 
computing the border length.  For a 32*32 rectangle (1024 pixels) the border 
length is 128, for a 128*8 rectangle (1024 pixels) the border length is 272. 
  For AA method 1 an additional half the border length number of pixels need 
to be sampled, thus for a 32*32 block 64 additional pixels are traced while 
for a 128*8 block 136 additional pixels are traced.  So the overhead just 
for AA sampling if non-square blocks are used will be 6.62% for 1024 pixel 
blocks.  For 16*16 vs 64*4 pixel blocks the difference will be 12.5%. 
Further, for line by line tracing exactly twice as many samples will be taken.

As far as communication overhead, it depends a lot on the system. The data 
overhead is only about 40 or so bytes per message.  One could send blocks 
only once per second (assuming anything changed), but this would increase 
the load on the preview drawing thread, taking away resources from the 
render threads.  Based on the experience from the Mac version (which ran 
rendering in a single thread and preview drawing in another thread since 
POV-Ray 3.5.1), the average slowdown was two to four minutes per megapixel 
of image if drawing every pixel individually (and not transmitting it 
again).   Collecting pixels reduced the slowdown considerably for some 
scenes, but for example for a scene rendered at 320*240 (a typical preview 
size I suppose), at 76K pixels, taking ten minutes total, and sending pixels 
only every second, on average only two pixels are send per second, hence 
still causing an overhead of about 20 to 30 seconds.

In short, seeing each pixels may well work for complex scenes with one hour 
or longer render times per megapixel, but it doesn't help for fast previews 
of less complex scenes.

	Thorsten

Post a reply to this message