 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Yet me again!
I've been thinking about trace() and particles, and I wondered.
Particles fly in parabolas as gravity affects them squared, not linear,
so how do you actually calculate rebounces with trace()?
For one, you could shoot several trace()s for the particle while
it moves on it's path, but what, for example, you shoot it up at a
ceiling?
You'd have to check upwards for that, not the direction of flying.
(Hope I'm not misunderstood here... ;)
My question is, what do you guys do in order to get exact results (or
near-exact
results)?
Tim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
1. Particle has a velocity at a time t
2. Forces act on the particle. Compute change in velocity as result of
forces.
3. You now have new trajectory and new distance to be travelled in next
frame.
4. Do a trace to obstacles.
5. If vlength(Position-NearestObstaclePoint) < velocity*time, then change
postion by velocity * time.
6. If it's greater, do a vdot at incident point, substract
(Position-NearestObstaclePoint) from velocity*time, go to step 4 until no
obstacles within distance.
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"Tim Nikias" wrote:
> Particles fly in parabolas as gravity affects them
> squared, not linear, so how do you actually calculate
> rebounces with trace()?
I/O based particle systems work fundamentally different than your particle
system. I/O based systems cannot know the point and location of a collision
before it actually occurs. They calculate the path of each particle by
taking very small steps forward in time, repeatedly, and calculate the
forces each particle is affected by for each step (such as gravity). The
smaller the steps, the better precision.
Gravity is only linear (in the typical environment), but as it's added again
and again for every step, the effect is squared.
Trace is done for every step in the direction the particle is flying.
> For one, you could shoot several trace()s for the
> particle while it moves on it's path, but what, for
> example, you shoot it up at a ceiling?
Yes, what about that?
> You'd have to check upwards for that, not the
> direction of flying. (Hope I'm not misunderstood
> here... ;)
If the above didn't explain it, please ask again.
> My question is, what do you guys do in order to get
> exact results (or near-exact results)?
If the above didn't explain it, please ask again.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
What I was talking about now in more detail:
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?
I've attached a crude image that shows what I mean.
Do you do some extra-trace()s and do a rough check of the near
vicinity or what?
Post a reply to this message
Attachments:
Download 'path.jpg' (9 KB)
Preview of image 'path.jpg'
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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?
All I can say is "touché"...
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...
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 schrieb in Nachricht <3c1273ec@news.povray.org>...
>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 allow user defined collision detection macros, as you allow
afaik user defined objects? Most of the time a particle is short enough to
test just the centre IMO, but if one wants to use bigger "things", one
should also know where are the best places to test for intersections.
Just my 2 Pfennige,
Marc-Hendrik
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...
>
Just a simple idea I had:
If you have the direction the particle is heading, why don't you do a
"axis-check"?
Example:
Particle flies in x-Direction.
You also check some angles which differ from original angle up to
90 degrees or so.
It's like creating a field-of-vision for the particles direction and looking
for intersections there.
On the other hand, that might become pretty parsing-intensive...
Perhaps the simple solution will work until someone has found some ingenious
way...
By the way: I've just downloaded the POV-Ray3.5 Beta 8 and am making
myself comfortable with it. Perhaps we'd see some "neat awesome-action-packed-
particle-animation" of *my taste* soon...
No offense, just kidding.
Tim
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
In my animations I use the centre of the particles and its radii to
calculate collisions along its velocity vector.
To avoid the problem you're showing here, I would use four more trace()s
along the same direction but starting from the frontier of the particles
rather than from the centre. You have to cover its envelope along its
velocity direction. I will try this and post the results as soon as I have
some time (I haven't raytraced for four days :-(
--
Jonathan.
"Tim Nikias" <Tim### [at] gmx de> ha scritto nel messaggio
news:3C125A3D.B348AD3B@gmx.de...
>
> What I was talking about now in more detail:
>
> 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?
>
> I've attached a crude image that shows what I mean.
>
> Do you do some extra-trace()s and do a rough check of the near
> vicinity or what?
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
"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.
> By the way: I've just downloaded the POV-Ray 3.5 Beta 8 and
> am making myself comfortable with it. Perhaps we'd see some
> "neat awesome-action-packed-particle-animation" of *my taste*
> soon...
Haha, I'll look forward to that. :)
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
No, the direction has to be the same. Think of your particle as a
sphere_sweep: you simply have to trace() from the centre and from some
points of the diameter normal to the velocity direction.
--
Jonathan.
"Tim Nikias" <Tim### [at] gmxde> ha scritto nel messaggio
news:3C129615.8BAE3640@gmx.de...
> >
> > 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...
> >
>
> Just a simple idea I had:
> If you have the direction the particle is heading, why don't you do a
> "axis-check"?
> Example:
> Particle flies in x-Direction.
> You also check some angles which differ from original angle up to
> 90 degrees or so.
> It's like creating a field-of-vision for the particles direction and
looking
> for intersections there.
>
> On the other hand, that might become pretty parsing-intensive...
>
> Perhaps the simple solution will work until someone has found some
ingenious
> way...
>
> By the way: I've just downloaded the POV-Ray3.5 Beta 8 and am making
> myself comfortable with it. Perhaps we'd see some "neat
awesome-action-packed-
> particle-animation" of *my taste* soon...
>
> No offense, just kidding.
>
> Tim
>
>
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
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?
>
> All I can say is "touché"...
>
> 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
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?
> >
> > All I can say is "touché"...
> >
> > 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
|
|
| |
| |
|
|
|
|
| |
|
|
