Just want to clean little about Euler integration , often used in a reviews, this post continue some previous posted. Many times a have seen such a code : Body::StepSimple( float time_step ){ CulcAcceleration(); velocity += acceleration * time_step; position += velocity * time_step; } OR Body::StepSimple2( float time_step ){ CulcAcceleration(); position += velocity * time_step; velocity += acceleration * time_step; } Do every body see diffrence ? Who is right ? But many of us know that Correct calculation is: Body::StepCorrect( float time_step ){ CulcAcceleration(); VelocityOld = Velocity; Velocity += Acceleration*DT; Position += 0.5*(VelocityOld + Velocity)*DT } Even more ... i sow that calculation of momental forces take 95% of calculation but integrate still by StepSimple. Why so much Physics engines still use StepSimple ? Because they work with Forces that changes intensively and depends of position and velocity, that can''t be solved right. Example : vector3 SomeFriction( ){ FrictionForce = - Velocity.normalize()*Velocity.len_square()*FC; } To be stable in such case we need a little time_step and calculate it very fast or it goes unstable. Or calculate some Constrained motion, that too need a minimal time_step. But if you use in simulation some Space Ships with gravity and engines IT is more and more faster calculate StepCorrect 1 time between frames than do some several StepSimle with comparable precision. Everybody wellcome to discussion .

I use step-simple (as you put it) for space-ship physics because the differential equation(s) to figure position near a set of gravity wells is REALLY nasty.

They''re fairly accurate if the step size is kept small (remember, integration is just the result math when you make the step size uncalculatably small). With my systems, I usually vary time_step based on what framerate I''m getting... but I have to use a fixed time_step in a multi-player setting, which means multiple physics calculations per graphics (potentially) or the other way around.

It''s kind of annoying that "step-simple" isn''t exact, but I really don''t want to look at the differential equations for gravity wells anymore.

The normal Euler''s method is:

x(n+1) = x(n)+v(n)*h
v(n+1) = v(n)+a(n)*h

a much more stable approximation is the second method you gave:

x(n+1) = x(n)+v(n+1)*h
v(n+1) = v(n)+a(n)*h

This is still trivial to compute. It doesn''t involve solving systems of equations. You suggested as the third method:

x(n+1) = x(n)+[v(n)+v(n+1)]*h/2
v(n+1) = v(n)+a(n)*h

I don''t see why this would make the method more stable. I''ll try testing it at home. It should have a little better error properties, though. The most stable method is of course to write:

x(n+1) = x(n)+v(n+1)*h
v(n+1) = v(n)+a(n+1)*h

But this involves (usually) linearization and solving a huge system of linear equations. OK, that was my bit.

- Mikko Kauppila

To Nypyren:
That is most popular way i think. But it possible in a multyplaer calculate behavior forces coliisions and e.t. by fixed time_step and motion calculate (if fps bigger) by time_step related on frame duration.

To uutee
I talk about apriori stable simulation, the gravity is a stable enought in far away from planet, and we can do exac solution instead "stable approximation".
If we will speak about general case, than it very intresting. Exist many methods.

Can you talk how you plan to test stability ? It is very intresting ! Let me know please if you will test .

And i don''t understand how can be calculated ?
x(n+1) = x(n)+v(n+1)*h
v(n+1) = v(n)+a(n+1)*h
if a(n+1) based on x(n+1) and v(n+1) , how can we know a(n+1) ?

quote:

---

And i don''t understand how can be calculated ?
x(n+1) = x(n)+v(n+1)*h
v(n+1) = v(n)+a(n+1)*h
if a(n+1) based on x(n+1) and v(n+1) , how can we know a(n+1) ?

---

Base a(n+1) on x(n) and v(n) then.

"Base a(n+1) on x(n) and v(n) then."

Can it be better than two simple steps of 0.5*time_step ?

http://www.ioi.dk/Homepages/thomasj/publications/gdc2001.htm

I found this article , where such as befor method of integration called Verlet

quote:

---

Original post by uutee
x(n+1) = x(n)+v(n+1)*h
v(n+1) = v(n)+a(n)*h

---

Of course, you'd have to evaluate that in this order:

v(n+1) = v(n)+a(n)*hx(n+1) = x(n)+v(n+1)*h  

And, of course, that is no longer the simple Euler method, .

quote:

---

Original post by uutee
x(n+1) = x(n)+[v(n)+v(n+1)]*h/2
v(n+1) = v(n)+a(n)*h

I don't see why this would make the method more stable. I'll try testing it at home. It should have a little better error properties, though.

---

Again, that would have to be evaluated in the opposite order, e.g., calculating v(n+1) first before x(n+1). Yes, this form might be a bit destablizing.

quote:

---

Original post by uutee
The most stable method is of course to write:

x(n+1) = x(n)+v(n+1)*h
v(n+1) = v(n)+a(n+1)*h

---

Ah, yes, the infamous "implicit Euler" method. Much more stable, difficult to code. But actually not necessarily the most stable method. Among implicit methods even there are variations in stability. And certainly there are more accurate implicit methods.

That was a very good post, Mikko!

Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.

[edited by - grhodes_at_work on December 18, 2002 3:12:12 PM]

> And certainly there are more accurate implicit methods.

You can''t just leave it like that Graham.
We are all waiting (well, maybe just me) for a detailed description of these wonderfull methods you talk about.

I have a spelling correction for minorlogic:

"Neuton Low" should be "Newton''s Law"

Graham Rhodes
Senior Scientist
Applied Research Associates, Inc.