On Tue, 22 Jul 2003 17:27:07 +0200, "Rune" <run### [at] runevisioncom> 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.

There is no stright connection between image_size and effects now. But since
find_edges effect in 'old' MegaPOV measure radius in pixels I have to consider
it if I want to deliver macros for backward compatibility. But macro which
duplicates old behaviour is just wrapper for another more flexible macro which
has more settings than old effect.

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

That's the idea of one of optimizations I plan. If at least one post_process
is in a script and non of predefined channels is used it means that whole
post_process base on non-normal-rendering data so no need for rendering at
all.

> And wouldn't then the rendering time be approximately the same?

It wouldn't. To calculate one pixel in find edges process you need data about
colour, depth, received normal of neighbouring. Depending on radius of edges
more samples is required. In 'old' post_processing and in geting values fron
rendering in 'new' post_processing there is image_width*image_height possible
values of samples because number of samples is limited. Using 'new'
post_processing with camera_view pigment gives much more accurate effect
becuse every sampling of camera_view cause sending new ray. Camera_view is not
precalculated into image_map. It is calculated online per request without
pixelization.

> > 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! :(

I know. But if you are comparing this time to times in 'old' postprocessing
time than you are doing wrong becuase it is like comparing rendering time of
isosurface in 3.5 with rendering of teapot in povray 2.0. The main slowdown is
from many rays sended for find_edges subview and in 'old' MegaPOV there wasn't
neither camera_view nor subview possibility. Moreover applying that averaging
multiply postprocessing time by more than 4 but this averaging was added only
to introduce little more smoothnes.

I plan some optimizations to make it faster and more efficient but I do not
know if they will be ready before release of MegaPOV 1.1. Perhaps they will be
in some future versions after notes of users. There is also possibility that
users can find more flexible versions of my macros so they make it better. I
just reused algorithms from old MegaPOV postproc.c code.

If windows binary could contain JIT compiler to native code for functions as
it is (afaik) done for Macintoshes then it could be also faster.

Another interesting thing is that the same set of macros delivers pigments
with equivalent of effects so you can for example apply find_edges effect to
picture on the wall within scene.

ABX

Post a reply to this message