|
||||||||||||||||||
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 |
|
![]() meink Member since: 3/21/2004 From: Melbourne, Australia |
||||
|
|
||||
| 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/ |
||||
|
||||
![]() lonesock Member since: 2/12/2004 |
||||
|
|
||||
| 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 |
||||
|
||||
![]() dengu Member since: 6/6/2004 From: Sweden |
||||
|
|
||||
| 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 |
||||
|
||||
![]() lonesock Member since: 2/12/2004 |
||||
|
|
||||
| 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 |
||||
|
||||
![]() Koshmaar Member since: 11/21/2003 From: Cracovia, Poland |
||||
|
|
||||
| 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: 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) ) |
||||
|
||||
![]() lonesock Member since: 2/12/2004 |
||||
|
|
||||
Quote: 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 |
||||
|
||||
![]() JohnBolton Member since: 4/3/2002 From: Belmont, CA, United States |
||||
|
|
||||
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! |
||||
|
||||
![]() lonesock Member since: 2/12/2004 |
||||
|
|
||||
Quote: thanks Quote: 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: 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 |
||||
|
||||
![]() Koshmaar Member since: 11/21/2003 From: Cracovia, Poland |
||||
|
|
||||
Quote: 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: Nothing to worry about... :-) Koshmaar Magic Pencil | SDL_Config (Homepage, Download) ) |
||||
|
||||
![]() lonesock Member since: 2/12/2004 |
||||
|
|
||||
Quote: 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 |
||||
|
||||
![]() Ogla Member since: 9/13/2006 From: Kas, Turkey |
||||
|
|
||||
| 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 |
||||
|
||||
All times are ET (US)![]() |
Last Thread Next Thread ![]() |
|