Can anyone tell me if this is still the case?

From (bottom of page):
http://www.povray.org/documentation/view/3.6.0/184/

But this automatic bounding is not perfect. There are situations where a perfect
automatic bounding is very hard to calculate. One situation is the difference
and the intersection CSG operations. POV-Ray does what it can, but sometimes it
makes a pretty poor job. This can be specially seen when the resulting CSG
object is very small compared to the CSG member objects. For example:
intersection
{ sphere { <-1000,0,0>,1001 }
  sphere { <1000,0,0>,1001 }
}
(This is the same as making a difference with the second sphere inversed)
In this example the member objects extend from <-2001,-1001,-1001> to
<2001,1001,1001> although the resulting CSG object is a pretty small lens-shaped
object which is only 2 units wide in the x direction and perhaps 10 or 20 or
something wide in the y and z directions. As you can see, it is very difficult
to calculate the actual dimensions of the object (but not impossible).
In this type of cases POV-Ray makes a huge bounding box which is useless. You
should bound this kind of objects by hand (specially when the it has lots of
member objects). This can be done with the bounded_by keyword.

---------------------------------------------

This didn't seem to me to be a factual representation - I believe there are some
straightforward algorithms for determining the bounding box of the intersection
for any two overlapping axis-aligned bounding boxes (AABB).
Am I wrong?

I worked out some (messy but fully functional) code to do this, and it appears
to handle the few typical cases that I tested it with.

The only tricky part was getting it handle cases outside of Quadrant I, but I
just implemented a faux-translation of the union {} of the two bounding boxes to
place its min_extent at the origin. (I add in that correction vector for the
intermediate calculations)

If this is still an issue, are there certain cases that are especially
problematic for certain CSG operations?
Could we develop this into a small, fast part of the POV-Ray source code?


Thanks

Post a reply to this message