In article <3a0dc3fd$1@news.povray.org>, "Zeger Knaepen" 
<zeg### [at] yahoocom> wrote:

> > Slow rendering, or slow modelling?
> Uhm...
> Both!

Hmm, ok...


> I didn't say it would be impossible to do so, I said it would be a lot
> easier to have an effect_map.

Ok, I agree with you there...


> Aand per-object based PP wouldn't need that?

No, it wouldn't. All it would need is one "object map" to specify which 
object is hit first for each pixel. You would tell the filter which 
objects it needs to filter, and that's it.
For a post_process_map, it would have to store which filters are being 
blended between as well as the "amount" of each. About as much as 
somewhere between 1 and 2 object maps(depending on the area of the image 
being blended) in addition to another depth map for every post_process 
map.


> > blend between filters, you remove a most of the reason for having
> > pigment controlled filters in the first place!
>  I know, but I thought you said blending the PP would be too difficult.

It would require a lot of work and would chew up tons of memory, but it 
is possible. It would be a bad idea to partially implement a feature in 
such a way that it will completely change when it is finished. The basic 
idea of *_maps is that they blend between things...people will expect 
post_process_maps to behave the same. And besides, where would you draw 
the line between two filters or between filter and no-filter? Halfway 
between two different filters, going from each filter entry to the 
next...


> OK, but that's a choice every user can make for themself...  I mean: 
> if you include the option to do a global PP, it wouldn't always need 
> this amount of memory, only if the user wants it to.  Or am I wrong 
> again?

No, you are right, it would only use the memory if a post_process_map 
was used.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message