Home » Community » Forums » » A Simple Time-Corrected Verlet Integration Method
  Intel sponsors gamedev.net search:   
[Control Panel] [Register] [Bookmarks] [Who's Online] [Active Topics] [Stats] [FAQ] [Search]

Add Forum to Favorites |  Send Topic To a Friend | View Forum FAQ | Track this topic


 Last Thread Next Thread 
 A Simple Time-Corrected Verlet Integration Method
Post Reply 
Well written article, although I'd recommend fixing your physics timestep in the first place. Otherwise, you'll never be able to reliably recreate any scenario due to the inherent inaccuracies in integration. A fixed step physics engine is not only much easier to debug, but also much easier to add networking capabilities to. And as you stated in the article, normal verlet integration will yeild exactly the same results as TCV if the timestep is fixed.

Glenn Fiedler writes more about the issue on his website (as well as providing some excellent physics tutorials!): http://www.gaffer.org:8080/articles/

 User Rating: 1022   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Thanks for the feedback. There are many reasons to used a fixed timestep (gaffer's article is excellent), however, this is just a technique to improve accuracy if you can not or do not want to use a fixed time step.

[edit for spelling]

[Edited by - lonesock on February 7, 2005 1:34:12 PM]

lonesock
Piranha are people too.
www.lonesock.net
SOIL: Simple OpenGL Image Library
"The Core" iRiff
"The Mummy" iRiff

 User Rating: 1462   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Really good description of the verlet scheme. However, even if you time-correct your verlet integrator you will still run into problems if it includes constraints that are not 100% relaxed. Doing anything more advanced than an isolated particle requires a fixed time step, IMHO.

Dennis
http://www.meqon.com


 User Rating: 1037   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

hi, dengu.

I'm just now implementing physics for my little game engine (and I certainly have not coded a "physics middleware containing cutting-edge technology for interactive dynamics simulation", nice website! [8^). So I welcome your informed opinion.

My background is in numerical simulation methods for physical problems (finite element, difference, etc.) where an adaptive timestep is extremely desirable (as you can shrink dt if the solution changes too rapidly). In such cases Verlet, which is an otherwise elegant solution, had to be thrown out. The TCV is much better behaved with changing timesteps, so accuracy is once again mainly dependent on dt, and not on d(dt)/dt.

The Verlet still has issues when you just want to update, say, a particle's position. The position is not just position, but a combination of the last timestep's velocity and acceleration as well. So it _can_ go unstable very quickly when you start implementing collisions and simply update the current position, without touching the previous position as well.

thanks for your input.

[edit: AHHH, spelling!]

[Edited by - lonesock on February 7, 2005 7:29:59 PM]

lonesock
Piranha are people too.
www.lonesock.net
SOIL: Simple OpenGL Image Library
"The Core" iRiff
"The Mummy" iRiff

 User Rating: 1462   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Hey

I'm planning to code game with Gish-like-physics and it's the first time ever I'm writing sth more advanced involving physics. My previous games were using time fixed step, so on animation in 95% was a bit jerky :-/ I wanted to remedy that problem and use framerate independent solutions... I've written already bunch of code, done some assumptions... and now I found:

Quote:

However, even if you time-correct your verlet integrator you will still run into problems if it includes constraints that are not 100% relaxed. Doing anything more advanced than an isolated particle requires a fixed time step, IMHO.


Dengu, is it really impossible to create sth like this (http://www.chroniclogic.com/demo/gishdemo.exe) using non fixed game? I've read Advanced Character Physics by Jakobsen, and he stated that using Verlet + particles + infinitely stiff springs + handling collisions by relaxation + OtherStuff etc. is very stable, accurate, fast and rather simple way to achieve good looking physics (that system was used in Hitman). Alas, he didn't mention anything about time issue :-/ so I don't know what really think about it...

And one more question: when physics engine uses fixed time step, does it mean that whole rest of game also needs to be fixed?

(btw: nice article, but I've read it before on Lonesock's homepage :-))


Koshmaar

Magic Pencil | SDL_Config (Homepage, Download) )


 User Rating: 1292   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by Koshmaar
And one more question: when physics engine uses fixed time step, does it mean that whole rest of game also needs to be fixed?


Nope, typically you do want the frame rate to be as fast as possible, but things like networking and physics can be decoupled (see gaffer's articles that meink mentioned).

as to stability, using the TCV with changing dt is no less stable than using fixed time steps...what matters is that you impose an upper limit on the timestep.

something like:

while (dt > dt_thresh)
{
    Do_Physics (dt_thresh);
    dt -= dt_thresh;
}
Do_Physics (dt);


will take care of stability issues. In fact, with changing time steps you can be _more_ accurate. However, you will not be deterministic. Using fixed or variable timesteps is sometimes more a philosophy question more than a technical one.

Using fixed timesteps is nice for things like demo playback (though subsampling and interpolation will work just as well), and networking (timestamps can be integers, instead of floating point, etc.)

btw, thanks for reading it..sorry you had to see it on my webpage 1st [8^)


lonesock
Piranha are people too.
www.lonesock.net
SOIL: Simple OpenGL Image Library
"The Core" iRiff
"The Mummy" iRiff

 User Rating: 1462   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Nicely written article. As an alternative, what are the drawbacks to integrating with a variable number of fixed time steps, instead of integrating using a variable time step? (I'm sure there is a proper term for this) As an example:
real time       0     1.1    2.2     3.7  4.4 4.9   6.1   6.9  7.6 ...
                |     |      |       |    |   |     |     |    |
integrator time 0     1      2       3 4      5     6     7    8   ... 
Your integrator's time will be off by 1/2 time step, at most.


John Bolton
Locomotive Games (THQ)
Current Project: Destroy All Humans (Wii). IN STORES NOW!


 User Rating: 1839   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by JohnBolton
Nicely written article

thanks

Quote:
Original post by JohnBolton
what are the drawbacks to integrating with a variable number of fixed time steps, instead of integrating using a variable time step?...Your integrator's time will be off by 1/2 time step, at most.

My cheating answer: it depends [8^)
1) for simulations (not necessarily game related) with really stiff or very non-linear systems, the fixed timestep must be pretty small for stability or accuracy considerations. With a variable timestep, you can skate over the easy portions, and just adapt the dt when the state changes too fast.
2) for games, using interpolation you never have to be dt/2 off. But the interpolation is just as expensive as a Verlet (or Euler) step (not so if you use RK4, or similar, of course), so in the case of dt << fixed_dt, you are just interpolating, and losing accuracy (but just as cheap numerically). if dt~=fixed_dt then you doubled your workload, for no gain in accuracy. if dt>>fixed_dt, you get higher accuracy, but higher workload


Quote:
Page 44 Studios

dang, yet another nice website, with professionals who work on physics engines!

lonesock
Piranha are people too.
www.lonesock.net
SOIL: Simple OpenGL Image Library
"The Core" iRiff
"The Mummy" iRiff

 User Rating: 1462   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by lonesock

Nope, typically you do want the frame rate to be as fast as possible, but things like networking and physics can be decoupled (see gaffer's articles that meink mentioned).


Ok, thanks, that's what I wanted to read :-) (btw: I won't do networking in this game)

So in summary, I can use my normal, framerate independent stuff in game, and use fixed time step for physics loop (using normal Verlet, not-TCV, integrator).

How then main loop should look like? Do you have any links to relevant sources? It would be best if they were written in C++ with SDL, but that's not necessarily needed :-]


Quote:

btw, thanks for reading it..sorry you had to see it on my webpage 1st [8^)


Nothing to worry about... :-)


Koshmaar

Magic Pencil | SDL_Config (Homepage, Download) )


 User Rating: 1292   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Quote:
Original post by Koshmaar
How then main loop should look like? Do you have any links to relevant sources? It would be best if they were written in C++ with SDL, but that's not necessarily needed :-]


oliii has a nice demo webpage with executables and source. Check out his "3D verlet vehicle on terrain" demo and source. it's GLUT, not SDL, but very nice.

lonesock
Piranha are people too.
www.lonesock.net
SOIL: Simple OpenGL Image Library
"The Core" iRiff
"The Mummy" iRiff

 User Rating: 1462   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

Thank you very much for the article. I want to show a small mistake here:

>> *Hint: remember the central difference 2nd derivative approximation?
>> d2x / dt2 = ai2= (xi+1 - 2*xi + xi+1) / dt2

That last xi+1 should be xi-1 :))

Ogla


 User Rating: 1015   |  Rate This User  Send Private MessageView Profile Report this Post to a Moderator | Link

All times are ET (US)

Post Reply
 Last Thread Next Thread 
Forum Rules:
You may not post new threads
You may post replies
You may not edit your posts
You may not use HTML in your posts
Jump To:
Administrative Options: