The physics / simulation speed is the number of physics cycles per second, which is by default set to 55 FPS. This value can be adjusted from 2 to 1000 FPS.
Within each of these physics frames, characteristics such as the agility rate of models, momentum settings etc, are processed.
How often the physics routines execute (their cycle rate), is decoupled from the rendering cycle rate (often being your monitors vertical refresh rate, the case when V-Sync is turned on), which means the programming logic is free to execute physics steps independently.
Note: There are No time-based (delta time) calculations within the physics routines themselves.
The greater a monitor’s vertical refresh rate, the smoother the animation, because even though it’ll be refreshing its screen out of sync to when the physics cycles complete, the model’s position and rotation that are rendered will have been extrapolated (estimated; similar to interpolated) based on their last calculated values and how much time has passed since then.
Step 1) At the beginning of every game loop, the Elapsed time since the last execution of the physics routines is checked, and if one or more physics cycles are due, the Excess time is calculated as: Elapsed time - Physics rate (e.g. 1 / 55) * Number of physics cycles due. If no physics cycles are due, the Excess time is simply equal to the Elapsed time.
Step 2) The Excess time is used to calculate the extrapolated (time-based) values which are added to the last calculate physics values (1 or more i.e. could be accumulated).
Linear interpolation and extrapolation are the easiest to implement. Other techniques will be experimented with and potentially added as graphics options.
Interpolation and extrapolation produce smooth animation which avoids stuttering and skipping.
Note: the term “Interpolation” is used hereafter.
Originally the interpolation worked via a separate thread. The physics routines ran on that thread, and their resulting values were passed to the main (rendering) thread in a controlled synchronised manner via mutex locks.
After realising pretty much the same logic could be accomplished using a single thread, the physics and interpolation routines were modified to work together on the main thread, as described above. This has simplified the process by avoiding having to synchronise numerous model object related values between threads.
The processing workload of the physics routines is relatively low, so it doesn’t necessarily make sense to have physics routines running on their own thread.
However, features such as the Particle Fountain can be very demanding when set to a high number of particles, and so moving this aspect to its own thread is on the to-do list. It’ll mean for example, if the particle flow animation was to stall (stutter), other aspects such as the model’s physics will still run unaffected on the main thread. Very little synchronisation will be required because only a C++ vector of particle position values will need passing to the main thread.
Indistinguishable after testing both methods.
Technically, the single thread approach can result in a different number of physics cycles being executed for each main loop cycle.
If the physics rate was instead 59 FPS, there would occasionally be a main loop that didn’t execute a physics cycle, which is observed as a frame stutter if there’s no interpolation.
However, the following points are true:
Finally, to emphasize that gameplay is indistinguishable with respect to different rendering rates. Even when V-Sync was turned off during benchmarking, which resulted in rapid FPS fluctuations (between 500 and 675), gameplay remained completely consistent.
V-Sync turned on will likely produce a very good overall result for animation smoothness and consistency. It eliminates screen image tearing. And it’s probably the best method for allowing the CPU to rest (sleep).
Graphics cards have various settings that might influence image animation quality and reduce potential input lag, so experimenting with the graphics card’s settings is obviously an option.
If for example the physics and rendering rates are almost the same value, such as 59 FPS physics and 60 FPS rendering, you’ll never get that horrible periodic, potentially prolonged overlapping, frame stuttering and/or skipping, that would otherwise occur every several seconds, like you can get when using a basic timer and V-Sync is turned on. Or maybe you’ll have 15 FPS physics (e.g. practicing flying in slow motion) and 120 FPS rendering, and again it’ll be butter smooth with no periodic stuttering.
Still the same interpolation benefits as with V-Sync enabled, but the image is sent to the screen without waiting for the vertical refresh ready signal from the monitor. This is sometimes considered to be beneficial because players see more up-to-date objects, characters etc, on screen.
V-Sync turned off can cause screen image tearing because a physics frame can be sent to the monitor at any time, and it’ll likely not coincide with when the monitor is ready to refresh.
Potential “Game Lag” will only be noticed by some people; many will prefer V-Sync turned on.
Another disadvantage is that the allocated CPU share provided to the application can be cycling at full speed without resting; resting happens automatically with V-Sync turned on. Requesting a small sleep period can significantly alleviate potential issues, and even though requested sleep periods are not guaranteed to be accurate, requesting a 1ms sleep has had good results so far during testing.
Note: There is a separate setting (frame rate limiter) for controlling the rendering frame rate.
When V-Sync is turned off, resting the CPU and controlling the rendering frame rate, are controlled independently from each other.
If the physics is cycling faster than the monitor’s vertical refresh rate, the number of physics frames (steps) due can accumulate, which can result in two or more consecutive physics cycles being executed within one game (main) loop, in which case you will not see each of those frames displayed on screen.
Note: Even with a slower monitor, the interpolation still executes correctly in this situation i.e. the interpolated part is still added to the last accumulation of calculated values, as always.
This can cause screen image tearing because of multiple frames being displayed on screen at the same time, resulting in several tear lines. However, all frames will be visible, although only partially because as flipping between buffers occurs, only part of each frame will have been drawn.
By default, this is applied only when V-Sync is disabled.
However, it can be set to always on, which might help if some advanced graphics card setting changes the behaviour of V-Sync related functionality.
When V-Sync is enabled, the main thread will cycle (execute) synchronised with the monitors vertical refresh rate, which results in the CPU having a rest each rendering cycle, and because the rendering draw calls are in the main thread which is only running as fast as the monitor refreshes, the GPU also rests each cycle.
But when V-Sync is off, even though the CPU can rest by having set a minimal sleep value (read further up regarding sleep accuracy testing), if there was no additional control, although the physics and interpolation would continue to execute correctly, the draw calls would be happening at an uncontrolled rate.
This is where the frame rate limiter setting comes into play, by independently restricting how often draw calls occur, which provides some control over how hard the GPU will be working.
Transmitters and dongles have a limited resolution of their own.
11ms or 22ms is typical. 1 / 0.011 = 90.9 FPS.
The simulator physics cycle at 200 FPS, and the slower of the Tx or dongle dominates their own effective FPS to 1 / 0.022 = 45 FPS (i.e. the rate the input values are fed into the physics routines).
That would mean several physic routines would execute using the same stick values from the transmitter whilst held in your hands, even if you’d been moving the sticks.
Floor collision example:
If an object was descending via a fixed physics rate of 200 FPS, and its position and rotation values were changing at half the amount than if the physics were instead 100 FPS (which would keep the pace of the game looking the same), the precision of detecting when the object passes through the floor would be twice as accurate. So, for collision detection purposes it seems higher physics rates can be beneficial.