/*
There's something weird with the following code:
*/

camera{location <0,0,-13.5> look_at<0,0,0> angle 30}

light_source{<-200,100,-150> color rgb <1,1,1>.1}

plane{z,600 hollow on pigment{rgb .25}}
   
#declare xx=1.9;
#declare yy=.5;

merge{
  sphere{<-xx,-yy,0>,.1}
  sphere{<xx,-yy,0>,.1}
  sphere{<-xx,yy,0>,.1}
  sphere{<xx,yy,0>,.1}
  cylinder{<-xx,-yy,0><xx,-yy,0>,.1}
  cylinder{<-xx,yy,0><xx,yy,0>,.1}
  cylinder{<-xx,-yy,0><-xx,yy,0>,.1}
  cylinder{<xx,-yy,0><xx,yy,0>,.1}

  cylinder{<-xx,-yy,0><-xx,-yy,5>,.1}
  cylinder{<xx,-yy,0><xx,-yy,5>,.1}
  cylinder{<-xx,yy,0><-xx,yy,5>,.1}
  cylinder{<xx,yy,0><xx,yy,5>,.1}
        
  box{<-xx,-yy-.1,0><xx,yy+.1,5>}
  box{<-xx-.1,-yy,0><xx+.1,yy,5>}
  pigment{rgb 5}
}

/*
What you should get is a bevelled box. 
If I make this into a union it's okay,
but with merge the inner part is gone.

Is this some known weird merge-behaviour
or am I making a stupid mistake?
(I thought union and merge should look
the same on the outside)

Cheerio,

Remco

Post a reply to this message

Remco de Korte wrote:

> /*
> There's something weird with the following code:
> */
>
> camera{location <0,0,-13.5> look_at<0,0,0> angle 30}
>
> light_source{<-200,100,-150> color rgb <1,1,1>.1}
>
> plane{z,600 hollow on pigment{rgb .25}}
>
> #declare xx=1.9;
> #declare yy=.5;
>
> merge{
>   sphere{<-xx,-yy,0>,.1}
>   sphere{<xx,-yy,0>,.1}
>   sphere{<-xx,yy,0>,.1}
>   sphere{<xx,yy,0>,.1}
>   cylinder{<-xx,-yy,0><xx,-yy,0>,.1}
>   cylinder{<-xx,yy,0><xx,yy,0>,.1}
>   cylinder{<-xx,-yy,0><-xx,yy,0>,.1}
>   cylinder{<xx,-yy,0><xx,yy,0>,.1}
>
>   cylinder{<-xx,-yy,0><-xx,-yy,5>,.1}
>   cylinder{<xx,-yy,0><xx,-yy,5>,.1}
>   cylinder{<-xx,yy,0><-xx,yy,5>,.1}
>   cylinder{<xx,yy,0><xx,yy,5>,.1}
>
>   box{<-xx,-yy-.1,0><xx,yy+.1,5>}
>   box{<-xx-.1,-yy,0><xx+.1,yy,5>}
>   pigment{rgb 5}
> }
>
> /*
> What you should get is a bevelled box.
> If I make this into a union it's okay,
> but with merge the inner part is gone.
>
> Is this some known weird merge-behaviour
> or am I making a stupid mistake?
> (I thought union and merge should look
> the same on the outside)
>
> Cheerio,
>
> Remco

You have coincident surfaces. Use this code instead:

merge {
  sphere{<-xx,-yy,0>,.1}
  sphere{<xx,-yy,0>,.1}
  sphere{<-xx,yy,0>,.1}
  sphere{<xx,yy,0>,.1}
  cylinder{<-xx,-yy,0><xx,-yy,0>,.1}
  cylinder{<-xx,yy,0><xx,yy,0>,.1}
  cylinder{<-xx,-yy,0><-xx,yy,0>,.1}
  cylinder{<xx,-yy,0><xx,yy,0>,.1}

  cylinder{<-xx,-yy,0><-xx,-yy,5>,.1}
  cylinder{<xx,-yy,0><xx,-yy,5>,.1}
  cylinder{<-xx,yy,0><-xx,yy,5>,.1}
  cylinder{<xx,yy,0><xx,yy,5>,.1}

  box{<-xx,-yy-.1,0.00001><xx,yy+.1,5>}
  box{<-xx-.1,-yy,0><xx+.1,yy,5>}
}

Post a reply to this message

Larry Fontaine wrote:
> 
> You have coincident surfaces. 
> 
Yes I understand, but I didn't know that mattered. It doesn't for a union. 
Somehow I think your solution, though effective, isn't all that elegant.
:)

Thanks anyhow,

Remco

Post a reply to this message

On Tue, 07 Sep 1999 03:17:15 +0200, Remco de Korte
<rem### [at] xs4allnl> wrote:

>Larry Fontaine wrote:
>> 
>> You have coincident surfaces. 
>> 
>Yes I understand, but I didn't know that mattered. It doesn't for a union. 
>Somehow I think your solution, though effective, isn't all that elegant.
>:)

It does matter.  Merge is actually an intersection, believe it or not,

though it's not represented that way internally like difference is. 
Nevertheless, anything that's important for an intersection is
important for a merge as well.

merge {object a object b} 

is equivalent to (but perhaps a little faster than)

intersection {object {a inverse} object {b inverse} inverse }

Post a reply to this message

Ron Parker wrote:

> It does matter.  Merge is actually an intersection, believe it or not,
>
> though it's not represented that way internally like difference is.
> Nevertheless, anything that's important for an intersection is
> important for a merge as well.
>
> merge {object a object b}
>
> is equivalent to (but perhaps a little faster than)
>
> intersection {object {a inverse} object {b inverse} inverse }

In addition to this,
   difference { object a object b }
is the same as
   intersection { object a object {b inverse } }

I think the latter computes faster? Maybe bounding is more accurate because in
diff. you have to specify your own bound...

Post a reply to this message

They are both the same, there shouldn't be any difference(sorry!)
between the speeds. If speed is important, you should manually bound
both difference and intersection, because the program can't reliably
determine the best bounds for them.(I haven't done this in my macro
collection, and it needs it badly for some objects composed of many
primitives. For simpler objects, the gain is so small it can be
unnoticeable.)

Post a reply to this message

Remco de Korte wrote:

> Larry Fontaine wrote:
> >
> > You have coincident surfaces.
> >
> Yes I understand, but I didn't know that mattered. It doesn't for a union.
> Somehow I think your solution, though effective, isn't all that elegant.
> :)

It looks like you only want to round four fo the edges of the box, not all
twelve? Otherwise, with twelve, you'd have 12 cylinders, six spheres and some
boxes, and they could all be perfectly positioned without coincidence.

Post a reply to this message

On Tue, 07 Sep 1999 16:34:22 -0500, Larry Fontaine wrote:

>In addition to this,
>   difference { object a object b }
>is the same as
>   intersection { object a object {b inverse } }
>
>I think the latter computes faster? 

There's no way to know, because POV internally turns a difference into
the equivalent intersection.  Other than a little bit in the parser, 
there is no "difference" code in POV.

Post a reply to this message