POV-Ray : Newsgroups : povray.programming : bounding boxes problem and solution : bounding boxes problem and solution Server Time
3 Jul 2024 05:37:57 EDT (-0400)
  bounding boxes problem and solution  
From: Andrew Clinton
Date: 30 Nov 2003 18:10:00
Message: <web.3fca78382917df13611ee4e60@news.povray.org>
I've been looking through the code that is used by POV-Ray to create
bounding boxes for objects, and have found a fairly serious performance
issue for bounding box creation with csg objects.  The problem can be
observed with this very simple scene:

------

camera {
 location <0,0,-4>
 look_at 0
}
light_source {
 <-10,10,-10>
 color rgb 1
}
intersection {
 sphere {
  <0.5,0,0>,1
 }
 sphere {
  <-0.5,0,0>,1
 }
 rotate z*45
 rotate z*-45
 pigment { color rgb 1 }
}

--------

What I observe is that when the scene is rendered with the transformations
on the intersection{}, there is a increase in the number of rays tested
against the intersection of about 4x, even though the scene renders exactly
the same way as without the transformations.

The problem results from the fact that bounding boxes for csg objects are
expanded independently for every transformation that is applied to the csg
while parsing, without considering the effect on the underlying objects.

I think that one way this could be fixed is by separating the bounding box
creation code from parsing.  This could be done by removing all the code
from parse.cpp that computes object bounding boxes, removing all calls to
Recompute_BBox from per-object transformation methods, and removing all
calls to Compute_*_BBox from per-object transformation methods.  Then, the
Compute_BBox method could be made a standard method on all objects, and a
new routine could be made that iterates through all the objects and
produces bounding boxes using the general Compute_BBox method.  This could
be done at some time later than parsing.  This would solve the problem
above, because the CSG bounding box compute method could correctly take
into account the bounding boxes of its children AFTER all transformations
have been applied.  It would also clean up the code.

I'm wondering if anyone has input on this solution?  I would like to
implement something like this in my patch.  If there is some reason that it
will not work as described let me know.

Andrew


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.