Verlet integration problems and physics update frequency
Author
My game include simple sphere objects animated using a particle which is driven by verlet integration. The problem is that different deltaTime values have dramatic effect on end results. ie Acceleration affects velocity more in lower deltaTime and less in higher deltaTime.
Lets say I want to jump my character. I add some verticle velocity to it, every time i want to make him jump. But game will run on different machines giving fps ranges from 30fps to 600+fps. On slower machines the player will not be able to defai gravity and on fast machines he will act like walking on moon.
I tried to solve this problem by multipling deltaTime with jump velocity. This reduced the problem but the difference is "big enough to break game-play" rules.
I also tried to limit timeDelta to 1/100 when fps are bigger than 100 fps. But still there is a clear difference in integration with timeDelta=1/100 in 100 times a second and 400 times/second.
An other idea which i think should work is to fix the update rate of physics to 100fps. And skipping physics_updates when fps are higher that 100fps. But i dont know how to do it efficently.
Btw how pro-games solve this problem. I never experienced difference in physics if frames range from 40fps to 600 fps.
"I never experienced difference in physics if frames range from 40fps to 600 fps."
Actually, even Quake 3 was like this.
There are some jumps that you can make when your framerate is only 120+
http://ucguides.savagehelp.com/Quake3/FAQFPSJumps.html
In your case though, things are much worse. Verlet integration is tricky for variable time steps. The easiest thing to do(which is also the best in some situations) is to use a fixed time step like you said.
Each frame, you figure out how much time has passed since the previous frame, and then you divide that by your step size. Take the leftover time that doesn't fit into a complete time step and add it to the next frame. This should work well enough if you use a large timestep(100 maybe), but it may appear to be a little jerky. Some commercial games even use a time step as low as 25. To fix jerkiness you perform interpolation between physics steps, for rendering purposes only.
Actually, even Quake 3 was like this.
There are some jumps that you can make when your framerate is only 120+
http://ucguides.savagehelp.com/Quake3/FAQFPSJumps.html
In your case though, things are much worse. Verlet integration is tricky for variable time steps. The easiest thing to do(which is also the best in some situations) is to use a fixed time step like you said.
Each frame, you figure out how much time has passed since the previous frame, and then you divide that by your step size. Take the leftover time that doesn't fit into a complete time step and add it to the next frame. This should work well enough if you use a large timestep(100 maybe), but it may appear to be a little jerky. Some commercial games even use a time step as low as 25. To fix jerkiness you perform interpolation between physics steps, for rendering purposes only.
Try
posNew = posCurr + (posCurr-posPrev)*dt/dtPrev + acc*dt*dt;
Taken from here, and fixed I hope
Should fix most of it. In my limited experiments verlet works best with a fixed physics timestep.
posNew = posCurr + (posCurr-posPrev)*dt/dtPrev + acc*dt*dt;
Taken from here, and fixed I hope
Should fix most of it. In my limited experiments verlet works best with a fixed physics timestep.
I also strongly suggest that you consider implementing a frame-rate independent physics update. Search the forum archives for a discussion of frame-rate independent physics.
Author
I am using frame-rate independent tech. but there is a difference in integrating with 0.01 to 0.001. At lower delta values the acceleration affects velocity more and more.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
