|
 |
In article <6dS### [at] econym demon co uk>, Mike Williams
<mik### [at] econym demon co uk> wrote:
> Wasn't it Simen Kvaal who wrote:
> >You seem to know these built-in-functions well!
>
> It didn't start out that way. It took a lot of hard work to obtain all
> that information.
I'll bet! I personally avoid using the built-in functions(the syntax is
awful, and I highly doubt it would survive if these functions are
included in the official version), but this is very useful information
for those who do use them.
> A subtle, and not quite intentional, side effect of the presence of my
> container surfaces is that they clobber the parts where the surface runs
> round the contained_by sphere. Because my transparent container surfaces
> are exactly coincident with the contained_by surface, only one of them
> gets rendered, and that happens to be the transparent surface.
I suggest something like "scale 1.001" to remedy this...or maybe "scale
0.999", so those parts stand out as container-intersections. This could
make debugging functions easier, since you could immediately see that
the problem is a container intersecting with the surface.
> An alternative solution is to add the keyword "open" just after the
> contained_by statement.
Note that this solution doesn't help if your object contains media or is
used in CSG...though "open inverse" should work. I would suggest just
using a negative threshold, or declaring the function(a good practice
anyway) and using it's negative("-FuncName(x,y,z)").
Or use "sign -1". :-)
--
Christopher James Huff - Personal e-mail: chr### [at] yahoo com
TAG(Technical Assistance Group) e-mail: chr### [at] tag povray org
Personal Web page: http://chrishuff.dhs.org/
TAG Web page: http://tag.povray.org/
Post a reply to this message
|
 |