> How do you think POV-Ray would calculate the bounding of an intersection? 
> If the primary objects are big, chances are the bounding object for the 
> intersection will be a lot bigger than it should be.

The bounding of the intersection is the intersection of the
bounding boxes. So for example if you have two spheres...
#declare A = sphere {<0,0,0>,1};
#declare B = sphere {<1.99,0,0>,1};
Then the bounding of the intersection would be
box {<0.99,-1,-1>,<1,1,1>} which has a volume of
0.04, compared to the bounding of the sphere which
has a volume of 8, and the bounding of the union
which is 15.96, the volume of the intersection is
(pi/12)*(4*R+d)*(2R-d)^2 =
(0.261)*(5.99)*(0.0001) = 0.000157
so the ratio of the intersection is 0.00157/0.04 = 0.39%
the accuracy at 1000 tests will be (1-(0.9961^1000)) ~
98%, but at 2000 tests it will be 99.95% accurate.

> Well, it's *random*. Given a sphere (which takes more than half its 
> bounding box), it's absolutely possible it will hit everywhere *but* the 
> sphere :)

The worst case scenario for this macro is long narrow cylinders that
aren't parallel to any axis, in those cases the bounding fails to conform
well to the object. For normal objects the chance of this failing is like
the chance of flipping a coin a thousand times and having it always
come up tails.

> But if you make it clear that your code isn't deterministic, seems good 
> enough.

Since the random generator in POV is deterministic, this will fail
in deterministic ways... it won't introduce jittered movment to an
animation for example, but yeah, it can fail to detect collisions if
the rez used is low. Something like 30000 is enough to detect hard
cases, but it's quite slow for that... I was thinking about re-writing
it to use trace, that might improve the accuracy a bit.

Post a reply to this message