NEWS wrote:
> i check the bounding  of the intersection ... and not the intersection of 2
> bounding ...

   That doesn't tell whether the objects are intersecting or not,
only if their bounding boxes are.

   There's no reasonable way for POV-Ray to tell for sure if two
objects are intersecting or not.

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> NEWS wrote:
> > i check the bounding  of the intersection ... and not the intersection of 2
> > bounding ...
>
>    That doesn't tell whether the objects are intersecting or not,
> only if their bounding boxes are.
>
>    There's no reasonable way for POV-Ray to tell for sure if two
> objects are intersecting or not.

What's the disadvantage of what I suggested?  Instead of checking for the
intersecting of bounding boxes, check the min and max extents of a CSG
intersection.  The only odd part is when I test it, when there is no
intersection, the min-max is not zero, but a very large number, but this
should still be usable, basically check the min-max of a CSG intersection
vs the min-max of a CSG union.

-tgq

Post a reply to this message

>    There's no reasonable way for POV-Ray to tell for sure if two
> objects are intersecting or not.

Ah, but there are always the unreasonably cumbersome ways to know whether it
is likely.... You can also render that CSG difference scaled to fit the
screen and have your pet monkey tell you whether it sees any color....  Or
you could make use of a trace, or feed the above rendering back in and use
eval_pigment instead of the monkey.

Who needs "reasonable"? :)

Charles

Post a reply to this message

Thanks to all who tried to help. If I come up with anything that works
fairly well,I will certainly post it.

To Charles: Sadly, my monkey is not availble to assist.  He was busy trying
to type out "Hamlet" and got as far as "... To be or not to be; that is the
qestibjdkjnmksyg..." when he threw up is arms in disgust and walked off to
get drunk with an infinite number of chums.

Best wishes to all,
-Mike C.

Post a reply to this message

"Trevor G Quayle" <Tin### [at] hotmailcom> wrote:
> Warp <war### [at] tagpovrayorg> wrote:
> > NEWS wrote:
> > > i check the bounding  of the intersection ... and not the intersection of 2
> > > bounding ...
> >
> >    That doesn't tell whether the objects are intersecting or not,
> > only if their bounding boxes are.
> >
> >    There's no reasonable way for POV-Ray to tell for sure if two
> > objects are intersecting or not.
>
> What's the disadvantage of what I suggested?  Instead of checking for the
> intersecting of bounding boxes, check the min and max extents of a CSG
> intersection.  The only odd part is when I test it, when there is no
> intersection, the min-max is not zero, but a very large number, but this
> should still be usable, basically check the min-max of a CSG intersection
> vs the min-max of a CSG union.
>
> -tgq

ok, I did some more testing and it doesn't always work, I guess I just got
lucky with the first couple tests I tried...

-tgq

Post a reply to this message

Testing the min_extent (or max_extent) of the intesetion of the two objects
seems to work pretty well.

In the example below, "TheBox" will intersect "TheSphere" iff "SphereRadius"
has a magnitude of 1 or more.

===============================================
#declare SphereRadius = 1;      //Just big enough
#declare TheBox = box{<1,1,1>,<-1,-1,-1>}
#declare TheSphere = sphere{<2,0,0>,SphereRadius}
#declare TestThing = intersection{object{TheBox} object{TheSphere}}

#if (min_extent(TestThing).x > -1000000)
        #warning "Yes, they intersect."
#else
        #warning "No, they do not intersect."
#end
===============================================
produces: "Parse Warning: Yes, they intersect."

AND

===============================================
#declare SphereRadius = .999999;       //Just too small
#declare TheBox = box{<1,1,1>,<-1,-1,-1>}
#declare TheSphere = sphere{<2,0,0>,SphereRadius}
#declare TestThing = intersection{object{TheBox} object{TheSphere}}

#if (min_extent(TestThing).x > -1000000)
        #warning "Yes, they intersect."
#else
        #warning "No, they do not intersect."
#end
===============================================
produces: "Parse Warning: No, they do not intersect."


In a further experiment, where one of the test objects was a slightly more
complex object (a union of several spheres) the results remained
consistent.  This method seems quite sufficient for my purpose.  (Which, by
the way, is filling a box with "packing peanuts" turned every which way so
that no two "peanuts" will occupy the same space.)

Thanks again to all who contributed.

-Mike C.

Post a reply to this message

Mike the Elder wrote:
> Testing the min_extent (or max_extent) of the intesetion of the two objects
> seems to work pretty well.

   It works pretty well if it's enough to see if the bounding boxes
of the objects intersect.
   However, bounding box is not the same as the object. In some cases
the bounding boxes may intersect but the objects don't.

Post a reply to this message

Mike the Elder wrote:
> To Charles: Sadly, my monkey is not availble to assist.  He was busy trying
> to type out "Hamlet" and got as far as "... To be or not to be; that is the
> qestibjdkjnmksyg..." when he threw up is arms in disgust and walked off to
> get drunk with an infinite number of chums.

And to meet up with Bob Newhart, I suppose??     ;-)

      -=- Larry -=-

Post a reply to this message

Warp <war### [at] tagpovrayorg> wrote:
> Mike the Elder wrote:
> > Testing the min_extent (or max_extent) of the intesetion of the two objects
> > seems to work pretty well.
>
>    It works pretty well if it's enough to see if the bounding boxes
> of the objects intersect.
>    However, bounding box is not the same as the object. In some cases
> the bounding boxes may intersect but the objects don't.

Warp is, of course, correct about this. Two shperes of radius 1 located at
<-1,-1,-1> and <1,1,1> read incorrectly as intersecting when it is just
their bounding boxes that touch.  For the "packing peanut" problem,
however, the min_extent test method, combined with some fudged tolerances
for moving each new "peanut" just a bit past the first point of positive
itersection testing SHOULD (I hope) provide a way of piling up a bunch of
them in a more efficient manner than placing hundres of them individually.
Designing the individual "peanut" in such a way that it mostly fills a box
sould also help.

Best Wishes All,
- MIke C.

Post a reply to this message

> you could make use of a trace, or feed the above rendering back in and use
> eval_pigment instead of the monkey.

Who needs a monkey when you have a computer?
This isn't perfect, as Warp pointed out, sometimes this method will fail
to detect intersecting objects. Mostly it works though.

#include "rand.inc"

#macro collision(A B rez)
   #local result = false;
   #if (((min_extent(A).x > max_extent(B).x ) |
         (min_extent(B).x > max_extent(A).x ) |
         (min_extent(A).y > max_extent(B).y ) |
         (min_extent(B).y > max_extent(A).y ) |
         (min_extent(A).z > max_extent(B).z ) |
         (min_extent(B).z > max_extent(A).z ))=false)
      #local AB = intersection{object{A} object{B}};
      #local Mn = min_extent(AB);
      #local Mx = max_extent(AB);
      #local S1 = seed(1);
      #local Pt = VRand_In_Box(Mn, Mx, S1);
      #local cnt = 0;
      #while ((result = false) & (cnt < rez))
         #local Pt = VRand_In_Box(Mn, Mx, S1);
         #if (inside(AB, Pt))
            #local result = true;
         #end
         #local cnt = cnt + 1;
      #end
   #end
   result
#end

#declare sample1 = union {
   box {<0,0,0>,<1,1,1>}
   sphere{<0,1,0>,0.1}
   pigment{Red}
};

#declare sample2 = union {
   box {<0,0,0>,<1,1,1>}
   sphere{<1,0,0>,0.1}
   sphere{<0,0,0>,0.1}
   pigment{Blue}
   translate <-1.05,0.25,0>
};

#local result = collision(sample1 sample2 1000);

Post a reply to this message