 |
|
|
|
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm stuck: my new I/O Particle-System uses adaptive iteration to calculate
the path for a particle, along with object interaction. Now, when Particles
would normally roll on a surface, they oscillate heavily in my System:
Gravity pulls them down, object interaction puts them back on surface, only
the speed perpendicular to the surface-normal is retained. Thus, a particle
won't slow down when rolling along plane, but it will "hop" on the surface
hundreds of times (two of my particles reached more than 2500 iterations
that way...).
To avoid this, I want a particle to switch to "Rolling" when enough
iterations have been done, and thus the particle will just get moved along
the surface without "real" interaction. Now, if I'd just be dealing with a
plane, that'd be no problem, but since particles may also roll uphill, I
want to calculate how much velocity they'd lose when doing that. I know the
angle of the surface, the initial velocity and the distance the particle
will travel, now what's the formulae to calculate how much velocity is lost?
For simplicities sake, use a ball with 10km/h that starts rolling a 45
degree upward slope for 10 meters. Gravity is 10m/s. What'd be the velocity
after 5 meters? What's the formula for that?
Links, direct answers, anything will do. I've tried googling, but it seems
I'm using the wrong keywords...
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> Ignoring friction and rotational energy, you'd simply be checking that
> your potential energy matches your kinetic energy, wouldn't you? The
> formulae for both are pretty straightforward.
Ehm, yeah, sure... Point is: I can't find those formulae. That aside, I just
want the velocity approach, not energies etc, cause I don't know anything
else of that particle beside it's velocity. Might be that I'm talking BS
because I don't know which formulae you're talking about, but, for example,
I've got a few formulae like "Height after object is thrown with that slope
and that velocity with earth's gravity". What I want is something along the
lines of "Velocity after object is rolled up/down a slope with that angle,
velocity and gravity".
I'm in a rush now, but I'll check on your energy-clues when I'm back, might
be that they'll lead me to exactly what I was looking for.
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
From: Lutz-Peter Hooge
Subject: Re: Some aid in physics required...
Date: 23 Feb 2004 12:24:57
Message: <403a3769@news.povray.org>
|
|
|
| |
| |
|
|
<"Tim Nikias v2.0" <tim.nikias (@) nolights.de>> wrote:
> For simplicities sake, use a ball with 10km/h that starts rolling a 45
> degree upward slope for 10 meters. Gravity is 10m/s. What'd be the velocity
> after 5 meters? What's the formula for that?
1) Does the ball have an initial rotation?
2) Should it be completely rolling (or is partial sliding allowed)?
3) if 1=true and 2=false, is a direction of rotation that is not
parallel to vcross(velocity,middleOfBall-pointWhereBallTouchesSurface)
allowed?
If 3 is true, the solution can get quite complicated, I think.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Among other things, Tim Nikias v2.0 wrote:
>> Ignoring friction and rotational energy, you'd simply be checking that
>> your potential energy matches your kinetic energy, wouldn't you? The
>> formulae for both are pretty straightforward.
>
> Ehm, yeah, sure... Point is: I can't find those formulae. That aside, I
> just want the velocity approach, not energies etc, cause I don't know
> anything else of that particle beside it's velocity. Might be that I'm
> talking BS because I don't know which formulae you're talking about, but,
> for example, I've got a few formulae like "Height after object is thrown
> with that slope and that velocity with earth's gravity". What I want is
> something along the lines of "Velocity after object is rolled up/down a
> slope with that angle, velocity and gravity".
Kinetic energy: 1/2 * m * v^2
Potential energy: g * m * h
Total energy must be constant.
If the particle has velocity v1 at height h1, then at height h2 it should
have:
1/2*m*(v1)^2 + g*m*(h1) = 1/2*m*(v2)^2 + g*m*(h2)
1/2*m*(v2)^2 = 1/2*m*(v1)^2 - g*m*(h2-h1)
(v2)^2 = (v1)^2 - 2*g*(h2-h1)
v2 = sqrt[ (v1)^2 - 2*g*(h2-h1) ]
--
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby
Post a reply to this message
|
|
| |
| |
|
|
From: Lutz-Peter Hooge
Subject: Re: Some aid in physics required...
Date: 23 Feb 2004 12:40:57
Message: <403a3b29@news.povray.org>
|
|
|
| |
| |
|
|
Jellby <jel### [at] M-yahoo com> wrote:
> Kinetic energy: 1/2 * m * v^2
> Potential energy: g * m * h
This is the correct solution for a sliding (or slipping?
what is the correct term?) particle, but not for a rolling ball.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
You could use the law of conservation of energy if you want:
Ek = m*pow(v,2)
Ep= F*Height , F = m*a
E = Ek + Ep == constant
where m is a mass, v is the velocity, a is the gravity acceleration and at
any time E must be constant in a frictionless system. This way, you can
alway tell what should eb the speed at any point without simulating.
In practice, you may want to apply mechanics equation like this
v(n) = v(n-1) - at
pos(n) = pos(n-1) + vt + 0.5a*pow(t,2)
where t is the time step, a is the length of the horizontal component of the
gravity acceleration (cos A if A = 0 for horizontal plane) given the normal
of the surface.
If you dig in the vectorial aspect of Newtonian mechanics (High school level
I think), you should be able to solve your rolling problem by assigning a
matching vector component to the normal of the surface the particule is
rolling on in the first place.
Hope this helps, as well as the other posts sent while I was writing
this(...)
bongo
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias v2.0 wrote:
> I'm stuck: my new I/O Particle-System uses adaptive iteration to calcul
ate
> the path for a particle, along with object interaction. Now, when Parti
cles
> would normally roll on a surface, they oscillate heavily in my System:
> Gravity pulls them down, object interaction puts them back on surface,
only
> the speed perpendicular to the surface-normal is retained. Thus, a part
icle
> won't slow down when rolling along plane, but it will "hop" on the surf
ace
> hundreds of times (two of my particles reached more than 2500 iteration
s
> that way...).
>
> To avoid this, I want a particle to switch to "Rolling" when enough
> iterations have been done, and thus the particle will just get moved al
ong
> the surface without "real" interaction. Now, if I'd just be dealing wit
h a
> plane, that'd be no problem, but since particles may also roll uphill,
I
> want to calculate how much velocity they'd lose when doing that. I know
the
> angle of the surface, the initial velocity and the distance the particl
e
> will travel, now what's the formulae to calculate how much velocity is
lost?
In a particle system you usually describe the particles as point masses
so they won't roll (rolling means rotation and a point can't rotate).
The effect you get (hopping) is pretty normal but it will diminish if
you add damping (just imagine a glass marble falling on a carpet floor
instead of a massive steel block). Damping can be modelled in different
ways - you can either continuously diminish the kinetic energy or you
slow down the particles during every collision.
> For simplicities sake, use a ball with 10km/h that starts rolling a 45
> degree upward slope for 10 meters. Gravity is 10m/s. What'd be the velo
city
> after 5 meters? What's the formula for that?
Gravity is measured in m/sē, the answer to your question probably mostl
y
depends on the friction between the ball and the surface (if you really
want it rolling you also have to take the moment of inertia into account)
.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
I'm not sure I understand...
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?
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Among other things, Lutz-Peter Hooge wrote:
>> Kinetic energy: 1/2 * m * v^2
>> Potential energy: g * m * h
>
> This is the correct solution for a sliding (or slipping?
> what is the correct term?) particle, but not for a rolling ball.
It's a quick "ad-hoc" solution I wrote assuming no friction and no
rotational energy :)
--
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> It's a quick "ad-hoc" solution I wrote assuming no friction and no
> rotational energy :)
Which is what I'm after, thank you very much. It's too late now, gotta go to
bed, but I'll sort through that complex-looking formula and see what I can
do.
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> 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] Xs4allnl
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> The hopping is the correct solution of the model your are simulating.
> Of course this model is a really bad approximation of nature.
>
> 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.
I think you've misunderstood what I'm saying. With "lying on the floor" I
didn't mean "lying there totally still". Maybe its sliding along the x-axis.
The basic idea is simple: a particle bounces around most of the time, that's
essentially why particle system are written in the first place. Now, when
you just keep with bouncing particles all the time, you get what I'm
getting: a particle will eventually oscillate on a surface, cause though it
does lose some energy everytime it hits the floor, it's always a percentage
of the energy it had before impact, thus, there'll always be an energy
residue. Now, in an Euler System, energy due to gravity gets added in steps,
as do several other calculations. Even when a particle lies motionless on a
surface, gravity will pull it down, adding energy (which is always stored as
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).
Now, what I want to do is to simplify the model when the particle starts to
oscillate: instead of oscillating, I slide the particle along the surface -
if possible. If a particle lies on the y-plane and its just y-velocity from
gravitation, there's no movement at all. But when there is some x-velocity,
it will slide along the x-axis. 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.
Now, with those assumptions for my particle system, I want a very simple
approach to calculate how much slower a particle would get when moving
uphill, that's all I was asking for. I've stated that I don't need friction,
dampening etc. And we're still discussing just that: friction, dampening,
the model I'm using...
Don't get me wrong, the suggestions and comments do have valid points. But
I'm just not after a system which calculates hundreds of tiny *balls* with
incredible physical accuracy. A particle system, in most cases, is used and
designed to quickly and efficiently create hundreds or thousands of tiny
objects which together give the *impression* of a more complex simulation.
Instead of simulating actual millions of dust particles for smoke, one uses
a few hundred and attaches some media-spheres to a particle, so that, in the
end, it *looks* like real smoke.
The hopping particles *look* correct, I'm not bothered about that. I'm
bothered by the parsing time and thus want something even more simple which
may spare the CPU of such intensive processing, as long as the end result
stills *looks* correct.
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
On Wed, 25 Feb 2004 00:48:06 +0100, "Tim Nikias v2.0" <tim.nikias (@)
nolights.de> wrote:
>[...]
>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'?
>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.
>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.
>instead of oscillating, I slide the particle along the surface -
>if possible. If a particle lies on the y-plane and its just y-velocity from
>gravitation, there's no movement at all. But when there is some x-velocity,
>it will slide along the x-axis.
>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.
>Now, with those assumptions for my particle system, I want a very simple
>approach to calculate how much slower a particle would get when moving
>uphill, that's all I was asking for.
It has yet been posted. All you need is the conservation of energy,
0.5 * m * sqr(v) + m * g * h = const (as you don't like friction &
dampening).
> I've stated that I don't need friction, [...]
No. You have stated that you need, but don't want friction, dampening,
...
May be I'm completely mistaken, please tell me what you would expect
for your particle system for just one particle in this case.
BTW You are aware of the possible problems of
- modelling using discrete time series,
- limited accuracy of calculations,
?
--
Andreas
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> >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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias v2.0 wrote:
>> 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.
I still don't get it. Am I correct to seem to remember that you said
that your system uses variable time steps? And that is the reason that
there can be as much as 3500 steps per frame? If it is a problem that
your system creates 3500 steps per frame when a particle slides along a
surface, then why don't you just tell it to use fewer steps?
You talk about calculating the slow-down when a particle slides uphill.
Why can you only calculate that with your current model when you use a
huge number of steps? Why doesn't the calculations work equally well
(though slightly less precise) when fewer steps are used?
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> I still don't get it. Am I correct to seem to remember that you said
> that your system uses variable time steps? And that is the reason that
> there can be as much as 3500 steps per frame? If it is a problem that
> your system creates 3500 steps per frame when a particle slides along a
> surface, then why don't you just tell it to use fewer steps?
The idea for the adaptive timesteps is simple: I've got a minimum and a
maximum timestep along with a maximum distance. I begin with using the
maximum timestep. If the particle moves more than the given maximum
distance, I reduce the timestep until I can use some value between min and
max timestep. If I'm already using the min timestep, I can't go any lower
than that when just basing the timestep on the distance. This is to ensure
that the simulation won't run longer than it would take for the min
timesteps to compute when particles are in free-fall.
Now it's done like this: I've got the position and the velocity of a
particle. I move the particle by a given timestep along the velocity and
thus get a new position. Then I check if an object lies between the former
and the new position. If it does, I just use a linear solution to find when
during the timestep the impact occurs. That value is used to recalculate
speed and/or other data that may be passed along with the particle. I
position the particle at the impact point, reverse the velocity-vector and
move on from there. Thus, the actual minimum timestep won't be used, but
maybe an even smaller one for impacts. Why I do that? When a particle gets
into tight spaces, I may have to bounce the particle off of several
surfaces, even when using just the minimum timestep. I still want to get as
much precision as possible, sort of approaching using so tiny iterations
that it'll converge against 0. The adaptive system is there simply because
when in free-fall, I can easily jump across larger timesteps because there's
no interferance.
So when an object gets hit, the timestep gets adjusted to the amount of time
it would require the particle to get from former position till impact
position based on the initial velocity (which also leaves some accuracy
behind, I know that). So, once a particle gets really slow and is just on a
surface, a particle will impact very, very quickly (even during a min
timestep) and hundreds of these impacts occur (that's why the iteration can
run up to 3500 or more).
What I want to do is thus switch from "fast bouncing/hopping/oscillation" to
"frictionless sliding on surface". So, instead of calculating very minimal
hops, I assume that I'd be having dozens of these hops and just check if I
can safely move the particle along the surface without an obstacle in
between. In this manner, the particle may of course get airborn (e.g. I'm
.5*x units away from the edge of a box and move it by one unit towards -x,
I'll be -.5*x over the edge, there's no obstacle inbetween and everything is
fine). So, at the end, if I am airborn (if the particle is higher above a
surface than a given threshold) I switch back to the bouncing-model.
Now, in theory, if using too large timesteps, a particle will of course be
visibly inaccurate: if the particle gets moved way too far across the edge,
it'll look quiet unrealistic. Now, the maximum distance takes care that a
particle won't move farther than that. And I can even add some more checks
in between, as I've said, 20 checks is better than 3500 hops.
> You talk about calculating the slow-down when a particle slides uphill.
> Why can you only calculate that with your current model when you use a
> huge number of steps? Why doesn't the calculations work equally well
> (though slightly less precise) when fewer steps are used?
It's not the problem that I can't calculate that with fewer steps, the
problem was the impact-approach on the timesteps (which I don't want to drop
or change significantly because so far it works very well for tight corners
and such, leaving the hopping aside). I was at loss of the formula for
calculating the loss of speed when moving uphill, but I think I've found
one, and I'll have to try to see if it works.
Regards,
Tim
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
If I understand you right, then things happen like this in your system:
On impact, the particle is moved to the surface, so it is practically 0
units away from the surface. After this, when you calculate the new
position, and find out that there is a surface between the old and the
new position, you use linear interpolation to find the impact time.
Since the old position was about zero distance from the surface, the
interpolation will tell you that the new impact happened at the SAME
time as the old impact. Thus you get extremely frequent impacts as you
describe.
I must admit that I think the idea of switching between two modes to
solve the problem is a rather clumsy hack, especially the ways you have
to "detect" when to switch.
A better solution in my opinion is to not create a new time-step every
time an impact occurs, but instead allow for several impacts in the same
time-step. However, gravity will only be added once every time-step, so
in most cases you will never have more than one impact per time-step.
This way, you can use your normal algorithm to control the lengths of
time-steps dependent on distance, regardless of impacts, and thus you
can have pretty large time-steps also when a particle is sliding along a
surface. (The cases where you will still have many impacts are for
example those where your particle gets caught in a v-like-shape, but
those situations are not that frequent.)
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> If I understand you right, then things happen like this in your system:
>
> On impact, the particle is moved to the surface, so it is practically 0
> units away from the surface. After this, when you calculate the new
> position, and find out that there is a surface between the old and the
> new position, you use linear interpolation to find the impact time.
> Since the old position was about zero distance from the surface, the
> interpolation will tell you that the new impact happened at the SAME
> time as the old impact. Thus you get extremely frequent impacts as you
> describe.
I'm placing them a small value (.00001) away from the surface, because if
I'd be using a trace downwards with 0 distance, I'd shoot right through the
floor. With this tiny distance I still have some time pass between new
impacts, otherwise my system would catch itself in a loop. But basically,
you're right.
> I must admit that I think the idea of switching between two modes to
> solve the problem is a rather clumsy hack, especially the ways you have
> to "detect" when to switch.
>
> A better solution in my opinion is to not create a new time-step every
> time an impact occurs, but instead allow for several impacts in the same
> time-step. However, gravity will only be added once every time-step, so
> in most cases you will never have more than one impact per time-step.
> This way, you can use your normal algorithm to control the lengths of
> time-steps dependent on distance, regardless of impacts, and thus you
> can have pretty large time-steps also when a particle is sliding along a
> surface. (The cases where you will still have many impacts are for
> example those where your particle gets caught in a v-like-shape, but
> those situations are not that frequent.)
Ah, that's an idea I hadn't thought about... Let me see: I have a particle
lying on the floor. Gravity gets added, one impact is calculated, it
rebounces off the floor, probably staying a certain distance above the
floor. It falls back down, maybe gets even more momentum due to the
falling... That wouldn't work. A lying particle would then suddenly start
jumping. If I'd apply dampening, the effect might be lessened to a degree
which solves that problem, but still, gravity or other effects would add
energy to a particle where it's theoretically not possible. The design idea
was to easily introduce new effects: I use Macros to generate the
velocity/energy based on the timestep, and my system takes care of moving
the particle accordingly. Building the effects into the structure like
checking if it's already on the floor and thus gravity need not be added
would be counterproductive.
Basically I have no other choice than to switch between modes with this
model. Might be a little clumsy, but its the result that counts. That aside,
I've read a thesis paper once where they mentioned just that problem, though
with a more simulational background, it was essentially the same: what if
cohesive forces or stationary particles would directly counter-effect an
energy? The thesis went on with some solutions to various types of this
(lying particle with gravity, sticky particles on walls, etc), but it seems
like I've lost that PDF with my System crash last year, and googling for
particles... Well, there are dozens of papers on that.
BTW, how did you handle this in your particle system? Like you described,
one impact per timestep? Did you then use dampening etc? I'm not sure how
flexible your system is, e.g. User-Defined Macros for Wind/Gravity/Special
Effects. IIRC one could supply starting positions and velocities, and things
like gravity and wind are "hardwired" into the internal processes. But I
might be wrong, so I'll rather wait for your reply. :-)
Regards,
Tim
PS: Just had an idea: I could maybe just trace the surface normal and if
it's close enough to the particle, energies added towards the normal get
nullified when the velocity at the moment aren't high enough so that a
rebounce might be feasible... That'd be a combination of your idea of using
just the minimum timesteps but allowing several hits and my idea of having a
simple check to avoid adding impossible energies... I'll have to look into
that.
--
"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:
> I'm placing them a small value (.00001) away from
> the surface
Yes, I know, but I knew you'd get the idea... ;)
> Ah, that's an idea I hadn't thought about... Let me see:
> I have a particle lying on the floor. Gravity gets added,
> one impact is calculated, it rebounces off the floor,
> probably staying a certain distance above the floor. It
> falls back down, maybe gets even more momentum due to
> the falling...
It will not get increasingly more momentum, but come to a rest at a
negligible amount, which will make it constantly hover above the surface
with a distance that equals the distance that gravity can move an
initially non-moving particle over one time-step (that is very little)
plus the distance you move the particle away from the surface with (e.g.
.00001).
That's how particles slide and come to a rest in my system, and it works
fine.
> Building the effects into the structure like checking
> if it's already on the floor and thus gravity need not
> be added would be counterproductive.
Yes, gravity should always be added.
> BTW, how did you handle this in your particle system? Like you
> described, one impact per timestep?
Mine works like I described: There can be more than one impact per
timestep but usually there is only one.
> Did you then use dampening etc?
No.
> I'm not sure how flexible your system is, e.g. User-
> Defined Macros for Wind/Gravity/Special Effects. IIRC
> one could supply starting positions and velocities,
> and things like gravity and wind are "hardwired" into
> the internal processes.
You can define the gravity force and direction for every point in space
for every moment in time. Needless to say, you can use it for effects
that look nothing like gravity at all. Likewise for wind.
> PS: Just had an idea: I could maybe just trace the
> surface normal and if it's close enough to the
> particle, energies added towards the normal get
> nullified when the velocity at the moment aren't high
> enough so that a rebounce might be feasible... That'd
> be a combination of your idea of using just the
> minimum timesteps but allowing several hits and my
> idea of having a simple check to avoid adding
> impossible energies... I'll have to look into that.
It still sounds like a hack... As I see it, a resting particle is simply
a sliding particle that don't happen to be moving.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Tim Nikias v2.0 wrote:
>
> 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.
See it a different way - you say you have a system simulating something
having next to nothing to do with real physics and now you want the
*correct* formula to calculate a certain effect in this system. What
several people gave you was the formula for conservation of total system
energy which would be the point to start with when you do a *realistic*
simulation. Now this naturally does not help you because you don't care
about the energy in your system but it should be obvious that your
question does not make much sense then - there is no correct formula.
> [...] 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,
You should understand that most people here when talking about gravity,
energy etc. are referring to what these terms mean in physics, not how
you use them in your simulation system. In physics gravity in an
acceleration which - according to Newton - exerts a force on all masses
in the system. Whether or not this results in a change of velocity (and
thereby in kinetic energy) depends on the environment.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> See it a different way - you say you have a system simulating something
> having next to nothing to do with real physics and now you want the
> *correct* formula to calculate a certain effect in this system. What
> several people gave you was the formula for conservation of total system
> energy which would be the point to start with when you do a *realistic*
> simulation. Now this naturally does not help you because you don't care
> about the energy in your system but it should be obvious that your
> question does not make much sense then - there is no correct formula.
It does have to do with physics. I add gravity, wind etc and use formulae to
calculate velocity etc. Like: when an object falls 10 meters with some
initial velocity and heading, it will have [insert correct value here]
velocity in [insert correct direction] direction afterwards. Those are
physical properties that I do try to achieve.
Now, how to go about implementing it? It's not a real physical system, but
merely some particle system with some physical properties. What I want is to
include certain characteristics which will in turn result in realistic kinds
of animation. Look at Rune's or my other particle system, they do have
certain characteristics which have their basis in the real world.
Then the formula for a 100% realistic simulation would be helpful if, in
fact, certain criteria are present in my system. Some of them are, some
aren't. There is energy in my system, but its just stuck with the particles.
When a particle hits the floor, I don't add energy to the floor, calculate
its... Ehm, forget the right term. "Laziness in getting moved" I'll entitle
it :-) and thus reduce the energy remaining for the particle, I just
subtract some percentage of the velocity which is parallel to the surface
normal.
Take, for example, the distance an object has dropped in free fall, the
formula is
h = g*t^2 / 2
There's nothing like air stopping the falling in this formula, it's entirely
simplified, but still relevant. It just assumes that there's no friction. I
was asking for the same: in a no friction-system, what's the rate of
slowdown for an object moving uphill?
As said before: the points discussed are valid, but they weren't what I was
asking for. I didn't want to discuss how and why my particle system works
the way it does, I've spent thought on that already and decided to go a
certain way. The discussion provided me with some insight into some
drawbacks of the approach, but they weren't relevant to the question.
> You should understand that most people here when talking about gravity,
> energy etc. are referring to what these terms mean in physics, not how
> you use them in your simulation system. In physics gravity in an
> acceleration which - according to Newton - exerts a force on all masses
> in the system. Whether or not this results in a change of velocity (and
> thereby in kinetic energy) depends on the environment.
Of course, I understand that. Still, I was trying to find a solution to a
problem that occurs *in* my simulation, not *in* the real world. While I was
describing what happens in the system and trying to find a solution for
that, I got responses like "oscillation doesn't happen in the real world".
How does that help me solve my problem? And, aside of that, I'm not a newbie
to the real world. :-)
I hope there are no hurt feelings because of my recent reply. I just felt at
some point like it was a discussion of "real world" vs "simulation" and that
wasn't really an issue, real world just is real, simulation isn't, see? ;-)
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:
>
> Take, for example, the distance an object has dropped in free fall, the
> formula is
> h = g*t^2 / 2
> There's nothing like air stopping the falling in this formula, it's entirely
> simplified, but still relevant. It just assumes that there's no friction. I
> was asking for the same: in a no friction-system, what's the rate of
> slowdown for an object moving uphill?
As always the key to solving a problem is to understand it. Your formula:
h = g*t^2 / 2
is in the 1-dimensional case you describe the result of the following ideas:
- the position of a point mass at the time T is:
T
x = x0 + S v dt
t=0
(The 'S' being an integral)
- the velocity of the point mass with an acceleration a is:
T
v = v0 + S a dt
t=0
(x0 and v0 are the starting values for position and velocity at T=0)
Now just integrate twice and you get your formula (assuming starting
conditions v0=0 and x0=0, h=x, g=a). For the 2D/3D case it is
essentially the same, just with vectors for position, velocity and
acceleration of course. Note you can have arbitrary starting conditions
- the formulas will work the same way for 'uphill' and 'downhill'.
But don't forget that a is *not* the gravity but the sum of all
accelerations - or accoring to Newton: F=m*a - the result of all forces
influencing the particle. In case of surface contact (slipping) the
contact force (which has nothing to do with friction) has to be taken
into account (and it will strongly vary, a=a(t) in the above integral).
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
> > Take, for example, the distance an object has dropped in free fall, the
> > formula is
> > h = g*t^2 / 2
> > There's nothing like air stopping the falling in this formula, it's
entirely
> > simplified, but still relevant. It just assumes that there's no
friction. I
> > was asking for the same: in a no friction-system, what's the rate of
> > slowdown for an object moving uphill?
>
> As always the key to solving a problem is to understand it.
SNIP
I don't get what you're trying to tell me, and I'm not sure that you got
what I've been trying to tell you. We have real world issues and simulation
issues that are independant of each other. Something that happens in a
simulation doesn't require the real world to behave that way and vice versa.
Now, my system can solve the problem of rolling uphill via tons of impacts
and it does look right. But how about just a formula to roll uphill,
independant of impacts? I was at a loss of the formula, not the issue
itself.
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:
>>> Take, for example, the distance an object has dropped in free fall, the
>>> formula is
>>> h = g*t^2 / 2
>>> There's nothing like air stopping the falling in this formula, it's
>>> entirely
>>> simplified, but still relevant. It just assumes that there's no
>>> friction. I
>>> was asking for the same: in a no friction-system, what's the rate of
>>> slowdown for an object moving uphill?
>>
>>As always the key to solving a problem is to understand it.
>
> SNIP
>
> I don't get what you're trying to tell me, and I'm not sure that you got
> what I've been trying to tell you. We have real world issues and simulation
> issues that are independant of each other. Something that happens in a
> simulation doesn't require the real world to behave that way and vice versa.
Now i am stuck, could you please read the question i quoted from you
above again and tell me if i answered your question or not? If not
please specify what is missing.
I have the impression that when you don't like the answer you get you
simply say that's not what you are trying to do, that you don't want to
simulate reality at all - fine, but then why do you ask the question in
the first place?
> Now, my system can solve the problem of rolling uphill via tons of impacts
> and it does look right. But how about just a formula to roll uphill,
> independant of impacts? I was at a loss of the formula, not the issue
> itself.
I did not talk about impacts in my answer at all.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Christoph Hormann wrote:
> Now i am stuck, could you please read the question i
> quoted from you above again and tell me if i answered
> your question or not? If not please specify what is
> missing.
If I may come with my thoughts here... I have a feeling that Tim is
creating his system in a way that resembles the way I did it.
My particle system doesn't have any such things as potential energy,
conversation of energy, or even masses. I didn't care about that. Yet I
managed to create a system where the end results looks like something
that at least resembles the real world, and where particles do in
certain ways move the way they would in the real world.
All the time while creating it my goal was not that the internal
data-representation resembled the real world, but rather that the end
result (the animations) looked (more or less) like the real world to a
certain extent. Tim Nikias probably know more about the physics of the
real world than I, but it seems he have the same attitude toward
creating a simulation as I had.
Of course it is a bit problematic in this situation to ask for help with
creating the system. Tim have to just "take it or leave it" with regards
to the proposed solutions he get, but the repliers also have to accept
that their proposed solutions might not be what Tim is looking for even
if they are physically correct...
Well, that's how I see it. I might be wrong. In any case I hope nobody
gets offended, because that's not my intention.
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Rune wrote:
>
> [...]
That's completely right, but you have to take care not to reject a
solution just *because* it is realistic.
BTW the "it does not have to be realistic, it just has to look nice" vs.
"if it is realistic it will look correct as well" is a very old conflict
in CG. But in the end it often boils down to a
physically/mathematically correct solution - if implemented efficiently
- also being the most useful one and the best intuitive solutions also
being physically quite accurate.
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's completely right, but you have to take care not to reject a
> solution just *because* it is realistic.
I wasn't rejecting them for being accurate, but for being near to impossible
to implement in the model I've built so far. I thought that my replies made
clear that I wasn't rejecting the physical properties, but the solutions
presented weren't fitting to my model. I tried to explain why it wouldn't
work, but I guess I've failed. Maybe we've talked alongside each other and
were interpreting too much or too little what the other was saying. Lets
just settle it with "my simulation isn't realistic, just looks like it, so
real-life formulas can't always be applied", okay? ;-)
> BTW the "it does not have to be realistic, it just has to look nice" vs.
> "if it is realistic it will look correct as well" is a very old conflict
> in CG. But in the end it often boils down to a
> physically/mathematically correct solution - if implemented efficiently
> - also being the most useful one and the best intuitive solutions also
> being physically quite accurate.
It depends on what you're after. If you want something versatile and
intuitive, then sure, by all means, make it realistic and efficient. If you
just want one certain effect, do it quick and dirty. :-)
--
"Tim Nikias v2.0"
Homepage: <http://www.nolights.de>
Email: tim.nikias (@) nolights.de
Post a reply to this message
|
|
| |
| |
|
|
From: Lutz-Peter Hooge
Subject: Re: Some aid in physics required...
Date: 25 Feb 2004 11:12:23
Message: <403cc967@news.povray.org>
|
|
|
| |
| |
|
|
<"Tim Nikias v2.0" <tim.nikias (@) nolights.de>> wrote:
> 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
So if I understand you correctly, every time a particle bounces on a surface,
you remove some kinectic energy form it by lowering it's velocity perpedicular
to the surface. Like v_new = -0.8*v_perpendicular + v_parallel.
Of course this leads to the situation that each bounce will get smaller (and
will also take a shorter time) than the previous one.
One solution to this would be, that when v_perpedicular is lower than a certain
threshold just use v_new = -v_perpendicular + v_parallel, so the bounces will
stop getting smaller. With the correct threshold the bounces should get so
small that you just can't see them, but not smaller than that.
Lutz-Peter
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Just wanted to inform you that your idea with tracing within a timestep
works fine. I did get a few particles that traced more than 4000 iterations
of this trace-loop (the particle were rolling down a cone-tunnel, animation
will be posted shortly) but it was quick: 0.2 seconds per frame, at the
beginning and sometimes inbetween even 0.1 seconds.
Quiet a lot of bugs popped up when trying to implement this, but its finally
sorted out and I'm really satisfied with the stable results. Thanks for the
suggestion!
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:
> Just wanted to inform you that your idea with
> tracing within a timestep works fine.
> Quiet a lot of bugs popped up when trying to
> implement this, but its finally sorted out and
> I'm really satisfied with the stable results.
> Thanks for the suggestion!
No problem. I'll have a look at the animation. :)
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
|
|
| |
| |
|
|
|
|
| |
| |
|
|
This conservation of energy idea is cool. Someone suggested it back when I
was trying to model the solar system back in 2002, but I think I got it now.
OLD SYSTEM:
particle at p with velocity v
p=p+v/constant
a=sum of forces based on new surroundings
v=v+a/constant
repeat for every frame of animation, giving extreme energy losses.
NEW PROPOSED SYSTEM:
particle at p with velocity v and kinetic energy K
p=p+v/constant
calculate work done by moving along/against all forces in x,y, and z.
this gives a delta to old kinetic energy K.
okay now I'm lost
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
| |
|
|
Among other things, Greg M. Johnson wrote:
> This conservation of energy idea is cool. Someone suggested it back when
> I was trying to model the solar system back in 2002, but I think I got it
> now.
>
>
> OLD SYSTEM:
> particle at p with velocity v
> p=p+v/constant
> a=sum of forces based on new surroundings
> v=v+a/constant
>
> repeat for every frame of animation, giving extreme energy losses.
>
> NEW PROPOSED SYSTEM:
> particle at p with velocity v and kinetic energy K
> p=p+v/constant
> calculate work done by moving along/against all forces in x,y, and z.
> this gives a delta to old kinetic energy K.
>
> okay now I'm lost
Are you looking for a way of simulating a system of "particles", subject to
interactions between them, in a physically meaningful way? You should have
a look at some "molecular dynamics" algorithms. Moldy
(http://chin.icm.ac.cn/~xxia/webchin/software/moldy.html) is a nice free
program, which features an interesting manual. Basically, you know the
positions, velocities and forces on all the particles at a given time, and
calculate them for a later moment, and repeat. To obtain the new positions
(and velocities), algorithms like Verlet and "leapfrog" are popular.
--
light_source{9+9*x,1}camera{orthographic look_at(1-y)/4angle 30location
9/4-z*4}light_source{-9*z,1}union{box{.9-z.1+x clipped_by{plane{2+y-4*x
0}}}box{z-y-.1.1+z}box{-.1.1+x}box{.1z-.1}pigment{rgb<.8.2,1>}}//Jellby
Post a reply to this message
|
|
| |
| |
|
|
|
|
| |
|
|
