Simulation of Physics

As the Engine has a variable framerate while the physics framerate is fixed, execution of physics calculations always adapts to the current situation.

In case the Engine framerate drops below the physics framerate (which is a very rare case), some of the physics frames have no enough time for execution and become missed. The physics module keeps such missed frames in memory for a certain period (called Missed Frame Lifetime) and tries to execute them when the situation gets better (Engine FPS grows) or when the CPU is idle while waiting for GPU to complete rendering (if there is enough time). This is called catching up and helps avoiding "slow-motion" effect that occurs when physics frames are dropped off. In case of insufficient hardware capabilities missed frames are removed from the buffer as their lifetime expires and become lost forever.

Actual time of physics calcuations can go beyond the current budget as the ones performed while waiting for GPU are not taken into account. So the budget is not absolutely strict in this respect and can be exceeded if the CPU is idle.

1. Before anything else, a spatial tree is updated, this is performed in the Main thread regardless of the current update mode. 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 this function is implemented for the plugin.
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).

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 become 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#

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.

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.

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