Wasn't it Carl Hoff who wrote:
>Other couple questions that are related to this topic.  Here is a piece of
>code from the CSG that I'm trying to optimize.
>
>  #declare rear_tire = difference {
>    sphere {<0, 85, 0>, 85 scale <1,1,.2>}
>    union {
>      cone {<0, 85, 20>, 50 <0, 85, -20>, 60}
>      cone {<0, 85, -20>, 50 <0, 85, 20>, 60}
>    }
>    bounded_by { box {<-85,0, -13>, <85,170, 13>} }
>  }
>
>I can tell by viewing the bounding slabs with the +UD option that this has a
>tighter bounding slab then it would if I didn't specify a bounded_by box.
>
>First question: Why?  I did not use the -UR option and the documentation
>says "To turn off the automatic removal of manual bounds you should specify
>Remove_Bounds=off or use -UR. The default is Remove_Bounds=on."  Isn't the
>above a manual bound?

The automatic bounding slab is big enough to contain the sphere. POV
isn't smart enough to work out beforehand how the difference reduces the
size of the bounding slab, so it has to use the size of the object
you're differencing from.

If you print out the size of the automatic bounding slab by using

#include "strings.inc"
#debug concat( VStr(min_extent(rear_tire)), "  ",         
               VStr(max_extent(rear_tire)), "\n")

you'll get <-85,0,-17>, <85,170,17>. Observe that 17 is 85 scaled by .2.


>Second question:  In terms of optimization does it make any difference if
>the above union is replaced with a merge?  I also just now spotted this line
>in the documentation "The CSG difference operation takes the intersection
>between the first object and the inverse of all subsequent objects."  I just
>verified that the above union statement isn't even needed. Would removing it
>cause it to render faster?  Its a little easier for me to follow the code if
>I leave it in there.

It's easy to run the comparison and observe the statistics in the
message pane. The stats are identical for union and merge, so that makes
no difference. Removing the union entirely reduces the number of "CSG
Intersection" tests and leaves all the other stats the same, so it would
render fractionally faster.

Other things that you might have considered are adding a bounding box
for the union:

  #declare rear_tire = difference {
    sphere {<0, 85, 0>, 85 scale <1,1,.2>}
    union {
      cone {<0, 85, 20>, 50 <0, 85, -20>, 60}
      cone {<0, 85, -20>, 50 <0, 85, 20>, 60}
      bounded_by {box {<-60,35,-13><60,145,13>}}
    }
    bounded_by { box {<-85,0, -13>, <85,170, 13>} }
  }  

which goes slightly faster than your original code, but not as fast as
omitting "union".

You could also have considered using a non-box bounding object, like

  #declare rear_tire = difference {
    sphere {<0, 85, 0>, 85 scale <1,1,.2>}
    cone {<0, 85, 20>, 50 <0, 85, -20>, 60}
    cone {<0, 85, -20>, 50 <0, 85, 20>, 60}
    bounded_by { sphere {<0, 85, 0>, 85 scale <1,1,.2>} }
  }  

which sometimes gives an improvement when the bounding shape fits more
tightly than a box and is quick to test. In this case it runs very
slightly slower than using a bounding box.


Overall, you're probably not going to find a great deal of improvement
when trying to optimise a simple object like this. POV is quite fast at
performing sphere and cone tests, so replacing a few of those tests by
bounding tests is only going to produce minor improvements.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message