In article <3e3c4faa@news.povray.org> , Wolfgang Wieser <wwi### [at] gmxde>  
wrote:

> The principle is to only render some pixels and calculate the color of
> other pixels using interpolation.
>
> I read some papers which indicate that (if done properly) speed can be
> increased by an order of magnitude while nearly not affecting quality
> (depending on the scene, of course). The stuff in question is called
> Directional Coherence Map.   [ Wow. Sounds cool, right? ;) ]

In simpler terms: It is a kind of adaptive antialiasing on pixel blocks.

> My first question is: Is somebody working on that for POVRay?
> Are there patches addressing this issue?

None that I know about.

> 1. (Mosaic) Preview:
>
> The current mosaic preview adds rendering time because the pixels
> rendered in the preview are not used in the final rendering.

Yes.  I know it is intentional, but I do not know why.

> 2.1. First, the povray code structure:
>
> Some easy modifications would have to made (better control when
> plot_pixel() actually calls XPutImage() by adding a plot_flush(x,y,w,h)
> function, etc).

I assume XPutImage is some platform specific function.  I am not sure where
you are going here or what exactly you are talking about.  Please clarify.

> Do_Cooperate().
>   Don't know when it should be called or if it can cope with the
>   situation. Could someone enlighten me on POVMS? It seems to deal
>   with "messages", "queues" and "objects" but I have no clue.

POVMS is a way to abstract the different output streams and render control
in a way more suitable for GUI platforms.  It has nothing to do with the
actual ray-tracing core.  In future releases of the POV-Ray 3.5.x the other
means of handling output will be gradually removed and replaced by a
POVMS-only system with default code for command-line versions.

> Current_Line_Number and Current_Line.
>   These are global vars and the latter is hard to grep because of
>   the similarity with the first one. I don't use them as I use my
>   own line buffer (9 lines).

Some code depends on them.  So be careful, things may fail in unexpected
ways.

> Field_Render_Flag:
>   Seems to be some strange thing skipping odd or even lines.
>   Probably not 100% incompatible but I currently see no reason for
>   supporting it. Maybe anyone has arguments [explain why useful].

It is an easy way to create animations for interlaced display devices (aka
televisions).

> MOST CRITICAL is the detection if there is more than one object
> inside the 8x8 block. A routine doing a quick test on that would
> come quite handy. Problems may occur with partial reflection or
> interior (ior) etc. but returning (false) positives for some parts
> of the scene is acceptable. Unfortunately, I am not familiar with
> the innermost workings of the POVRay "engine" so help is appreciated.

The object found is always on the intersection stack, so you can use that.

    Thorsten

Post a reply to this message