Jump to content
  • Advertisement
Sign in to follow this  
Nairou

Slow motion without screwing up the physics timestep?

This topic is 4203 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I've read a lot about how it is essential for the physics in a game engine to be run at a fixed timestep, so that it doesn't go out of whack and so that it is predictable. However, how would you implement slow motion with a fixed timestep? Pausing time all together I can understand somewhat, since you're just not advancing the physics at all, but before and after the pause it continues at a fixed timestep. However, with all of the random stuff like particles, would that mean that every single particle would have to be controlled by the physics system to prevent them from playing out while the world was paused? I can think of many games where you're watching a demonstration of the engine, and suddenly they pause the game and zoom around an object, and you can see all of the particles and explosions frozen in time. How do you keep track of all that and sync it with the physics? I guess I always assumed that sort of stuff would be too much for physics to handle and would just be implemented on top. But slow motion seems even harder, I don't see how you could keep a fixed timestep when time itself was changing, and I don't want to just let the timestep change during those times because then all bets are off. Is there a way this is usually done?

Share this post


Link to post
Share on other sites
Advertisement
You can keep track of two different times -- the real time and the simulation time. The physics system always uses the simulation time and to run it in slow motion, you just update the simulation time more slowly than the real time. For example, for every 20 ms in real time, you add 10 ms to the simulation time.

The complication is that the simulation time will always be different than the real time.

Share this post


Link to post
Share on other sites
Whenever you update your physics advance it to just beyond "game" time, using a fixed timestep. Then the object render positions/orientations are obtained by interpolating between the physics positions/orientations at the previous and current physics step, based on the old-physics, new-physics and current-game times.

Then if game time progresses slowly than reality, that just means that most updates you don't actually need to advance the physics engine - you just get new render positions/orientation by the interpolation with a new value of current-game time.

Another reason for doing this is if your game is capable of running at a higher frame rate than the physics update frequency (assuming a fixed timestep, which might be less than 60Hz) - the motion looks much smooth.

The problem with doing this for slow motion is that you might get slightly strange motion when interpolating over a collision even - but unless you go really slow this would hopefully not be a problem.

Particles wouldn't normally affect physics, so how you slow them down doesn't really matter so long as it looks sensible. If they do affect physics, they would normally be in the physics engine. Also, if they're "physical" particles then maybe the physics engine would also handle them (but probably not as a full rigid body).;

Share this post


Link to post
Share on other sites
I believe fixed timesteps are usually held at 1/60, in otherwords if you have a constant velocity that velocity is applied over one second, and not one frame (assuming your framerate is a constant 60).

If the framerate were to drop below, say, 30 then objects would be moving about twice as fast per frame, and the collision detection and response (aka, physics) would be less accurate.

The same goes for if the framerate stays at 60, and you increase the timestep by two (effectively doubling your playing speed).

However, if you were to DECREASE the timestep, and thus slowing gameplay (or the passing of time) objects would move much slower. Assuming all of your physics code is based on time, and it usually is, then this would INCREASE your collision detection and response accuracy. This is a good thing.

Decreasing your timestep, at least in my experiences, has never hindered a physics engine's performance. If anything, it has always helped it.

You shouldn't have a problem decreasing the time step. Just be careful if you want to speed it up.

Share this post


Link to post
Share on other sites
I have theorised about this myself. IM still working on collision detection so im not at the stage you are at.



Just to clarify you want the following:

time based animation
rendering happens once per frame
animation happens once per frame
fixed timestep for physics engine
variable speed of animation

I would have a global constant for the speed of motion, which applied to everything, and multiply everything that moves by this constant.

for example, if your particles move once per frame using this algorithm:


position_vec = position_vec + (translation_vec * speed_const * time_elapsed);
^^^^^^^^^^^



you simply have to modify the speed constant to set the speed of the game engine. your timestep can still be 1/60 and you can still have the same time step for the physics engine. for a standard speed of game, the constant would be 1.

just a question, why is a fixed timestep critical for a physics engine? if the framerate of the game drops below the timestep frequency you have problems anyway.
My (theorical)solution is to animate the physics engine once per frame, interpolating if the framerate goes below 60 (which it will at some point, on somebodies computer)

Share this post


Link to post
Share on other sites
What MrRowl suggests is the best method, it is also what is described here: gaffer.org.

This method combines the best of two worlds: predictable, stable physics/collisions and smooth movement. The drawing should be an interpolation between the current and next physics frame. It works kinda like this:


t = realTime()
while(1) {
while(t < realTime()) {
t += dt;
calc(); // advance all objects and remember old positions
}
tInter = (realTime() - (t-dt))/dt;
draw(tInter); // draw everything with oldPos*(1-tInter)+newPos*tInter
}



To do slow motion all you have to do is make realTime advance slower than normal. (I think - haven't tested it myself.)

Share this post


Link to post
Share on other sites
Quote:
Original post by MrRowl
Whenever you update your physics advance it to just beyond "game" time, using a fixed timestep. Then the object render positions/orientations are obtained by interpolating between the physics positions/orientations at the previous and current physics step, based on the old-physics, new-physics and current-game times.


I should have said - this is what I do in my physics test program - source code etc here.

Share this post


Link to post
Share on other sites
Thank you MrRowl for your explanations, and slvmnd for the gaffer link which was extremely helpful. After reading MrRowl's post a few times, I finally understand it and it really does makes sense. I just had to change my thinking on how slow motion would affect the physics. I'll have to try that out. Thanks!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!