Velocity Tracking

try euler integration:

velocity = velocity * acceleration * timeStep
position = position * velocity * timeStep

intrest86, your idea to update velocity based on acceleration is appropriate, but your equation is wrong. genovov's equation for Euler integration is correct, BUT (a major BUT), Euler integration is actually the poorest way to do numerical integration. It is inaccurate, but the accuracy is less of a problem than the stability. It is also inherently unstable for many problems that you might want to simulate in a game. And you don't want your game simulations to be unstable.

Try a 2nd order Runge-Kutta integration or a Verlet integrator. You should be able to find these easily with a web search on google.com. I did a paper for GDC 2001 that discussed numerical integration methods. Its a bit advanced, but you can find it here:

Title "Stable Rigid-Body Physics"
actual subject: stability issues of numerical methods (not much physics discussion)
http://www.gdconf.com/archives/proceedings/2001/prog_papers.html
There are PDF downloads for the paper and presentation.

Also, genovov, you may not know this, but Euler integration was named after a man. It is proper to capitalize the first letter of methods and equations named after people. This might seem like a minor point, but it would be important for more formal writings, such as published technical papers.

Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.

Edited by - grhodes_at_work on December 19, 2001 3:57:52 PM

> Euler integration is actually the poorest way to do numerical integration.

In my experience this is not always true. Euler integration is simpler and cruder, but this also makes it cheaper in terms of processor cycles.

So instead of choosing a better method you can instead call your Euler integrator more often, with a smaller time step. This still is a generally worse approach, except there may be other reasons for using a smaller time step.

E.g. with dynamics simulations you often want to run the simulation with as small a time step as possible for more accurate collision detection, as a bigger time step may result in objects interpenetrating more before a collision is detected. Or the high frame rates of the game, or the need for instant responsiveness, may impose a high update rate.

For a high update rate the cost of calculating the step needs to cheap as possible, and in general an Euler integrator is cheapest. If it is accurate and stable enough at the chosen update rate there''s no reason to use anything else.

quote:

---

Original post by johnb
In my experience this is not always true. Euler integration is simpler and cruder, but this also makes it cheaper in terms of processor cycles.

So instead of choosing a better method you can instead call your Euler integrator more often, with a smaller time step. This still is a generally worse approach, except there may be other reasons for using a smaller time step.

E.g. with dynamics simulations you often want to run the simulation with as small a time step as possible for more accurate collision detection, as a bigger time step may result in objects interpenetrating more before a collision is detected. Or the high frame rates of the game, or the need for instant responsiveness, may impose a high update rate.

For a high update rate the cost of calculating the step needs to cheap as possible, and in general an Euler integrator is cheapest. If it is accurate and stable enough at the chosen update rate there''s no reason to use anything else.

---

Well, yes, perhaps I was a little overzealous! The Euler method certainly is the cheapest integration step. And it can absolutely be used if done with care. Actually, as long as you don''t put springs in your system (either by trying to model real springs or to model collisions or rigid body constraints), the simple Euler method should not be unstable at all. And even if you do have springs that are only active for very short periods of time, you can still use the Euler method as long as you are VERY careful to restart the integration from a known good state after the spring action is done. And turn the springs off as soon as possible. It is quite easy to get into trouble in this case.

Be aware that smaller time steps do not make the Euler method stable when you have spring-like forces and behavior. The smaller time steps merely delay the inevitable instability, and it is always necessary to stop applying any spring forces before the simulation gets out of hand.

Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.

i am aware that it''s ''Euler'', i just tend not to capitialize in posts.

Verlet integration (as i understand it) is as simple as Euler intergration, and computationaly cheap as well. I was exposed to it in an interesting article here:
http://www.ioi.dk/Homepages/tj/publications/gdc2001.htm

i''d be very interested in your comments about that paper, Graham, if you have a couple minutes to read it over. i''m seriously considering creating an engine based on the ideas the author presents to simulate soft, rigid and articulated bodies in a beliveable way.

Ok, wait a sec...

d=(initial position)+(initial velocity)(time)+.5(acceleration)(time)^2

We differentiate to find velocity:

v=(intitial velocity)+(acceleration)(time)

So, wouldn''t this work? Instead of usin an integration I am usin a limit as time approaches 0...




If one person would write a book on DirectX in VB, I would make them a rich man!

quote:

---

Original post by genovov
try euler integration:

velocity = velocity * acceleration * timeStep
position = position * velocity * timeStep

---

Shouldn''t it be

velocity = velocity + acceleration * timeStep?

I assume it''s a typo, but I''ve never looked at Euler integration, so I''m not sure if I understand the problem, or understand how Euler integration is applied.

Btw, what part of NS are you from? I''m in Lunenburg! Originally from PEI.

doh! you''re right, it was a typo.
i''m in halifax, originally from ontario. isn''t there a game shop down in lunenburg?