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.
This could be done one line at a time, or maybe with a fixed refresh rate,
or maybe one line at a time with a minimum/maximum refresh rate. Another
possibility would be the option to change the block shape, so I could use
really long and thin blocks and the image would (sort of) be drawn from the
top down like in 3.6.

Of course, this isn't so important for a final render, so maybe it's not
something that needs to be considered until mosaic preview is reimplemented.
I just wanted to mention that this is a minor frustration for me (and may be
for other users).

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

Post a reply to this message

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

-- 

                                                          - Warp

Post a reply to this message

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

> 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

Slime <fak### [at] emailaddress> wrote:
> Changing block size is a bad idea. Got it. =)

  Actually I was not talking about block sizes at all. I think Thorsten
misunderstood me (or I misunderstood someone).

  What I was talking about was that if POV-Ray started to show on the
preview window each line of each block immediately when they are
calculated, how much overhead this would cause to fast renders. (This
would be quite relevant if you are rendering a 100000-frame animation
where each frame takes 2 seconds to render.)

  Block sizes have nothing to do with this. Determining a good rendering
block size depends on other things.
  The larger the block size, the smaller the overhead caused by
antialiasing, but the higher the probability of an uneven render
(IOW the higher the risk that threads will start to idle at the end
of the render while the last blocks are still being rendered).
  And the opposite: Smaller block sizes increase the probability of
a very well-balanced render but increase the overhead introduced by
antialiasing (and secondarily other things).

-- 
                                                          - Warp

Post a reply to this message

>   Actually I was not talking about block sizes at all. I think Thorsten
> misunderstood me (or I misunderstood someone).


Yeah, I understood what you meant. But since I had mentioned changing block
sizes in my original post, Thorsten's first paragraph was still helpful (to
me).

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

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Slime <fak### [at] emailaddress> wrote:
> > Changing block size is a bad idea. Got it. =)
>
>   Actually I was not talking about block sizes at all. I think Thorsten
> misunderstood me (or I misunderstood someone).
>
>   What I was talking about was that if POV-Ray started to show on the
> preview window each line of each block immediately when they are
> calculated, how much overhead this would cause to fast renders. (This
> would be quite relevant if you are rendering a 100000-frame animation
> where each frame takes 2 seconds to render.)

This makes a lot of sense - I myself have done things like this sometimes
just to see how it runs.

>   Block sizes have nothing to do with this. Determining a good rendering
> block size depends on other things.
>   The larger the block size, the smaller the overhead caused by
> antialiasing, but the higher the probability of an uneven render
> (IOW the higher the risk that threads will start to idle at the end
> of the render while the last blocks are still being rendered).
>   And the opposite: Smaller block sizes increase the probability of
> a very well-balanced render but increase the overhead introduced by
> antialiasing (and secondarily other things).

What prevents you from using different block sizes for different things?
For example, render with a 4x4 block size to ensure evenness (although this
does nothing for overhead...), and then group 16 of those 4x4 blocks
together into a bigger block when calculating antialiasing so that
antialiasing is calculated with 16x16 blocks.

Although that might be getting unnecessarily complex...  another option
might be a 'simple' block mode and a 'complex' block mode - the former
divides the image into large blocks and tries to reduce overhead, the
latter is for rendering complex scenes that take a while and run the risk
of uneven renders and/or have complex needs (e.g. sophisticated AA, or the
different-block-size idea I presented above).  That said, 'simple' and
'complex' are subjective...

Post a reply to this message

Mike C wrote:
> What prevents you from using different block sizes for different things?
> For example, render with a 4x4 block size to ensure evenness (although this
> does nothing for overhead...), and then group 16 of those 4x4 blocks
> together into a bigger block when calculating antialiasing so that
> antialiasing is calculated with 16x16 blocks.

You have a misconceptions how antialiasing works. It is not a process that 
is independent of tracing pixels. As such, what you propose does not make sense.

	Thorsten

Post a reply to this message