|
![](/i/fill.gif) |
In article <3a0a970e@news.povray.org>, "Zeger Knaepen"
<zeg### [at] student kuleuven ac be> 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] 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) |