I don't recall merge ever acting this way before. I'm getting a reverse
intersection clipping with the following:

#include "colors.inc"

camera {
   location <-2.5,6.5,4.1>
   look_at <-3.05,6,4.5>

}

light_source {
   <50,50,-10>
   color White
}

//union {
   merge {
      box {
         <0,0,4.25>, <.25,6,4.5>
      }
      box {
         <0,5.75,0>, <.25,6,4.5>
      }
   //}
   cylinder {
      <0,5.9,4.375>, <6.5,5.9,4.375>, .06
   }
   
   translate <-3.25,0,0>
   pigment {
      color Blue
   }
}

In the source above, the objects are clipped where they meet.

Comment out the 'merge' line and uncomment the 'union', and it appears as
I would expect--two blocks with a cylinder coming out of them.

Uncomment everything, so that the blocks are in a merge but the cylinder
is in a union, and the blocks get clipped where they meet, with the
cylinder appearing in the space inside.

I put an example up at http://cerebus.acusd.edu/merge/ . I'm getting this
in both the official compile for Macintosh (3.1g.r1) and the unofficial
compile (November 17, 1999).

Is this right?

Jerry

Post a reply to this message

Jerry wrote:
> 
> I don't recall merge ever acting this way before. I'm getting a reverse
> intersection clipping with the following:

> In the source above, the objects are clipped where they meet.

> Is this right?

What you are experiencing is called coincedent surfaces. POV-Ray
cannot tell which surface to evaluate as inside or outside because
the surface to the two boxes line up perfectly. This is not a bug
rather a limitation of raytracing.

Change your second box to:

      box {
         <0,5.75,0>, <.2501,6.001,4.501>
      }

and it works properly.

-- 
Ken Tyler -  1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <383C6D99.35A9B7FF@pacbell.net>, lin### [at] povrayorg wrote:

>Jerry wrote:
>> 
>> I don't recall merge ever acting this way before. I'm getting a reverse
>> intersection clipping with the following:
>
>> In the source above, the objects are clipped where they meet.
>
>> Is this right?
>
>What you are experiencing is called coincedent surfaces. POV-Ray
>cannot tell which surface to evaluate as inside or outside because
>the surface to the two boxes line up perfectly. This is not a bug
>rather a limitation of raytracing.

I've never seen coincident surfaces act like this. In the past, it has
always chosen one or the other at (apparent) random to display (and when
both are the same texture, it hasn't shown). So merge, rather than doing
what union does and choosing one, just gives up and effectively clips the
surfaces?

Is it my imagination that merge did not used to do this?

Jerry
http://www.hoboes.com/jerry/

Post a reply to this message

In article <new### [at] cx38767-adt1sdcahomecom>, Jerry
Stratton <new### [at] hoboescom> wrote:

> I've never seen coincident surfaces act like this. In the past, it has
> always chosen one or the other at (apparent) random to display (and when
> both are the same texture, it hasn't shown). So merge, rather than doing
> what union does and choosing one, just gives up and effectively clips the
> surfaces?
> 
> Is it my imagination that merge did not used to do this?

It doesn't pick either surface, it just picks the one which seems
closest, which varies due to precision errors. Sometimes it picks one,
sometimes the other, sometimes an entire area will consist of one. It
isn't very predictable, and seems to depend on the combination of the
objects being used, and on the position of the camera and object. Of
course, the problem is nonexistant when both parts are the same
texture, and the only CSG is a union...
The newer version may produce different results from coincident
surfaces because of a different compiler or different libraries, like
the prism problem(see a thread back in povray.general about this).(With
the exception that the prism thing is a fixeable problem, while this is
just a characteristic of this type of rendering)

-- 
Chris Huff
e-mail: chr### [at] yahoocom
Web page: http://chrishuff.dhs.org/

Post a reply to this message

Jerry Stratton wrote:

> I've never seen coincident surfaces act like this. In the past, it has
> always chosen one or the other at (apparent) random to display (and when
> both are the same texture, it hasn't shown). So merge, rather than doing
> what union does and choosing one, just gives up and effectively clips the
> surfaces?
> 
> Is it my imagination that merge did not used to do this?

 I just tried it on the dos version of POV-Ray v2.2 and it acted the same.
The reason you are percieving it as a clipping operation is because the
merge operation removes all interior surfaces. In fact I would say that
you are lucky that the two boxes where they overlap are coming out so
clean. If it were a true coincident surfaces problem you would likely
see physical artifacts left over by the merge operation. As it is the
merge operation is simply removing all overlapping and interior surfaces
just like you would expect it to.

 In the example below you can see where I have learned to exploit this
feature of the merge function to create an open geometeric object. Also
not unusual use of the cone object which has a negative radius specified.

  #declare SnowTex = 
   texture {
     pigment { rgb 1 }
      finish { ambient .6
               diffuse .2
               specular 1
               roughness .001
               brilliance 2
               reflection .02
               crand 0.1
             }
           }

  #declare MB = union{
  cone{<0,0,0>,1.3,< 0, 1, 0>,-0.25 open}
  cone{<0,0,0>,1.3,< 0,-1, 0>,-0.25 open}
  cone{<0,0,0>,1.3,< 1, 0, 0>,-0.25 open}
  cone{<0,0,0>,1.3,<-1, 0, 0>,-0.25 open}
  cone{<0,0,0>,1.3,< 0, 0, 1>,-0.25 open}
  cone{<0,0,0>,1.3,< 0, 0,-1>,-0.25 open}}

  #declare Fk = merge{
  sphere{<0,0,0>,1.1}
  object{MB rotate  0*y}
  object{MB rotate 45*z}
  object{MB rotate 45*y}
  object{MB rotate 45*x}}

  object{Fk texture { SnowTex } scale 2 }

  light_source { <100,225,-200> rgb 1}

  camera{location<0,0,-9> look_at 0 }

-- 
Ken Tyler -  1200+ Povray, Graphics, 3D Rendering, and Raytracing Links:
http://home.pacbell.net/tylereng/index.html http://www.povray.org/links/

Post a reply to this message

In article <383C8CC6.10746C53@pacbell.net>, lin### [at] povrayorg wrote:
>Jerry Stratton wrote:
>> Is it my imagination that merge did not used to do this?
>
> I just tried it on the dos version of POV-Ray v2.2 and it acted the same.
>The reason you are percieving it as a clipping operation is because the
>merge operation removes all interior surfaces. In fact I would say that
>you are lucky that the two boxes where they overlap are coming out so
>clean. If it were a true coincident surfaces problem you would likely
>see physical artifacts left over by the merge operation.

Yes, that's what I expect with coincident surfaces. I just checked the 3.0
version that I started with (didn't have it at the office today), and it
does exactly the same thing. I could've sworn I've used merge in this
manner before, but apparently it really was just my imagination.

Sorry for the trouble.

Jerry
http://www.hoboes.com/jerry/

Post a reply to this message