Hey

Lets say I'm making an animation with a ball kicking about in a box -
obviously the ball needs to bounce off the box which is ok if I know the
dimensions of the box. But lets suppose I don't. So how do I achieve
collision detection?

I have a feeling that the answer lies in the trace() function but after
reading and re-reading the docs I still don't understand the concept. Is
there any tutorials anywhere for this sort of thing?

Thanks
jim

Post a reply to this message

In article <3c9cbc3b@news.povray.org>,
 "jimbobjim" <jim### [at] blueyondercouk> wrote:

> I have a feeling that the answer lies in the trace() function but after
> reading and re-reading the docs I still don't understand the concept. Is
> there any tutorials anywhere for this sort of thing?

Trace just finds the intersection point of a ray (a line originating 
from a single point and going infinitely in one direction) and an 
object. What are you having trouble with?

For collision checking between a sphere and a box, you could trace a 
bunch of rays fairly evenly over the surface of the sphere and check for 
any intersection points inside the sphere. That would mean the sphere is 
partially going through the box...use enough points and small enough 
time intervals for your simulation and the amount of overlap shouldn't 
be a problem. This would also work for any other object...but it will be 
slow parsing.
If it is always in an axis-aligned box, you can speed it up a lot by 
only shooting 6 rays (one at each face of the box) or by using the 
min_extent() and max_extent() functions. You could do this once at the 
very beginning of the simulation to get the dimensions of the box, and 
use that in your calculations. What I'm wondering is how you can specify 
a box and not know its dimensions...what are you doing?

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

"Christopher James Huff" <chr### [at] maccom> wrote
<snip>
>...What I'm wondering is how you can specify
> a box and not know its dimensions...what are you doing?

The idea is to create system whereby the ball can be placed in any scene
with some start velocity (or just dropped + gravity) and it interact with
objects in the scene in the correct physical manner. e.g. rolls down slopes,
bounces off obstacles, etc...I would therefore need some "on the fly"
collision detection or a method of knowing where every surface is in a scene
is beforehand. It seems to me that the on the fly method is best.

I have the physics and math figured but not the collision detection.

thanks
jim

As an aside, it occurred to me that once it's up and running many spheres
could be modelled to form a blob that would perhaps look like liquid flow.
Although I don't know about the validity of this idea.

Post a reply to this message

jimbobjim said:

> As an aside, it occurred to me that once it's up and running many spheres
> could be modelled to form a blob that would perhaps look like liquid flow.
> Although I don't know about the validity of this idea.

This idea has been done before, look at the various particle-systems
written by several users, like Rune, JRG and myself. While most (if not
all) use I/O systems, which calculates collisions sort of "on the fly",
I am using non-I/O, which ties my possibilities for collisions to a
box...
In binaries.animations you'd find many mpg with particle interactions,
on my homepage you'd find some examples of my system.

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html

Post a reply to this message

In article <3C9DC399.CAEE1445@gmx.de>, Tim Nikias <tim### [at] gmxde> 
wrote:

> This idea has been done before, look at the various particle-systems
> written by several users, like Rune, JRG and myself. While most (if not
> all) use I/O systems, which calculates collisions sort of "on the fly",
> I am using non-I/O, which ties my possibilities for collisions to a
> box...

Huh? Using file I/O is just a way to avoid recalculating the particles 
for each frame, it has nothing to do with what you can compute 
collisions with.

-- 
Christopher James Huff <chr### [at] maccom>
POV-Ray TAG e-mail: chr### [at] tagpovrayorg
TAG web site: http://tag.povray.org/

Post a reply to this message

Christopher James Huff wrote:

> Huh? Using file I/O is just a way to avoid recalculating the particles
> for each frame, it has nothing to do with what you can compute
> collisions with.

Sure, sure. You're right on that matter, but I was referring to
his idea using several of his "bouncing balls" as blobs and
simulating liquid with that.

--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html

Post a reply to this message

"Christopher James Huff" wrote:
> Huh? Using file I/O is just a way to avoid recalculating
> the particles for each frame, it has nothing to do with
> what you can compute collisions with.

True.

However, Tim Nikias' particle system is not only non I/O, it's actually non
calc-frame. It doesn't recalculate the data for each particle a certain
number of times per time unit to get the cumulated result at a given time.
Instead it directly returns the position (and other data) for a particle for
a given time, without having to first calculate its history, and this is
100% accurate, unlike calc-frame based systems. Gravity is for example a
parabolic function. However, the complexity is limited with this method.
Collision detection is only feasible with planes, in and Tim Nikias' system
only with a single box. Chaotic-like simulations, where the result for a
given time is highly unpredictable, are also practically impossible.

(Please correct me if I'm wrong at any of this.)

So, in conclusion, a non calc-frame system has both advantages and
disadvantages.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:  http://rsj.mobilixnet.dk (updated Feb 16)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Ring:  http://webring.povray.co.uk

Post a reply to this message

Yeah, just what I meant to say...


--
Tim Nikias
Homepage: http://www.digitaltwilight.de/no_lights/index.html

Post a reply to this message