• Vellum uses continuous collision detection. This is great to avoid fast moving geometry teleporting through your cloth, but is useless if your points are randomized every frame.

• Don’t assume your geometry sequence is good. Try dropping a timeshift at $F+1, and wire it and the original into a sequence blend to see if it blends. If not, check if there are point id attributes that are causing problems. The id attribute overrides point numbers, which can sometimes fix your matching. You can also try using a Match Topology to make your point numbers consistent frame to frame.

  Note

  Even if your sources work, the subdivided version of your sources may not. Vellum only cares about points of the previous frame, so won’t mind if your primitive numbers are randomized each frame. Subdivide will generate different point numbers if it has different primitive numbers. Likewise, if you had matching id attributes before, after a subdivide you probably won’t which could produce bad results.

The default Vellum pscale is small, but any pscale attribute in the input will trump it. This means your sequence may already have a surprising value. It maybe to too small.

Vellum works best with a pscale that isn’t too small, so it can float the cloth on top of the collider without hard collisions. Generally you don’t want your pscale to be bigger than your edge length, which could cause self intersections.

Vellum does pre-processing, like bullet does, on the original geometry so it doesn’t explode even if points are on top of each other. It records the original distances into attributes and uses those to reduce pscale for collisions. When the cloth separates, these attributes will be relaxed so the cloth won’t got back to too close. Setting a too large pscale likely won’t blow up the cloth, but it will do collision tests with the large pscale. This can cause your cloth to crawl to a stop.

Always sanity test pscale. The Vellum Solver SOP has a parameter on the Visualize tab to show thickness by putting a sphere on each point. This may be too tiny to see with defaults. Adjust the default pscale accordingly.

There are four main areas you can tweak to get the cloth simulating as fast as possible and look as good as possible.

1. Substeps:

   This breaks up the frame into smaller steps, which is essential for fast moving cloth. If you have too many collisions and changes in a single substep, the cloth can slow down a lot because triangles are all potentially colliding with each other. Using smaller substeps gives better collision bounds, possibly meaning less of a performance hit than you'd expect.

2. Constraint Iterations:

   These allow the stretch and bend constraints to work. To get stiff, non-stretching, or non-bending, cloth you need larger numbers. These are usually cheaper than you think.

   A rough minimum is the “diameter” of your cloth. This is the “longest shortest path”, ie, find the farthest points on the surface of your cloth, trace the shortest path between them, and count the number of edges you needed to go through. In practice, gravity is the big force to deal with, so you can likewise estimate how many edges “tall” your cloth piece is. No need to be 100% accurate.

   If you increase substeps, the amount of forces effectively go down, so you can reduce iterations.

3. Collision Passes:

   Handles both external and self collisions. These are interleaved between the constraint iterations. For example, if you have 50 iterations and 5 collisions, it will do 10 iterations between each collision. Increasing this helps with failed collisions, but also consider increasing substeps instead.

   Having 2 substeps and 10 collisions is about same cost as 1 substep and 20 collisions, but the former will likely be better.

4. Post Collision Passes:

   After all constraint iterations are done, these additional passes are done in hopes of cleaning everything up. Because these passes don’t interact with the constraints, you will get protrusions where the cloth is pushed out in the shape of the collider rather than forming a tent. This is the last attempt to avoid failed collisions.

When using the output of a drape or a previous sim as a starting point, care must be taken of attributes.

Simulating cloth or hair 10,000 units or further from the origin can cause problems making cloth look crinkled and hair look tangled. If you move your objects closer to the origin, this should fix the problem. However, if that isn’t an option, you can use a 64-bit solve for more precision. This is not typically recommended though, since it is significantly slower. For more information, see Setting up a 64-bit solve.