> Planes have an inside and an outside. Patch objects are just surfaces
> - they have no solid parts, so CGS isn't terribly useful for them.
> (Union should be ok, but the intersection of that would be lines and
> points, like you were expecting for planes.) Shouldn't cause an issue
> though - as you seem to have found out.

Well the "patch" that I'm using doesn't have a surface either.  Let me
show you have I'm doing that gives me the warning.

  #declare light_stick = merge {
    sphere {<96.5, 49.5, 26.5>, 5}
    sphere {<96.5, 49.5, -26.5>, 5}
    cone {<96.5, 49.5, 26.5>, 5 <96.5, 49.5, -26.5>, 5}
  }

  #declare light_stick_P = union {
    object {light_stick}
    light_source {<96.5, 49.5, 0> White
      fade_distance 85
      fade_power 2
    }
  }

Now I take this light_stick_P and use it as part of a much more
complex CSG which is used in an intersection.  Its then that I
get the warning, but it works and the final shape still has the light
source in it.  So despite the fact that it says "Patch objects not
allowed in intersections" my patch object, the light_source lived
to tell about it.  Maybe I shouldn't be putting light sources in my
CSG's but I wanted the light fixed relative to the CSG that I
wanted to be able to scale and translate and not have to worry
about repositioning the light_source separately.  If there is a
proper way to do this I'm all ears my my way does seem to
work even though it gives me a warning.

> > Good question... something I'll test with the Draw_Vistas
> > option you talk about below.  I'm thinking the bounding box
> > will be alot bigger then the small shape but I'm not sure.
>
> That's what I'm wondering.

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 it 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?

> Erm... actually... a box is a finite object. In the intersection
> above,

True.  In my thought process I was approximating an infinite
object by making the box as large as I was.  I was doing this
because at times I was cutting more complicated CSG's in
half and I didn't want to worry about the exact size of the
CSG so I'd use a box that I knew was an order of magnitude
or more larger then my object.

> the box object will probably become the exact bounding
> volume! If you use a plane, I imagine POV-Ray will use the
> sphere as the exact bounding volume - which is about twice
> as big! (Actually, having said that, I notice that that box is
> rather large... in that case, POV-Ray might be using the
> sphere anyway; IIRC it uses whichever is smallest. If you
> change that box to {<0, -20, -20>, <+20, +20, +20>} is
> should render the same, but [possibly] go faster.

True... you get the same and when cutting a sphere in half
that's easy enough to do.  I was just begining to question if I
should go back and figure out the exact size boxes I'd need
for cutting some of my more complex CSG in half.

> OTOH, maybe POV-Ray can work that out itself... I'm not
> sure. Hey, try it! ;-)

Maybe but I'm not not sure Draw_Vistas = on is the way to
check.  Mike over in the new users area gave me this code:

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

This may be a more direct way to answer these questions
as the relationship between the boxes drawn by the +UD
option and the bouding boxes isn't clear to me.

> Indeed. I think we're basically ALL still learning...

True... but I'm still greener then most I think.

Carl

Post a reply to this message