> Is this an example of Isosurface Image Noise Problem?


No; the problem you're seeing is caused by merging the isosurfaces. In
places where two isosurfaces in the merge{} are very close together, the
surface disappears. My guess is that the ray is intersecting one of them,
but the intersection is slightly innacurate, so it thinks it's inside the
other one (and hence determines there is no surface at that position); then
the ray continues and never intersects the other one since it was too close
to the first intersection. So a surface is never detected. A similar thing
is happening with the difference with the poly object.

The problem can be *almost* eliminated by reducing accuracy to something
more like .00000001.

However, I think your best solution here is to rethink your code entirely.
You say you require the usage of isosurfaces. Why is that? Are you sure it's
necessary? And if it *is* necessary, then isn't the usage of CSG with these
isosurfaces going to be just as much of a problem as using predefined shapes
would have been in the first place? (I mean, what does the usage of
isosurfaces do for you when your outmost object is a difference{} anyway?)

If isosurfaces are an absolute must, then I would expect that CSG isn't an
option for the same reason, whatever that reason may be. In this case, I
strongly suggest using the IsoCSG macros provided at
http://www-public.tu-bs.de:8080/~y0013390/pov/ic/ . Then your entire object
will be an isosurface function, and you can do whatever you want with it
(apply deformations, for instance). Also, the problem you're experiencing
here won't exist anymore.

If you're not positive that isosurfaces are necessary, then tell us your
reasoning and we'll help you decide.

Note that the poly{} object could probably be replaced with a torus.

As a final note, it would be wise to add the all_intersections keyword when
using transparency with an isosurface.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message