> It can only (1) find individual points on the surface of any single
> primitive, and then (2) check whether any such individual point is
> inside a given set of other primitives.

Indeed, but given those 2 facts, it seems that there should be some function or
method for implementing them to determine where the intersection points are.
-x is inside, and +x is outside, so somewhere in between is the intersection
point.  I suppose I could asymptotically approach from either end with a loop
and the trace and inside functions, but since it seems that POV-Ray is _already
doing this when it parses/renders a scene...

In the case of the loop, what is the minimum recommended dx of the increment?
I'd rather not divide the distance between 2 points and test 10,000
subdivisions, if 1000 would do the job.  Similarly, the mathematically infinite
number of points between the inside and outside starting points gets bumped up
to another order of infinity when I'd then work around the axis of the
intersecting circles.
Clearly, I could do 2 or 3 tests, and then some more math to get an idea of the
plane where the circle of intersection lies, but that breaks down when using
other shaped primitives intersecting at angles, which aren't intersecting, which
are coincident, etc.

I guess I was just thinking that given the results of intersection, merge,
difference, bounding boxes, minextent and maxextent, that it's reinventing the
wheel and doing an awful lot of extra work to redo what POV-Ray already seems to
do in order to properly render the scene.

I mean, it seems like it should be a trivial task to place a disk, or align a
plane, or draw a skinny torus around exactly where two spheres intersect in a
scene.  But I must admit that I'm lost as to a fast and efficient means of doing
this.  Expand that problem to "drawing an outline" around the intersection of
any given arbitrary CSG primitives, and it seems like a tough nut to crack all
by my lonesome.
Granted there may be a clever way to implement incidental results of colors or
textures or normals to _visualize_ those points, but the user is still left with
no usable information about those points from which to build upon.

Thanks for your time and patience.

Post a reply to this message