 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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] simberon com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
TinCanMan wrote:
>
> "David Buck" <dav### [at] simberoncom> wrote in message
> > 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).
Won't this work only if your walls and floors are parallel to the X, Y,
or Z axes?
David Buck
Simberon Inc.
www.simberon.com
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"David Buck" wrote:
> 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:
In my particle system barriers can only be sensed using the trace function
in POV-Ray 3.5. Thus I have no way of knowing the distance from a particle
to a barrier.
> 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.
Though I'm not 100% sure, I think my system can handle that, but again, I
think it works fundamentally different than yours.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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...
Couldn't you add the radius value in all directions (or at least some of
them) and see if any radii touch the obstacle?
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Mahalis" wrote:
> Couldn't you add the radius value in all directions
> (or at least some of them) and see if any radii touch
> the obstacle?
If you're referring to the method JRG describes, then yes, I could do that,
but it would make the calculations at least 5 times slower and still not
produce very accurate results.
Rune
--
3D images and anims, include files, tutorials and more:
Rune's World: http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users: http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
> "Tim Nikias" wrote:
> > If you have the direction the particle is heading,
> > why don't you do a "axis-check"?
>
> > On the other hand, that might become pretty
> > parsing-intensive...
>
> Yes, and even so, it's not very precise. That's why I don't like it.
>
> And in most of the simulations I do, it won't make a difference anyway.
> Remember that solid objects is just one out of many uses. For liquids, fire,
> smoke, sparks etc. it doesn't matter at all.
Sigh. I bit the bullet too, and decided that precise testing involved too much
trace testing, and was probably not worth the effort. The centre is all that
matters in my system :-(
MJL
--
light_source{12*(y-z)rgb 2fade_distance 9fade_power 2area_light x,z,5,5}#macro A
(H,B,R,T)prism{0,1H+4,0u*9,9v*9,0#local I=1;#while(I<H)#local V=asc(substr(B,I,1
))-33;<div(V,10)mod(V,10)>#local I=I+1;#end pigment{red 1}rotate-<90,R>translate
-T}#end A(16"/.@VZno=<PLA89/"0,5*x)A(14",6;MWmhryXN3,"60<15,0,8>)camera{location
25*(y-z)look_at 0}A(8"6hiAG=6"-60,-10*x)box{-99(x+z)*99 pigment{rgb 1}} // MJL
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
David Buck wrote:
> 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).
Yep, ran into that problem myself. My solution was to avoid it completely. Maybe
everyone trying to get a particle system running should post examples like this,
that is, difficult situations, so that we can work together on solutions.
MJL
--
light_source{12*(y-z)rgb 2fade_distance 9fade_power 2area_light x,z,5,5}#macro A
(H,B,R,T)prism{0,1H+4,0u*9,9v*9,0#local I=1;#while(I<H)#local V=asc(substr(B,I,1
))-33;<div(V,10)mod(V,10)>#local I=I+1;#end pigment{red 1}rotate-<90,R>translate
-T}#end A(16"/.@VZno=<PLA89/"0,5*x)A(14",6;MWmhryXN3,"60<15,0,8>)camera{location
25*(y-z)look_at 0}A(8"6hiAG=6"-60,-10*x)box{-99(x+z)*99 pigment{rgb 1}} // MJL
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Perhaps it would be a good idea to send at least one extra trace() which
is just slightly off the original direction. You can do this one only if the probable
rebounce position is already in direct vicinity. If the two gathered normals
differ too much, perhaps you have an idea on what's going on?
It's just an idea. Not too parsing intensive, I guess, but perhaps some more thinking
would do a better trick.
Tim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
