nCloth tearable constraint and extrusion. help!


Hi all,

I’ve been doing a lot of nCloth studies and am using the same technique as in this test I made >> but for some reason when I’m trying to apply this same technique to a new model I’m running into problems.

I’m using the tearable constraint and the sim looks fine until I add an extrude downstream of the nCloth node. The outer surface disappears in some frames and the only way to somewhat get rid of it is adjusting the polyMergeVert distance but even then there are still a few frames that pop. Has anyone run into this before?

Also, when I apply a different material to the outer faces and the inner ones, after the tear starts to happen I notice that not all the inside faces have the inner material past a certain point. I’m sure that since the number of faces is changing it is having an effect on how the materials are being applied but I’m stuck on how to make it work. Any ideas would be super helpful and appreciated.



Im still having no luck with weld, reducing max distance reduces the constraint to not enough points to tear anything, and when there is enough it just distorts, its probably because im still painting verts which can’t be a good method. Still trying to figure out this workflow.
pfunk, that test looked amazing, the colorAtPoint script sounds very interesting. I read you used a fractal to define where the tears occured, to do this would you have to make the entire mesh part of the constraint and use the fractal as a glue strength map. Is this the correct workflow?
Because i want my mesh to tear in so many places to select each vert on something so high res would take ages.

Edit:Sorry, wrong thread. :slight_smile:


Have you tried throwing a Normal > Set To Face on there before the extrude? Or after…not sure where it works best, but I have done this before to fix some wonkiness with extruding cloth…though not in as elaborate a setup as it looks like you are trying.
It is a start hopefully.
Good luck.


Thanks for the response Ben. Yeah I’ve tried just about everything with the normals, hahaaa. The extrusion itself works fine for about 80% of the frames but on the others the problem I explained above still happens even if the normals and everything else fine.

After reading a bit about the extract faces, combine, and use weld adjacent bordees constraint I tried that out but since the mesh is pretty dense and crazy ( still triangulated fine though ) it was super slow and in the end didn’t seem like the most efficient way to go about things.

The one good thing about that method from what I understand is that the tearable constraint creates new edges and things as the geometry rips whereas with the pre-shattered geometry all edges are already established and ( maybe ) wouldn’t cause any popping issues with the extrusion or material assignment problems. If anyone has any input it’d be much appreciated.


The thing about the tearable constraint that causes problems for most is that the added polyMergeVertex node changes the topology of the output cloth mesh as the cloth vertices pull apart. It is done just so that the shattered mesh looks smooth. (select the cloth and do hypergraph:connections to the the construction history chain) Another result of the merge vertex is that the topology of the output mesh does not match that of the input, so all vertex painting and constraining should be done on the input mesh not the output mesh( nCloth: display input mesh).

Some construction history things are passed OK through the merge node but others are not.
If one has problems it is not hard to select the merge vertex node and simply delete it. One should also delete the polySoftEdge node if doing this.


Thanks for the reply Duncan. After reading a bit more I was wondering if the correct workflow for this would be to apply a tearable constraint on the output mesh and all other constraints ( in my case a pointToSurface with an animated texture ) on the input mesh so when the topology changes they aren’t applying the constraint to incorrect verts once things tear? I tried just deleting the merge and polySoftEdge and then extruding and some funky stuff happens, similar to the effect of extruding with keep faces together turned off. I also tried creating a tearable constraint on the input mesh but things seem to just freeze up and so I thought I’d double check with you about the workflow.

Last thing, I was curious about was the difference between the Weld Adjacent Borders method and the Tearable constraint since what’s written in the manual about the tearable constraint sounds very similar to the method written about the WAD constraint in the help files:

“The current nCloth is made tearable or shatterable by separating all of its faces, generating new edges and vertices, merging the nCloth’s vertices, softening the nCloth’s edges, and constraining the nCloth’s points (tear) or edges (shatter) together using the Weld constraint method. As a result, the topology of your nCloth’s output mesh will no longer match that of its input mesh.”



The weld adjacent borders doesn’t modify the input mesh or add any topology changing construction history. The thing it has in common with the tearable constraint is that is sets up the constraint to use max distance. On the nComponent node it also restricts the constrained elements to border edges. (the tearable constraint does vertex constraints)

If you create a tearable constraint you should do so before adding any other constraints. After creating the tearable constraint you should make selections on the input cloth mesh when adding or modifying constraints. Also you should not create more than one tearable constraint on a mesh.

If you want to add construction history downstream of the cloth do so after creating the tearable constraint. Also it is best to run the simulation until the cloth is fully torn before adding the history. Or one could temporarily set nodeState to “has no effect” on the polyMergeVert node. The reason is that a lot of construction history hard codes the list of components… for example an extrude might set the inputComponents attribute for the extrude to “f[0:29]”…faces 1 to 30. If the number of faces then increases it can have problems. Perhaps best is to hand edit the components in these cases to simply use all faces (or verts or edges, depending on the history item). So for an extrude one could do:

setAttr polyExtrudeface1.inputComponents “f[li]”
It would be nice if the extrude command did this when a mesh was selected for extrusion rather than explicit faces, but currently these commands work by internally converting the selection to what the command wants, so they don’t know the mesh was selected.

This is not so much a problem with the make tearable constraint, but rather difficulties with handling topology changes with construction history.


" So for an extrude one could do:
setAttr polyExtrudeface1.inputComponents “f[li]”

Thanks for these detailed responses, and I think I have something going and was wondering if there was a better way of updating the extrude nodes component list. Since I couldnt find a way to “unpack” a list of components with MEL, I made a super long string with all the components listed in it. Here’s the expression I wrote that seems to be working ok ( but VERY slow ):

if (frame < 10000) {
int $numFaces[] = polyEvaluate -f outputCloth1;
string $faces;
for ($f = 0; $f < $numFaces[0]; $f++) {
$faces = ($faces + ( “f[” + $f + "] "));
setAttr polyExtrudeFace1.inputComponents -type componentList $numFaces[0] $faces;

thanks again for all the help


The component string understands shorthand for the list, so “f[li]” automatically uses all the face components, which is good when the number changes over time… no need to build a huge string the way you are doing. So instead do:
[/li]setAttr polyExtrudeFace1.inputComponents -type componentList 1 “f[li]”
There is just one entry ( all faces) in the component list which is why you need the “1”.

Sorry about the confusion… I forgot about the syntax to set a component list attribute in my previous email.


Awesome awesome awesome awesome! That has been giving me a headache for days now! Works great. I actually got it to work before I saw the last post by deleting the extrude node each frame, adding a new one, and setting the local translate Z but this way seems much cleaner and faster. Cheers, i really appreciate all the info and help :bowdown:

edit : One final question. What I noticed with deleting and remaking the extrusion was that I was able to apply a material to the inside faces since the componentList was constantly being updated with an explicit component list and not just “f[*]”. Would there be a way to update a material assignment as well?


If you first set up everything with the tearable surface and extrude with componentList = f[li], then to do the inside shading set the polyMergeVert nodeState to no effect (will show everything fractured) then select the inside faces and assign your shader. Then set the node state back to normal.
If selecting the inside faces is tricky, they will always be at the end of the list, or all faces over a certain number. So for example if one started with a 10x10 plane, the full fracture extrusion is 600 faces. One could do:

select -r pPlane1.f[200:599]

to get all the inside faces.


Hmmmm, that didn’t seem to work for me. There were still inside faces that had the outer material on it once the mesh really breaks apart :frowning: I ended up just doing the rebuild extrude method but haven’t tested rendering with the expression. Works great in the viewport at least! Fingers crossed.


Ohhh man, wish I knew this a month ago for a shot I was working on! Would of saved me a heap of troubles! :stuck_out_tongue:

LOL, life is funny like that eh?

Thanks for the awesome info Duncan!

Nice tearing and particle effects there pfunk! :smiley:


This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.