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