Now my particle system handles damping properly: the balls end up 
sliding (looks like rolling...). I was afraid that I need some 
conditionals to distinguish between slide/bounce state but "luckily" the 
same piece of code handles both cases.

There is no friction at all. The speed along the surface normal is 
dampened by 30% every time a ball bounces off the floor.

Severi S.

Post a reply to this message

Attachments:
Download 'yaps3.m1v.mpg' (684 KB)

> Now my particle system handles damping properly: the balls end up
> sliding (looks like rolling...). I was afraid that I need some
> conditionals to distinguish between slide/bounce state but "luckily" the
> same piece of code handles both cases.
>
> There is no friction at all. The speed along the surface normal is
> dampened by 30% every time a ball bounces off the floor.

Nice one! How do you do it to keep particles out of the objects?

And what's your "lucky" code which keeps particles sliding nicely?

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Tim Nikias v2.0 wrote:
>>Now my particle system handles damping properly: the balls end up
>>sliding (looks like rolling...). I was afraid that I need some
>>conditionals to distinguish between slide/bounce state but "luckily" the
>>same piece of code handles both cases.
>>
>>There is no friction at all. The speed along the surface normal is
>>dampened by 30% every time a ball bounces off the floor.
> 
> 
> Nice one! How do you do it to keep particles out of the objects?
> 
> And what's your "lucky" code which keeps particles sliding nicely?

I won't show the code (it is still very ugly) but here is what I'm 
basically doing:

1. My approach is a "refined" Euler method -  I guess :) When the 
position of a particle is updated the gravity is also taken directly 
into account - not only speed. So gravity affects both the speed and the 
position during every step. Without it I see my particles bounce for too 
long with damping. This also gives 100% accuracy (when particles are not 
colliding) no matter how big time steps between frames.

2. If the new position indicates a collision, the previous position is 
restored (so basically particles _can't_ intersect with an object). The 
next happens:

a) speed is directed away from the surface taking the damping into 
account: this gives basic bounces.
b) particle is moved along the surface: this allows rolling and the 
bounces are also more accurate, still not perfect though. If I want them 
perfect I would have to find the _exact_ moment of collision.
c) gravity affects the speed along the surface: this allows the increase 
in speed when rolling - also the accuracy of bounces increase.

I might have forgotten something but basically it works like that.

By "lucky" I mean that there seems to be no bugs and everything seems to 
work as expected after I implemented 2.b and 2.c. BTW, have you tried 
how Cristophs particle system/MegaPov handles rolling/sliding? Just 
curious. At least it is a lot faster as it is hard coded.

Now I have only planes as environment and I check collisions by shooting 
a ray towards every plane. This obviously is accurate but a bad thing to 
do when there are many objects. Next I have to make the environment as a 
one single union and shoot proper rays towards it. Accuracy decreases 
but I can use as complex environment as I want.

Severi

Post a reply to this message

> 2. If the new position indicates a collision, the previous position is
> restored (so basically particles _can't_ intersect with an object). The
> next happens:
>
> a) speed is directed away from the surface taking the damping into
> account: this gives basic bounces.
> b) particle is moved along the surface: this allows rolling and the
> bounces are also more accurate, still not perfect though. If I want them
> perfect I would have to find the _exact_ moment of collision.
> c) gravity affects the speed along the surface: this allows the increase
> in speed when rolling - also the accuracy of bounces increase.

But you surely have to calculate where the particle hits the object, don't
you? Either I'm missing something here, or you're missing some really big
issue. Just take the following:
A particle flying with 20mph. It'll hit a wall in 50 seconds, but you jump
and calculate 2 minutes. So, instead of rebouncing off the surface, you just
take the exisiting position and reverse the direction of velocity, so it'll
fly another direction. Maybe it'll hit another surface there to, so you
reverse the velocity once again... That it should have actually dropped a
few meters until it hit the first wall is left out?

> By "lucky" I mean that there seems to be no bugs and everything seems to
> work as expected after I implemented 2.b and 2.c. BTW, have you tried
> how Cristophs particle system/MegaPov handles rolling/sliding? Just
> curious. At least it is a lot faster as it is hard coded.

Never looked at it, but just ask Christoph, he'll surely know. :-)

> Now I have only planes as environment and I check collisions by shooting
> a ray towards every plane. This obviously is accurate but a bad thing to
> do when there are many objects. Next I have to make the environment as a
> one single union and shoot proper rays towards it. Accuracy decreases
> but I can use as complex environment as I want.

How does accuracy decreas when using a ray per object or one ray total per
union? Internally, I think POV-Ray just shoots the rays at the different
union-components, but returns only the closest hit. It's faster than doing
that yourself, and the comparison in SDL might be less accurate than what
POV-Ray is capable of internally, but surely not that much?

Since you're now shooting a ray at every plane individually, I expect you're
shooting them parallel to the plane's surface-normals, and thus maintain
that a particle won't intersect a plane because you know it's radius and can
then easily move it along the normal so that it won't intersect the plane.
This technique will run into problems with other objects, where the closest
point to the object isn't found with some arbitrary normal that easily.

-- 
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de

Post a reply to this message

Tim Nikias v2.0 wrote:

> But you surely have to calculate where the particle hits the object, don't
> you?  

Yes, of course. I do the regular time stepping as everybody. First there 
is the "main loop" for each particle that divides each frame according 
to the speed and size of the particle. This loop moves the particles and 
checks if there was a collision. If there was it moves to a "sub loop" 
which has smaller time steps. So I do find the moment when the particle 
collides, but it is not mathematically 100% accurate.

> Either I'm missing something here, or you're missing some really big 
> issue. Just take the following: A particle flying with 20mph. It'll
> hit a wall in 50 seconds, but you jump and calculate 2 minutes. So,
> instead of rebouncing off the surface, you just take the exisiting
> position and reverse the direction of velocity, so it'll fly another
> direction. Maybe it'll hit another surface there to, so you reverse
> the velocity once again...

Basically yes, but the timescale will be different because of adaptive 
stepping. During a collision a particle is moved allways only a fraction 
of its radius every step. So the accuracy should be adequate.

> That it should have actually dropped a few meters until it hit the
> first wall is left out?

No, that is why there is the point 2.b (and 1.) which is done at every 
collision.

>>By "lucky" I mean that there seems to be no bugs and everything seems to
>>work as expected after I implemented 2.b and 2.c. BTW, have you tried
>>how Cristophs particle system/MegaPov handles rolling/sliding? Just
>>curious. At least it is a lot faster as it is hard coded.
> 
> 
> Never looked at it, but just ask Christoph, he'll surely know. :-)

Well, maybe I'll try it myself if Christoph doesn't show up automagically :)

> How does accuracy decreas when using a ray per object or one ray total per
> union? Internally, I think POV-Ray just shoots the rays at the different
> union-components, but returns only the closest hit. It's faster than doing
> that yourself, and the comparison in SDL might be less accurate than what
> POV-Ray is capable of internally, but surely not that much?

I meant that the accuracy decreases as you can't shoot the ray allways 
directly to the nearest point in the environment. You have to "guess". 
If you knew the shape of each object it might be possible to shoot the 
ray to the nearest point (as I was doing with the planes).

> Since you're now shooting a ray at every plane individually, I expect you're
> shooting them parallel to the plane's surface-normals, and thus maintain
> that a particle won't intersect a plane because you know it's radius and can
> then easily move it along the normal so that it won't intersect the plane.
> This technique will run into problems with other objects, where the closest
> point to the object isn't found with some arbitrary normal that easily.

I will change to using a few well chosen ray directions (like speed and 
gravity or something between them) and test the system with different 
kinds of environment objects. So, more animations to follow!

Severi

Post a reply to this message