# Fixed Timestep -- fixing frequency "beat"

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

## Recommended Posts

I split my physics logic from my rendering logic with something along the lines of this link, except that I have the two logics running in different threads. Everything works very well, but I've noticed the slightest jitter which occurs with a frequency -- a 'beat'.

After analysis I think the problem is when accelerating or decelerating:
My rendering logic knows nothing of the acceleration or deceleration or even velocity; it just interpolates (linearly) between the previous location and the next location (as advanced by the physics logic). But if the velocity is changing during this span, shouldn't the interpolation take this into account? I think this is introducing the slight (yet still unwelcome) beat.

Does it sound like I'm on the right track? And any suggestion on how to fix my display interpolation (what it needs along with the 2 positions -- and how to use these additional parameters)? I think I can figure this all out, but after swimming in all this for a while I'm not seeing the answer clearly. Help is appreciated!

##### Share on other sites
What are your physics and graphics framerates?

##### Share on other sites
My graphics framerate is 60fps. I've tried out different physics rates -- all produce the slight jitter I've mentioned (though the frequency of the beat appears to change), though I've never gone above ~33 steps per second.

##### Share on other sites
I think it could be an aliasing issue.

Image a switch which has two positions, up(U) or down(D)

The physics executes at some time step. Graphics thread is operating, for the sake of simplicity, at twice that time step

*= stepswitch position:  UDUDUDUDUDUDUDUDUDUDUDUDUDUDtime           :  --------------------------->physx thread   :  ****************************graphx thread  :  * * * * * * * * * * * * * *

the viewer will see the switch permanently in the Up position, even though the physics thread is making the switch oscillate. If you average the states, then the graphics thread will show the switch at 50%, neither up or down which is (sort of) more accurate than always showing it as up.

In order to accurately convey all of the object motion generated by the physics thread, the graphics thread will, according to Nyquist have to update at least 2x the rate of the physics thread.

at least that's what I think... lol. been wrong before so add salt as necessary.

##### Share on other sites
Hmm, the jitter is greatly reduced if I increase the frequency of my Physics steps (I tried 100 steps per second instead of 10, 20, 30, or the other low-frequencies I had been doing). This makes sense to me -- the interpolation is not happening between such wide steps.

Is it typical to step your physics at a higher frequency than the display? My initial thought was to have the physics step at a lower frequency to minimize physics calculation time -- is it possible to do something like this while maintaining smooth movement, or must the physics steps happen often?

##### Share on other sites
Quote:
 Original post by Gamer GamesterIs it typical to step your physics at a higher frequency than the display?
Yes. The primary reason to decouple your physics and graphics updates is so you can run physics at a higher framerate.
Quote:
 My initial thought was to have the physics step at a lower frequency to minimize physics calculation time
Is your game too slow right now? Did your profiler tell you that physics was taking a large timeslice?

##### Share on other sites
Ah, thanks -- my thinking on this is clearing up now.

My game is not running slowly, and I have no
reason to think Physics are eating up much CPU.
I'll bump up the physics rate.

Any suggested standard/typical/good physics rates (for games!)?

##### Share on other sites
Quote:
 Original post by Gamer GamesterAh, thanks -- my thinking on this is clearing up now.My game is not running slowly, and I have noreason to think Physics are eating up much CPU.I'll bump up the physics rate.Any suggested standard/typical/good physics rates (for games!)?

I believe the source engine (and possibly others like the infinity engine, call of duty) links physics updates to be the same as the rendering fps. It can probably be difficult to manage though to stop the physics "exploding".

ie. As there will be a gpu bottleneck, if uncapped rendering is running at 340 fps, physics will also attempt to run at 340, if physics can only run at 144 due to a cpu bottleneck then it will only let it render at 144 fps (for the particular frame, so it's bouncy physics and rendering if uncapped or un vsynced! - bad)

Making the right choice depends on the platform which the game will be on. Ie for a console you may opt to go with vsynced fps and that is when you are burdened with choosing a physics update rate, however that also poses the solution of fixing the update rate before hand to be set to whatever the refresh rate is - while making it possible to run at a different rate too.

Of course, rendering also puts a lot of load on the cpu so that is often the direct cause of a cpu bottleneck - but it would be using the same resources (depending on how multithreading is implemented) as the physics and other cpu loads.

I believe there is never an obvious solution, but you might want to try applying the same rate to both. I could be completely wrong of course ^_^

##### Share on other sites
I almost alwasy do my fixed timestep stuff at 100 Hz. That is always going to be above the monitor refresh and in most situations it gives small enough increments to the sort of things you do in real situations.

Lately I've taken to ticking my "normal" game logic at this speed also (ie not just pure physics sims). Makes a lot of things a lot simpler.

Picking a common rate and sticking to it also means you can move models from one app to another without any nasty surprises.

##### Share on other sites
Quote:
 Original post by Gamer GamesterAny suggested standard/typical/good physics rates (for games!)?

It really depends. A standard "blow stuff up" FPS sort of physics probably doesn't need much... 60 FPS could be sufficient. If your gameplay requires accurate contact forces, particularly with stacking, and particularly if you're relying on accurate sliding friction, you could need a higher framerate, up to, say, 200 FPS. Higher framerates can also compensate for collision models which do not handle deep penetrations well.

Bottom line: If you're making Boom Blox or Forza, prob'ly pretty high. Otherwise, not so much.

• 10
• 9
• 48
• 12
• 10
• ### Forum Statistics

• Total Topics
631383
• Total Posts
2999688
×