|
![](/i/fill.gif) |
In article <3a08f6fe@news.povray.org>, "Zeger Knaepen"
<zeg### [at] student kuleuven ac be> 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] mac com, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tag povray org, http://tag.povray.org/
<><
Post a reply to this message
|
![](/i/fill.gif) |