ABX wrote:
>> The old post-process feature did not support
>> antialiasing. Does this new approach support it?
>
> Yes and no. Engine requests the same number of
> pixels as needed for image.

Hmm. Is there any specific reason that you can not set the width and
height individually for each filter? It seems from your function example
that the filters are not really dependent on having a specific
resolution... But maybe I don't fully understand the concept yet.

> You can use output of normal rendering which has
> disadventage of pixelization but is fast because
> it is just reading of floats from array. But you
> can also use mentioned camera_view feature which
> means that every sample requested cause new
> sended ray. In this case postprocessing time
> increases.

Hmm. Wouldn't it then be possible to use the camera_view *instead* of
the normal rendering? That is, to skip the normal rendering step
completely, but get the same result by getting the image through the
camera_view? And wouldn't then the rendering time be approximately the
same?

> Here is summary statistic from presented process:
> <snip>

Hmm, only 25 minutes for tracing but almost 13 hours for post
processing - this *is* pretty slow! :(

Rune
--
3D images and anims, include files, tutorials and more:
rune|vision:  http://runevision.com (updated Oct 19)
POV-Ray Ring: http://webring.povray.co.uk

Post a reply to this message