POV-Ray : Newsgroups : povray.general : intersection test Server Time
4 Nov 2024 21:25:03 EST (-0500)
  intersection test (Message 1 to 10 of 10)  
From: stevenvh
Subject: intersection test
Date: 12 Apr 2008 15:45:00
Message: <web.48011111c11fed705245d3740@news.povray.org>
Can I use the "intersection" operator as intersection test, i.e. check wether
the result is empty?
TIA
Steven


Post a reply to this message

From: Warp
Subject: Re: intersection test
Date: 12 Apr 2008 16:11:55
Message: <4801178b@news.povray.org>
stevenvh <nomail@nomail> wrote:
> Can I use the "intersection" operator as intersection test, i.e. check wether
> the result is empty?

  No.

-- 
                                                          - Warp


Post a reply to this message

From: Tim Attwood
Subject: Re: intersection test
Date: 13 Apr 2008 18:24:49
Message: <48028831$1@news.povray.org>
>> Can I use the "intersection" operator as intersection test, i.e. check 
>> wether
>> the result is empty?
>
>  No.

Intersection is a keyword for a CSG object in POV.
This should work 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


Post a reply to this message

From: Warp
Subject: Re: intersection test
Date: 14 Apr 2008 06:52:17
Message: <48033760@news.povray.org>
Tim Attwood <tim### [at] comcastnet> wrote:
> This should work though...

  If the intersection of the objects is extremely small, there's a big
chance that your macro won't detect it.

>       #local Pt = VRand_In_Box(Mn, Mx, S1);
>       #local cnt = 0;
>       #while ((result = false) & (cnt < rez))
>          #local Pt = VRand_In_Box(Mn, Mx, S1);

  Why the first Pt? It's not used anywhere.

-- 
                                                          - Warp


Post a reply to this message

From: Tim Attwood
Subject: Re: intersection test
Date: 14 Apr 2008 21:29:26
Message: <480404f6$1@news.povray.org>
>  If the intersection of the objects is extremely small, there's a big
> chance that your macro won't detect it.

The odds are in favor of finding a collision if it's there.
The bounding of the intersection object is used so
the volume tested can be small even though the primary
objects are large. Additionally in cases where the ratio
of intersection volume to testing volume is small the
repeated test should still find most of the collisions.
For example, if a rez of 1000 is used, then a collision
that has a ratio of 1% in the testing volume will be
detected with (1-(0.99^1000)) ~ 99.995% accuracy.

There also will never be a false collision, and if a
collision is missed it's likely to be in a "forgiving"
location where the viewer is likely to not be able to
see it.

>>       #local Pt = VRand_In_Box(Mn, Mx, S1);
>>       #local cnt = 0;
>>       #while ((result = false) & (cnt < rez))
>>          #local Pt = VRand_In_Box(Mn, Mx, S1);
>
>  Why the first Pt? It's not used anywhere.

Hmm, yeah, you're right, not sure what I was thinking,
it's been a while since I wrote it.


Post a reply to this message

From: Nicolas Alvarez
Subject: Re: intersection test
Date: 14 Apr 2008 22:07:59
Message: <48040dff@news.povray.org>
Tim Attwood escribió:
> The bounding of the intersection object is used so
> the volume tested can be small even though the primary
> objects are large.

How do you think POV-Ray would calculate the bounding of an 
intersection? If the primary objects are big, chances are the bounding 
object for the intersection will be a lot bigger than it should be.

> There also will never be a false collision, and if a
> collision is missed it's likely to be in a "forgiving"
> location where the viewer is likely to not be able to
> see it.

Well, it's *random*. Given a sphere (which takes more than half its 
bounding box), it's absolutely possible it will hit everywhere *but* the 
sphere :)

But if you make it clear that your code isn't deterministic, seems good 
enough.


Post a reply to this message

From: stevenvh
Subject: Re: intersection test
Date: 15 Apr 2008 12:45:00
Message: <web.4804da9e32e497e5245d3740@news.povray.org>
Thanks, Tim.
I realize your method doesn't guarantee to always detect a non-empty
intersection, but the odds are good, and for my current project seems to work
well.


Post a reply to this message

From: Tim Attwood
Subject: Re: intersection test
Date: 16 Apr 2008 06:29:50
Message: <4805d51e$1@news.povray.org>
> How do you think POV-Ray would calculate the bounding of an intersection? 
> If the primary objects are big, chances are the bounding object for the 
> intersection will be a lot bigger than it should be.

The bounding of the intersection is the intersection of the
bounding boxes. So for example if you have two spheres...
#declare A = sphere {<0,0,0>,1};
#declare B = sphere {<1.99,0,0>,1};
Then the bounding of the intersection would be
box {<0.99,-1,-1>,<1,1,1>} which has a volume of
0.04, compared to the bounding of the sphere which
has a volume of 8, and the bounding of the union
which is 15.96, the volume of the intersection is
(pi/12)*(4*R+d)*(2R-d)^2 =
(0.261)*(5.99)*(0.0001) = 0.000157
so the ratio of the intersection is 0.00157/0.04 = 0.39%
the accuracy at 1000 tests will be (1-(0.9961^1000)) ~
98%, but at 2000 tests it will be 99.95% accurate.

> Well, it's *random*. Given a sphere (which takes more than half its 
> bounding box), it's absolutely possible it will hit everywhere *but* the 
> sphere :)

The worst case scenario for this macro is long narrow cylinders that
aren't parallel to any axis, in those cases the bounding fails to conform
well to the object. For normal objects the chance of this failing is like
the chance of flipping a coin a thousand times and having it always
come up tails.

> But if you make it clear that your code isn't deterministic, seems good 
> enough.

Since the random generator in POV is deterministic, this will fail
in deterministic ways... it won't introduce jittered movment to an
animation for example, but yeah, it can fail to detect collisions if
the rez used is low. Something like 30000 is enough to detect hard
cases, but it's quite slow for that... I was thinking about re-writing
it to use trace, that might improve the accuracy a bit.


Post a reply to this message

From: Alain
Subject: Re: intersection test
Date: 16 Apr 2008 12:03:11
Message: <4806233f@news.povray.org>
en ce 2008/04/16 06:29 :)   ->

> Since the random generator in POV is deterministic, this will fail
> in deterministic ways... it won't introduce jittered movment to an
> animation for example, but yeah, it can fail to detect collisions if
> the rez used is low. Something like 30000 is enough to detect hard
> cases, but it's quite slow for that... I was thinking about re-writing
> it to use trace, that might improve the accuracy a bit. 
> 
> 
You pick a random point on one of the faces of the bounding box and shoot toward 
the oposite face. Using the smalest face will probably help.
You exit on the first non-zero normal.
Advantage of using trace:
Advantage: you no longer test points but lines. One test will check millons of 
points.

-- 
Alain
-------------------------------------------------
Stay out of my head, its a bad neighborhood.


Post a reply to this message

From: Tim Attwood
Subject: Re: intersection test
Date: 16 Apr 2008 22:59:45
Message: <4806bd21$1@news.povray.org>
> You pick a random point on one of the faces of the bounding box and shoot 
> toward the oposite face. Using the smalest face will probably help.

Yeah, but then you might miss long skinny things aligned that way sometimes.

> You exit on the first non-zero normal.

Yeah, the old one was early exit too, the poorest performance is for non-
collisions since all the checks have to run.

> Advantage of using trace:
> Advantage: you no longer test points but lines. One test will check 
> millons of points.

Yeah, after a few tests it feels a bit more accurate, this should
be able to find collisions with low volume that have a larger surface
area easier too. I'm not sure what the math for figuring out the
failure rate is for this method, theoretically there are an infinite
number of points on a line segment, I guess in practice you could
count them as being points 0.001 apart.

#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 cnt = 0;
      #while ((result = false) & (cnt < rez))
         #local Pt = VRand_In_Box(Mn, Mx, S1);
         #local Norm = <0,0,0>;
         #local Hit = trace(AB,<Pt.x,Mn.y-0.1,Pt.z>,y,Norm);
         #if (vlength(Norm)!=0)
            #local result = true;
         #else
            #local Hit = trace(AB,<Mn.x-0.1,Pt.y,Pt.z>,x,Norm);
            #if (vlength(Norm)!=0)
               #local result = true;
            #else
               #local Hit = trace(AB,<Pt.x,Pt.y,Mn.z-0.1,>,z,Norm);
               #if (vlength(Norm)!=0)
                  #local result = true;
               #end
            #end
         #end
         #local cnt = cnt + 1;
      #end
   #end
   (result)
#end


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.