This page has been translated automatically.
UnigineEditor
Interface Overview
Assets Workflow
Settings and Preferences
Working With Projects
Adjusting Node Parameters
Setting Up Materials
Setting Up Properties
Landscape Tool
Using Editor Tools for Specific Tasks
Extending Editor Functionality
Programming
Fundamentals
Setting Up Development Environment
Usage Examples
UnigineScript
C++
C#
UUSL (Unified UNIGINE Shader Language)
File Formats
Rebuilding the Engine Tools
GUI
Double Precision Coordinates
API
Containers
Common Functionality
Controls-Related Classes
Engine-Related Classes
Filesystem Functionality
GUI-Related Classes
Math Functionality
Node-Related Classes
Objects-Related Classes
Networking Functionality
Pathfinding-Related Classes
Physics-Related Classes
Plugins-Related Classes
IG Plugin
CIGIConnector Plugin
Rendering-Related Classes
Warning! This version of documentation is OUTDATED, as it describes an older SDK version! Please switch to the documentation for the latest SDK version.
Warning! This version of documentation describes an old SDK version which is no longer supported! Please upgrade to the latest SDK version.

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.

Notice
To show the physics performance profiler that reports statistics on different physics simulation aspects, press 1 hotkey three times or type show_profiler  3 in the console.

Rate of Physics Simulation#

Unigine physics module performs all its calculations during the rendering stage of the execution sequence. 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 rendering FPS can also be capped by 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 "slo-mo" 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.

Stable Mode (experimental)#

Stable 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.

Stages of Physics Simulation#

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#

  1. Before anything else, a spatial tree is updated. After we have the up-to-date data regarding how all objects with physical bodies are positioned, it would be safe to transform them or calculate collisions.
  2. C++ API Plugin updatePhysics() is called, if there is such a function.
  3. Physics module calls the updatePhysics() of the world logic. Here you can call all functions that handle physics simulation and interactions (and not only that, see the details on updatePhysics() usage and limitations).

2. Collision Detection#

After the script-based changes have been made (bodies with their shapes and joints were transformed according to game logic, physics-based callbacks were set, etc.), physics can be simulated.

  1. All objects that have physical bodies are found within the Physical distance. They will be simulated during the current physics tick. Make sure that the physical distance in your Unigine-based application is not too small, because physical interactions beyond this limit are not simulated, so objects becom frozen. However, even if at least one body belonging to an island is found within the physical distance, the whole island shall be simulated.
    Notice
    You can force to update nodes that are outside the Physical distance using addUpdateNode() function.
  2. All collisions (shape-shape and shape-surface) along with contact points are found for all colliding bodies among the ones found at the previous step (i.e., intersecting or have the distance between them less than the value of penetration tolerance). Contact points are represented by their coordinates, normals, depth of shapes penetration, relative velocity (between two bodies), relative friction and restitution. So, here we collect all the data that is required to resolve collisions later.
    Notice
    If a body is frozen and no contacts are found that would push it out of its frozen state with strong enough impulse, such body is not simulated in the current tick.
  3. Islands are built using the contacts obtained at the previos step.
  4. Bodies, shapes and joints are sorted inside islands. By that, we ensure that contacts are solved in the predefined order and visualization of physics in the world is repetitive (on one computer).

In the performance profiler you can find:

  • The total time of collision detection is displayed by the PCollision counter.
  • The number of contacts is displayed by the PContacts counter.
  • The number of islands is shown by the PIslands counter.
  • The number of bodies is shown by the PBodies counter.
  • The total number of joints is shown by the PJoints counter.

Continuous Collision Detection#

If a sphere or a capsule participates in the contact with any other shape or surface, continuous collision detection (CCD) is performed. UNIGINE takes velocities of the body, radius of its shape and calculates what contacts this body will have (during the current physics tick), assuming it continues its current trajectory. So, unlike the simple collision detection, contacts are analyzed not discretely, once per physics tick, but rather found for the whole frame.

4. Simulation#

When a collision has been detected, collision response is calculated, so that the colliding bodies would gain new velocities.

  1. Here bodies are prepared to participate in collisions: contacts found for them are cached together with contacts from the previous frame — to ensure that they interact with each other properly.
  2. Collision response for each body is calculated. Based on the gathered contact points data, the Engine computes the impulse each body gets after collision. Contact points are solved in a pseudo-random order to achieve simulation stability and reproducibility.
  3. When contact responses are calculated, joints constraining relative motion of bodies are solved. Joints are solved in the pseudo-random order just like contact points.
    Notice
    Within one physics iteration, joints can be solved several times. The high number of joint iterations increase the precision of calculations, as well as computational load.

    In the performance profiler, the total time of both collision response and joint solving stages is displayed by the PResponse counter.

  4. The results of contact and joint solving are accumulated and, finally, are applied to bodies. The coordinates of the bodies change according to their new linear and angular velocities.

    In the performance profiler, the time of this stage is displayed by the PIntegrate counter.

In the performance profiler, the total time of simulation stage is displayed by the PSimulation counter.

5. Synchronization of Physics#

Synchronization is the final stage of physics simulation. During the swap() in the Unigine main loop, physics module calls its internal updatePhysics() function. Bodies set their calculated transformations to objects. In the next frame, objects will be rendered in their new physics-based positions.

Notice
Physics simulation goes in parallel to the actual rendering process. This is the reason calculated physics is visible only in the next following frame.

If visualizer options are enabled, shapes, joints or contacts of non-frozen bodies will be rendered.

Multi-Threaded Physics Simulation#

Multi-threaded simulation of physics is run when 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.
Last update: 2020-07-31
Build: ()