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

> That's how I used to do it: modelling the windows...  But that was 
> way too slow!

Slow rendering, or slow modelling?


> Maybe, but what about more complex shapes?
> Example: let's say I'm trying to model the birth of a planet.  A 
> planet with parts of it still hot and glowing, and parts of cold 
> stone.  I would use a pattern so I can easily give the glowing parts 
> a different texture.  With per-object post-processing, I really don't 
> know how I should do this...

Use eval_pattern() or eval_pigment() to place spheres or some other 
fast-redering shape(or glows, which won't even need a post_process 
filter) at the right places? Use an isosurface as the target 
object?(Probably too slow...)
Or just use media...


> But if it doesn't allow blending, I don't see why it would need more 
> memory than per-object based PP...? 

It would require a separate "post process map" for every filter 
controlled by a pigment, for one thing. And by removing the ability to 
blend between filters, you remove a most of the reason for having 
pigment controlled filters in the first place!


> One extra bit per pixel: 
> post-process this pixel or not.  Same as per-object PP.

Wrong. At bare minimum, it would require storing some sort of post 
process filter ID, to specify *which* filter to run. Probably a pointer, 
unless you want to limit the number of filters you can use. Much more 
than "one extra bit".

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