In article <3a08f6fe@news.povray.org>, "Zeger Knaepen" 
<zeg### [at] studentkuleuvenacbe> wrote:

> It doesn't always need to make sense to be useful!

But it *does* have to make sense in order for someone to implement it!
I suppose you could "branch" the post process stage into several 
results, one for each filter, and interpolate between them, but this 
would be very memory intensive.


> > is done, I think controlling it with the pigment would be a very bad
> > idea...some kind of post_process_map texture element would be better.
> Maybe...  Doesn't really matter where you put it, I think...


> No, that's not what I was trying to say :-)
> Instead of telling POV to post-process all rgb <1,.5,.2> areas for 
> instance, 'just' add a color-component, like rgbp <1,.5,.2,1>.

Oh, I see what you mean. Not a color, just another channel. This sounds 
similar to the post_process_map I was thinking of.


> > Object controlled filters would be easier to use, lower in memory
> > use(you only need one object map instead of a bunch of alpha maps),
> > easier to code, and just make more sense.
> 
> I don't think it would make more sense.  If you want to save memory,

Object controlled filters would use less memory.


> or don't really like the in-between values, you can always say that a 
> post_process_map value of 0 would be no post_processing, and a value 
> different of 0 would be full post_processing.
> But doing it object-controlled would be a lot less flexible and 
> useful than per-color or per-pigment pp.
> Example: say I'm modelling a big spaceship.  Instead of modelling 
> each window, I like to fake them with texture_maps.  To make things 
> look more realistic, each lit window should be glowing a bit.  With 
> per-object pp, I should really model the windows, which would render 
> a lot slower and use more memory than texture_maps, but it would be 
> no problem with per-pigment pp.

I'd say you should use an object controlled post process and model the 
windows anyway. Actually, a simple transparent box at each window 
position would work, you wouldn't have to model anything, just make a 
"signal object" in the right places to tell the post_process filter to 
work.

A texture controlled filter wouldn't be cheap in memory, and if it 
allows "blending" of filters, it would really eat memory and be 
difficult to code.

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