- This document contains information regarding the tools provided by Vortex® Studio to help find dynamics performance issues. Please refer to the Performance Analysis for more general details.
If The Profiler tab in the Vortex Studio Player indicates excessive time consumption in the dynamics module (usually called DynamicsEngine in your application setup) you can modify your simulation content or tune simulation parameters to reduce the time spent.
In order to see if the dynamics module is the bottleneck, enable the Timings option in the Profiler panel and examine the time spent by the DynamicsEngine in the Timings section by navigating to ApplicationUpdate > ModulesUpdate > DynamicsEngine.
For a breakdown of the time spent, enable the Values option and navigate to ApplicationUpdate > ModulesUpdate > DynamicsEngine > PhysicsBreakdown. The image below shows the detailed timings of the individual components in the physics engine pipeline.
Most of the time is taken by "Solve Dynamics" and most of this time is spent in "Compute Forces"
The solver could spend a lot of time to solve a stiff or overconstrained system. Some constraints could be relaxed, e.g., their stiffness reduced or their slip increased, in order to help the solver find a solution more quickly. In the Vortex Studio Editor, you can use the Solver Analytics panel (accessed by pressing the button) to help you find the constraints that cause the slowdown and should be relaxed. The constraints that have a high pivot count are the ones that cause the most processing time in the solver. Note that the constraint in this list was not necessarily created by the user; it could be a constraint created by a dynamics extension such as the Vehicle System, Tire Model, or Cable System.
For relaxations of these kinds of constraints, the specialized interfaces of the corresponding dynamics extensions need to be used such as the Dynamics Properties extension in a Generic Cable. To navigate to the dynamics extension that is involved, use the link button on the left hand side in the Solver Analytics panel.
Split the Problem
The solver takes too long because the matrix is big and cannot split the problem into small matrices that could be solved in parallel. Splitting the simulation could be a good way to have an efficient speedup in your simulation. (To split the simulation, you can use Solver Group). Two small problems are much quicker to solve than a larger one for two main reasons: first, the complexity of a direct solver is nonlinear in the number of constraints, and secondly the two problems could be solved in parallel.
An easy way to split the simulation is to use kinematic constraints, meaning one rigid body would be seen as infinitely massive by the other one, producing only unidirectional force coupling between the constrained parts. This modeling approach is an approximation that has to be used with care. By carefully selecting the constraints that should apply force only in one direction, one can split off an entire subsystem of the mechanism and immediately benefit from parallelization. The Vortex Studio parallel solver will solve these systems independently. To understand the structure of the simulation and the subsystems (partitions) involved, use the Partition Display (available in the Debug Display options in the Editor). Unidirectional force coupling can be enabled by using the Kinematic Part property in a constraint.
For example, when simulating a car with an antenna made of many parts, the vehicle part in the constraint that attaches the vehicle to the antenna could be set as Kinematic Part. In the constraint that attaches the vehicle to the antenna, the part representing the vehicle could be set as Kinematic Part. Then two partitions would be created and the simulation will be solved much more quickly. Note that the collision between the antenna and the vehicle should be disabled after this change, in order to prevent undesired effects produced by the antenna adding collision forces to the vehicle that are not considered at the base of the antenna.
Simulation Not Sleeping
If you have a lot of rigid bodies on the ground in your scene that does not have any motion, they should automatically fall into sleeping mode.
Display the inertia tensor of the entire scene to verify that all the inactive rigid bodies are sleeping; the inertia tensor and the center of mass should be displayed in dark red. However if the inertia is display in light red, it means the rigid body is simulated and not in a sleeping state. To make those rigid bodies sleep, you can tune the material to have more stable contact, change the collision geometry or make it simpler, or tune the sleeping thresholds.
Simulating Long and Detailed Flexible Cables
In a simulation with many flexible cables, the computational cost can be reduced by either increasing the Preferred Section Length of some flexible cable segments, or replacing some flexible cable segments by non-flexible cable segments by unselecting the Flexible Definition box in the segment definition.
In the cases where using less flexible cable segments or flexible cable segments with less detail is not an option, consider using Adaptive Cables.
The following cases describe where time may be spent during dynamics calculations.
Time Spent by "Collision Detection Broad Phase"
The first step in the physics pipeline is the broad phase. The broad phase computes the potential intersections between collision geometries. It is rarely the source of the bottleneck, but it can happen when a large number of collision geometries are present in the scene. A good way to improve the broad phase is to use composites for the collision geometries which are in the same part. At the broad phase level, all the collision geometries that would be in the same composite will be processed as only a single bounding volume. This will reduce the time consumption for the broad phase but will also have an impact on the contact generation. This impact is due to the so-called contact simplification process, which will consider the composite as a single collision geometry and will reduce the number of contacts accordingly.
Time Spent by "Collision Detection Contact Generation"
In the Profiler, under Physics > Census, Enabled Contacts reveals the number of available contacts. If the number is quite high, this could be the source of the performance problem. There are several ways to deal with this issue:
- Using collision rules can considerably reduce undesired or useless contacts.
- Using meshes with a high level of detail can be computationally expensive for the collision detection. You can try splitting your mesh into multiple convex meshes using the Convex Mesh Decomposition feature.
- Optimize the middle phase of the Mesh UV Grid using the UV Grid Visualizer, which is an extension that help you to tune the parameters.
- Many contacts are still enabled because rigid bodies are not sleeping. See Setting Sleep Thresholds of Parts for more information.
- An interaction between two rigid bodies generates too many contacts. By putting the collision geometries into a composite, the number of contacts will be reduced via a process referred to as contact simplification. See Creating Composite Collision Geometries for more information.
Time Spent by "Step Extension"
Using fluid interaction is likely the source of this problem. If a lot of rigid bodies or complex triangle meshes are used in a fluid, that could be the cause of your slowdown in performance. Simplifying your fluid collision geometries can solve this issue.
If you have written your own VxDynamicsExtension, your code could be the source of the issue.
Time Spent by "Intersect Subscriber"
This could be related to an intense use of sensors and triggers.
Alternatively, if you wrote an extension which uses an implementation of the class VxUniverse::IntersectSubscriber, it is possible that the time is spent in this implementation.
Vortex® Studio 2018c by CM Labs | Last update: 8:07 AM, 12/20/2018 — Release 2018.18.0.45 | © CM Labs Simulations Inc.