# Verlet integration problems and physics update frequency

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

## Recommended Posts

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.

##### Share on other sites
"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.

##### Share on other sites
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.

##### Share on other sites
thanx for such informative links guys.

##### Share on other sites
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.

##### Share on other sites
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.

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 13
• 14
• 40
• 63