The following scene demonstrates a bug involving difference and clipped_by.  
When you render it, you should get three objects.  The one on the left, 
the red one, is rendered correctly.  

The one in the center (the green one) should be identical to the one on 
the left, but I added a clipped_by to the cylinder in an attempt to make 
it render faster (Inside_Box is slightly faster than Inside_Cone, but 
Inside_Object ignores bounded_by so I used clipped_by.)  It's obvious 
from looking at the result that the automatic inverse operation applied 
by difference doesn't properly deal with the clipping object(s).  This 
looks like a bug.

So, I applied the inverse to the clipping object manually.  The result is 
what you see on the right, the blue object.  I can't say I didn't expect 
this result, for it is true that !(A & B) (the "correct" result) is not equal 
to (!A & !B) (the result of inverting the clipping object separately).  So
we can't just set the inverse flags on the clipping objects and expect it 
to work right in a difference.  It looks like Inside_Object needs to return
the state of the inverse flag (of the parent object, not the clipping object) 
instead of false when it is given a point that is not in the clipping object.

It seems like this might change the behavior of existing scenes, however,
so perhaps it should only happen if the inverse was applied implicitly by 
a difference operation.  (I'll admit that I can't think of a scene where
the change in behavior would be noticeable, with the possible exception 
of one involving media, and I think media is already broken by clipped_by.)

-------------------------------------------------------
camera {location <0,1,-5> look_at <0,0,0>}
light_source { <50,50,-50> color rgb 3 }
    
difference {
  box {-.5,.5}
  cylinder {-.6*z,.6*z,.25}
  texture {pigment {color red 1} finish {ambient .5}}
  translate -1.1*x
}

difference {
  box {-.5,.5}
  cylinder {-.6*z,.6*z,.25 
            clipped_by{box {<-.26,-.26,-.6><.26,.26,.6>}}}
  texture {pigment {color green 1} finish {ambient .5}}
}

difference {
  box {-.5,.5}
  cylinder {-.6*z,.6*z,.25 
            clipped_by{box {<-.26,-.26,-.6><.26,.26,.6> inverse}}}
  texture {pigment {color blue 1} finish {ambient .5}}
  translate 1.1*x
}
-------------------------------------------------------

Post a reply to this message

Ron Parker <par### [at] my-dejanewscom> wrote:
: This looks like a bug.

  It may look like a bug, but certainly this is exactly how it works. It
may be an unwanted behaviour, but it's not a bug (ie. a programming mistake).

: So, I applied the inverse to the clipping object manually.  The result is 
: what you see on the right, the blue object.  I can't say I didn't expect 
: this result, for it is true that !(A & B) (the "correct" result) is not equal
: to (!A & !B)

  You are right. Logic rules say that !(A & B) equals to (!A | !B). We
would need a clipped_by which works like an union instead of the one that
works like an intersection.
  Perhaps povray should use a union-like clipped_by when it automatically
inverses a clipped object (and of course it should inverse the clipping
object too). But is this the wanted behaviour?

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

On 27 Apr 1999 13:00:06 -0500, Nieminen Mika <war### [at] cctutfi> wrote:
>Ron Parker <par### [at] my-dejanewscom> wrote:
>: This looks like a bug.
>
>  It may look like a bug, but certainly this is exactly how it works. It
>may be an unwanted behaviour, but it's not a bug (ie. a programming mistake).

Bugs aren't just programming mistakes.  Sometimes they're design mistakes.
This looks like one of those times.  After all, it is reasonable to do
what I did, expecting the results I expected.  The results I got are neither
what I expected (the red box) nor what I perhaps would have expected upon 
further contemplation (the blue box).

>  Perhaps povray should use a union-like clipped_by when it automatically
>inverses a clipped object (and of course it should inverse the clipping
>object too). But is this the wanted behaviour?

This is exactly what would happen if Inside_Object returned the inverse
flag for the parent instead of FALSE.  It seems like it wouldn't always 
be the desired behavior, but I'm hard-pressed to find an example of when
the current behavior would ever be the desired behavior.

Post a reply to this message

Far as I've known 'clipped_by' behaves similarly to a cut command in an
image processing program, ie. extracts the selected region, discarding
it. I too have thought it opposite the usual way you would want to use
it, but this seems correct if thought of right. Clipping snips off from
the clipped object, unless the surface of the clipping object is
inversed thus making for a collecting instead. Basically it's a
'difference' and 'merge' together sort of thing in my view. By the way I
think 'bounded_by' is intended to be the inversed clipped_by isn't it?


Ron Parker wrote:
> 
> On 27 Apr 1999 13:00:06 -0500, Nieminen Mika <war### [at] cctutfi> wrote:
> >Ron Parker <par### [at] my-dejanewscom> wrote:
> >: This looks like a bug.
> >
> >  It may look like a bug, but certainly this is exactly how it works. It
> >may be an unwanted behaviour, but it's not a bug (ie. a programming mistake).
> 
> Bugs aren't just programming mistakes.  Sometimes they're design mistakes.
> This looks like one of those times.  After all, it is reasonable to do
> what I did, expecting the results I expected.  The results I got are neither
> what I expected (the red box) nor what I perhaps would have expected upon
> further contemplation (the blue box).
> 
> >  Perhaps povray should use a union-like clipped_by when it automatically
> >inverses a clipped object (and of course it should inverse the clipping
> >object too). But is this the wanted behaviour?
> 
> This is exactly what would happen if Inside_Object returned the inverse
> flag for the parent instead of FALSE.  It seems like it wouldn't always
> be the desired behavior, but I'm hard-pressed to find an example of when
> the current behavior would ever be the desired behavior.

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto:inv### [at] aolcom?Subject=PoV-News

Post a reply to this message

Bob Hughes <inv### [at] aolcom> wrote:
: Far as I've known 'clipped_by' behaves similarly to a cut command in an
: image processing program, ie. extracts the selected region, discarding
: it. I too have thought it opposite the usual way you would want to use
: it, but this seems correct if thought of right. Clipping snips off from
: the clipped object, unless the surface of the clipping object is
: inversed thus making for a collecting instead. Basically it's a
: 'difference' and 'merge' together sort of thing in my view. By the way I
: think 'bounded_by' is intended to be the inversed clipped_by isn't it?

  No.
  clipped_by works exactly like the intersection CSG except that it doesn't
render the surface of the second (ie. the clipping) object.
  bounded_by has little, if nothing, to do with CSG. You may think about it
as if it worked like an intersection CSG (but better not since you may get
surprises in some cases).

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I see my mistake, thanks. I was going on the old fashioned 'bounded_by'
which may have been used similarly to the way 'clipped_by' is used. I
neglected the fact that this isn't a certainty as a part of CSG since it
doesn't always keep just the parts within it's boundary (haphazard
containment).
Although that 'bounded_by' has nothing to do with CSG is an incorrect
thing to say. Manual bounding is a desireable thing for differences and
merges to contain just the visible portions and not needlessly trace
rays of invisible parts. 


Nieminen Mika wrote:
> 
> Bob Hughes <inv### [at] aolcom> wrote:
> : Far as I've known 'clipped_by' behaves similarly to a cut command in an
> : image processing program, ie. extracts the selected region, discarding
> : it. I too have thought it opposite the usual way you would want to use
> : it, but this seems correct if thought of right. Clipping snips off from
> : the clipped object, unless the surface of the clipping object is
> : inversed thus making for a collecting instead. Basically it's a
> : 'difference' and 'merge' together sort of thing in my view. By the way I
> : think 'bounded_by' is intended to be the inversed clipped_by isn't it?
> 
>   No.
>   clipped_by works exactly like the intersection CSG except that it doesn't
> render the surface of the second (ie. the clipping) object.
>   bounded_by has little, if nothing, to do with CSG. You may think about it
> as if it worked like an intersection CSG (but better not since you may get
> surprises in some cases).
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto:inv### [at] aolcom?Subject=PoV-News

Post a reply to this message

Bob Hughes <inv### [at] aolcom> wrote:
: Although that 'bounded_by' has nothing to do with CSG is an incorrect
: thing to say. Manual bounding is a desireable thing for differences and
: merges to contain just the visible portions and not needlessly trace
: rays of invisible parts. 

  It's not a CSG specific think. You should also bound manually blobs,
polys, etc. Bounding object are a general feature, not a CSG specific
feature => It has nothing to do with CSG.

-- 
main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

Post a reply to this message

I will concur, this time ;)


Nieminen Mika wrote:
> 
> Bob Hughes <inv### [at] aolcom> wrote:
> : Although that 'bounded_by' has nothing to do with CSG is an incorrect
> : thing to say. Manual bounding is a desireable thing for differences and
> : merges to contain just the visible portions and not needlessly trace
> : rays of invisible parts.
> 
>   It's not a CSG specific think. You should also bound manually blobs,
> polys, etc. Bounding object are a general feature, not a CSG specific
> feature => It has nothing to do with CSG.
> 
> --
> main(i,_){for(_?--i,main(i+2,"FhhQHFIJD|FQTITFN]zRFHhhTBFHhhTBFysdB"[i]
> ):5;i&&_>1;printf("%s",_-70?_&1?"[]":" ":(_=0,"\n")),_/=2);} /*- Warp -*/

-- 
 omniVERSE: beyond the universe
  http://members.aol.com/inversez/homepage.htm
 mailto:inv### [at] aolcom?Subject=PoV-News

Post a reply to this message