I was writing up something and I came across an interesting "bug".  I
donno if its something I'm doing wrong or if its a feature or whatever. 
Any input would be appreciated.

I tried to make holes in a wall with difference.  Fairly simple, eh? 
Well, I tried the 'difference' CSG modifier and I got grainy lines, like
my surface of interactin between the cutting object and the object being
cut were incident on each other.  Unun.  I tried moveing the
light_source and camera around but it still didn't work.  I still got
interfierence lines in the windows.

The following code gave me clean windows, when I made the cutting blocks
transmit everything and 'merge'd it with the object to be cut.  What did
I do wrong?  I added the code that worked for you to look at...  Not
that I mind one over the other (actually, the merge took a *bit* longer
to render) just curious.  Anyone?

Thanks.

Saif

PS - Sorry about the condition of the code, I'm not very good at clean
code :(

#declare first_arc=
object{
       intersection{
       cylinder{ <3, 0, -.6> <3, 0, .6> 5 }
       box { <-3, 0, -.7> <0, 5, .7> }
       }
}

#declare full_arc=
object{
       union{
       #object { first_arc }
       #object { first_arc rotate y* 180 }
       }
}

#declare large_window=
union{
      #object { full_arc scale <2, 1, 1> }
      box { <-4, -5, -.6> <4, 0, .6> }
      pigment { rgbt <1, 1, 1, 1> }
}

#declare narrow_window=
union{
      #object { full_arc scale <.5, 1, 1> }
      box { <-1, -5, -.6> <1, 0, .6> }
      pigment { rgbt <1, 1, 1, 1> }
}

#declare x_1 = -20
#declare x_2 = 20

#declare Wall=

merge{

box { <-25, 0, -.5> <25, 15, .5> pigment { Gray95 } }
object { large_window translate <0, 8, 0> }

#while (x_1 <= -8)
    #object { narrow_window translate <x_1, 8, 0> }
    #declare x_1 = x_1 + 6
#end

#while (x_2 >= 8)
    #object { narrow_window translate <x_2, 8, 0> }
    #declare x_2 = x_2 - 6
#end

}

Post a reply to this message

Hi Saif,

One other thing you could try to understand your bug better is make your
objects semi-transparent. I had that problem myself with the difference of
two objects each being composed of an intersection of others.

To make things simple to explain, say you have A, B, C and D all simple
objects (i.e. planes).
Now make E as the intersection of A and B and make F as the intersection of
C and D.
The final object, called G is the difference of F less E.
Making that object G semi-transparent and semi-reflective, putting a sky
sphere that is a gradient (just to make any reflection or transparency
obvious) shows the border line of C and D inside G (if they intersect at all
with the final G object).
Now if you use a merge all spurious border lines disappear.

This clearly is a bug, although I did not take time to report it when I got
it, but that makes two of us now as I'm pretty sure your problem is the same
as mine.

So if the POV-Team or POV-admin is listening, please pass on to the
programmers team.
Cheers & regards to all,
Al.


Saif Ansari wrote:

> I tried to make holes in a wall with difference.  Fairly simple, eh?
> Well, I tried the 'difference' CSG modifier and I got grainy lines, like
> my surface of interactin between the cutting object and the object being
> cut were incident on each other.  Unun.  I tried moveing the
> light_source and camera around but it still didn't work.  I still got
> interfierence lines in the windows.

--
ANTI SPAM / ANTI ARROSAGE COMMERCIAL :

To answer me, please take out the Z from my address.

Post a reply to this message

Alain CULOS wrote:

> One other thing you could try to understand your bug better is make your
> objects semi-transparent. I had that problem myself with the difference of
> two objects each being composed of an intersection of others.

Right, thats how I got around it in the first place.  I simply thought
maybe difference wasn't meant to be used in that way (not to make blank
gaps, maybe simply to dig patterns, or maybe not to be used with
pre-CSG-ed objects).  I was content slideing around it with merge of a
transparent object, even if the render time took a bit of a boost.

> This clearly is a bug, although I did not take time to report it when I got
> it, but that makes two of us now as I'm pretty sure your problem is the same
> as mine.

Hum.  Seems rather odd that it would linger for so long without being
detected or reported, haven't the current CSG modifiers been in use
since the Old Days when I wasn't yet born? :) Well, if it is, I guess
detecting it is a Good Thing.  Thanks for the feedback!

> So if the POV-Team or POV-admin is listening, please pass on to the
> programmers team.

Wow, I may contribute to the POV-team :) I feel somewhat special.

> Cheers & regards to all,
> Al.

Many thanks,
Saif.

Post a reply to this message

Alain CULOS wrote:
> 
> To make things simple to explain, say you have A, B, C and D all simple
> objects (i.e. planes).
> Now make E as the intersection of A and B and make F as the intersection of
> C and D.
> The final object, called G is the difference of F less E.
> Making that object G semi-transparent and semi-reflective, putting a sky
> sphere that is a gradient (just to make any reflection or transparency
> obvious) shows the border line of C and D inside G (if they intersect at all
> with the final G object).
> Now if you use a merge all spurious border lines disappear.
> 

ummm.... I tried to create your scenario, but I couldn't see a bug.  Could
you post a scene (complete w/ camera, lights, background, etc).  I'll try
to track down the bug.

-Nathan Kopp

Post a reply to this message

Nathan Kopp wrote:

> ummm.... I tried to create your scenario, but I couldn't see a bug.  Could
> you post a scene (complete w/ camera, lights, background, etc).  I'll try
> to track down the bug.


Here you go ... very simple : the file was there on my disk ready, I just did not
get around to do anything with it other than trace it once or twice.

The top shape is perfect (prism) the bottom shape is the one that yields
surprising inside surfaces.

Have fun with it,
Al.

--
ANTI SPAM / ANTI ARROSAGE COMMERCIAL :

To answer me, please take out the Z from my address.

Post a reply to this message

Attachments:
Download 'differenceofintersectionbug.pov.txt' (2 KB)

Thanks for the file.  I narrowed the bug down to a logical error in the
function Invert_CSG_Intersection().  Inverting an intersection should
lead to a MERGE object, but instead POV converts it to a UNION.  This
is why you get the extra surfaces.

The fix is as simple as changing one line from
  Object->Methods = &CSG_Union_Methods;
into
  Object->Methods = &CSG_Merge_Methods;

I'll send the fix to the POV team right away.

-Nathan Kopp

Post a reply to this message

Nathan Kopp wrote:

> I'll send the fix to the POV team right away.

Much Obliged!  I'm glad Alain was of more help than I, and the bug will
be caught.  It left me pondering for a few of my images...

Thanks again, for the responce.

S

Post a reply to this message

Nathan Kopp wrote:

> Thanks for the file.

You're welcome.

> I narrowed the bug down to a logical error in the
> function Invert_CSG_Intersection().  Inverting an intersection should
> lead to a MERGE object, but instead POV converts it to a UNION.  This
> is why you get the extra surfaces.

That was fast !Good job.


> The fix is as simple as changing one line from
>   Object->Methods = &CSG_Union_Methods;
> into
>   Object->Methods = &CSG_Merge_Methods;

I'll bear that in mind, just in case.

> I'll send the fix to the POV team right away.

Great.Talk again,
Al.


--
ANTI SPAM / ANTI ARROSAGE COMMERCIAL :

To answer me, please take out the Z from my address.

Post a reply to this message