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