Ron Parker wrote in message <36e7f128.0@news.povray.org>...
>On Thu, 11 Mar 1999 22:03:44 +0800, Gordon <gbe### [at] birdcameroncomau>
wrote:
>>I've found that doing what Ken has done usually works. You can usually use
>>differences to chop bits off meshes. If you try to reverse the difference,
>>take the mesh from the sphere, it doesn't quite work though. The mesh
>>appears as an infinitely thin surface (which makes sense I guess) and
>>appears to behave as such in CSGs.
>
>Are you sure?  It seems it should work the other way, since meshes
>are defined to have no inside.  Difference is just intersection with
>an inverse, so I'll use intersection to explain:
>
>What intersection does is find all ray-object intersections with each
>component object, then filter the results so only the intersections
>that are inside all other component objects are returned.  Since
>nothing is inside a mesh, all intersections with non-mesh objects
>should be ignored.  Intersections with the mesh object would survive.
>The result seems like it would be quite unlike an intersection.
>
>difference{sphere{...}mesh{...}} would return all intersections
>with the sphere, plus whatever mesh surfaces fall inside the sphere.
>For opaque objects, the result should be a sphere.
>
>difference{mesh{...}sphere{...}} would return whatever intersections
>with the mesh fall outside the sphere, but no intersections with the
>sphere.  The result would be a hole in your mesh, not a spherical
>cutout.

A hole in the mesh is what I mean't. I was considering the mesh to be a
surface not a solid. So the difference{mesh{}sphere{}} does let me "trim" a
mesh which is often useful. I agree completely that POVRay doesn't currently
deal with meshes as solid objects in any sensible way.

>
>>On the topic in general, I would think the method of using the normals to
>>determine the "inside" was more useful as this way open meshes could also
be
>>used. I still have a little trouble picturing how this would work exactly
>>though!
>
>Quite simply, it wouldn't really.  The "inside" of such a mesh would not
>be well-defined, as whether a given point were inside or outside would
>depend on which triangle it hit when testing.  Some points would always
>be inside, of course, and some outside, but for anything but a simple flat
>mesh you'd have lots of points that were undefined.
>

From the programmers point of view, I agree. What I mean't was that from a
modellers point of view, this may be more useful. Though if it can't be
implemented, I guess the point is moot.

Regards
Gordon

Post a reply to this message