I've got a couple quick questions.  I'm using the Draw_Vistas option or +UD
flag to test a CSG to see if I should be using some manual bounding boxes.

(1)  What is the significance of the color of the box this options draws on
the render window?  I've seen red boxes and blue boxes and I can't see any
reason behind what gets a blue box and what gets a red box.

(2)  I learned rather fast that when testing my CSG that if I just had a
very simple piece I was testing that I also needed the +MB0 flag turned on.
However I could have as few as 3 frame level objects and I no longer needed
the +MB0 flag.  The documentaion says the default setting is +MB25.  What is
the relationship between the number of "objects" used in this flag and what
the message window refers to as "frame level objects"?

Thanks,
Carl

Post a reply to this message

In article <401c52cd$1@news.povray.org>, "Carl Hoff" <hof### [at] wtnet> 
wrote:

> (1)  What is the significance of the color of the box this options draws on
> the render window?  I've seen red boxes and blue boxes and I can't see any
> reason behind what gets a blue box and what gets a red box.

From the code, it looks like blue boxes are compound objects, red boxes 
are lone objects.


> (2)  I learned rather fast that when testing my CSG that if I just had a
> very simple piece I was testing that I also needed the +MB0 flag turned on.
> However I could have as few as 3 frame level objects and I no longer needed
> the +MB0 flag.  The documentaion says the default setting is +MB25.  What is
> the relationship between the number of "objects" used in this flag and what
> the message window refers to as "frame level objects"?

You have 3 frame level objects and the default +MB setting, and still 
get bounding slabs?
The default is 25, and the number considered is the number of frame 
level objects. In fact, whether or not to build the slabs is decided 
right after printing that information, in Build_Bounding_Slabs() in 
bbox.cpp. The code's a little odd, but should work as expected. Maybe 
there's an .ini file setting or something overriding the default...

-- 
Christopher James Huff <cja### [at] earthlinknet>
http://home.earthlink.net/~cjameshuff/
POV-Ray TAG: <chr### [at] tagpovrayorg>
http://tag.povray.org/

Post a reply to this message

Wasn't it Carl Hoff who wrote:
>(2)  I learned rather fast that when testing my CSG that if I just had a
>very simple piece I was testing that I also needed the +MB0 flag turned on.
>However I could have as few as 3 frame level objects and I no longer needed
>the +MB0 flag.  The documentaion says the default setting is +MB25.  What is
>the relationship between the number of "objects" used in this flag and what
>the message window refers to as "frame level objects"?

I guess that what got documented is the default default. What the POVRay
executable would do if nothing else changed the setting.

The supplied version of the master POVRAY.INI contains this code, which
countermands that default.

; Sets minimum number of objects before auto bounding kicks in.
;
Bounding_Threshold = 3

Which is the verbose way of saying +MB3.

If you remove that setting from POVRAY.INI then you'll find that scenes
with less than 25 frame level objects have no bounding boxes.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

> From the code, it looks like blue boxes are compound objects, red
> boxes are lone objects.

Thanks, that fits with what I've seen I believe.

> You have 3 frame level objects and the default +MB setting, and
> still get bounding slabs?

Yes.

> The default is 25, and the number considered is the number of
> frame level objects. In fact, whether or not to build the slabs is
> decided right after printing that information, in
> Build_Bounding_Slabs() in bbox.cpp. The code's a little odd,
> but should work as expected. Maybe there's an .ini file setting
> or something overriding the default...

According to Mikes post the master POVRAY.INI file sets
it to 3.  I haven't checked but that fits with what I'm seeing.

Thanks for the help guys,
Carl

Post a reply to this message

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?

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.

Thanks,
Carl

Post a reply to this message

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

> 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

This is cut from a post of mine over in the images area that I think might
serve me better here.

I'm still playing with the Draw_Vistas option and I'm still not
sure if I need the -UR flag to be able to use my manual bounding
or not.

With these options (+UD +MB0) try the following:

  #include "colors.inc"
  camera {location <-500, 0, 0> look_at <0, 85, 0> angle 36}
  light_source { <110, 5, -500> White}

  #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 { box {<-85, 0, -13>, <85, 170, 13>} }
  }

  object {rear_tire pigment {Blue}}

Now comment out the bounded_by line. You'll be able to
see the difference even without the -UR flag.

However while playing with this code using the same options:

  #include "colors.inc"
  camera {location <0, 0, -500> look_at <0, 85, 0> angle 36}
  light_source { <110, 5, -500> White}

  #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 { box {<-85, 0, -13>, <85, 170, 13>} }
  }

  #declare rear_axle = sphere {<0, 85, 0>, 17}

  #declare rear_hub = difference {
    cylinder {<0, 85, 1>, <0, 85, -1>, 60}
    object {rear_tire}
    object {rear_axle}
    bounded_by { box {<-56, 29, -2>, <56, 141, 2>} }
  }

  object {rear_hub pigment {Blue}}

I note that even with the -UR flag on, the bounding slab
size doesn't visual change from the default.

Even replace the bounded_by line with this:
    bounded_by { box {<-50, 29, -2>, <56, 141, 2>} }
    clipped_by {bounded_by}

And you will see the shape is clipped but the bounding box
hasn't moved.  I'm using [800x600,AA 0.3] if that makes
a difference.

But if I replace it with:
    bounded_by { box {<0, 29, -2>, <56, 141, 2>} }
    clipped_by {bounded_by}

Now the bounding slap IS where it should be even without
the -UR flag.

I even tried this:
    bounded_by { box {<0, 29, -2>, <56, 1000, 2>} }
    clipped_by {bounded_by}

The shape is clipped BUT the bounding slap grew back in
the x-direction and NOT in the y-direction.  Why?

I get the smallest bounding slab and the shape I want if I
take the bounded_by statement off altogether and replace
the cylinder with:
cylinder {<0, 85, 1>, <0, 85, -1>, 56}

So this Draw_Vistas option isn't behaving in what I'd consider
a predictable manner.  Is what I've seen called the bounding
slab a 2D projection of the bounding box?  It sure looks like
something else when I use:

    bounded_by { box {<0, 29, -2>, <56, 1000, 2>} }
    clipped_by {bounded_by}

And see the object clipped and I see a short fat box when
I'd expect to see a thin tall box that extends to the top of
the screen.  Can anyone tell me what is going on here?

Post a reply to this message

Wasn't it Carl Hoff who wrote:

>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 don't think that scaling ever slows down any ray tests. What happens
is that all the scaling, rotations and translations for an object are
combined during parsing into a single transformation matrix. Applying
the resulting matrix goes at the same speed whatever type of
transformation is being applied.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message

Wasn't it Carl Hoff who wrote:
>This is cut from a post of mine over in the images area that I think might
>serve me better here.
>
>I'm still playing with the Draw_Vistas option and I'm still not
>sure if I need the -UR flag to be able to use my manual bounding
>or not.
>
>With these options (+UD +MB0) try the following:
>
>  #include "colors.inc"
>  camera {location <-500, 0, 0> look_at <0, 85, 0> angle 36}
>  light_source { <110, 5, -500> White}
>
>  #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 { box {<-85, 0, -13>, <85, 170, 13>} }
>  }
>
>  object {rear_tire pigment {Blue}}
>
>Now comment out the bounded_by line. You'll be able to
>see the difference even without the -UR flag.

One of the things that is going on is that POV-Ray is reasonably smart
about knowing when it is likely to be helpful to remove manual bounding.
+UR doesn't remove all manual bounds, only manual bounds where POV-Ray
thinks it can do better. In this case, it has trusted you to provide
better manual bounds than it would have applied automatically.

>
>However while playing with this code using the same options:
>
>  #include "colors.inc"
>  camera {location <0, 0, -500> look_at <0, 85, 0> angle 36}
>  light_source { <110, 5, -500> White}
>
>  #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 { box {<-85, 0, -13>, <85, 170, 13>} }
>  }
>
>  #declare rear_axle = sphere {<0, 85, 0>, 17}
>
>  #declare rear_hub = difference {
>    cylinder {<0, 85, 1>, <0, 85, -1>, 60}
>    object {rear_tire}
>    object {rear_axle}
>    bounded_by { box {<-56, 29, -2>, <56, 141, 2>} }
>  }
>
>  object {rear_hub pigment {Blue}}
>
>I note that even with the -UR flag on, the bounding slab
>size doesn't visual change from the default.

In this case, the automatic bounding box calculated by POV-Ray is
*considerably* better than the one you provided manually. I would have
though that -UR would force it to use the manual bounding. However, the
documented reason why you would want to keep inefficient manual bounds
doesn't apply in this case, and perhaps POV-Ray is smart enough to have
worked that out.

Your manual bounding box has a volume of 50,176 cubic units, whereas the
automatic bounds calculated by POV-Ray has a volume of 28800 cubic
units. A quick experiment shows that POV-Ray is choosing the bounds that
have the lower volume irrespective of the UR setting.

Try making the Z values of your manual bounding box a closer fit.

-- 
Mike Williams
Gentleman of Leisure

Post a reply to this message