 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> And if it isn't visible, then what is the reason that you want to avoid
> it?
You want to avoid it because the particle which is bouncing back
is adding energy to the system, instead of losing energy
through damping.
To stabelize your system you need to (a) introduce damping
and (b) reduce the timestep.
I had to reduce the timestep in the "Space particles" in p.b.a
several times in order not to have the system become instable
when multiple particles interacted.
Hope it helps..
---------------------------------------------------------------------------
Willem de Wilde
Replace the DOT with dots: Willem DOT de DOT Wil### [at] Xs4all nl
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If, every time the particle is pulled down by gravity, it is brough back
> up immediately (before the positions are represented on the screen),
> then why is the hopping visible in the animation?
>
> And if it isn't visible, then what is the reason that you want to avoid
> it?
It's not visible, but I want to keep the System slick and fast.
Due to the adaptive technique, results like this occur: dozens of my
particle just require one or two passes through a while-loop to interact
with objects (when an intersection occurs, I redo the loop from that
position onward, as to calculate energy-loss due to the bouncing, maybe
irregularities in the reflection-direction etc). But a lying particle will
do hundreds of passes through the loop as it will quickly bounce onto the
surface (due to gravity) several times during the time that's passing per
frame. That's when my System almost hangs up (the loop will terminate
eventually, it's designed not to keep going on for ever cause some time
amount will always be processed during one pass) and passes the loop like
3500 times for a single particle. Now, add some more trace-calls and a more
complex algorithm inside the loop, and voila: Parsing times skyrocket!
That's not slick and fast. :-) For two such >2500 particles in a bunch of
350, the parsing time went from 0.8 seconds to something around 2 or 3
seconds. Now just imagine a setup where several particles will eventually
come to rest at the end!
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Maybe some more technical information is required, so instead of answering
all of you helpful guys one by one, I'll have another shot:
My particle system doesn't use rotational energies, the particles don't
interact, they're actually points and thus don't roll but rather slide,
though without friction or dampening. What happens though is when a particle
hits a wall, the velocity in the direction of the surface-normal gets
reduced somewhat, in effect, a ball dropping to the floor won't jump as high
as it was dropped from. But when it's flung, it will still retain the
velocity in the x-direction.
Now, from there on, a particle moving uphill would bounce hundreds of times
up the slope, whereby it loses it's velocity that is moving it upward in the
first place: thus, it slows down, comes to a halt, and moves back down: in
the test-animations everything is looking a-okay..
But instead of calculating thousands of bounces, I want to have a quick
formula to move the particle somewhat uphill, take some proper amount of
velocity, and save thousands of bounces, thus saving precious parsing time.
While at work and keeping pondering about this, I thought that maybe it'd be
possible to calculate the speed the particle would get when free-falling,
that velocity is somehow calculated along with the dot-product of the
downward/gravity times the slope-surface-normal. Add/subtract that to the
particle and it will slow down, stop, and turn back at some point.
Now, precision-wise the particle would be doing some physics-ignorant stuff:
when its rolling uphills, it already loses some speed, and thus wouldn't get
that far as it would when just moving it uphill and subtracting some speed
then. But, due to the small timesteps the system uses, I think I can just
forget about that, it shouldn't be noticeable. Doing a 100% correct
physical-particle System wasn't my goal. :-)
Still, all your comments and suggestions are good food for thought, and I'll
have some thinking time about it tomorrow, when I'm fully awake again.
Thanks all!
Regards,
Tim
--
"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:
> It's not visible, but I want to keep the System slick and fast.
How will you avoid these calculation, when in "rolling mode" you still
have to calculate:
a) The path along the surface, which also needs trace() calls.
b) To find out the exact moment the particle leaves the surface again
and thus goes out of rolling mode...
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com **updated Jan 29**
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> How will you avoid these calculation, when in "rolling mode" you still
> have to calculate:
>
> a) The path along the surface, which also needs trace() calls.
Well, one call vs 3500 is a better quota...
> b) To find out the exact moment the particle leaves the surface again
> and thus goes out of rolling mode...
I could either do a set amount of intervals across the distance the particle
travels in that frame (I could even use 20, it's *still* better than 3500)
or I could just assume that the integration is set with sufficient amount of
detail that the User can't tell if its precise or slightly not precise. For
CGI, things just have to *look* correct, they don't necessarily have to *be*
correct. :-)
Regards,
Tim
--
"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:
> Well, one call vs 3500 is a better quota...
> (I could even use 20, it's *still* better than 3500)
3500 is the number of "hops" for one particle in one frame? Or...?
So you want to reduce it to 1 or 20 when a particle slides along a
surface - which are the cases then where you actually DO want the 3500
samples being taken? I mean - why do your system take that small time
steps sometimes when it seems you're saying that you don't need that
precise calculations anyway?
Rune
--
3D images and anims, include files, tutorials and more:
rune|vision: http://runevision.com **updated Jan 29**
POV-Ray Ring: http://webring.povray.co.uk
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 3500 is the number of "hops" for one particle in one frame? Or...?
Yup, in one frame.
> So you want to reduce it to 1 or 20 when a particle slides along a
> surface - which are the cases then where you actually DO want the 3500
> samples being taken?
The precision-settings will take care of that. You set a minimum and a
maximum time-step for calculations. When the timesteps drop below the
minimum time-step for several times (perhap 10 or 20) then the System
assumes that the particle is oscillating on a surface and switches to
rolling/sliding. Now you ask, when would a time-step drop below the minimum
interval? When a particle hits a surface, it doesn't necessarily do that at
the end of the time-step, but in between. So I switch the time-step to only
calculate everything till impact, and then move on. An impact is the only
reason why a particle's timestep may drop below the minimum. Now, if this
happens far too often, I want to switch to a less parsing intensive
calculation.
> I mean - why do your system take that small time
> steps sometimes when it seems you're saying that you don't need that
> precise calculations anyway?
I'm not saying I don't need it anyway. But 3500 bounces always lose a
certain amount of precision, just due to rounding of floating points. On a
cost-scale, I can spend that precision with less parsing, but still get the
same satisfying results. That's what I'm after.
--
"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:
>>And if it isn't visible, then what is the reason that you want to avoid
>>it?
>
>
> It's not visible, but I want to keep the System slick and fast.
>
> Due to the adaptive technique, results like this occur: dozens of my
> particle just require one or two passes through a while-loop to interact
> with objects (when an intersection occurs, I redo the loop from that
> position onward, as to calculate energy-loss due to the bouncing, maybe
> irregularities in the reflection-direction etc). But a lying particle will
> do hundreds of passes through the loop as it will quickly bounce onto the
> surface (due to gravity) several times during the time that's passing per
> frame. That's when my System almost hangs up (the loop will terminate
> eventually, it's designed not to keep going on for ever cause some time
> amount will always be processed during one pass) and passes the loop like
> 3500 times for a single particle. Now, add some more trace-calls and a more
> complex algorithm inside the loop, and voila: Parsing times skyrocket!
> That's not slick and fast. :-) For two such >2500 particles in a bunch of
> 350, the parsing time went from 0.8 seconds to something around 2 or 3
> seconds. Now just imagine a setup where several particles will eventually
> come to rest at the end!
That is to be expected - you diminish the velocity during every
collision but none the less the particles will still hop on the surface.
- the hops will get smaller over the time but this won't help of
course. This hopping is in fact the correct solution for your
simulation problem. What you need is a more realistic model of the
surface contact - you model the collision by inverting the particle
velocity but you would need to model the damping during the longer time
of actual surface contact. This of course will not really solve your
performance problem in the end because you will need small time steps
during the collision but it will improve the quality of the simulation -
in the end your particles will smoothly 'flow' on the surface.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> That is to be expected - you diminish the velocity during every
> collision but none the less the particles will still hop on the surface.
> - the hops will get smaller over the time but this won't help of
> course. This hopping is in fact the correct solution for your
> simulation problem.
The hopping isn't the correct solution, an object doesn't hop on the surface
of something forever (maybe on an electrostatical level, but that's not what
I'm after).
> What you need is a more realistic model of the
> surface contact - you model the collision by inverting the particle
> velocity but you would need to model the damping during the longer time
> of actual surface contact. This of course will not really solve your
> performance problem in the end because you will need small time steps
> during the collision but it will improve the quality of the simulation -
> in the end your particles will smoothly 'flow' on the surface.
Why would I want damping? There are two possible states: a particle is
air-born, or its lying on a surface. When lying on a surface, normally
friction, inertia and whatnot would affect the particle. Now, leaving
friction out of the equation, all I need is to find the velocity the
particle loses when rolling uphill. And I want to achieve that without
thousands of trace-calls to the surface.
What I'm reading out of your suggestion is to use actual dampening instead
of losing velocity due to impact, but keep on going with the
parsing-intensive small timesteps. I wouldn't win anything that way,
particles move properly as it is, using a different algorithm with roughly
the same complexity doesn't avoid long parsing-times.
--
"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:
>>That is to be expected - you diminish the velocity during every
>>collision but none the less the particles will still hop on the surface.
>> - the hops will get smaller over the time but this won't help of
>>course. This hopping is in fact the correct solution for your
>>simulation problem.
>
>
> The hopping isn't the correct solution, an object doesn't hop on the surface
> of something forever (maybe on an electrostatical level, but that's not what
> I'm after).
The hopping is the correct solution of the model your are simulating.
Of course this model is a really bad approximation of nature.
>
> Why would I want damping? There are two possible states: a particle is
> air-born, or its lying on a surface. [...]
These two states exist in your model but not in nature - there you have
a deformation of the particles as well as the surface during collision -
this involves all kind of dissipation of energy - friction and inner
damping of the materials for example. To model all these things
precisely is extremely difficult but you can approximate them. If the
particle would actually be lying on the surface the simulation would be
finished - there is neither kinetic nor potential energy in the system.
What you say is essentially you want realism without much computation -
this is hardly possible.
Christoph
--
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 11 Jan. 2004 _____./\/^>_*_<^\/\.______
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
