> 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.

Thanks, but that much I expected and understand.  What I didn't
understand is why POV-Ray would use my manual bounding
without the -UR option?  The documentation says the default is
to remove all manual bounds.  So I only expected to see a
difference when I used -UR.  That wasn't the case.

> 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")

Thanks for this code.  I'm sure I'll find this useful.

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

Yes, that is what I expected the default would be.

> 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.

Thanks.  Yes, I need to pay more attention to the message pane.
I presently don't understand all the info printed there but I'll learn

> 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>} }
>   }

I got the impression from the documentation that its a bad idea to
manually bound unions so you are correct I hadn't even
considered this.

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

Thanks.   This tells me that sometimes I should bound unions.

> 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>} }
>   }

Wow!!!  I knew you could use a sphere as a bounding object but
I wasn't aware that it could be a scaled sphere.

> 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.

I find that a little surprising as the scaled sphere is a much better fit.
If the sphere test is slower then a box test then I'm curious when
using a sphere as a bounding object would actually give an
improvement.  Could it be the scaling that's slowing it down?

I'll see if I can tell if there is a difference between these two:
bounded_by { box {<-85,0, -17>, <85,170, 17>} }
bounded_by { box {<-85,0, -85>, <85,170, 85>scale <1,1,.2>}  }

> 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.

Well the final CSG I'm playing with is far more complicated.
I'm starting with the simple stuff so that I have an idea what
I'm doing before I jump into the trickier stuff.

Thanks for all the help,
Carl

Post a reply to this message