On Time
Author
Can anyone point me in the right direction on some articles that discuss the topic of time when it comes to calculating physics. In my experiments I've implemented time in different ways depending on what I was doing. For each it was specialized for the task at hand and tying those experiments together would not be easy.
I'm hoping that somewhere there is some good information on different ways to approach time in real time games and simulations, what their strong and weak points are, and examples of implementation. It seems like this would be covered in a game engine development tutorial or book, but I've been trying to find it in something a little less heavy. If anyone knows off hand any good documents or books that go in depth into dealing with time a point in the right direction would be appreciated.
-Corey
I don't have a definitive reference for you, but here are some pointers, in stream-of-consciousness order.
1) Decouple the simulation from the rendering and do the simulation in discrete time steps ( ie 16 milliseconds per tick ).
These together make your physics more stable, and testable. As part of this, you will make your game loop take an time argument like so
also, your rendering probably needs a tick, but not necessarily the same value as the session tick.
The renderer can track the time since it last rendered to do motion trails, etc. This allows an easy freeze frame matrix-like effect.
For consistency, I always work in seconds with my physics.
3) Have a game session object that tracks the current time as seen by this game session.
This should be where all game-related things get their time count. Very few places in your engine should ever query the actual system time.
When the simulation is paused, tick is either not called, or called with a zero time value.
Something like the HUD, gui or menu probably needs the real-time clock to do animations.
4) Game events should have a time to activate.
This allows you to ensure events happen in causal order, as well as schedule events for the future.
5) If each game object has its own tick function taking a time parameter, each object could potentially operate in slow or fast motion.
6) Networked games need a consistent time measurement for all clients. Typically the server provides this at connect time, and may periodically update the time.
7) Networked games often benefit from tracking the real-time latency of each client to do prediction and correction.
1) Decouple the simulation from the rendering and do the simulation in discrete time steps ( ie 16 milliseconds per tick ).
These together make your physics more stable, and testable. As part of this, you will make your game loop take an time argument like so
void Game::Session::Tick( const size_t milliseconds );also, your rendering probably needs a tick, but not necessarily the same value as the session tick.
void Renderer::Frame( const size_t milliseconds );The renderer can track the time since it last rendered to do motion trails, etc. This allows an easy freeze frame matrix-like effect.
For consistency, I always work in seconds with my physics.
void Game::Object::Tick( const float32& seconds );3) Have a game session object that tracks the current time as seen by this game session.
This should be where all game-related things get their time count. Very few places in your engine should ever query the actual system time.
When the simulation is paused, tick is either not called, or called with a zero time value.
Something like the HUD, gui or menu probably needs the real-time clock to do animations.
4) Game events should have a time to activate.
This allows you to ensure events happen in causal order, as well as schedule events for the future.
5) If each game object has its own tick function taking a time parameter, each object could potentially operate in slow or fast motion.
6) Networked games need a consistent time measurement for all clients. Typically the server provides this at connect time, and may periodically update the time.
7) Networked games often benefit from tracking the real-time latency of each client to do prediction and correction.
The usual references are David Baraff, Ron Fedkiw, Thomas Jakobsen, Chris Hecker, Jeff Lander. I'd also suggest looking at David Wu's work. These should all pop up readily in a google search, and you should also find direct links if you search the forum archives.
Actually,
I misread your question, :). You might search the forum archives for "frame-rate independent physics" or "physics time step" or similar. Many folks, myself included, believe that using a constant physics time step that doesn't vary with frame rate is the way to go. It certainly makes for 100%, perfectly repeatable results on any hardware. And, sync'ing up with the real game clock so you don't have objects moving fast on fast CPU's, slow on slow CPU's, is quite easy. This is discussed in prior threads, even some in the past couple of weeks here.
Forum member Gaffer wrote a nice article on how to do fixed physics time stepping:
Fix Your Timestep!
Forum member lonesock has written a nice article on Verlet integration using a variable time step that helps make that method more stable when you do choose to use a variable time step. (Actually, without his approach, it is NOT Verlet integration when time step is variable. Traditional Verlet is based, by definition, on a fixed time step.) Good reading, but it is somewhat academic. If you don't want to learn the math, you aren't going to get too far I'm afraid.
Time-corrected Verlet Integration
[Edited by - grhodes_at_work on January 3, 2005 11:42:12 PM]
I misread your question, :). You might search the forum archives for "frame-rate independent physics" or "physics time step" or similar. Many folks, myself included, believe that using a constant physics time step that doesn't vary with frame rate is the way to go. It certainly makes for 100%, perfectly repeatable results on any hardware. And, sync'ing up with the real game clock so you don't have objects moving fast on fast CPU's, slow on slow CPU's, is quite easy. This is discussed in prior threads, even some in the past couple of weeks here.
Forum member Gaffer wrote a nice article on how to do fixed physics time stepping:
Fix Your Timestep!
Forum member lonesock has written a nice article on Verlet integration using a variable time step that helps make that method more stable when you do choose to use a variable time step. (Actually, without his approach, it is NOT Verlet integration when time step is variable. Traditional Verlet is based, by definition, on a fixed time step.) Good reading, but it is somewhat academic. If you don't want to learn the math, you aren't going to get too far I'm afraid.
Time-corrected Verlet Integration
[Edited by - grhodes_at_work on January 3, 2005 11:42:12 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
