> >Even when a particle lies motionless on a
> >surface, gravity will pull it down, adding energy (which is always stored
as
>                                      ^^^^^^^^^^^^^
> Gravity doesn't add energy to something.
> Do you mean the conversion between 'potential energy' and 'kinetic
> energy'?

I guess from this point on you've misunderstood what I wrote. I was always
talking about the particle system and its underlying model for simulation.
What *I* do in my particle system (and that is in no way related to 100%
accurate or physical models) is very simple:
1. Take a particle.
2. Take a given timestep (may change during the animation, from frame to
frame or even from timestep to timestep)
3. Generate and add "energies" to create a Direction/Velocity-Vector
4. Move particle by the Velocity-Vector and check for Object-Interaction
between former and new position

Now, *that's* the model. What happens within that system is that when a
particle lies motionless on a surface, I come to Step 3 and add energy due
to gravity (in fact, it's more like downward-movement that gets added, if
you want to see it that way). Thus again, in Step 4, I have to calculate new
Object-Interaction. And that's the oscillation taking place in the system. I
know that its not a real-life issue, I've never said that in real-life
objects oscillate on a surface.

What I want now is a method to check if a particle is lying/sliding on a
surface and then keep that sliding state. Instead of calculating the
oscillation (which takes quiet some recognizable parsing time) I want to
simply slide the particle.

> >a velocity vector) which will lead it to oscillate on the surface, even
> >though it visibly doesn't move a bit (unless with a microscope).
>
> No.
> Don't mistake your model/imagination for the real world.
> There's nothing that causes anything to oscillate.

There is in my system, that's what I'm trying to circumvent.

> >Now, what I want to do is to simplify the model when the particle starts
to
> >oscillate:
>
> No, you don't want to simplify your model, you want to add some
> complexity to avoid 'oscillations' that don't happen in real world.

Again: it is a simplification of the model I'm using. Instead of doing
hundreds of calculations in a given model, I switch to a different model
which handles the problem of sliding particles far easier and faster. That
the oscillations don't happen in the real world was mentioned above.

> >Friction and dampening is left out for simplicities sake,
> >its a particle system and, IMHO, doesn't need physical
> >calculations like friction and dampening to slowly stop a particle from
> >sliding along a surface.
>
> Sorry to disappoint you, but without friction and dampening (energy
> dissipation) you'll have to live with those oscillations.

I don't. And even when using friction or dampening on the "pure" model (the
one that's being used all the time), then I'll have to live with it. If I
add a Step between Steps 3 and 4 with dampening, what would the result be? I
*still* get a velocity-vector which will move my particle through the floor,
and I *still* have to calculate hundreds of hops.

But, as my very first post in this thread suggested, I want a different
solution to switch from the "pure" model to a "sliding" model when an
oscillation is imminent.

> No. You have stated that you need, but don't want friction, dampening,
> ...

I have stated that I cannot calculate friction based on surface-contact
because my particles, as it is, only have very short contacts. My particles
don't slide, they hop on the surface. Dampening in an Euler System is
usually a tweaking of the energies in order to have it stop at some point.
When using springs, you add dampening so that a spring won't juggle back and
forth for ever or even juggle itself farther and farther. As mentioned
above, in *my model*, these oscillations can't be handled with dampening.
Just think it through: I've got a particle lying just above a surface. It
lies just above because if it would, the trace() call, due to precision
issues in floating points, won't give me a hit on the surface directly
underneath, but rather shoot through it. Now, if I just assume that a
particle with a given distance above a surface is lying on it, and then
switch to "sliding-model", every so often a particle flying towards a
surface will stop plain dead on the surface and switch to sliding. Why?
Because it may occur that the particle gets that close to a surface with
high velocity without the impact taking place.

> May be I'm completely mistaken, please tell me what you would expect
> for your particle system for just one particle in this case.

Simple: Once I've noted that the particle hits the surface too many times
during a single frame, I switch to sliding. Instead of calculating several
hundreds of hits, I slide it with only two or three checks to see if it
still doesn't hit or gets air-born, in which case it would go back to
"hopping/bouncing model".

> BTW You are aware of the possible problems of
> - modelling using discrete time series,
> - limited accuracy of calculations,
> ?

Of course I am. That's what I mentioned to Rune: the oscillations (in the
model) have a great deal of limited accuracy (in respect to the real world)
and I've mentioned to him that using a different, even more simple model
there doesn't harm, because I'm after the *looks*. As long as the final
animation looks fine, I'm not bothered by how inaccurate it really is. And I
do have experience with discrete time series, I've had courses at the
University, I've written a non particle I/O System which tries to overcome
discrete time series, and I've written the LSSM which is an immensely
simplified, discrete version of the Navier Stokes Equations for fluids.

What I don't get, to be honest, is why several people have speculated how it
*should* be done, what's happening in the real world etc even though I was
always talking about my particle system. My first post was along the lines
of: My particle system does this and that, I want to overcome that with this
and that, but don't seem to find the formula required for that.
Then I get responses with suggestions like friction (not possible with the
model), dampening (wouldn't change the problem of my oscillations and isn't
trivial to implement with an adaptive timestep method) and that oscillations
don't occur in real-life! Though the suggestions all have valid points, I've
ruled them out because they're not possible in the system, unless I use a
completely different approach. And even after I've described why the
oscillations occur, I get responses like "gravity doesn't add energy", I
mean, come one! It *does* add energy in my model, I should know it, I wrote
it. Gravity maybe doesn't add that sort of energy in real-life, but I'm not
god and creating a real-life particle system, I'm human and creating a rough
and functioning particle system for a PC which *looks* like real.
That's the main point I've stated several times: it just has to *look* real,
it doesn't have to *be* real.

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

Post a reply to this message