POV-Ray : Newsgroups : povray.binaries.animations : Particle Algorithms : Re: Particle Algorithms Server Time
20 Jul 2024 07:27:26 EDT (-0400)
  Re: Particle Algorithms  
From: TinCanMan
Date: 8 Dec 2001 22:29:59
Message: <3c12dab7$1@news.povray.org>
"David Buck" <dav### [at] simberoncom> wrote in message
news:3C12D101.861968FA@simberon.com...
> Rune wrote:
>
> > "Tim Nikias" wrote:
> > > If you shoot a particle in an angle, and the position
> > > calculated for the particle does just not touch the
> > > ceiling, but the radius of the particle does, how do
> > > you do that?
> >

> >
> > My particle system does indeed only do collision detection using the
center
> > point of the particle as reference. I don't think there's much I can do
> > about that unfortunately...
>
> In ElastoLab, I actually test to see if the center of the particle comes
within
> the radius distance of any barrier.  If anyone is interested in the math,
I put
> the following comment into the code:
>
>  // Derivation:
>  // We want to find time t where:
>  //   (locationOfParticle(t) - barrierPoint) . n = r
>  //   (lastLocation + (location - lastLocation) t - barrierPoint) . n = r
>  //   (lastLocation - barrierPoint) . n + (location - lastLocation) t .n =
r
>  //   t = (r - (lastLocation - barrierPoint) . n) / ((location -
lastLocation)
> . n)
>  //   t = (r - (lastLocation . n) + (barrierPoint . n)) / ((location -
> lastLocation) . n)
>  // If
>  //   barrierOffset = -(barrierPoint . n)
>  // Then we can write:
>  //   t = (r - (lastLocation . n) - barrierOffset) / ((location -
lastLocation)
> . n)
>  // If dot1 = (location - lastLocation) . n,
>  //   t = r/dot1 - ((lastLocation . n) + barrierOffset)/dot1
>
> Another interesting case is when a particle hits a corner.  The normal for
the
> "reflection" of the particle depends on the exact point of the particle
that
> hit the corner.
>
> Yet another interesting case is when you have two barriers that form an X
shape
> and you drop the particle into the top of the X.  It should come to rest
just
> above the center of the X.  It's very hard to prevent the particle from
falling
> through.
>
> (If anyone has a good solution for that, I'd love to see it.  The only
good
> solution I've seen involves solving sets of linear equations inside a
triple
> nested loop).
>
> David Buck
> Simberon Inc.
> dav### [at] simberoncom
>
>
I have been working on a simple particle (ball actually) simulator that
simulates balls bouncing, colliding, whatever within an area.  I did have
problems with balls 'sinking' through floors and solid objects because of
gravity influence, but what I did to overcome that was add an extra property
(3 actually, x,y,z) to each ball that indicated a dead ball in each axis
direction.  When a ball collides with a solid object, if it gains no
momentum in one given axis, this flag is set to true (deadball) and
gravitational acelleration has no influence on it in that direction (if
another ball hits it, though, it gains the momentum back and the flag is
reset).  The problem I have is with balls themselves.  When they start to
settle and are sitting three or four deep, they start sinking into each
other. I don't have any solution for this yet that (that doesn't compromise
the effieciency of the program). The only way I can think of is, as you
suggested, several nested loops but this adds considerably to the
calculation times.  I also increase the number of iterations between drawing
cycles because (with VB anyways) the program calculates a lot faster than it
draws, so I will do perhaps five calculation cycles per drawing cycle.

-tgq


Post a reply to this message

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