Constant time steps: be or not to be?!?
Author
Use constant time steps is a bad thing?! As i have already read around people dont like it. Or like? Have I missunderstood something?!
As I could see by analising some games (N4SPD Underground for example), when I get some slowdowns, the car moves slower and it reveals that the game uses constant time steps (maybe Verlet integration with constant time steps?). So, what do you use? What should I use (talking about dynamics simulators)? Runge Kutta 4 or Verlet with constant time steps? what are the advantages and disadvantages?
thx a lot, and sorry if I have not been too clear.
Its probably better to use TCV (Time-correct Verlet)
http://www.gamedev.net/reference/programming/features/verlet/
It is essentially the Verlet integerator with support for non-constatnt time steps.
http://www.gamedev.net/reference/programming/features/verlet/
It is essentially the Verlet integerator with support for non-constatnt time steps.
Where did you get the idea that constant timesteps is a bad idea ?
in general the use of constant timesteps does simplify things.
the main drawback of a constant timestep is that cpu load gets more or less static, (since you will need to run a set number of updates each second),
with a dynamic timestep you generally run one update / frame , the drawback of this is that you need to watch out for extreme movement that can screw up your collision detection. (a bit more complex), and you should also make sure 2 or 3 fast frames always give the same result as 1 slow frame. (can be a huge problem if for example AI updates run less frequently if your framerate is lower).
can become quite a pain on networked simulations if you try to do some prediction.
another option is to use semi dynamic timesteps where the timestep is allowed to vary within a limited range.
in general the use of constant timesteps does simplify things.
the main drawback of a constant timestep is that cpu load gets more or less static, (since you will need to run a set number of updates each second),
with a dynamic timestep you generally run one update / frame , the drawback of this is that you need to watch out for extreme movement that can screw up your collision detection. (a bit more complex), and you should also make sure 2 or 3 fast frames always give the same result as 1 slow frame. (can be a huge problem if for example AI updates run less frequently if your framerate is lower).
can become quite a pain on networked simulations if you try to do some prediction.
another option is to use semi dynamic timesteps where the timestep is allowed to vary within a limited range.
Author
Thanks for replying guys.
hmm...I really don't know =D ! ! !
A question to solve this thread: For a rigid body simulation, what integrator should I use?! Is RK4 a good option? or TCV is too much better? or there's another better option?!?
Thnx ;)
Quote:Where did you get the idea that constant timesteps is a bad idea ?
hmm...I really don't know =D ! ! !
A question to solve this thread: For a rigid body simulation, what integrator should I use?! Is RK4 a good option? or TCV is too much better? or there's another better option?!?
Thnx ;)
I use plain-vanilla constant time step verlet for pretty much everything. It is the most predictable (moreso than TCV) and works well enough for my applications. I am the type that doesn't care to have my game run any higher than 60fps, so if I hit my target framerate on the lowest supported platform then I'm happy with constant time steps.
What do you want to do - rigid bodies with contact and constraints? If yes these are differential algebraic systems (an algebraic system with an underlying differential system) and not differential equations. E.g. a simply particle on a circle is decribed as follows:
dx/dt = v
dv/dt = M^1 * (f_ext + JT * lambda)
x^2 + y^2 - r^2 = 0
A lot of strategies exist to solve such systems and from your posting I think that you don't have much experience with this topic. If you want to get an easy start with something that works out of the box at good speed and also stable I recommend Erin Catto's "Sequentiel Impulses".
Indeed you want to use fixed timesteps since otherwise your system is not deterministic. A level with a better framerate behaves different to a level with a worser framerate. I personally think it is a good tradeoff that when the game gets slower that your simulation gets slower as well as long as it is unconditionally stable. IMO to get fixed timesteps the whole archtecture of your engine is effected and this can't just be solved in the physic module.
And one final note:
1) Don't use RK 4 (e.g. http://graphics.ethz.ch/~mattmuel/publications/deformationCGI2004.pdf )
2) Verlet und semi-implicit Euler have the same characteristics
HTH,
-Dirk
dx/dt = v
dv/dt = M^1 * (f_ext + JT * lambda)
x^2 + y^2 - r^2 = 0
A lot of strategies exist to solve such systems and from your posting I think that you don't have much experience with this topic. If you want to get an easy start with something that works out of the box at good speed and also stable I recommend Erin Catto's "Sequentiel Impulses".
Indeed you want to use fixed timesteps since otherwise your system is not deterministic. A level with a better framerate behaves different to a level with a worser framerate. I personally think it is a good tradeoff that when the game gets slower that your simulation gets slower as well as long as it is unconditionally stable. IMO to get fixed timesteps the whole archtecture of your engine is effected and this can't just be solved in the physic module.
And one final note:
1) Don't use RK 4 (e.g. http://graphics.ethz.ch/~mattmuel/publications/deformationCGI2004.pdf )
2) Verlet und semi-implicit Euler have the same characteristics
HTH,
-Dirk
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement