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?



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] gmxde> 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