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


Changing block size is a bad idea. Got it. =)

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

What if you used the maximum of one update per second in combination with a
maximum of one update per line? This would ensure that a minimum of 64
pixels were drawn at once (avoiding sending an entire image 2 pixels at a
time), and in fast scenes would send them in larger chunks (because of the
once-per-second limit). You could even try once every 2 or 4 lines since
blocks are so thin.

In combination with this, if we wanted to get fancy, there could also be a
maximum update interval of, say, 30 or 60 seconds, so that if the render
gets horribly stuck right when it hits the edge of a certain object, you
could notice that and consider, say, changing the object's texture.

While I was rendering my image last night, one block got stuck and didn't
display for about 20 minutes (other blocks were taking under a minute). I
almost stopped the render, thinking something must have frozen, but
apparently there was just something very slow in that spot of the image. I
just feel uninformed about how my image is rendering.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message