Simulation of Physics

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 flush() is called, if there is such a function.
3. Physics module calls the flush() of the world script. Here you can call all functions that handle physics simulation and interactions (and not only that, see the details on flush() usage and limitations).

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. Within the Physical distance, all objects are found that have physical bodies. 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 outside of it are not calculated, so objects freeze up. (However, even if one body from the island is found within the physical distance, the whole island would be simulated).
   Notice

   You can force to update nodes that are outside the Physical distance using addUpdateNode() function.
2. Checking all pairs of objects for collision is too time consuming, especially if the scene is large. That is why potentially colliding objects are found based on a fast and rough test. If bodies intersect with their bounding volumes (which are shape-sized, and do not depend on nodes bounding volumes), or there are joints that connect them, such bodies are combined in a island. To put it short, all bodies are somehow connected (spatially or with joints), go into one island. That means, bodies inside one island can possibly interact with each other in this frame, while bodies in different islands would not collide for certain.
   Notice

   Non-colliding body dummy is skipped and not simulated unless it interacts with other bodies through joints.
   Basically, broad phase increases the efficiency of collision detection and decreases computational load. Before doing more precise and costly calculations, we can filter out pairs of objects that are positioned too far to collide.
3. Unigine physics is deterministic. Bodies, shapes and joints are sorted inside islands. By that, we ensure that contacts will always be solved in the predefined order and visualization of physics in the world is fully repetitive (one one computer).

In the performance profiler you can find:

• The total time of broad phase is displayed by the PBroad 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.

During the narrow phase, exact collision tests are performed. In a single-threaded mode (when there are none or one separate physics thread) the simulation continues in the following way.

Shape-based collisions are found for bodies inside each island:

• Collisions between the physical objects: contact points between pairs of shapes are found.
• Collisions between the physical objects and static surfaces. If the surface is assigned a surface_base property (by default), it can also passively participate in physical interaction and prevent the physical object from going through it. In this case, contact points between the shape and surface polygons are computed.

Continuous Collision Detection

In the performance profiler you can find:

• The total time of this narrow phase stage is displayed by the PNarrow counter.
• The number of contacts is displayed by the PContacts counter.

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

1. Right now bodies are prepared to participate in collisions: their found contacts are cached together with contacts from the previous frame — to ensure that they interact with each other properly.

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

2. Collision response for each body is calculated. Based on the gathered contact points data, Unigine computes the impulse a shape gets by collision: how the body changes its the motion after it has collided with another body or a surface. Contact points are solved in a pseudo-random order to achieve simulation stability and reproducibility.
3. When contact responses are calculated, joints are solved. The impulses that joints give the bodies attached to them are computed: how according to the current state of the joint, the bodies should respond to keep the joint unbroken (i.e. based on their masses, linear and angular velocities, change their movement direction and orientation), and how that response affects the joint. For example, if the impulse exerted on a joint is too large, it is broken.
   Joints are also solved in the pseudo-random order.
   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 flush() 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 is enabled, shapes, joints or contacts of non-frozen bodies will be rendered.