Frequently Asked Questions¶
Iterations vs Subdivisions
Iterations Iterations control the convergence, so the more iterations the better the convergence towards the problem solution. The convergence is directly impacted by the size of the problem, the mass ratios between objects interacting, the stiffness desired, etc… In other words, in a complex system it is impossible to tell how many iterations might be needed to converge at a given precision and it gets even worse considering that most problems end up over constrained locally by pinching or collisions singularities. So, we allow you to set a hard limit in number of iterations to balance processing time and convergence while avoiding systems iterating forever around a solution that might not even exist.
Subdivisions Imagine you have a scene at 24 frames per second. So, if you set 10 subdivisions, then the physics solver will perform 10 substeps between each frame, interpolating the information internally to run at 240 Hertz (10 x 24 per second). So, the output is still at a frame every 1/24 seconds but the solver will run 10 solves per frame through substeps of 1/240 second. The number of subdivisions is very important because it controls the accuracy of the collision. If you have small / thin objects and fast motion, then you need higher number of subdivisions to better sample the time to avoid objects interpenetrating. The number of subdivisions is also very important to capture fast oscillations. The time sampling must be smaller than the frequency of the oscillation and the number of subdivisions is your friend in this case too. In summary, any simulation error is relative to the simulation time step (time step = frame step / subdivisions). So, either reducing the frame step or increasing the number of subdivisions will increase precision.
Iterations & Subdivisions Relationship The number of iterations and the number of subdivisions also combine. For example, imagine a simulation using 10 subdivisions but also needing 50 iterations to converge as desired. The same problem with a setting of 20 subdivisions might only need 20 iterations or less to reach the desired convergence while increasing the accuracy of a problem that struggled to converge. The computation time in both cases is roughly the same since the physics will execute 500 solver steps with 10 collision detections in the first case and 400 solver steps with 20 collision detections in the second case.
Convergence
The Carbon solver is an iterative solver, meaning that during each simulated frame, it will run a fixed number of iterations towards the “correct” physical solution. The larger the constraints network (i.e. number of triangles/quads), the longer it will take any iterative solver to reach a converged state. This means that with a fixed number of iterations/subdivisions, we will almost never reach a converged state, because most problems are too large.
Simulation Scale
Simulation scale not only affect the objects, but also the scene conditions, such as gravity. Here is a simple example: you look at a jenga pile falling: It’s fast. Now, compare this to a falling building, it looks very slow because the point of view and scale are bigger.
Now, imagine an artist created a jenga pile, but with units that made it the scale of a building. Everything would look like in low gravity, slow falling. The obvious solution would be to scale down the whole scene including the camera position etc… and then get the right perception. But this would be very time consuming. In order to avoid this, we have the Simulation Scale parameter, which invert-scales all parameters that are length dependent such as gravity and density.
Can two different resistance values be specified for compression and extension?
Carbon uses its own proprietary cloth models and have its own performance requirements that do not allow separate resistance values for compression and extension.
However, the Stretch Equilibrium parameter can be used to force more extension resistance than compression resistance by alteration of the elongation.
Small variations in the Stretch Equilibrium, such as a value of 0.95, should make the extension looks stiffer than the compression, even under a reasonably small number of iterations.
See also
What to do in order to make the simulated cloths look less rubbery?
There are 2 main parameter groups that need to be looked at: Stretch and Bend.
Adding a certain degree of angular plasticity, which allows preservation of creases, to a cloth removes the rubbery look in most cases.
See also
A rubbery feel is often also caused by a bad setting of the Stretch Compression/Extension. These two parameters are hard limits and therefore are not physical. They exist to help decrease the simulation times so that in most cases it is not necessary to raise the Simulation Iterations.
Without enough leeway, the stretch limits tend to prevent bending in a snappy kind of way, making the cloth behave like a rubbery material.
This could also mask a bad setting of the Stretch Stiffness and give an unrealistically low expectation of the Simulation Iterations which could also exacerbate the rubbery behavior.
This is why it is recommended to start setting up the cloth with these two limits disabled (by setting very low compression and very high extension values) in order to find the correct physical setup. Once this is done, then the limits can be re-adjusted to values that do not seem to affect the physicality of the simulation. Finally, the simulation times can be sped up by dropping the number of Simulation Iterations to a sensible value.
How to prevent the simulation to be unstable when over-constrained?
There is a difference between solvability and stability. When a system is over-constrained it is not solvable. And since there is no solution to a non-solvable problem, then it is very difficult to define its stability.
What is expected from the simulation is to find a close solution despite the fact that the system has no solution. This is about robustness and can be achieved in 2 ways:
- Hope that the simulation does not blow up with the current conditions and try to patch it up afterwards (untangling).
- Change the initial problem so a solution can exist (contact filtering).
Since in both cases, the given problem has no solution, any solution provided by correction or alteration can produce unexpected results.
There is currently no untangling algorithm, but contact filtering has been implemented to specifically help with the over-constrained collision issues. To enable it, simply set a non-zero Collider Filtering Gap.