Cloth thickness has no effect

[Dispel]

build 13.0.237..

 

So I am trying to setup a more complicated sim, but as a base I'm just testing one thing.

So I take an object, make it a cloth object, lay down a ground plane, gravity/collisions etc all working fine.

If I set visualize thickness on, and adjust cloth thickness, I see the visual feedback.

However my object is collapsing as if there is that visualized thickness is not present whatsoever.

 

Something i'm doing wrong? At default parameters it acts this way, though I tried messing with some other things to make sure I wasn't being stupid.

[Dispel]

Here's an example file.. By frame 60 it has pretty much collapsed completely, despite cloth thickness of 0.1

collapsiball.hip

Edited January 10, 2014 by Dispel

[anim]

try updating, maybe it's related to this:

 

Thursday, January 9, 2014
Houdini 13.0.288: Fixed an issue in the finite element solver that caused the collision thickness to be different from the user-specified collision thickness. After this fix, the used collision radius agrees with the thickness that is shown by the visualziation options.

[Dispel]

Always one update behind Doh.

Will give it a try when I get back this evening.

[ntkirby]

Try to turn off  volume based collision detection on your objects and see what happens

[Dispel]

13.0.288 version appears to make at least a solid difference. It's not perfect, but it's much better than before. Hopefully good enough for the real thing.

frescalus, that option doesn't exist for cloth objects. Or if it does, I can't find it anywhere obvious.

[Guest tar]

13.0.288 version appears to make at least a solid difference. It's not perfect, but it's much better than before. Hopefully good enough for the real thing.

frescalus, that option doesn't exist for cloth objects. Or if it does, I can't find it anywhere obvious.

 

Nice! What could be improved to make it perfect? 

[Dispel]

Apparently cloth thickness can only be manipulated on both sides at the same time according to the visualization. It makes it a little awkward to make a thick object, as I might want to make only the outside or only the inside thicker. Further, the thickness only *appears* to apply to the inside of the object at the moment. The visualization shows it getting thicker on both sides, but a collision on the ground will show the bottom-most polys clearly penetrating the groundplane. (Take my file above, loaded into 13.0.288 as an example)

 

Further, the results generated from the sphere with a 1.0 and a 0.1 thickness are not terribly dissimilar, (but are at least quite different from the default thickness, which is very good) and still collapses more than one would expect it to given it's supposed thickness according to the visualization.

Edited January 12, 2014 by Dispel

[ntkirby]

The volume collision is on the collision objects

[goshone]

I had submitted the original ticket for this only a few days before this thread appeared, and after testing with the 288 build, I agree that it is improved, but still far from perfect.  

 

This bug fix seems to only affect the cloth self collisions, and does nothing for handling the collision with other objects, like a static RBD object for example.  

 

EDIT

While doing further testing while writing this post, I can verify that disabling the volume collisions on the static RBD does make a difference in the collision distance.  That's a good find there. 

 

I am continuing to test with this new build, trying to replace nCloth as the go-to method for CG clothing/skin/softbodies.

[michiel]

When cloth collides with a Static Object that has Volume Collisions turned on, then only the vertices of the cloth object will be colliding with the volume.

So, in the case of volume collisions, the solver prevents only the vertices from passing through the Static Object; the interiors of the polygons may stick through the volume.

If you want more accurate collisions, where the inside of polygons can collide with the Static Object, you need to turn off the Volume Collisions, so that the more accurate geometry-based collisions are used instead. This explains why it seems that thickness doesn't have that much of an effect when volume collisions are used.

 

Also note that in simulations with a lot of self collisions, you may want to increase the number of collision passes on the finite element solver from the default (say to 32 or 64). Otherwise, a noticable amount of collisions may be left unresolved.

 

Michiel

[Guest tar]

 

 

I am continuing to test with this new build, trying to replace nCloth as the go-to method for CG clothing/skin/softbodies.

 

Out of interest what is the advantage of nCloth currently? What could be changed in Houdini cloth? 

 

Thanks!

[goshone]

Out of interest what is the advantage of nCloth currently? What could be changed in Houdini cloth? 

 

Thanks!

 

Here are my opinions of nCloth vs Houdini cloth (FEM solver)

 

nCloth

Pros:

1.  really fast

2.  stable

3.  integrated into Maya, which is our software of choice

4.  large freelance talent pool

5.  flexible as a cloth, skin, soft body, or rigid body solver

 

Cons:

1.  doesn't scale well - higher resolution meshes require tweaking to get similar low resolution results

2.  doesn't natively allow for high-quality tearing effects

3.  integrated into Maya ;-P (limited effects integration)

4.  Complicated parameters, and a lot of them

 

 

Houdini cloth

Pros:

1.  Integrated into Houdini, works well with other effects, fields, and known techniques (sop solver, sop modifications, etc.)

2.  Scales predictably (supposedly) - hi resolution meshes behave similarly to low resolution meshes.

3.  Robust... Allows for tearing, deformation, rigidity, etc.

4.  Streamlined parameters, not much to tweak

 

Cons:

1.  Slow (currently) - trying to see which parameters to turn down to improve performance without losing accuracy

2.  Not very stable - Again, still learning the new solver, so I have to see which parameters do what on the solver.

3.  Streamlined parameters, not much to tweak (also a pro, but with experience, this may not be as big of an issue)

4.  Not production proven

 

That is my list currently.  If there are any other opinions regarding this, please share.

[Dispel]

goshones opinion is pretty similar to my own. The only difference is that I don't really consider nCloth to be stable (I've had plenty of production problems with its ability to handle fast-moving collisions, and for that reason, Houdini's new cloth stuff really interests me, as it is much better at handling that sort of thing without needing orders of magnitude more substeps by comparison - Or at least, it only temporarily does, since it is adaptively substepping, to the best of my knowledge.

Not much else to add.

[Doum]

When cloth collides with a Static Object that has Volume Collisions turned on, then only the vertices of the cloth object will be colliding with the volume.

So, in the case of volume collisions, the solver prevents only the vertices from passing through the Static Object; the interiors of the polygons may stick through the volume.

If you want more accurate collisions, where the inside of polygons can collide with the Static Object, you need to turn off the Volume Collisions, so that the more accurate geometry-based collisions are used instead. This explains why it seems that thickness doesn't have that much of an effect when volume collisions are used.

 

Also note that in simulations with a lot of self collisions, you may want to increase the number of collision passes on the finite element solver from the default (say to 32 or 64). Otherwise, a noticable amount of collisions may be left unresolved.

 

Michiel

Hey Michiel,

 

When your all talking about increasing the number of collision passes, are you talking about Global or local. Is local mean self collision and global collision with other dopobj ? I'm not sure which one to play with.

 

Thanks

 

Doum

[Milan]

I've had a number of cloth sims on current production and I always squeezed time to compare nCloth (I'm a lone houdini wolf in here) to the new FEM. Mostly standard clothes on fairly fast moving character, and have to say that even though I often got better looking results from FEM (with simpler setup too), the slowness just crosses it of the list for most standard uses currently. Maybe its just incorrect setting as Josh said, for now I'll keep trying and hoping for improvements.

[Guest tar]

I've had a number of cloth sims on current production and I always squeezed time to compare nCloth (I'm a lone houdini wolf in here) to the new FEM. Mostly standard clothes on fairly fast moving character, and have to say that even though I often got better looking results from FEM (with simpler setup too), the slowness just crosses it of the list for most standard uses currently. Maybe its just incorrect setting as Josh said, for now I'll keep trying and hoping for improvements.

 

Are you using the Cloth proxy? 

[Milan]

Are you using the Cloth proxy? 

 

most of the time yes. There were some odd cases where I couldn't for variety of reasons. In simpler case with proxies it's totally fine. It's the bastard shots, where you need really good accuracy that seems to be problematic. I really think that it's just getting used to the solver and after that it'll kick ass.

[WhyGee]

I've noticed that the cloth thickness visualization might be misleading if the cloth object is referencing geometry with a transform scale != 1. Almost as if you need to compensate the thickness by multiplying by the transform's scale.

Can anyone confirm this?

 

Thanks