"Thorsten Froehlich" <nomail@nomail> wrote:
> Le_Forgeron <jgr### [at] freefr> wrote:
> > The final stage of that evolution would be a more complex code than
> > simply requesting a block size of 1.
> >
> > The problem with sampling is just that: samples. It won't protect you of
> > pathological scenes were the expensive spots are just near the sampling
> > position.
>
> No, but it is actually possible to do this: Instead of rendering blocks from
> left-top to bottom-right row by row, one can render a block in four
> subdivisions. Should a block stall it would then be possible to subdivide and
> split off the remaining subblocks. However, this requires more communication
> than just an atomic counter to find blocks because it requires a queue of such
> blocks (through that queue would need to be just threads*3 (or *15 for two
> allowed subdivsisions) in depth.
>
>
> Thorsten

Thanks for all your replies.
Indeed the algorithm and implementation would be a little more complex.

There is also another approach: the human approach and the reuse of the fixed
region render to allow ordered batch fixed region render + the remaining at the
end.

Nothing beats a pov-ray user for determining where the media/reflections are in
a static scene.

I am imagining that through the interface or through the command line, one would
supply render regions that would be treated in the selection order and the rest
of the scene through the selected block render pattern.

That could, however, be performed without any code modification through image
combination, And is probably already in the scope of things that are possible
through HttpPOV, but with some necessary overhead.

Rodrigo.

Post a reply to this message