How can I create a collision detection routine? More specifically, what
do I look at to determine if two objects have collided in pov-space ? I
can figure it out with...say... unit spheres, that is easy, but what
about rotated cubes and more oddly shaped objects??

thank you


paul
-- 



--------------------------------------------------}
Paul Daniel Jones
The Pennslyvania State University

pdj### [at] psuedu
http://research.chem.psu.edu/glassgrp/paul

       C            The way is near, but men
     // \           seek it afar. It is in the
    N    N          easy things, but men seek it
    |    ||         in the difficult things.
    C    C          -Menicius
     \\  /
       C
--------------------------------------------------}

Post a reply to this message

Paul Jones wrote:
> 
> How can I create a collision detection routine? More specifically, what
> do I look at to determine if two objects have collided in pov-space ? I
> can figure it out with...say... unit spheres, that is easy, but what
> about rotated cubes and more oddly shaped objects??
> 

In general that's a very difficult task, one method would be doing a lot
of tests with 'trace'.  

Finding out whether two boxes collide could for example be done by
'tracing' along all their edges.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

On Thu, 22 Feb 2001 16:27:45 +0100, Christoph Hormann wrote:
>In general that's a very difficult task, one method would be doing a lot
>of tests with 'trace'.  

In general, it's an impossible task.  The best you can do is an 
approximation.  For example, try to determine whether the intersection 
of two complex CSG objects is nonempty.

>Finding out whether two boxes collide could for example be done by
>'tracing' along all their edges.  

Even that wouldn't see the special case where one box is entirely enclosed
by the other box.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Christoph Hormann wrote:
> 
> Paul Jones wrote:
> >
> > How can I create a collision detection routine? More specifically, what
> > do I look at to determine if two objects have collided in pov-space ? I
> > can figure it out with...say... unit spheres, that is easy, but what
> > about rotated cubes and more oddly shaped objects??
> >
> 
> In general that's a very difficult task, one method would be doing a lot
> of tests with 'trace'.
> 
> Finding out whether two boxes collide could for example be done by
> 'tracing' along all their edges.

You can limit the number of traces necessary if you first find the
min_extent and max_extent of your objects.  If these don't overlap, then
your objects don't touch one another.  If they do, then you have to
start tracing along the side(s) where the bounding boxes overlap.

Note: You need MegaPOV to do this.

-- 
Francois Labreque |   //\\    Wear an ASCII ribbon!
    flabreque     |  ||  ||   
        @         |   \\//    Support the campain
   videotron.ca        \\     against HTML e-mail
                      //\\    and news!

Post a reply to this message

In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> Even that wouldn't see the special case where one box is entirely enclosed
> by the other box.

But you could use eval_pattern() with the object pattern to catch this 
case...you would still need to use trace() though, because there are 
cases when two boxes intersect but all of their corners are outside.

And if you use a similar method to do collision with meshes, you could 
tesselate (almost) any object with the tesselation patch and use the 
resulting mesh for collision testing. It would be slow (a patch might be 
needed to get a useable speed, like a "objects_intersect(ObjectA, 
ObjectB, ...ObjectX) function), but you could speed it up a little by 
using low-resolution meshes, either as a bounds test or for the actual 
collision detection.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Ron Parker wrote:
> 
> In general, it's an impossible task.  The best you can do is an
> approximation.  For example, try to determine whether the intersection
> of two complex CSG objects is nonempty.

As long as the shapes are basic mathematical objects (like sphere,
cylinder, box, etc.) it is possible to find an precise solution.  Of
course if the objects are approximated themselves (like isosurfaces) it is
not.

> 
> >Finding out whether two boxes collide could for example be done by
> >'tracing' along all their edges.
> 
> Even that wouldn't see the special case where one box is entirely enclosed
> by the other box.
> 

All right, as Chris Huff mentioned you could use eval_pattern and the
object pattern (maybe it would be a good idea to make the Inside_Object()
function available in POV script just like trace()).

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

On Thu, 22 Feb 2001 11:06:32 -0500, Chris Huff wrote:
>And if you use a similar method to do collision with meshes, you could 
>tesselate (almost) any object with the tesselation patch and use the 
>resulting mesh for collision testing. It would be slow (a patch might be 

But that is, as I said, an approximation.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On Thu, 22 Feb 2001 17:19:18 +0100, Christoph Hormann wrote:
>As long as the shapes are basic mathematical objects (like sphere,
>cylinder, box, etc.) it is possible to find an precise solution.  Of
>course if the objects are approximated themselves (like isosurfaces) it is
>not.

Isosurfaces can be viewed as basic mathematical objects for the sake of
this exercise, since the approximation is purely visual.  The problem
of determining whether two "basic mathematical objects" overlap reduces
to a simple matter of solving a set of simultaneous equations and looking
for solutions within given ranges.  Unfortunately, the equations you're
solving aren't necessarily linear or even polynomial.  Presumably it's
possible to solve such a system for any given combination of objects
(though not necessarily) but it's either impossible or ridiculously 
difficult to automate the process for any two arbitrary objects.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker wrote:
> 
> Isosurfaces can be viewed as basic mathematical objects for the sake of
> this exercise, since the approximation is purely visual.  The problem
> of determining whether two "basic mathematical objects" overlap reduces
> to a simple matter of solving a set of simultaneous equations and looking
> for solutions within given ranges.  Unfortunately, the equations you're
> solving aren't necessarily linear or even polynomial.  Presumably it's
> possible to solve such a system for any given combination of objects
> (though not necessarily) but it's either impossible or ridiculously
> difficult to automate the process for any two arbitrary objects.
> 

Seems you are right if you want to make it work for any CSG.  Anyway if
you only need the objects themselves (or unions) it could be reduced to a
set of independent equations.  

After all, whether you need a numerical approximation to solve the problem
is not important in this case.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

Chris Huff wrote:
> 
> And if you use a similar method to do collision with meshes, you could
> tesselate (almost) any object with the tesselation patch and use the
> resulting mesh for collision testing. It would be slow (a patch might be
> needed to get a useable speed, like a "objects_intersect(ObjectA,
> ObjectB, ...ObjectX) function), but you could speed it up a little by
> using low-resolution meshes, either as a bounds test or for the actual
> collision detection.
> 

One could also use the brute force method using eval_pattern on the object
patterns of the two objects in a fine parallel raster...

I'm not even sure if that's slower, because tesselation is not needed.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

On Thu, 22 Feb 2001 17:56:21 +0100, Christoph Hormann wrote:
>
>
>Ron Parker wrote:
>> 
>> Isosurfaces can be viewed as basic mathematical objects for the sake of
>> this exercise, since the approximation is purely visual.  The problem
>> of determining whether two "basic mathematical objects" overlap reduces
>> to a simple matter of solving a set of simultaneous equations and looking
>> for solutions within given ranges.  Unfortunately, the equations you're
>> solving aren't necessarily linear or even polynomial.  Presumably it's
>> possible to solve such a system for any given combination of objects
>> (though not necessarily) but it's either impossible or ridiculously
>> difficult to automate the process for any two arbitrary objects.
>> 
>
>Seems you are right if you want to make it work for any CSG.  Anyway if
>you only need the objects themselves (or unions) it could be reduced to a
>set of independent equations.  

Yes and no.  Some objects, like isosurfaces, blobs, and polys, are fairly
ugly even then.  Other objects, like cubes and cones and cylinders, can 
get fairly ugly after you apply transformations to them.

Even CSG intersections could be handled, if you could handle the solution of
the independent equations.  The problem is that that solution is not easy.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

On Thu, 22 Feb 2001 17:57:43 +0100, Christoph Hormann wrote:
>One could also use the brute force method using eval_pattern on the object
>patterns of the two objects in a fine parallel raster...

Or on the object pattern of the intersection of the two objects.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker wrote:
> 
> Yes and no.  Some objects, like isosurfaces, blobs, and polys, are fairly
> ugly even then.  Other objects, like cubes and cones and cylinders, can
> get fairly ugly after you apply transformations to them.
> 

I was only thinking about spheres, cylinders and objects made of planes
(like boxes) which would result in distances between points, lines and
planes.  I agree that everything else can get really ugly.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3A953C06.F7A4B59D@gmx.de>, Christoph Hormann 
<chr### [at] gmxde> wrote:

> (maybe it would be a good idea to make the Inside_Object()
> function available in POV script just like trace()).

I haven't done it before, since this macro is pretty easy:
#macro InObj(Pt, Obj) eval_pattern(object {Obj}, Pt) #end

But all it should take is adding a "inside_object" token to parse.h and 
tokenize.c, and adding this case to Parse_Num_Factor() in express.c 
(make sure you put it with the float functions):
          case INSIDE_OBJECT_TOKEN:
          {
            OBJECT * Object; 
            VECTOR Point;

            GET(LEFT_PAREN_TOKEN);
            Parse_Vector(Point);
            Parse_Comma();
            EXPECT
                CASE(OBJECT_ID_TOKEN)
                    Object = Token.Data;
                    EXIT
                END_CASE
                OTHERWISE
                    Object = NULL;
                    UNGET
                    EXIT
                END_CASE
            END_EXPECT
            if(Object == NULL)
            {   Error ("Object Identifier Expected.");}
            GET(RIGHT_PAREN_TOKEN);
            
            Val = Inside_Object(Point, Object);
          }
          break;

I haven't tested this patch (I haven't even compiled it), but it should 
work.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:
> 
> I haven't done it before, since this macro is pretty easy:
> #macro InObj(Pt, Obj) eval_pattern(object {Obj}, Pt) #end
> 
> But all it should take is adding a "inside_object" token to parse.h and
> tokenize.c, and adding this case to Parse_Num_Factor() in express.c
> (make sure you put it with the float functions):
> [...]
> 
> I haven't tested this patch (I haven't even compiled it), but it should
> work.
> 

The hardcoded version would probably be much faster so i think it's quite
a good idea when it should be used for collision detection where it would
be called quite often.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3A9550F9.80FAA811@gmx.de>, Christoph Hormann 
<chr### [at] gmxde> wrote:

> The hardcoded version would probably be much faster so i think it's quite
> a good idea when it should be used for collision detection where it would
> be called quite often.  

The patch I posted compiled and ran fine.
I tested the speed with a file that called the function or macro 64^3 
(262144) times.
The macro version used 238 seconds, and the function version used 208 
seconds, so the function version takes about 87% as long as the macro.

It seems macros don't have that much overhead...at least, the MegaPOV 
macros, which have been optimized. However, in a collision detection 
algorithm, which could easily use even more calls, this small 
improvement would still be helpful.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

In article <chrishuff-99F94F.13380822022001@news.povray.org>, Chris 
Huff <chr### [at] maccom> wrote:

> The macro version used 238 seconds, and the function version used 208 
> seconds, so the function version takes about 87% as long as the macro.

I decided to do a more accurate calculation by subtracting out the 
"overhead" of the rest of the scene (by replacing the call to the macro 
or function with a 0), and found out a surprisingly large portion of the 
time was spent in the loops themselves...and the function is a great 
deal faster than the macro.
The scene with no calls but the same number of repetitions used 204 
seconds, so the total time used by the function was 4 seconds and the 
total time used by the macro was 34 seconds. The function only takes 
about 11.7% as long as the macro...nearly 10 times faster.

Which figure is more relevant? The 11.7% is a better comparison of the 
speed of the macro with the speed of the function, but the 87% figure is 
closer to what you will see in real life...you will probably have the 
call nested in a bunch of loops and other macro calls. Only a small 
portion of the time was actually spent in the macro/function call.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

On Thu, 22 Feb 2001 13:55:25 -0500, Chris Huff wrote:
>> The macro version used 238 seconds, and the function version used 208 
>> seconds, so the function version takes about 87% as long as the macro.
>
>I decided to do a more accurate calculation by subtracting out the 
>"overhead" of the rest of the scene (by replacing the call to the macro 
>or function with a 0), and found out a surprisingly large portion of the 
>time was spent in the loops themselves...and the function is a great 
>deal faster than the macro.

If we're gonna add functions, might as well make one that does the whole
apprxomated-collision-detection operation, especially if loops are that
slow.

-- 
Ron Parker   http://www2.fwi.com/~parkerr/traces.html
My opinions.  Mine.  Not anyone else's.

Post a reply to this message

Ron Parker wrote:
> 
> If we're gonna add functions, might as well make one that does the whole
> apprxomated-collision-detection operation, especially if loops are that
> slow.
> 

You mean something like:

collide(object, object, method, accuracy)

returning 1 or 0 for collision or no collision?

It yould be useful, but what's really needed in most cases is a function
returning where an object collides with another one if it is moved in a
certain way.  This would mean something like 'trace' with an additional
object parameter. 

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <slr### [at] fwicom>, ron### [at] povrayorg 
wrote:

> If we're gonna add functions, might as well make one that does the whole
> apprxomated-collision-detection operation, especially if loops are that
> slow.

Agreed...a collision detection algorithm that works this way written 
entirely in POV-Script would likely be almost unbearably slow.


In article <3A9### [at] gmxde>, Christoph Hormann 
<chr### [at] gmxde> wrote:

> It yould be useful, but what's really needed in most cases is a function
> returning where an object collides with another one if it is moved in a
> certain way.  This would mean something like 'trace' with an additional
> object parameter. 

One little problem...how do you define "where an object collides with 
another one"? This will most likely not be a point.
Or do you mean a function that checks if objects *will* collide and 
returns the first point of contact? You might as well just implement a 
general kinetics system in POV. I've considered something like this, a 
system that would handle solid objects, cloths and strings, and fluid 
particles, all interacting with each other, but it would be a lot of 
work. It'd make some fun animations, though. :-)

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

Chris Huff wrote:
> 
> One little problem...how do you define "where an object collides with
> another one"? This will most likely not be a point.
> Or do you mean a function that checks if objects *will* collide and
> returns the first point of contact? You might as well just implement a
> general kinetics system in POV. I've considered something like this, a
> system that would handle solid objects, cloths and strings, and fluid
> particles, all interacting with each other, but it would be a lot of
> work. It'd make some fun animations, though. :-)
> 

I meant the first contact, what happes afterwards is also influenced by
the mass distribution in the object and therefore quite tricky (one could
use a povray pattern for defining an inhomogeneous distribution of course,
would involve some very time consuming integration ...)

BTW, what happens after the second contact is easier again, you only have
to know the center of mass for that (as long as you don't need the
accurate description of movement for an animation).  

The rest of the things you suggested sounds really complicated, most known
techniques for modelling those things would require tesselation of the
objects BTW.  It would sound quite reasonable to me to restrict things to
movement of solid bodies without elasticity.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

"Ron Parker" <ron### [at] povrayorg> wrote in message
news:slr### [at] fwicom...
>
> Or on the object pattern of the intersection of the two objects.
>

Presumably the answer is "No", but is it possible to test directly whether
the intersection of two objects actually resulted in any actual shape (a
collision) or not?

Post a reply to this message

In article <3a9629a5@news.povray.org>, "Tom Melly" <tom### [at] tomandlucouk> 
wrote:

> Presumably the answer is "No", but is it possible to test directly whether
> the intersection of two objects actually resulted in any actual shape (a
> collision) or not?

"No"
You will have to do something like scan across the intersection of the 
bounding boxes with trace() or inside_object() (or the InObj() macro) to 
find out if there is anything left. And then there is the possibility 
that you simply missed it because you didn't scan the bounding area at a 
high enough resolution, and it would be slow, even if patched into 
POV...and you wouldn't be able to detect if an object just touches 
another this way.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-E536A4.05255923022001@news.povray.org...
> In article <3a9629a5@news.povray.org>, "Tom Melly" <tom### [at] tomandlucouk>
> wrote:
>
> > Presumably the answer is "No", but is it possible to test directly
whether
> > the intersection of two objects actually resulted in any actual shape (a
> > collision) or not?
>
> "No"


Hmm, okay. How about this - if I render the following object:

#declare X=0.99;//1.1

intersection{
  sphere{0, 1 translate x*-X}
  sphere{0, 1 translate x*X}
  pigment{Red}
}

I will see at the end of render "CSG Intersection succeeded = 0 " (if X>=1)
or a positive value (if X<1).

Now, for collision detection, we are not interested in textures or
resolution. Would it not be fairly easy (?!?) to write a patch that would
render two objects as an intersection and return the CSG intersection
succeeded value?

The "render" would not have to produce any image output and all textures,
media, photons, radiosity, etc. could be ignored to speed up the process.

Would this be slower/harder to implement than any of the other suggestions?

Post a reply to this message

Tom Melly wrote:
> 
> [...]
> 
> I will see at the end of render "CSG Intersection succeeded = 0 " (if X>=1)
> or a positive value (if X<1).
> 
> Now, for collision detection, we are not interested in textures or
> resolution. Would it not be fairly easy (?!?) to write a patch that would
> render two objects as an intersection and return the CSG intersection
> succeeded value?
> 
> The "render" would not have to produce any image output and all textures,
> media, photons, radiosity, etc. could be ignored to speed up the process.
> 
> Would this be slower/harder to implement than any of the other suggestions?

Rendering in this case does nothing more than searching for intersection
in a certain raster like the method i suggested. The problems are the
same, if the intersection is too small in relation to the render
resolution or the object is not visible in the render camera, the result
will be wrong.  Furthermore scanning the whole camera angle is much less
efficient than scanning only the intersection of the bounding boxes.

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

"Christoph Hormann" <chr### [at] gmxde> wrote in message
news:3A965EBF.EDD947E8@gmx.de...
>
> Rendering in this case does nothing more than searching for intersection
> in a certain raster like the method i suggested. The problems are the
> same, if the intersection is too small in relation to the render
> resolution or the object is not visible in the render camera, the result
> will be wrong.  Furthermore scanning the whole camera angle is much less
> efficient than scanning only the intersection of the bounding boxes.
>

Ah - a couple of thoughts occur.

1. If the intersection is too small, I suppose for most purposes it can be
ignored since it won't be apparent to the observer that something went
wrong.

2. What will happen to "off-stage" collisions? Does your suggestion
calculate collisions even if the relevant objects are off the screen and not
reflected? Would mine?

Post a reply to this message

Tom Melly wrote:
> 
> 2. What will happen to "off-stage" collisions? Does your suggestion
> calculate collisions even if the relevant objects are off the screen and not
> reflected? Would mine?

Your 'rendering solution' needs a camera to be specified and therefore
misses everything not in the view of that camera.  Using the bounding
boxes does not have this problem.  

Christoph

-- 
Christoph Hormann <chr### [at] gmxde>
IsoWood include, radiosity tutorial, TransSkin and other 
things on: http://www.schunter.etc.tu-bs.de/~chris/

Post a reply to this message

In article <3a965931$1@news.povray.org>, "Tom Melly" 
<tom### [at] tomandlucouk> wrote:

> Hmm, okay. How about this - if I render the following object:
> 
> #declare X=0.99;//1.1
> 
> intersection{
>   sphere{0, 1 translate x*-X}
>   sphere{0, 1 translate x*X}
>   pigment{Red}
> }
> 
> I will see at the end of render "CSG Intersection succeeded = 0 " (if 
> X>=1) or a positive value (if X<1).
> 
> Now, for collision detection, we are not interested in textures or
> resolution. Would it not be fairly easy (?!?) to write a patch that would
> render two objects as an intersection and return the CSG intersection
> succeeded value?
> 
> The "render" would not have to produce any image output and all textures,
> media, photons, radiosity, etc. could be ignored to speed up the process.

I'm not sure what you mean...are you talking about the render 
statistics, and a setting that makes it simulate rendering without 
actually generating an image or computing textures? That statistic is 
just the number of rays from the camera that hit an intersection, not 
whether there was something left from the intersection or not. Using it 
for collision detection wouldn't work very well, the results would 
depend on whether the objects are visible, how far away they are, how 
large they are, what resolution you are rendering at, etc...it would be 
much more efficient to just code a function that scans the bounding box 
of the object with rays and/or insideness tests.

-- 
Christopher James Huff
Personal: chr### [at] maccom, http://homepage.mac.com/chrishuff/
TAG: chr### [at] tagpovrayorg, http://tag.povray.org/

<><

Post a reply to this message

"Chris Huff" <chr### [at] maccom> wrote in message
news:chrishuff-27B695.09243523022001@news.povray.org...

<SNIP>

So I gathered - I was more being curious rather than proposing a viable
solution. In a slightly related question, is it possible to return a
true/false as to whether any particular point is in the view of the camera
or not (ignoring reflections)?

Post a reply to this message

Francois Labreque wrote:

> You can limit the number of traces necessary if you first find the
> min_extent and max_extent of your objects.

My volume macro relies on eval_pattern.   To the accuracy you require, it gives
you the volume of an object.  If you have "all day," it can sit there and tell
the intersection of two objects based on the volume of their intersection.

> Paul Jones wrote:
> How can I create a collision detection routine?

There are several applications where a "field repulsion" gives the desired
effect.  Are you shooting birds (true collision detection req'd) or do you have
a flock that's trying to avoid collisions?  If you have the latter, see:
http://www.geocities.com/pterandon/boids.html

Post a reply to this message