tyFlow’s CUDA Cloth Collision Solver is a GPU-accelerated, robust cloth-cloth and cloth-object collision solver.
These settings are global settings for the CUDA cloth collision solver, which operates on all cloth meshes that have CUDA collisions enabled.
Increasing repulsion steps can help the collision algorithm maintain more rigid cloth thickness, and also help stabilize cloth in situations where many pieces of cloth are layered on top of each other. However, the returns from increasing this value diminish fairly quickly unless the simulation involves lots of densely layered cloth. For cloth without a lot of layering/folding, it is often better to decrease overall simulation steps than to increase this value too high. Capping this value around 3 to 5 for some extra simulation stability is usually sufficient. For densely layered cloth (dozens/hundreds of cloth layers), values of 20-50+ may be necessary. Keep in mind that unlike IZ steps, repulsion steps have no early termination condition. Thus, increasing the number of repulsion steps will linearly increase the time it takes for the simulation to compute.
A higher repulsion strength multiplier can help to separate cloth triangles in close proximity with each other faster, but the higher the strength the more elastic (bouncy) the result. It is best to keep this value fairly low.
Collision impulses help to prevent cloth intersections, but they do not guarantee a collision-free state because one impulse acting on two triangles may actually cause a new intersection to form elsewhere. However, because impulses can be processed faster than Impact Zones, having a few initial impulses generated first helps take pressure off the IZ solver. A small number of impulse steps followed by a large number of IZ steps is the best way to ensure all collisions will be solved after repulsions are processed.
Impulse mult values greater than 1 can sometimes help offset the numerical relaxation that is a result of the way impulses are processes in parallel. If you are solely relying on the impulse solver for intersection prevention but find it requires a lot of iterations in order to produce a correct result, try increasing the impulse mult value to 1.2-1.3.
The Impact Zone solver attempts to resolve all simultaneous collisions in one fell swoop, as opposed to the Impulse solver which attempts to resolve collisions sequentially. The benefit of the Impact Zone solver is that it can resolve very complex collision configurations that the Impulse solver cannot, however the IZ Solver is much slower than the Impulse solver. For this reason, several Impulse steps should be evaluated before the IZ solver is triggered. It is also important to keep IZ steps quite high, in order to catch all collisions, because the IZ solver is a failsafe for both the Repulsion and Impulse solvers.
If the inelastic Impact Zone solver requires more substeps than the specified maximum in order to converge for a particular frame, a warning will be printed to the MAXScript Listener. In some situations with extremely complex intersection configuations, the solver may never converge. Please see the FAQ for more info.
The core of the collision algorithm tracks simultaneous collisions in a cloth-collision adjacency graph called an Impact Zone. When the number of collisions in a graph of adjacent vertices exceeds this value, the processing algorithms for the zone will be executed on the GPU (using CUDA) rather than the CPU. If the IZ thresh value is set too low, the overhead of transferring data to/from the GPU can exceed the time required to process the vertices in parallel on the CPU. You should not need to change this value unless your CPU has very few cores (in which case, you may need to lower the value to offload more work to the GPU). A value that is too large means all IZ processing will happen on the CPU. A value that is too small means all IZ processing will happen on the GPU.
The CG thresh value determines how many rows/columns must exist in an IZ matrix in order for the Conjugate Gradient portion of the IZ process algorithm to be offloaded to the GPU. Due to the overhead required to transfer matrix data to the GPU, performing the CG method on the GPU will only become faster when a matrix is sufficiently large. You should not need to change this value unless your CPU has very few cores (in which case, you may need to lower the value to offload more work to the GPU). A value that is too large means all CG processing will happen on the CPU. A value that is too small means all CG processing will happen on the GPU.
While the solver is running, it will fragment IZs with more impacts/nodes than this value into multiple IZs. The more impacts/nodes per IZ, the greater the accuracy of the collison solver. However, too many impacts/nodes in a single zone can greatly reduce the performance of the solver. Therefore, finding a balance between accuracy and IZ size is important. Usually this value does not need to be changed. Turning on “Print CCCS details” in the debugging rollout will print information about IZ size in the MAXScript listener during each iteration of the solver.
Occasionally an IZ can get “stuck” during a solve. This usually happens when the solution to a particular impact generates a new collision whose solution re-causes the prior impact within a very tiny numerical tolerance, ad infinitum. This manifests as repeated IZ solver iterations whose total impact count doesn’t change over time (turning on CCCS printouts from the Debugging rollout can reveal when these situations occur). Without any artificial jitter applied to impact particles, the CCCS will be caught in a loop until the max number of IZ solver iterations is reached. This can greatly increase simulation time despite the fact that the extra time doesn’t improve the solution. By increasing the “stuck IZ jitter” setting, any time a stuck IZ is detected, all of the offending particles will be artiticially jittered in order to hopefully break past the precision issues resulting in the infinite solver loop. The jittering may introdue new impacts which will need to be solved in the next IZ solver iteration, but if the goal to break out of the loop is achieved then the total processing time will still be lowered. Keeping this value small (but not too small) will help prevent stuck IZs. A value that is 10% of cloth thickness is a good starting place.
In situations where all remaining IZs are stuck (as explained above) and repeated attempts to unstick them with jitter fail to resolve the remaining collisions, the stuck IZ limit can be used to manually break out of the solver loop early. This can improve simulation time in situations where time is wasted repeatedly attempting to solve collisions which can never be solved even with jitter applied (due to extreme numerical precision issues). For example, if you’ve set the max IZ iterations to 200, and the last remaining IZ becomes stuck at iteration 25, it’s possible for the solver to get stuck in a loop from iteration 26 to 200 without being able to solve the last collision(s) even after repeated attempts to unstick them. In that example, by setting the stuck IZ limit to 3, the solver would break out of the loop after the 3rd failed attempt to unstick the IZ…which would reduce the amount of total simulation time by the amount of time required to perform the 100+ failed IZ iterations.
Greedy VRAM Usage: the CUDA solver will not clear VRAM after each time step, which allows it to run faster because then VRAM allocations do not need to be fully re-initialized each time step.
Conservative VRAM Usage: the CUDA solver will clear VRAM after each time step, which may slow down the overall simulation due to re-allocations being required each frame, but frees up the VRAM for other processes to use after the solver completes its task.
If you are getting CUDA allocation errors (usually displayed as error 700), try switching to “conservative VRAM usage” mode (then save the scene and restart 3ds Max, since a restart is required in order to re-initialize CUDA after a crash).
By default, all collisions will be processed in 3D. However, in many situations you may want them to be processed on a flat plane (example: flat splines colliding with each other). Simply creating the splines on a flat plane is not enough to guarantee proper 2D collisions because rounding errors along the “up” axis perpendicular to the desired plane (ex: the Z axis) can prevent all collisions from being detected properly. By enabling the 2D solver, you can ensure that all 2D collisions will be detected on a particular plane, because the solver will switch to a special 2D mode that completely ignores the specified up axis.