I remember seeing white surgical gowns in the 1960's

.

In reply to aRtBee :

The basic cloth part of the sim will use pairwise, angle, out-of-plane bending, and possibly torsion "springs", i.e. combinations of 2,3, and 4 vertices, but not range based forces.

The only forces that will range based are the ones that arise from the constraints for e.g. keeping the cloth away from the collision targets, and I'd be very surprised if neighbour lists aren't already being used to limit the amount of calculation involved in generating these.

to nruddock:

sure.

The Poser-sim sees each vertex from the default-group as attached to its neighbors by dampened springs, and since most meshes are neat quad patches nowadays, each vert has 4 neighbors. Additionally to these stretch and shear forces, gravity is present as a constant, while the 4 poly's our vert is part of are also effected by static, dynamic and self-friction plus air-damping from atmosphere and wind-forces. As a result, each neighbors neighbor is relevant too, determining size and position of that poly. 

Some neighbors or neighbor-neighbors might be in a non-default group, are effected in other ways themselves but still effect the vertex at hand. 

When using a calculation thread as an independant process to derive the stable position of a bunch of vertices (1, 4, 9, 1024, ...) then this thread has to look (=calculate) outside, to the verts of other buckets around. This is the bucket-border, or bucket-overlap which is an overhead. Rendering uses a border of 2 or 4, and from the above I guess the sim calculation needs a wider one. Lowres meshes or cloth with high damping values might need 2 to 4, hires meshes or cloth with low damping might need 8 to 16. Increased overhead means a lower economic optimum for the amount of simultaneous threads issued.

Best regards, thanks for the input, this has developed into a quite informative thread.

Quote - When using a calculation thread as an independant process to derive the stable position of a bunch of vertices (1, 4, 9, 1024, ...) then this thread has to look (=calculate) outside, to the verts of other buckets around.

I'm sure I mentioned chunks in one of my previous posts. Dividing / mapping the geometry onto a set of chunks is probably being done spatially with either heuristic to determine whether or not wraparound is needed, or volumetrically (as opposed to a data decomposition).
These methods of problem decomposition are well known in the fields of MD, FEA, and CFD.

As the calculation is (currently only) being in memory shared by the parallel threads, the communication overhead is tiny, and the number of threads is going to be practically limited by the number that can be truely run in parallel, which is likely to be well short of the number that the calculation could be split into before comms becomes a problem.

You mentioned chunks in your second post indeed, missed that in my last reply, sorry.

Mapping geometry onto chunks is well understood indeed. But thanks to sleeves, pant legs and other issues it's definitely more complicated than mapping a rectangular image onto buckets as in rendering. 

In my observation, calculation threads are separate independant processes which can even run on seperate machines, or on CPU's with very different availabilities or speeds. Like in rendering the algorithm will not try to access data generated by other threads, only the thread manager will do that assembling the final result from the parts. It's a hierarchy, not a peer community, as I understand. The overlapping verts are calculated in both threads, of which one (the in-chunk thread) is considered the most accurate one, as it has more neighbors available in the calculation. 

If the threads could communicate, this kind of overlap would vanish indeed. Unfortunately, they don't and it's only a part of the issue anyway.

From taskmanager I can infer what's going on, and understand the process. This doesn't mean it's the best process around. But is does mean that very fundamental changes are required to quadruple speeds or better, and turn the simulation times referred to in my earlier posts to something more bearable. 

Throwing big bucks at this improvement is not on MY priority list. This will be different for anyone else, that's alright. Given all other info around, I just guess it's not on top of SM's list either. And - contraring to the assumptions in some posts above - there is at least some multithreading around already. Reassuring. These were my points on the multithreading / sim-improvement part of the debate as raised by Reinhold originally.

My points on the folds and wrinkles as raised by Reinhold as well were that these were caused by a relatively lowres mesh in a position which exceeded the limits for that resolution. Raising mesh resolution would make more extreme poses possible without the artifacts, but at some point they will re-occur. Relaxing cloth parameters did not make an improvement but raised calculation times considerably. I could see why and explained accordingly.

For now, I stop posting on folds, wrinkles and multithreading. Anyone else is welcome to step in, I keep being interested. Instead, I'm going to try to help Reinhold on his issue on the 0,0 bias in his drapes, to make him get his surgeons to work in the proper outfit.

To be continued...

Quote - If the threads could communicate, this kind of overlap would vanish indeed. Unfortunately, they don't and it's only a part of the issue anyway.

Of course the threads communicate, they have to, to exchange partial results for the chunk edges to be able to properly complete each step.
This is why there is a minimum chunk size below which parallelisation isn't efficient.
Bucket rendering is different because the optimal sizing is driven more by memory considerations rather than the need to exchange edge results efficiently (if that's done at all).