Particles with drag
Author
I've got a particle system with particles that I'm modeling with ordinary ol' physics equations (position += velocity * 1/fps, etc). This works fine for particles with constant acceleration, but the problem comes when I try to model an explosion using particles that have a huge initial velocity and a very large drag. First I apply the drag to the velocity, then apply the velocity to the position. But what happens is that many times the FPS is low enough that by the time the particles are processed, enough time has elapsed that the drag makes the velocity near zero. So when the position is updated, the particles don't really move.
Updating the position first then applying the drag to velocity won't work either, since then I could have particles that spread way too fast.
It seems like a simple issue, but I'm stumped.
There are a few recent threads on that issue, try looking them up.
Drag is a force, so it should be added to the acceleration in the usual way
' Acceleration += drag/m '
An approximating formula for it is given by
drag = (1/2)*Cd*rho*A*u^2
where Cd is the coefficient of drag, rho is the fluid's density (air's in this case), A is an approximation of the area of the object normal to the wind direction and u is the velocity.
Try googling these, you should find enough material.
edit:
Let me quote a couple of recent replies in another thread
Drag is a force, so it should be added to the acceleration in the usual way
' Acceleration += drag/m '
An approximating formula for it is given by
drag = (1/2)*Cd*rho*A*u^2
where Cd is the coefficient of drag, rho is the fluid's density (air's in this case), A is an approximation of the area of the object normal to the wind direction and u is the velocity.
Try googling these, you should find enough material.
edit:
Let me quote a couple of recent replies in another thread
Quote:
(Originally posted by Zipster)
For best results you want a fixed timestep, however the word 'best' is loosely applied as Euler integration is probably the least accurate method and has a tendency to fly off the handle if you're not careful. Usually, this means you can destabilize the system by applying too much force at once.
Quote:
(Originally posted by me)
I totally agree with Zipster. The fixed timestep is very important if you want accuracy. You may want to consider starting a new thread to run asynchronous physics simulations independently of your main loop. This will assure that whenever you will need to draw your objects, the correct number of simulations will already have been performed for the given time. People also avoid to use Euler integration for accuracy issues. Maybe you want to consider an alternative method. the Runge-Kutta methods seems to be quite popular...
Author
Well, I guess fixed timesteps would be pretty simple to do. I've already got a callback system where each object has a process_frame() and a process_timestep() that's called once per frame and once per timestep (at 100 Hz), respectively. I guess I'll just move the particle processing stuff from process_frame() to process_timestep().
Here's an interesting hack that might be useful. If the drag force is the only force acting on a particle then you can describe the motion of the particle as
v' = -a v2
x' = v
where "x" and "v" are the displacement and velocity of a particle, and "a" is a bunch of coefficients that someusername mentioned. You can treat this as a 1D problem if drag is the only force applied to the particle. So these equations apply in the original line of motion.
Sorry, I don't think i explained that very well**.
However, you can solve the above equations, which is a nice thing. We can solve for v to get
v(t) = (a*t + v(0))-1
where v(0) is the initial velocity of the particle. So now that we have v(t) we can also solve for x(t):
x(t) = ln((a*t)/v(0) + 1) + x(0)
I'm jumping a few steps (let me know if you want me to expand). So this is how the position of the particle will move using this drag law. It is a bit of a bummer that it involves a logarithm because you don't want to have to call that each timestep for each particle. It is also a nuisance to approximate a logarithm but you'd probably have to do that somehow.
** I'll try again. With only drag acting on the particle, the particle moves (with varying speed) along a line. So we only need to solve the above equation along that line. That means working with scalars, which is easier. The x(t) and v(t) are the displacement and velocity along that line. The direction of the line will be given by the original (2D or 3D) velocity. I hope that is clearer [smile]
v' = -a v2
x' = v
where "x" and "v" are the displacement and velocity of a particle, and "a" is a bunch of coefficients that someusername mentioned. You can treat this as a 1D problem if drag is the only force applied to the particle. So these equations apply in the original line of motion.
Sorry, I don't think i explained that very well**.
However, you can solve the above equations, which is a nice thing. We can solve for v to get
v(t) = (a*t + v(0))-1
where v(0) is the initial velocity of the particle. So now that we have v(t) we can also solve for x(t):
x(t) = ln((a*t)/v(0) + 1) + x(0)
I'm jumping a few steps (let me know if you want me to expand). So this is how the position of the particle will move using this drag law. It is a bit of a bummer that it involves a logarithm because you don't want to have to call that each timestep for each particle. It is also a nuisance to approximate a logarithm but you'd probably have to do that somehow.
** I'll try again. With only drag acting on the particle, the particle moves (with varying speed) along a line. So we only need to solve the above equation along that line. That means working with scalars, which is easier. The x(t) and v(t) are the displacement and velocity along that line. The direction of the line will be given by the original (2D or 3D) velocity. I hope that is clearer [smile]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
