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