I wish they would enhance clothing dynamics and collision detection
jdavison67
Posts: 689
It feels like this element of DAZ has been left behind in development. Dynamic clothing and collision detection are so crutial to realistic animation.
I find the animated draping to be so frustrating, in practice, that it is not worth the effort. This is exacerbated by the fact that clothing usually isn't one size fits all, and their is no way to size a clothing item befor appying a clothing drape in instances where the model may be more robust than the base figure the element may be designed for.
Just my two cents.
JD
Daz 3D is part of 
Connect
DAZ Productions, Inc.
7533 S Center View Ct #4664
West Jordan, UT 84084
Licensing Agreement | Terms of Service | Privacy Policy | EULA
© 2025 Daz Productions Inc. All Rights Reserved.
Comments
Can you post some specifics? Are you talking about poke through or cloth not moving realistically?
I'll post some examples, but I was really thinking about the whole approach.
Many talk about using primatives, and draping over alternane figures, scaling, etc...
I was just thinking in all these years somebody could have come up with a streamlined way of dealing all of these things and updated the plugin.
Imagine if you could pin part of an object in place, or chose parts of the clothing item to drape while the rest was frozen, just for example...
I think I'm wishing fro a re-vamp of the whole system, something that has taken all the workarounds into mind, with more user friendly interface to overcome the common obstacles.
Kind of like a morph then drape tool combined.
JD
Yes this was a DAZ wish, no disrespect to poser of course...
JD
I still have yet to mess with dynamic clothing much as, I too, find it confusing, frustrating and tedious.
Someday I may get the hang of it.
You may want to venture into Optitex's tutorial forum here: http://www.optitex-dynamiccloth.com/forum/viewforum.php?f=3 They address some of these issues and more there.
As one working on a dynamics system for DS, I can tell you that for most DS users, the necessary effort to set the parameters correctly will cause many to decide not to use them. Physics and the interactions with the various items in a scene will result in much tweaking. Anyone who has done such in Maya, 3DS Max, or C4D can tell you that a large amount of effort goes into getting the settings right for the dynamics.
Kendall
What would help a lot would be if the smoothing modifier would only smooth the geometry is the face groups match. So thighs would smooth only to thighs and arms only to arms. This would cut down on the "my clothing has suddenly turned into the alien symbiot suit from Spider-man" problem you get when you apply a smoothing modifier and your clothes turn into a liquid goop that swallows up your figure.
Wait...you are currently working on a dynamics system for Daz???
This would only work if the clothing article used the same facegroup naming conventions *and* the facegroups lined up exactly. Otherwise you have an even worse situation where borders between facegroups meet and the clothing/figure groups aren't matching. This particularly becomes a problem with oversized clothing (like dresses) when the figure is posed in moderate-to-extreme poses.
Kendall
I am. See my youtube channel for some teasers on some of the things that I'm working on. No promises on timelines.
Kendall
Then maybe something where you could turn off the smoothing modifier on the figure itself. Like turning off the hands and forearms so the clothings won't leap onto them since they're usually the worst offenders for the symbiot effect.
Going by what method I suspect is used for the current "smoothing and collision" the resolution on the meshes in question would need to be significantly higher than they currently are to stop the "slipover" effect. In many cases the hands are too small to be easily resolved as a secondary collision -- much less the fingers -- and end up colliding with the center of a facet as it is being pushed "out" from the mesh of the primary collision area. This leads to a situation where there is no collision detected for the hand/finger(s) (you'll see the same thing with most cloth collision systems) and the cloth facet is pushed over the finger/hand. What can exacerbate the situation is where a set of secondary mesh points ends up "behind" or "inside" the cloth. The next iteration of the check will now detect that the occluded mesh-points are inside the cloth and proceed to try to push "out" the cloth even further.
In order to fix this kind of thing would require processes that can take *significant* amounts of time to simulate with any precision. I would wager that most DS users would not have the patience to wait minutes for a cloth sim to correct itself after every pose change. Many cloth simulation systems simply turn the hands/fingers into a single bounding box/cylinder and run the collision from there as "good enough", and then fail spectacularly when "impossible" situations occur (e.g. fingers breaking the surface of/too close to the body mesh leaving no physical room for the cloth). I can tell you from experience that Alessandro and I catch a lot of grief about the short delay that large LAMH presets incur when translations/rotations/morphs/poses are changed and LAMH has to recalculate hundreds of thousands (sometimes millions) of hairs. The quantities of calculations required for what is being discussed in this thread can easily dwarf what even LAMH currently deals with.
There are tradeoffs involved with respect to the amount of processing resources, storage resources, and time necessary for these things to happen. When you also take into account that many people only have 1 computer and want to be able to run DS, their Web Browser, email program, internet radio, etc, they aren't normally too happy if DS slurps 100% of CPU, GPU, and disk leaving their other programs starved for resources. This would be what was necessary in order to get to the level of precision that users are expecting. Of course, DAZ could go to a non-realtime viewport update and require that the user click on a "update" button to recalculate the effects of their changes, but I suspect there would be adverse reactions to such a move.
Kendall
Finally, someone that understands and states the limitations that have to be put in place for the software to be useable for the largest number of people. It would be nice if they could add some means of determining the capablities of the computer and enable the better modes based on that, but it's not going to help folks that insist on using "wimpy" hardware to run DAZ Studio (or any other rendering application, for that matter).
hey, we are in 2016! See the real time physics based simulations in games with nVidia engines. Nowadays, it is not a computer power problem, it is a matter of strategic choice of developpers. The intergration of all the simulations by nVidia, powered by a simple GPU would add a big plus to Daz Studio. Each user then can choose his own horse power to use it.
So, Daz, I beg you to add thoose modules into daz studio.
I knew "games" was going be mentioned. Please look at the differences between the number of polygons between game assets and the assets that are being used in DS/Poser. These calculations increase *exponentially* by polygon count, not linearly; which is why game developers look to get rid of EVERY polygon they realistically can and use maps to try to simulate the geometry. I can tell you without a doubt that no one would be happy about using a "games level" polygon count asset. People already grouse about G3 having too few polygons as it stands.
As an example, a single figure+hair polycount in DS will be greater than most full scenes in a game environment. Then add clothing. Let's not forget the 4Kx4K texture maps (not going to see those in game renders) for every little thing.
Different worlds, different needs. nVidia has given some great tools, but even great tools need time scales on project sizes.
Kendall
you didn't get me Kendall! What I meant is that there is enough horse power available to make it useable. The game industry that I spoke about was just for the show/demo. Now with our Figures. G3. even a G4 with 1 million poly.Imagine what can do a single 980ti in term of calculation, already developped by nvidia and some other simulators companies. If you want to make it pro, you just have to add up some more GPUs. The upcomin pascal GP100 will be more than twice this power on a single card. It is way more than enough to calculate all of this, even single hair by single hair! I'm not speaking about doing it in realtime, but in a matter of seconds. then freeze, then render. job done.
Except that the developpers have to integrate it first. The scale is only on the harware side. The choice is on the people side.
I "get" what you are saying, trust me. I'm riding on the bleeding edge of this stuff. I have a rack of high powered machines including Tesla units. This stuff takes quite a bit of horsepower to get the kind of precision and detail that the users are demanding.
I'm hoping my solution gets out before anyone elses.
Kendall
PS: Before anyone panics, I'm not going to write it so that you need 48 cores, 128GB of RAM, and Tesla units to be useful.
Cloth/hair simulation is a computationally hard problem. Contrary to your apparent beliefs, current consumer-level hardware is nowhere near being able to handle full hair-by-hair simulation in a practical length of time. Even the major animation studios, working with systems beyond anything any of us can afford, try to minimize the number of simulations they have to run.
Despite the advances in GPGPU computing, it still is tricky to implement many kinds of algorithms into easily parallelizable chunks. Cloth/Hair simulation can be done this way, but it is by no means ideal algorithmically to parallelize. And that's what gets you the real advantages in a GPU-based solution. Lots of cores simultaneously solving the problem....i.e., parallel processing. But cloth/hair simulation....most soft-body simulation, in fact, is NOT easily done this way, due to the interactions between the mass-spring models. Collision detection, one of the fundamental physics problems, can be parallelized, but even that isn't optimal. Furthermore, GPU cores use a very limited set of operations to do what they do. Finding a way to implement the mathematics so that the GPUs can actually calculate the results is another problem.
PhysX and HairWorks took a lot of work by nVidia to get to work on their GPUs.....and trying to make them do things that they weren't designed to do (mainly gaming-based style physics) is VERY difficult. It also tends to be considerably slower.
Lastly, getting this stuff done via GPU is great....as long as the end-user will always be using a high-end nVidia card. Most developers for this kind of thing in DS want to be able to deliver it to ALL the users, not just say "Oh, you don't have a buff nVidia card? Too bad." So you would have to develop it along OpenCL lines, and hope you can maintain compatibility with the algorithms across all the platforms.
It's NOT a simple problem.
Not to mention that hairworks is PC only and tied to DirectX. That means that OSX users are left in the cold. We don't want to/can't wait for nVidia to provide a solution that works for more than a small subset of users.
Kendall
look at iClone - they are here now !
For me, considering that daz is mostly a still image render program, having some PhysX modules implemented in daz studio should be a great addition. Even it they are not 100% accurate, they seem to be a good starting point to "play" with.
https://developer.nvidia.com/gameworks-physx-overview
BTW, look what physX Clothing can do on a cheap nvidia card:
https://developer.nvidia.com/clothing
Of course, that means new cloth rigging/material/infos/data.
No need to have the full accurate simulation. You have to start with something. It is a matter of compromise...
And look at
http://techcrunch.com/2013/07/23/researchers-create-near-exhaustive-ultra-realistic-cloth-simulation/
"The cloth you see above is made of 29,000 vertices and rendered at 60 frames per second" REAL TIME.
And you know what? it was 2 years ago... So, something can be done, now in 2016 with the actual horse power available. keyword: "something"
You might want to actually read the article there. They pre-computed the whole thing. Pre-computing for a given figure, and a given piece of clothing, yes, you can get those kinds of frame rates and that kind of accuracy. You couldn't move the item to a new figure. You couldn't change the shape of the figure. You couldn't have the figure move in non-pre-computed ways. You couldn't add other collision items.
As it was, for a 29k vertex piece of clothing, with a relatively simple figure mesh, it took 70MB to store the pre-computed data.
This is not a generalized solution. It can work in a gaming environment since much of the data is pre-made, pre-computed, and optimized. Once again, that is NOT a general solution.
ETA:
As for nVidia Cloth, Apex, etc. Again, these are based around gaming solutions. It's not that generalizable, nor can you just keep adding more to the scenes. The optimization passes and pre-computation done for most of these are fairly fast, but that is because the figures and scenes have been optimized for it (like you can do in a gaming environment). This is not to say it could not be utilized for doing more general simulations, but it won't be nearly as fast. And it's pretty limiting that it's only going to be for nVidia cards, and probably Windows machines.
Sigh.... People, GPU processing is not a panacea and cannot solve all of the performance problems any more than High-Core Parallelism could. In fact, GPU's by their very nature, are limited in the scope of the computations they can perform and will be able to do less than a similarly spec'd CPU.
From an algorithmic standpoint, not all "obvious" parallel processing problems are truly solvable using parallel methods. Computing moving and colliding hair by assigning a processor to each WILL NOT give you correct results. Here's a simple example: hair_a is within collision distance of hair_b (self-collision and collision with base mesh will not be considered as it adds huge complexity). Both hairs are moving along timeline T. hair_a just so happens to be in a situation where the calculations are conducive to not having to run some of the more expensive math functions and is capable of being computed at 1.5x the speed of hair_b. So hair_a proceeds along computing just fine, EXCEPT that no collisions with hair_b can be considered since hair_b hasn't calculated to T*1.5 yet. So, now you have to decide whether to proceed with hair_a calculations *hoping* that no collisions (and resulting bouncebacks) occur, or to just stop and wait for hair_b to catch up. Now, let's expand this to say the approximately 20,000 hairs within collision distance of each other if the hair length is 2-3 inches. That's 20,000 hairs that could possibly collide with 19,000 other hairs AT ANY GIVEN TIME in timeline T. Now, each hair is made up of a number of control points (CP) that make up the spline the hair follows. Let's be nice and say that number is 10. Now, you have 20,000*10 CP that can collide with possibly another 19,999*10 CP *EVEN WITHIN THE SAME TIMELINE POINT T*. You now have to not only calculate the proposed position of each CP, but run the calcs to determine if there is a collision with ANY OTHER CP, and if so, what effect will be on the other CP within range. Anyone want to guess how many possible deadlock conditions will be encountered? How many of these can be parallelized, how many have to be sequential, what has to be recomputed due to collision. THIS IS A SHORT OVERLY SIMPLE EXAMPLE. Should I continue? Wanna add in clumping? Frizz? Tangles? Curls?
Games take a great number of shortcuts to get "performance" including limiting the range of possible motion, precomputation, and other things. Many of these would lead to unacceptable results for up close and detailed renders. There is a reason that the movie studios don't try to use realtime hair sims for their work, it is too imprecise, inaccurate, and looks bad in a realistic setting.
Think about it... we cannot even get truly "realtime" rendering without real hair and cloth sims in even the biggest and most expensive of the 3D packages. We're expecting more complex procedures than that in realtime at this level?
Kendall
EDIT: I'm going to add some computer science here to stave off a specific argument. "Assign the waiting processor to another hair" The operative concept here is called a "context switch." These are especially expensive on GPUs. A context switch is the process where the stored registers, memory variables stored in Level1, 2, and 3 onchip caches, stack, and operation addresses are copied off the CPU/GPU into memory and then loaded in for the next set of operations. In many, many cases the cost of a context switch is significantly more expensive than any "downtime" experienced in a wait.
To add to this discussion, from the perspective of FEA: finding a convergent solution for a large system within a small delta-t, in real time, is nearly impossible. Unless there's some miraculous secret code that someone is hiding -- a la Carmack's Approximation -- dynamic simulations will always be a challenge.
I beg to differ with you. I have used Iclone's phsyx soft cloth with Daz figures and clothing and none of your points bear up.
Here are two examples of DAZ characters in Iclone
The observation I make is that Optitex is nearly ten year old technology.(See the news Article here.) In the time since it's been added, how many times has it been updated? I'm not talking the bug fixes that come out because DAZ3D updated DAZ Studio --but how many actual plugin updates have you seen?
Even without mentioning Nvidia Physx, there are other plugins like Houdini engine, which is free incidentally and includes volumetrics and fluid simulations. (See example here). I think the Lament that JDavidson67 is making is more than valid. Adding Iray was a great step forward, but DAZ should have left it's current conforming setup for something more robust a long time ago. Conforming is great for stockings and bodysuits, but it's retarded when it comes to realism and they have not innovated very much in it's delivery. You have companies making up-to-date technology when it comes to cloth simulation, but DAZ is apparently content to leave everything status quo. I cringe every time I conform a dress to a female figure and have to spend twenty minutes adjusting the garment because someone things that clothing magnetizes itself to boobs.
I heard people complaining about baking the dynamics, but honestly what's wrong with that? DAZ could develop a program to take a garment and bake it's animations before it's conformed to the figure so that when you bend and arm or hip joint, the garment actually presents a realistic deformation? You could take a figure, prebake it's range of movement and then every time you create a garment -in the setup process create its deformations/animations based on those precalculated values so that when you move the figure you don't have to wait for a simulation --it's already there. The only thing you'd have to do then is come out with a couple of vertex brushes that will allow you to fix poke through and crease fabrics without distoring the vertex count or needed to create another morph. Let's face it --there are a lot of advancements that illustrate his point, and DAZ has not implemented a single one of them. The Optitex Plugin is dead and they should just let it die and get something with some juice to it.
I think in 5 years even cheapo Android tablets will handle such things with ease. :-)
Yeah, but you'll need the special Dry Ice Tablet Stand ($50 plus CO2 cartridges and emission waivers) to keep the damn thing cool.