Christian Froeschlin <chr### [at] chrfrde> wrote:
> I was trying to render a 3D puzzle by intersecting generic
> puzzle tiles with a desired target shape and found it rendered
> very slowly, even when intersecting the individual tiles before
> creating a union. The effect was curious as it turned out
>
> intersection
> {
>    object {A}
>    object {B}
>    bounded_by {B}
> }
>
> was much faster than
>
> intersection
> {
>    object {A}
>    object {B}
> }
>
> After some investigation I found that the problem was related to
> the number of puzzle tiles completely outside the target shape, so
> there seems to be some problem with empty intersections. I think
> these should be discarded or at least get a small bounding box,
> but they seem to be sticking around unbounded.
>

For any CSG, a bounding box is made as a single object that is known to contain
everything in the CSG.  So for an intersection operation, the bounding box will
be big enough to contain both (or all) your objects, regardless of how big the
remaining part is.  This is espescially an issue if one or mor objects doesn't
interesect, as it still gets included in the ray testing.

Fortunately in some cases, you have the benefit of knowing what your bounded
area should be and make a manual bounding box as you have done, and greatly
speed up rendering.  However, it is much more difficult to get POV to recognize
the need for a smaller bounding box.

This is even more extreme in difference operations as POV treats them as an
intersection of the first object with inverses of the subtracting objects.
Essentially the subtractiong objects are infinite in size.  (Try rendering a
plate with 10000 round holes in it for example.)

-tgq

Post a reply to this message