PhysX Rollout

These controls affect all PhysX rigidbodies in the simulation.


  • PGS/TGS: controls which PhysX solver to use in the simulation

Information about each solver (Projected/Temporal Gauss-Seidel) can be found on NVidia’s PhysX website. TGS is a relatively new addition to PhysX, and is typically faster than PGS for rigidbody simulations, but can produce unexpected results when solving PhysX bindings (constraints). In general, it should be treated as an experimental solver, and PGS should still be used by default.


  • Default gravity: controls whether a default gravity force will be applied to all PhysX particles.

  • Gravity value: controls the strength of the default gravity force.

  • Ground collider: controls whether a default ground collider will be added to the PhysX simulation.

  • Height: the height of the default ground collider, in world-space.

  • Restitution: the restitution of the default ground collider.

  • Static friction: the static friction of the default ground collider.

  • Dynamic friction: the dynamic friction of the default ground collider.

  • Simulation groups: the simulation groups that will be affected by the ground collider.

Property Combination

The property combination settings allow you to define how the friction/restitution settings of colliding PhysX objects will be combined. For example, if a PhysX particle with a friction value of 0 touches a PhysX particle with a friction value of 1 and the “friction minimum” setting is selected, the two objects will slide over each other because the minimum value (0) between the two of them will be used when frictional forces are calculated.

  • Friction/Restitution Average: the average of the two objects’ values will be used.

  • Friction/Restitution Minimum: the minimum of the two objects’ values will be used.

  • Friction/Restitution Maximum: the maximum of the two objects’ values will be used.

  • Friction/Restitution Multiply: the product of the two objects’ values will be used.


  • Substeps: the number of substeps that will be calculated per time-step for the PhysX simulation.

Increase substeps to increase the overall accuracy of the simulation. For high-fidelity simulations, a value of 12 or higher may be more appropriate than the default value.

  • Pos iterations: the number of position iterations that will be used to solve joint/contact constraints, per rigidbody, per substep.

  • Vel iterations: the number of velocity iterations that will be used to solve joint/contact constraints, per rigidbody, per substep.

Increase pos/vel iterations to reduce jittering when simulating particles with PhysX bindings.

  • Inertia mult: this is a multiplier which affects all PhysX particles’ inertia. Higher values can increase simulation stability while decreasing angular acceleration/deceleration. Lower values increase angular acceleration/deceleration, but can lead to jittering or other instabilities. For smaller objects with low mass, this value can be lowered (0.5 - 1.0). For bigger objects with a lot of mass, it should be kept high (5.0 - 20.0).

  • Friction every substep: when enabled, frictional contacts will be calculated every substep, rather than only on the last 3 substeps (default). This can improve simulation accuracy, at the cost of performance.

  • Kinematic collision pairs: controls whether inter-penetrating particle rigidbody pairs that are set to ‘kinematic’ or ‘trigger’ will generate contacts.

  • Multithreading: controls whether the PhysX engine will make use of multiple CPU threads.

  • CCD: controls whether continuous collision detection is enabled or disable. Continuous collision detection can prevent collision tunnelling between high-velocity rigidbodies, for a performance cost.

  • CCD steps: controls the number of substeps used to resolve collisions by the CCD engine.

  • CUDA: controls whether PhysX computations will be accelerated with CUDA.

In order for CUDA acceleration to work, tyFlow requires that two DLL files (PhysXDevice64.DLL and PhysXGPU64.DLL - both available on the tyFlow download page) be placed in the same folder where the tyFlow DLO file is loaded from.

CUDA acceleration does not always guarantee faster simulations. Due to performance costs related to transferring necessary data to-and-from the GPU, speed benefits from CUDA might not be apparent until hundreds/thousands of rigidbody particles are in the simulation. When a simulation has only a few rigidbody particles, CUDA acceleration being enabled may actually decrease overall performance.

  • Memory MB: the amount of GPU memory to allocate for CUDA computations.

Setting the CUDA memory limit higher than the default value does not mean the simulation will run faster. The memory limit controls the amount of VRAM to allocate for constraint/contact processing, and generally a CUDA simulation does not require much VRAM in order to process all contacts, even if a lot of rigidbodies are present in the simulation. Setting this value very high is usually unnecessary, and can actually contribute to slowdowns at the beginning of the simulation, due to the time it takes to initially allocate the VRAM. Just because you have a GPU with a lot of VRAM, does not necessarily mean you should increase this setting from its default value. For reference, the default value suggested by NVidia is approximately 140mb.

  • Print errors to listener: controls whether to print PhysX simulation errors (reported internally by the PhysX engine) to the MAXScript listener.

Sleep thresholds

  • Velocity thresh: Particles with a linear/angular velocity below this threshold at the end of the time step will be candidates for sleeping.

  • Min duration: Particles which satisfy the velocity threshold for this number of frames will be put to sleep.

Strange behavior can occur if particles with PhysX Bindings are put to sleep, therefore particles with PhysX Bindings will ignore the sleep threshold settings.