Simulation of Physics

At physics simulation, physics calculations are in the multi-threaded mode — some operations are performed in parallel.

Physics performance profiler enables real-time tracking of simulation performance.

Unigine physics module performs all its calculations . There are few things to point out about physics.

• It is simulated with its own fixed FPS, which does not depend on the rendering framerate. (The Engine FPS can also be synchronized with the physics one).
  Notice

  If physics takes more than the assigned budget, further calculations are delayed. These calculations shall be performed during the subsequent rendering frames, making physics simulation look like in a "slow-motion" mode. The default budget is 50 ms, but it can be increased, as necessary.
• During each tick, a number of calculation iterations can be performed. This includes the full cycle of physics simulation:
  1. updatePhysics() from the world logic is called.
  2. Collision detection is performed.
  3. Joints are solved.
  4. Collision response is performed.
  Notice

  There is no point in setting the number of iterations too high. Unigine checks whether the next iteration can be performed within physics budget limit, and if not, it is delayed and moved to the next rendering frame.

There are two update modes available for physics simulation (each of them has its advantages and use cases):

• Before Rendering — physics update (along with the spatial tree update and user callbacks) is executed in the Main thread just before rendering is performed (render). The number of physics ticks executed before the rendering frame here is defined by the physics and the Engine framerates. This mode is the most clear and straightforward (everything is executed safely in a strictly determined order) with no frame lag (results of physics calculations are applied in the current frame). But, on the other hand, this mode is the slowest as there are no asynchronous parallel calculations (everything's in the Main thread). Use this mode in case the time lag is unacceptabe for your application (you need all physics calculations to be applied in the current frame) and you want maximum simplicity and strictly determined order of execution for user code (physicsUpdate and physics callbacks).
• Async Rendering — physics update is performed asynchronously to rendering. In case of several physics ticks per one rendering frame (when the Engine framerate is lower, or catching up is performed), only the first one is executed in parallel, then the physics module waits for the completion of the rendering process, returns to the Main thread and executes the rest of the physics ticks. There is a frame lag (results of physics calculations are applied in the next frame) and there is some ambiguity regarding the time, when user code (physicsUpdate and physics callbacks) is to be executed in case of several physics ticks per one rendering frame (some part is executed before rendering while the other just after it). This mode is the fastest one and is used by default.

The modes are toggled in Global Physics Settings in UNIGINE Editor.

Catching Up#

Deterministic mode ensures that all contacts are solved in the predefined order and visualization of physics in the world is repetitive (on one computer). When this mode is enabled the Engine performs additional sorting of bodies, shapes and joints inside islands after building them.

Deterministic mode is unavailable in case there are missed frames — it is simply impossible. Moreover, there may be differences between visualization of physics on different hardware (e.g., AMD and Intel).

Determinism is guaranteed if there are no missed frames, the same Engine version is used, and the CPUs perform SSE operations similarly.

Please note that deterministic mode does not come for free, it may eat up 10-20% of the frame rate, and it also depends on the scene a lot.

The mode can be enabled in Global Physics Settings in UNIGINE Editor.

Simulation of physics goes through a number of stages when it is updated each iteration. They are as follows.

1. Physics update
2. Сollision detection
3. Simulation
4. Synchronization of physics

In the performance profiler, the total time of physics simulation is displayed by the Physics counter.

1. Physics Update#

2. Collision Detection#

3. Simulation#

4. Synchronization of Physics#

Multi-threaded simulation of physics is run when the Async Rendering update mode is selected and there are two or more physics threads.

1. updatePhysics() from the world script is always performed in the main physics thread.
2. After that, the Engine takes advantage of multiple CPUs during the collision detection and simulation stage.
   • Contacts for all physical bodies within the physical distance are found along with all necessary information.
   • Islands are created based on the data on object collisions.
   • As islands have been created, they can be safely handled in separate threads, because they are isolated.
   • Then threaded islands are synchronized in the main physics thread to exchange data about the current contacts and ones from the previous frames. It will ensure proper physical behavior of bodies.
   • From there on, collision response and joints solving are again calculated per island in separate threads.
3. Before physics is synchronized with the world, the engine waits for all threads to finish their calculations. When thread synchronization happens (during the swap stage of the Unigine main loop), all assigned physics callbacks are executed in the main thread (the order is as follows: bodies, joints, and triggers), and then physics is applied to nodes.
   Notice

   Physics callbacks (mainly used for creation, destruction or modification of other objects) are called in the main thread, as this is the only place where such operations can be performed safely.