The following text is from a thread that stared in the images
group and I felt it would be better disscussed here rather than
there. It contains the original posters text in full along with
my reply to his query.
  After going through the text below I would like to hear your
opinion.

Is it A, B, C, or D or ?

A. A Bug
B. A predictable by product of coincident surfaces
C. An unpredictable problem that one could easil expect
   under these operating conditions
D. combinations of the previous three options
?. 

=================================

Anton Sherwood wrote:
> 
> We all know that you shouldn't let the two objects in difference{} have a
> plane in common, because the algorithm can't decide which of the two is "on
> top" as it were.
> 
> But what about intersections?  Even if the algorithm can't decide between the
> two planes, it ought to find one or the other to be "inside", and respond to
> that one.
> 
> intersection {
>         cylinder { <-1,-1,0>, <-1,1,0>, 2
>                 pigment { color Red }
>                 normal { wrinkles scale 1/16 }
>                 }
>         cylinder { <1,-1,0>, <1,1,0>, 2
>                 pigment { color Green }
>                 normal { leopard scale 1/16}
>                 }
>         }
> 
> I'd be happy if the top of the object were red, green, yellow, or blotchy of
> both colors.  (The first time I spotted this bug, the object had one texture
> all over, anyway.)  Instead, the object has no top at all.
> 
> Is this bug well known?



I replied with the following comments and wisdom:

   It is weird whatever it is and it just keeps getting stranger.
I am sure it has something to do with the intersection testing but
without the aid of a programmers background and a copy of the source
code I can't say specificaly what it may be. The coincident surface
problem has been so well documented I doubt anyone but a 3 month old
newbie has not heard about or experienced it for himself. It's just
that your example takes it to a new extreme.

  I'll post this message with your comments intact in the programming
group and see if Ron of someone else can offer any insight into this
oddity.

Try this for even more fun with your strange behavior.

 Using the following code rendered each steps in the order I dictate below.
Observe the changes the overlapping pigments go through as each parameter
is modified.


   Leave the object statment untouched and change only the lights and 
   global settings parameters. 

========================

/* Render w/light inside the objects - observe overlapping illumination */
   light_source { < 0, 0, -3> rgb 1 }

/* Uncomment the global settings and render again. Note how neither of 
   the two pigments have dominance over the other */
// global_settings { max_intersections 2 }


/* Now try it with this global statement and witness the change */
// global_settings { max_intersections 4 }


/* Now try the previous two again with this lightsource included and 
   observe  the chages in appearence. */
//light_source { < 0, 0,-25> rgb 1 }


/* Also if you reverse the position of the two objects when the
   max_intersections setting is above 4 or more the object on the right
   always has priority over the object on the left as to which pigment
   will be on top of the other. */

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

   union {
        cylinder { <1,-1,0>, <1,1,0>, 2
                pigment { red 1 }
                normal {bozo scale 1/16 }// wrinkles scale 1/16 }
                }
        cylinder { <-1,-1,0>, <-1,1,0>, 2
                pigment { color green 1 }
                normal { leopard scale 1/16}
                }
        scale .35 rotate 90*-x translate<0,.25,-3>}

=======================

  The obvious fix for this problem is to simply scale one cylinder
slightly longer than the other and it will all go away. It is even
mentioned in the docs that this is an acceptable practice so don't
feel like you are cheating when you are forced to do so. If you are
expecting some other result from your current object placement and
csg type used then you are probably applying it wrong and should be
applying it differently or try using a different csg intersection type.



-- 
Ken Tyler

mailto://tylereng@pacbell.net

Post a reply to this message

On Mon, 17 May 1999 00:27:15 -0700, Ken wrote:
>Is it A, B, C, or D or ?
>
>A. A Bug
>B. A predictable by product of coincident surfaces
>C. An unpredictable problem that one could easil expect
>   under these operating conditions
>D. combinations of the previous three options

I'd call it B, with a smattering of C.  

>> We all know that you shouldn't let the two objects in difference{} have a
>> plane in common, because the algorithm can't decide which of the two is "on
>> top" as it were.
>> 
>> But what about intersections?  Even if the algorithm can't decide between the
>> two planes, it ought to find one or the other to be "inside", and respond to
>> that one.

Why should it?  If a point is on the surface of an object, is it inside or
outside?  Also, keep in mind that there is no difference between difference
and intersection.  The internal implementation of 

difference {object {A} object {B}} 

is

intersection {object {A} object {B inverse}}

Here's what the CSG-intersection algorithm does:  First, it finds all 
intersections[1] of your ray with the object in question.  Next, it tests 
the intersections in the order in which they were encountered, looking for 
one that is inside every sub-object in the CSG except the one that was hit.
If this doesn't hold for the first intersection, it goes to the next, and 
so on.

So let us look at the case in question.  The ray hits both planes at the same
point.  The sorting algorithm sorts one intersection in front of the other, 
in a predictable but seemingly random way.  Note that if cylinder A sorts 
ahead of cylinder B this time, they will likely sort the same way every time,
regardless of which direction the ray is coming from.  The first intersection 
that is found may or may not be "inside" the other plane, due to numerical 
inaccuracies.  If it is, it is kept.  If not, it's thrown away and the other 
intersection tested.  If the two planes have identical equations, the result 
of testing the other intersection will be identical to the first one.  So 
either the first intersection works, or neither one works.  If the first one 
works, you get a pixel colored like the first object.  If neither works, you 
go right through that face as if it didn't exist.  The result is a speckly 
surface where you expected something else.  If you're really lucky, the 
numerical inaccuracies may all go in your favor, leaving you with either a 
solid surface or a transparent one.  If you're extremely lucky, this will be 
the result you expected. :)

[1] intersection here does not mean CSG intersection.  It means "the place
where a ray hits an object."

Post a reply to this message