For those who have written particle systems: I'm using trace() and a large
number of collisions are missed.  How can I ensure that collisions are
detected?

Here's my collision handling macro:

#macro detect(X,Xold,V,T,elast,r)
  #local N=<0,0,0>;
  #local dir=X-Xold;
  #local contact=trace(blockobj,X,dir+vnormalize(dir)*r,N);
  #if(vlength(N)>0 & vlength(contact-X)<vlength(dir))
      #declare
V=((V-vnormalize(N)*vdot(V,N))-vnormalize(N)*vdot(V,N))*elast;
      #declare X=Xold;
  #end
#end

Post a reply to this message

> For those who have written particle systems: I'm using trace() and a large
> number of collisions are missed.  How can I ensure that collisions are
> detected?

Welcome to hell.

If you're having multiple particles moving at the same time, you can't rely
on trace to see if they intersect; that only works when only one of them is
moving. You have to analytically solve for the time at which the distance
between the centers of two particles is equal to the sum of their radii.

Then, if you want it to work for more than two particles, you have to make
sure that after a collision is handled, you recheck the particles that
bounced...

It gets pretty messy.

 - Slime
[ http://www.slimeland.com/ ]

Post a reply to this message

Slime <slm### [at] slimelandcom> wrote:
> If you're having multiple particles moving at the same time, you can't rely
> on trace to see if they intersect; that only works when only one of them is
> moving. You have to analytically solve for the time at which the distance
> between the centers of two particles is equal to the sum of their radii.

  And that's with spheres. If you are making, for example, a billiards game
simulation, that's enough.
  However, if the objects are not spheres, you will be asking even for
more trouble... :)

  I think that the "big boys" of CG use programs which cost lot$ and lot$ of
money for their animations with full collision detection of objects (I suppose
which are made of triangles or NURBS).
  And I suppose that even those programs can't calculate everything in
real-time...

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

On 6 Dec 2002 07:36:09 -0500, Warp <war### [at] tagpovrayorg> wrote:

>  I think that the "big boys" of CG use programs which cost lot$ and lot$ of
>money for their animations with full collision detection of objects 

Actually the big boys usually make the programs themselves. Many of
the world's leaders in physically based modeling are now employed in
such companies.

>(I suppose which are made of triangles or NURBS).

DNURBS seems to be the latest hype. It's a type of NURBS where the
same equations are used for modeling the shape and its dynamics. Very
clever... I believe Terzopoulos is behind it (again :) ).

>  And I suppose that even those programs can't calculate everything in
> real-time...

Not really realtime... However, most of the algorithms employed are
extremely well suited for parallelization, and you know what they
usually use in big productions :)


Peter Popov ICQ : 15002700
Personal e-mail : pet### [at] vipbg
TAG      e-mail : pet### [at] tagpovrayorg

Post a reply to this message

I think dividing objects into meshes and particles make things easier with
complex objects. A set of particles connected with very stiff springs are
lots of work to calculate, but fairly easy to implement and to work with. As
long as the object (which is made of those particles) don't deform too much,
people won't see it. But it's SLOW!

"Warp" <war### [at] tagpovrayorg> wrote in message
news:3df099b9@news.povray.org...
> Slime <slm### [at] slimelandcom> wrote:
> > If you're having multiple particles moving at the same time, you can't
rely
> > on trace to see if they intersect; that only works when only one of them
is
> > moving. You have to analytically solve for the time at which the
distance
> > between the centers of two particles is equal to the sum of their radii.
>
>   And that's with spheres. If you are making, for example, a billiards
game
> simulation, that's enough.
>   However, if the objects are not spheres, you will be asking even for
> more trouble... :)
>
>   I think that the "big boys" of CG use programs which cost lot$ and lot$
of
> money for their animations with full collision detection of objects (I
suppose
> which are made of triangles or NURBS).
>   And I suppose that even those programs can't calculate everything in
> real-time...
>
> --
> #macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb
x]
> [1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
> -1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// -
Warp -

Post a reply to this message