Should we try to write a Fast Dynamics Script for Conforming Clothes?

  • I have some big gripes with the cloth simulator, which is that it runs waaaaaay too slowly, it doesn't re-simulate only part of the simulation, it gets out of control very easily (things fly away, get in odd shapes exposing incovenient body parts when grandmother is just looking behind you) and can't be mixed with conforming clothes.

    I think that part of the problem is that it tries to use the same engine for two things - one is fitting, which requires great precision (therefore complicated calculations with significant changes in shape); that part can be slow, as it's done only once; the other is the actual dynamics, which should be very fast and in many cases should maintain the basic shape of the cloth (although there are cases of dynamics that indeed will create great changes in shape, like when dropping a cloth on the floor or sitting down).

    Now, the fitting part is now duplicated on the much superior, incredibly flexible, amazing and
    miraculous piece of software engineering called Fitting Tool. The fitting tools gives you for free a fully fitted, conformed and morphed cloth, which alas has no dynamics and no way of getting dynamics. But it gives you a cloth that the toon can walk around and sit with.

    So, now that I got a new plaything in the Python API, I do see possibility for a vertex delta-manipulation fast cloth dynamics thingie tailored for the results of the Fitting Tool. That is, a way to add simple fast dynamics to a fitted conforming cloth.

    It can have no collisions. Collisions are very very slow to calculate, and with tight complicated overlapping geometries they tend to go crazy and become incredibly difficult to control.

    But it can have Newtonian spring-based dynamics. Say I have a figure F (=conforming cloth) compose of several actors A_n (=body parts). Now say that the user uses Group Tool to create groups named FAST_1 to FAST_5. Don't change the materials. The idea is that FAST_1 is a group of vertices that will have very only a little dynamic push, and FAST_5 is a group of vertices with full dynamics push. That allows some transition to more freely flowing parts of the cloth.

    Then when the script runs it scans all figures in the scene for body parts with those group names, then builds a list in memory of these figures, actors and vertices. It then builds an invisible prop called Dynamics_Control_n to store some simulation parameter and attaches to the figures that don't have it already.

    It then calculates their dynamics in memory. At that point it doesn't care about F or A_n, just the list of vertices, that's why it doens't matter if the thing is a conforming cloth. It should work the same way in any prop, figure or hair. The calculation is based on the world coordinates of the vertices, so when the figure moves around the vertices will drag behind and then move to their rest position according to spring physics (will either oscilate or not, depending on the parameters). So the cloth will always drag behind the figure, as clothes do, but will always come back to its original rest position (instead of some crazy position based in gravity and collisions).

    Then a callback to add deltas in local coordinates based in the pre-calculated dynamics. That way you can have some ruffling of selected parts of conforming clothes, that should go across body part welds. As the calculations are simple (just difference equations), the baking should be fast I think, and it should bring some life to these conforming clothes (and hair too).

    So, should we start a new project?

  • By the way, if you noticed, the idea of using groups is because shamefully there is zero support in the Python API for weight maps. The proper way of defining influence is by weight maps instead of these groups; but no weight maps, so one must think, of a poor man's way of doing it.

  • It's whether you want to invest the time bearing in mind that there is already VWD's for-sale script that already does quicker cloth dynamics (which he's currently adding GPU acceleration to as well).

  • Another by the way... I think we probably can add some additional forces too, just for fun. Say that one script created spheres with special names say ATRACTOR_n, and parent it to the current figure.

    That sphere can do (per a parameter) attraction or repulsion of the FAST_n groups, up to a certain parameter distance. As the vertices would have springs, that attraction will balance itself at a certain point. That way the user can add incidental temporary dynamics to the shape of the cloth just by moving these attractors around.

    Another thought is to have another sphere called WIND_n, which just adds velocity to the FAST_n groups in +X direction within its limits. That will also come to stable solution, due to spring equation, and come down to rest once the wind is gone. The user can then orient the sphere and change the parameter to change the wind.

  • @raven said in Should we try to write a Fast Dynamics Script for Conforming Clothes?:

    It's whether you want to invest the time bearing in mind that there is already VWD's for-sale script that already does quicker cloth dynamics (which he's currently adding GPU acceleration to as well).


  • Oh, the Virtual World Dynamics guy at Renderosity, right? I thought that was for DAZ only.

  • No, it was Poser first, then someone did a DAZ bridge.

  • Clothing is essentially the same as the character's skin, then relaxed. Then, all you need is the ability to add collars and such... :-)

    I have always found it strange that Poser ignores the relationship between body parts. For some reason, Poser allows you to place a foot on the character's forehead...

  • @raven said in Should we try to write a Fast Dynamics Script for Conforming Clothes?:

    No, it was Poser first, then someone did a DAZ bridge.

    I see. So it runs on PP11?

  • Yes it does.

  • Hmm... guess not much need for this then.

    I'll do something else.

  • @raven ...but only for the PC, so it's still not a good solution.

  • @tburzio I wasn't aware of that. In that case, fbs7, I say go for it! :)

  • I'd be pleased to have a quick fit-to morph script within poser, similar to DAZ Studio's "smoothing modifier" to eliminate pole-through...

  • @fbs7 sounds like a plan. Even though there are gaping holes in the Python API, anything which can be loaded from a PZ2 or CR2 file, including weight maps and deformer zone falloff curves could be created and loaded by a python script, even if the script can't directly manipulate them in the scene.

  • @fbs7 If it does just what you say it would then there is still IMHO a need for it. Figures poking through clothing is still one of the biggest time consumers in Poserdom. Dynamics are great for dresses and coats, but I've long said that fixing conforming clothing shouldn't require a fully dynamic simulation. We know what the problem is and what causes it, it seems a special case solution could work in the most common cases.
    Often times dynamics seem like overkill. I'm not always trying to simulate specific cloth types, or worried about wind and/or gravity. 99% of the time we just want our clothing to cover the figure as it is posed.
    That said, VWD is on my wish list for its ability to run a dynamic simulation on trans-mapped hair alone.
    Now if we could just get soft body dynamics, and cloth/hair dynamics working reliably together without needing a degree in Poserology...

  • I'm rediscovering that there are still major problems with conforming figures where the base figure has scaling applied to individual actors. Even setting Conform Scale can introduce origin offset errors in conformed child actors of the scaled parent. It's especially troublesome if the child actors are just ghost bones affecting the parent with geometry via weight maps.

    I see what looks like morph mismatches in morphs copied from the base figure to the conformed figure which entirely disappear if the parent of the affected conformed actor has its separate scaling removed (reset to 100%). Clearing the Follow Origin and/or Follow Endpoint flags on the conforming figure do not eliminate the problem, they just change which way the offsets appear.