And now for panel 2, cloth-objects (or: sim items).

First, I had to found out hat was really meant by collision offset and depth. So I made a very large box (100% scale in X and Z, 10% in Y direction), took a square piece of cloth and dropped it. By using camera zoom in and by moving the box up in the final frame, I could what happened on varying those 2 values. 

No miracles here: even when the box slowly moves up when the cloth falls down, the cloth ends up some distance above the box. This is the OFFSET distance, in cm. When you think the "bottom" or inner surface of the cloth is on the figure, and the "top" layer or outer surface is the cloth itself, then OFFSET is the effective vritual thickness of the cloth. The minimum is 0,1 (= 1mm), the max is 10 (cm).

So again, like the parameters, distance is in cm.

Now, what does Depth do then? The manual and some SM-tutorials (like http://my.smithmicro.com/tutorials/418.html) suggest that it does what Offset shows to do. Someone has been mixing up things.

Seemingly, it did nothing. Until I made the box quite flat (2%, or 5,6 cm to be precise), I kept offset at 1 cm at varied depth. I saw the cloth falling (at a constant 8.8 cm/frame, thanks to airdamping) while the box moved slowly upwards. And at depth values of 1,2,3,4,5 and 6 the cloth ended up correctly, 1 cm above the box and moving up too.

Until the depth value became 7 or more (max = 10 cm). Now it disppeared at impact, and immediately reappeared... at the other side of the box, at 1 cm distance, and moving up with the animation.

Why did it move position when the depth became 7 cm? Well, since the cloth resides at 1 cm above the box normally, and the box is 5,6 cm thick, looking ahead 6 cm would not see the other side of the box, while looking ahead 7 cm would.
From this i could also infer that first: the cloth was put at 1 cm offset at a response to the collision, and second: the look-ahead for the other surface.

After that, the algorithm draw the wrong conclusion and warped the cloth to the other side, and above that: the cloth stopped falling down from gravity but started to move up with the box. 

Like the offset, the depth is measured from the cloth (outer) surface down towards the figure.

According to the tutorial above, the look-ahead method attempt to make more natural results faster. When you set the value too small (less or equal to the offset) it becomes ineffective. If you set it too large, it starts responding to pieces of the figure which are irrelevant to the simulation as it should be done. And vice versa, if other pieces of the object become too close and inside the look ahead range, they might disturb the result as well. Animations might do this, with hand close to the body. in that case: reduce the depth.

I have not tested yet for multi-figure situations (figure sitting on chair with cloth inbetween). Will do.

Then there is friction, static and dynamic. These have equivalents in the parameters section. The parameters address the characteristics of a specific dynamic cloth-object-group. The values in our cloth-object settings address the whole cloth-object, hence: all dynamic groups of that cloth-item. You can tick the checkbox at parameters, as Laurie has posted recently. Then the cloth-object values are used. When unticked, the cloth-object-group parameter values are used instead.

Why would that be? It suggest that one sets values at the object level first, till one likes them, and then fine-tunes for underlying groups individually. This implies that friction is an important factor in the simulation results. otherwise: why take this trouble for these parameters only? To be investigated upon.

Note: when you build your cloth from several cloth-objects (just go on clothifying object-portions to the list), the settings will hold for the entire set, not per cloth-item. So when a blouse and a skirt are added to the list, both with have the same offset, and depth, etcetera.

Note: I tried to take a conforming dress having hip, abdomen etc as in Vickys geometry, but also skirt and other elements that were not in Vickys structure. The first group of elements could all be clothified to the list, but the others could not. I could select them for clothification, but nothing happened after the [OK] button. Might be an OBJ thing. To be investigated upon.

Ticking the Start Draping from Zero-pose box implies exactly that. At the beginning of the Drape, the figure (and not the cloth or dress!) is set to the (in)famous T-bone pose, and while the dress drapes over the figure, the figure itself is animated towards the pose in frame 1. This of course does nothing for props with no zero-pose at all (like a table), and does nothing for those animations which start in zero-pose at frame 1. But, from the above, you can infer there is no need to do that. On the other hand you can understand that the more your frame 1 pose is off the zero pose, the more drape frames you need to start your animation / simulation with a properly fitting dress.

Finally, of course, you have to reveal the collision target aka 'the figure'. Choose Vicky, and select to ignore hand, feet and head to speed up calculations. But do add shoes when the dress suggests collisions, deselect arms for sleeveless dresses, and so on. Handle stacks of sims the way they appear in nature: if the blouse in sim A is over the skirt in sim B, then include the skirt as a target in the blouse sim. And so on. It does not harm that much to add in a bit too much geometry. It can only slow down processing a bit. Or it can disturn the results when geometries become to close.

For the sake of it, I'd like to share some observations on simulation calculation times. It appears to me that as long as a dress fits or falls in a smooth way, it runs fast whatever the settings, although the I've more enhanced the calculation, the more it takes.
When collision and disturbances kick in, simulation really slows down. But... an effect of the enhanced simulation settings in a lot of cases is, that the dress runs smooth for far more frames in the animation. As a result, simulations with the enhancements ticked frequently run faster than those with the options unticked.
Hence, the idea that the simulation options slow down the calculations is not my observation in general. Sometimes it does, frequently it doesn't.

So, I'm interested in your findings.

Thats it for panels 1 and 2 now. There is more to investigate. There might be bugs around, or non-understood features. We have to ask the SM people. Just hold on, we're moving ahead. Check upon me, I might be wrong. Fill me in as well. I'm not the all knowing guide through this swamp. But perhaps I'm just one stone ahead, like some others as well. Or was it the alligator I just stepped on? 

Have a good night.

 

- - - - - 

Usually I'm wrong. But to be effective and efficient, I don't need to be correct or accurate.

visit www.aRtBeeWeb.nl (works) or Missing Manuals (tutorials & reviews) - both need an update though