Hi,

So I recently watched this tutorial https://www.sidefx.com/tutorials/houdini-cloth-simulation-tutorial/ [www.sidefx.com] on cloth simulation set up. It is very helpful, but I am amazed at how well it works in the video. I'm trying to do something which I think is much simpler, and I'm having all kinds of problems with it.

My scene:

Three character objects. A head and two arms. A circular cloth with a hole for the head is constrained to the head piece. Cloth is all quads and all one piece. The character moves forward and lifts its arms up underneath the cloth. Total animation is about 70 frames. I allow 30 frames for the cloth to settle before any movement.

Main problems:

1) Spiky, jittery, popping cloth. Seems to be a result of collisions. Mainly occurs after movement of the character begins and as cloth initially settles onto character.

2) Cloth disregards collisions. At some point in the animation the cloth will just sink into the character, despite the fact that collisions are still on (and appeared to be working correctly a few frames before). It won't correct itself. I don't understand how the collision system allows this to happen. It seems this problem is worse when I make the collision radius on the cloth greater.



Things that are correct already:

1) Collision is on.
2) There is no interpenetrating geometry at the beginning of the sim.
3) Cloth neck points are constrained to head prims.
4) Dop object nodes are pointing to the right objects.
5) The character geos have normals on the verts (normal sop was added).
6) The collision mode on the static objects is set to ‘use surface collisions’. It was set to ‘use solver default’ for a bit. Not even really sure how much this matters, but use surface collisions is what the shelf tool does.)
7) Animated character geo has a trail sop before the import sop.
8) Static solver is present (again, not sure exactly what this does anyway)
9) Dop merge order is correct for the collisions.

Most of these comes from following the tutorial in the video. I did not use the shelf tool for my current set up (the shelf tool's set up gave me all the same problems, but is more confusing the way that it writes the sop paths and such)

I believe that the simulation is at least setup correctly input wise because everything is doing what it should, its just not doing it well.

Things I've tried to do:
1) Increase the substeps. I've gone up to 15. Doesn't seem to make much of a different passed 10. Seems to calm down the jittering/spiking a bit but not completely. Does not prevent the cloth sinking into the collision zones.
2) Increase the collision passes. Gone up to 10. Not much a different found here. Maybe 3 or 4 helps a bit.
3) Increased cloth resolution. The original cloth has about 2,000 prims. Actually noticed slightly better behavior dropping a subdiv to depth 2. Depth 3 was much worse (loss of collision). Go figure.
4) Adjust collision radius on cloth and static objects. Greater collision radius on the cloth seems to make the collision detection fail more.
5) Polydoctor and fuse node on the cloth sop
6) All of these in different combinations. I've run about 15 simulations adjusting all of these parameters. Haven't found a single combination yet that looks even remotely decent.

So this is kind of a depressing I must say. I have a character moving in the simplest of ways and a very simple cloth object and the resulting simulation is just a mess.

Maybe I'm doing something wrong. Maybe my objects are actually shit. Maybe I forgot to check some box. Maybe my cloth is the wrong shaped cone. All possible. Not saying the the simulation is shit, because I've seen it work well in videos and on my frames where there is no popping or bad collision it looks great. But if this cloth is really this unstable of a tool then it seriously needs more online documentation for getting it right. And it doesn't help that the cloth simulation documentation here http://www.sidefx.com/docs/houdini/cloth/fixing_cloth_problems [www.sidefx.com] is out of date (for instance, there is no collision tolerance parameter on the cloth solver itself. I've noticed lots of other inconsistencies in these pages).

Hopefully this thread can reflect the current best-practices for doing a character cloth sim in Houdini properly, in exact detail.

Unless I just made a really stupid, obvious mistake. In which case I'll go hide for awhile.

So I finally cracked the right parameter code to get something that looks ok. I increased the collision radius on the static objects to 0.005 from 0.001 (default) and also increased the collision radius on the cloth to 0.004. I also put the collision passes and substeps to 6 (had problems at 2 and 4). The cloth at this point feels a little thicker than I would like, and does seem to hover around the body in a force field a bit, but its a large leap from where I was. No jittering, popping, or not colliding so far, but this was only meant to be a test and the animation is pretty basic. I'll post back here if I run into anymore issues.

Also, if anyone has any insight as to exactly how these surface collisions work mathematically I would be very interested. Houdini docs state that there is a linear interpolation between substeps to prevent collisions objects penetrating. Somehow whatever checks this system was making was failing for a smaller collision radius and for shorter substeps/passes.

Moin,

there are quite a few caveats with Houdini's current cloth solving setup. For one, if you are using volume based (“tets filled”) cloth objects, the resolution of the cloth object itself (the render object that is) does not matter that much (except for shape definition), but the number/size and shape of the tets does. In a setup where you are going both for folds (one “job” for a cloth sim) *and* collisions (another “job” for cloth sim) you will have to balance both goals, since folds obviously want smaller distance thresholds and thus probably way more substeps (or even a stretched timeline, since, as you noticed, substeps can only take you that far, while simulating in “slow speed” can get you to another level of detail). However, collision detection works best if there is enough room/distance between the objects you are testing.
Also note that if you are using position based collision detection, you are bound to those elements that get checked (often only the points), so resolution of the mesh does play a role for collision detection (position based) and you will get “jitter” much faster and less controllable with low-resolution meshes.
Don't neglect the actual cloth attributes. If for example you introduce bending resistance, you are *actually* introducing a force into your system. With low-resolution meshes, this can (and probably will) lead to “explosive behavior”.

When starting to learn cloth simulations, my suggestion is to concentrate on one of the goals first: Collision behavior or folding (the latter being a matter of self-penetration / collision detection), with this order seeming the easiest approach.

I hope any of this is of some help!

Marc

(who's creating a cloth sim workshop for H …)

Thank you Marc. Yes, that does help, as have a few of your videos (so I am excited for your workshop).

So would you recommend using a volume based approach? Or if it is case by case, for which case would you say to go with a volume based collision detection vs the surface based one (which the houdini team seems to recommend for cloth). Am I correct in assuming that the points based approach is the same as the surface based collision detection, and that the parameters for these are set on the RBD tab in the static objects of the dopnetwork?

That is interesting about using the speed of the simulation as another variable. I suppose its only a minor inconvenience to double my key frame lengths and then play the final sim back at 2x speed. I guess the difference between doing this as opposed to just increasing substeps is that the substeps can only linearly interpolate positions while this will take into account the forces between transitions. Am I understanding this right?

Hi,

> So would you recommend using a volume based approach?

actually … that depends :-)

It is important to understand the difference between actual “volume based collision detection”, which means that you are dealing with all the pros and cons of volumes (i.e. in the case of collisions you are using SDF fields, which are VERY fast to use but obviously only have limited mathematical accuracy) and “FEM based collision detection”, which means that you are “replacing” your geometry by an approximation of “atomic instances”. The latter, to my understanding, is what SideFX suggests for cloth simulations and to some extend I do agree.
H16 does not provide “volume based cloth simulations” (i.e. if you don't set that up yourself) - to my knowledge.

Advantages of FEM based simulations are obvious: You aren't limited by your actual (render) geometry's resolution (at least not for collisions, deformation, obviously you *are* limited by your render geometry when it comes to rendering), you can scale (resolution wise) quite easily, you can get as precise as you want (FEM collisions are surface collisions, because you are calculating “crossovers” of points and edges/planes). Since you are replacing geometry, FEM can be considerably slower than (original points based) point-collisions.

Volume = fast, surface = precise. Volume = not so explosive, surface = detailed.

You pick your cookie

> Am I correct in assuming that the points based approach is the same as the surface based collision detection, and that the parameters for these are set on the RBD tab in the static objects of the dopnetwork?

“Points based approach” in my world basically means that you are only calculation points (as in “geometry points”), concentrate mass on those and ignore any kind of penetration that might occur between two points forming an edge. That is fine for dense meshes and if you don't expect too much strain on the forces holding your points together.
By “points” you *could* instead mean particles. Cloth simulations using particles are a different beast, somewhere between points-based (as in “original points”) and atomic (“FEM”) based thingies … in my world, they combine the bad sides of both :-) YMMV.
“Surfaces” in Houdini's language, as far as I know, apply to what you would commonly understand as surfaces: Polygons. Houdini's technobabble likes to mess things up a bit, when used together with non-Houdini-apps … vertices versus points, primitives versus polygons versus ACTUAL primitives … argh. The way I see Houdini's “surface based collision detection” is just the math side of things: You are doing a cross-over check on every simulation step. Has one point (wherever you get that point from) crossed a plane/edge or has it not? If yes: Collision. If not: No collision. So I don't connect “surface” with what you *see* in that sense …

I also find Houdini's terminology for … well, let's call them “simulation entities”, just for the fun of introducing yet another arbitrary term - “steep to learn”: “Cloth” in Houdini is a solid body. When I tried to understand what the documentation is talking about, this threw me off in the beginning, because when I am thinking about “cloth simulation”, the only thing I do not have in mind are “solid bodies”.
Of course it makes sense, since a “cloth” is not a volume or liquid - but you *can* use a volume based collision detection for cloth, so you can use “volumes” on “solids”. That's Houdini for you :-D

Anyway, real “volume based” solvers are only available for static objects in H, if you don't create your own solution. The “cloth solver” is, AFAIK, a FEM solver that has been tweaked to deal with volume-free geometry (here “volume” means “single sided polygonal constructions that do not wrap some actual geometric volume”), but it *is* a FEM solver and it *is* a surface collision solver (when it comes to self-penetrations for example). Only if you want cloth to collide with static objects, the latter can be volumes.

The question about substeps versus frame count again depends on the implementation. In general (based on other cloth solvers I have used or written) substeps are always linear, so you are not getting any rotation values, any curved or dynamic animation/behavior AND you are not “piping back” your collision velocities the same way you do after you solved a FRAME. Because, in the end, what you store as animation data is frame based and inbound velocities (for your cloth and your collision objects) therefor are calculated on FRAMES, not subframes. That is one of several reasons for those infamous “exploding skirts”: The *actual* corrective velocity would have been much smaller, but what you get after your last subframe's calculation (perfectly adjusting the cloth's point position) based on the previous frame is … HIGH acceleration for the next frame. Giving you way too high velocities to start your next frame's first subframe.
… if that makes sense. If you have the time: Write a simple (spring-based, particle- or point-dependent) cloth solver and go through the subframe-problem yourself :-)


Again, I hope any of this is of some help. Excuse the babbling, please, I am trying to break it all down for the video I want to do, but there's so much stuff “in the background”, so trying to make it “simple” is so difficult :-D

Marc

Thank you very much Marc. Yes, that does clear things up a bit. So a cloth object implements a FEM based collision detection scheme, and I'm assuming because of this the static objects in the same dop network will be, when it comes to collisions, interpreted as planes and edges that the cloth object's points may or may not penetrate. I understand this, I think. And I can see now how the cloth popping can result from the linear interpolation between frames over-calculating the appropriate repulsive force.

This was one on my problems, but I still am a bit confused on how the cloth object still finds away to penetrate the static objects anyway, as you can see it does in my video. Perhaps, based on what you've said and the fact that the popping seems occur right before the collision prevention seems to break down, these violent pops occur pushing a single point on the cloth out 3 feet away from the body and from the rest of the cloth at frame A, so then a large force is calculated to bring it back (a physically accurate strong force for a physically innacurate situation) but that this force is so strong that by frame B the point has ended up inside the static object. This would mean that the FEM based colision detection only happens at some distance R from the surface of the static option, and that a fast moving cloth point could overshoot that distance between substeps and escape detection. I guess this interpretation would explain why increasing collision radius on the static objects seemed to help. But is this interpretation correct? Your insight is much appreciated.

Hi,

unfortunately, I don't have access (or think I don't) to H's cloth solver code, else I would just dig right in and answer your question :-)
But in general, yes, I assume that “overshoots” can cross thresholds. I have had situations in my own solvers where a simple resonance from neighboring points was sufficient to add up to volatile outward energy, though. Substeps are one side of the medal. Dampening is another one (introducing some averaging between “theoretical position change and control”). You may also have to check what other parameters you are using could introduce forces. An example for this would be bending resistance, which basically stores energy that is to be “released” when thresholds are crossed.

Maybe someone with internal knowledge of H's cloth solver can step in and answer the question of thresholds. In Bullet Physics those (hardcoded) thresholds are cause for a lot of irritation (4cm being the lower threshold for example).

Marc

Alright, this is becoming very painful. So even after increasing the number of frames by a factor of 4, substeps to 10, and collision passes to 10 and playing with all manner of collision radii, my cloth cannot handle even the sloowest of rotations without exploding 1/4 of the way through.

Not to mention that on just the default settings, the most blatant of penetration occurs.



I'm still confounded at to how the collision detection is failing so miserably. So I have the static object radii in green, and the cloth's in blue. If you stop and scroll the video in the beginning you can see the cloth is falling at about an inch per frame. There are 4 substeps in between those frames, and 2 collision passes. Could anyone please explain to me what is happening exactly at these substeps and what these collision passes are doing? Because they are somehow failing to stop the cloth from penetrating deep into the arms. I watched the cloth masterclass, and there is that part where they show the ball moving through the cloth and how on two consecutive frames it is on opposite side of the cloth but because the solver can interpolate positions between frames it catches the collision anyway. How is that solver the same as the one that is doing this!

Also, if anyone anyone anyone could share me a hip file where they have a cloth sim on an animated character that actually works well please share it with me. It doesn't even have to be a character. Just anything where cloth should be colliding on some deforming static object. I'm really curious to see how it was done.

Like it blows my mind that someone was able to do this in this same program:



I'll also post my hipfile. I have a digital asset that in there I don't think I'll include, but all I ask is that someone look at my dop network and see if there's anything wrong in there settings-wise.

I'm suspecting that the winding order of your collision geometry may be reversed.
If you display the default-generated normals in the viewport, they should be pointing outward.
You can use a reverse SOP on your collision geo to see whether that fixes the problem.

About explosions with collisions: there was a friction-related bug for cloth that caused instability.
This should be fixed in 16.0.776 and newer.

The number of collision passes that you want to use depends on the complexity of the cloth sim.
Depending on what you're doing, you may need to go as high as 8 or 10 for this.

Michiel,

By God, you're right! The normals are pointing inward! Ok, in all fairness though, I did check this quickly before and I thought they were ok because I saw normals everywhere. Very, very, very long normals. I didn't realize that they were simply so long that they were oriented inward but just poked all the way through the mesh and out the otherside! Ok, I will reverse them and see how that works. Thank you very much Michiel.

By the way, is it a problem that they are so long?

The sim has no problem with the normal vectors appearing this long.
You can scale them down in the Display Options under “Guides”, by entering a lower value for “Scale Normal”.
I recommend doing this scale down, because when you display long normals, they may appear as if they're pointing outside when they're not. This is particularly tricky for convex shapes.