Physics Optimization

Set matching Collision Masks for those particular shapes, surfaces, and bodies that are expected to collide. If the masks do not match, shapes and bodies will simply ignore each other by going through.

Collisions are calculated for a plane and a sphere while a box is ignored due to unmatching Collision Masks

The Collision Mask of the sphere's physical shape	The Collision Mask of the box's physical shape
The Collision Mask of the plane's surface	The Collision Mask of the ground's surface

In Unigine, you can set up filtering accurately by using the Exclusion Mask. This mask allows ignoring shapes with the matching exclusion masks regardless of their Collision Masks.

Surfaces that are not intended for physical interactions should have the Collision flag disabled. For example, a dashboard inside a cockpit would never take part in collision detection on the outside.

Avoiding detection of undesired and unnecessary collisions is a basic way to reduce the amount of physical calculations.

Specify certain physicals that should affect only corresponding bodies by using the Physical Masks the same way as for collisions. On the image below, a Physical Wind object affects a cloth banner but not a sphere.

A physical wind affects a cloth but not a sphere

Physical mask of the cloth banner	Physical mask of the sphere
Physical mask of the Physical Wind object

Intersection is a generic point of a specified area (or line) and an object. Calculation of intersection between a ray cast and a surface is fast and inexpensive and therefore sometimes can be used instead of computing collision. For example, calculation of collisions of car wheels with the ground can be simplified by using intersections.

Although it is a programmatic approach only, it requires Intersection Masks to be set for filtering purposes.

Both physical shapes and surfaces have intersection masks.

Physical shapes consisting of simple primitives make collision calculations easier while keeping performance high and accuracy acceptable. Therefore, it is recommended to approximate geometry with simple primitives (Sphere, Capsule, Cylinder, Box), which are faster and less memory demanding.

Complex shapes, such as Convex Hull and a set of autogenerated convex hulls, should be selected for representing complex and composite geometry when simple shapes don't allow achieving the desired goals.

At the same time you should keep the number of shapes as low as possible in order to avoid heavy calculations leading to the performance drop. Remember that a shape doesn't have to duplicate the mesh it approximates. Even though primitives are not precise, in most cases they provide acceptable results.

The simpler geometry is used for surface collisions detection, the more performance will be gained.

If a mesh representing a physical obstacle has several levels of detail (LODs), the least detailed one is the most preferable for collision and intersection detection. Enable the Collision and Intersection options for this LOD and disable them for the other ones.

Approximating collision shapes by using primitives is also a good practice. You can apply the following approach:

1. Ensure that the original node is not a Collider — check that Collision is disabled for its surfaces, bodies, and shapes. Since now it is not taken into account by collision detection.

2. Add a cylinder object to the scene by choosing Create -> Primitive -> Cylinder in the Menu Bar and cover the original mesh with the primitive.

   

3. Make sure that the Collision option of the surface is enabled for the primitive node.

4. Hide the visual representation of the primitive's surface. You can do it either by clearing its Viewport and Shadow masks or simply by setting its Max Visibility parameter to the negative infinity (-inf) — this ensures that the surface is not visible at any distance.

   

   Now the detailed mesh provides only visual representation, while physical interactions are calculated for the primitive cylinder.