dForce Dress Scrambled
Bryan Valencia
Posts: 55
What in the ABSOLUTE HELL?
I made a mesh.
I "added a dforce simulation" to it
I clicked Simulate.
I thought this stuff was supposed to be EASY.
dForce Scramble.JPG
559 x 537 - 31K
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
© 2024 Daz Productions Inc. All Rights Reserved.
Comments
Was that a dress made for dForce or a non-dForce item where you added a dForce modifier?
Was it intersecting with something (even itself) when you launched the simulation? That tends to cause “explosions“ like this.
I made the mesh myself in Wings. I exported it as OBJ and DAE and both had this problem. In fact EVERYTHING I have created myself and tried to clothify has had this problem. I have never NOT had this problem with Daz dForce
Also check that the mesh has no overlapping vertices and is fully welded together. I created a simple skirt that accidentally had a gap in the mesh between the waistband and the skirt and it disappeared completely when I ran a simulation. I had another where I had a couple of vertices "inside" the mesh and that blew up on me.
Oh, and how is the clothing "attached" to the figure - did you use the transfer utility to make it into a fitting garment, parent it (if so, to which body part) or just load it and try to simulate from there? I get blow-ups if the garment is neither fitted nor parented.
I parented the dress to the upper chest. It's not rigged in any way.
Is that a G3F figure you are using? And she's in the starting pose (i.e. the T-pose)? And you are doing a single-frame simulation?
Are you certain there are no parts of the mesh intersecting the figure or itself, like Leana asked?
The object does not intersect itself. It DOES intersect the figure - I'm pretty sure. Let me try to simulate it off the figure.
OK, It flutters to the ground. so.. how do I make sure it's NOT intersecting?
Assuming you originally modelled the dress around the figure (so it basically fits) then you could take it back into Wings and adjust it till it's clear of the figure. (Maybe scale it up a tiny amount.)
Alternatively (and I'm not certain this will work, but it may be worth a try) then use the Transfer Utility to allow it to be "Fit To" the figure. Is the dress a .obj file you imported into Daz Studio? If so then the process would be to select the dress then: (1) Edit - Object - Rigging - Convert Prop to Figure; then (2) Edit - Object - Transfer Utillity... - set the source to the female figure, target to your dress, and if you are offered any Projection Templates in the drop-down list pick "Dress" or similar [I can't test this bit because I have SickleYield's templates product installed which gives lots of options and I can't remember which come as standard] and let it fit to source figure (tick box at the bottom - you'll need to "Show Options" to see that) This will do it's best to make the dress fit the figure. Then try the simulation again.
What I did try was to line it up and "add smoothing modifier, and let it smooth to the figure. I'm not sure how to "bake" those changes in though.
Did the simulation work after that?
(By the way, on further thought I don't think the rigging method I mentioned is going to do much good.)
No, the smoothing went away as the simulation started
Try exporting as OBJ with the smoothing on, and everything else hidden, then reimport that in place of the original - make sure you use the same preset in the options dialogue for import and export.
I rather thought so.
Well, if your dress is just an .obj, then after applying the smoothing you could hide everything except the dress then export the (smoothed) dress as a .obj, reimport it and use that (it won't require the smoothing modifer to be reapplied because it should be the right shape to fit the figure now).
Sorry I have to go now - it's after midnight where I am (UK) so I need to sign off for the night. I'll drop by tomorrow to see how things progressed. Good luck.
ETA: Ah I see Richard has arrived (he must keep later hours than me!) So this post wasn't needed.
ok thanks. Am having some better luck with a plain skirt
As I found out, the problem happens when you make things too rigid(stiff)
So if your clothes explode, reduce stiffness and it should fix the problem.
even if you used default dForce setting it doe not make you safe, because the coarse mesh will be stiffer than fine mesh
It is hard to tell why it happens but I assume it is a bug in the dForce modeling related to floating-point number use as usual.
Increasing the number of iterations/subframes can also help in that case.
He keep weird hours
Interesting idea. It proves that is is definitely number related issue.
But I wonder if it is possible to somehow convince Daz developers sot to fix this bug?
Now it is practically impossible to simulate any objects with reasonable stiffness.
If adjusting the iterations helps it isn't a bug - it's just a question of setting suitable values. The defaults were prsumably chosen to balance performance against the range of values they would work with.
Adjusting iterations is just a workaround for this bug. This is not normal behavior but the result of computation failure which should not happen under any values.
Adjusting stiffness will also fix the problem without any performance penalty.
I think it may be impossible to fix it properly, but it may be possible to implement some workaround to quench wrong numbers or at least terminate the simulation.
No, it isn't a workaround for a bug - as I understand it, if you stiffen the fabric it takes longer for the energy in the "springs" to propagate, so you need more iterations to be sure it spreads out and doesn't build up to an explosion. It may be a limitation of the method used, but that would not be a bug (something not working as designed).
It is not how it works. Stiffness and iterations do not cause explosions by themselves. According to the physic, it cannot happen in principle.
The reason why it happens is that those kinds of simulations use floating-point numbers and those numbers lose accuracy as they get bigger. That curacy is extremely important when you use absolute numbers because subtracting 10-9 and substracting 1000 000 000 - 999 999 999 will give you cardinally different results that may differ several times. You need to think about that when developing your software. High stiffness and big iteration steps just introduce big numbers into the simulation and that essentially makes it crash.
I think it should be possible to fix if there is something added to catch those conditions. Simulation accuracy may suffer a bit but at least it will not crash like that.
What is most interesting, that explosions happen in the very beginning of the simulation when there is no tension or any energy yet, which implies that it has something to do with initial conditions. It has to do something with energy propagation, but it is not because of physic, but because something is wrong with computations so that error builds up quickly and causes an explosion.
Do you actually have access to the code as the basis for that?
The process is a simulation of a mesh defined by a relatively sparse, compared to real cloth, mesh and a series of rules that attempts to abstract physical processes, it isn't real physics. The whole thing relies on the diffusion of energy through the mesh network (according to the developers, not an assumption on my part) and sometimes it is necessary to adjust the parameters to get a proper result.
I obviously do not have access to the code, but this is not a unique situation, it is a general issue with all software.
iRay renderer also has a similar bug where when the object gets far from the zero position strange problems start to appear.
"It's a common problem" is not the same as "it's the problem here" though, and I'm not sure how addressing the issue by increasing the number of iterations could be read as evidence in favour of its being the problem here..
I'd be interested to know at what distance from zero things start to get problematic.
I regularly work with items that may be several hundred thousand units from 0, especially mountains and "Far off stuff". and haven't see any problems.
The mathematics, of course, are not perfect, but DAZ is far from the only application which experiences "exploding" meshes from bad input. For example, Marvelous Designer is one of the de-facto fabric simulators on the market and does real-time simulations you can interact with. However, if the fabric settings are incorrect, or if the meshes are intersecting, or even moving too fast, then it can cause "exploding" results usually followed by an infinitely stuck simulation. Now, this is expensive software designed solely for fabric simulations and it ALSO has this issue, so I don't feel even a bit confident that ONIX is anything but an armchair programmer here.
Aside from all that, the exploding happening in DAZ is often caused by too close or too far collision offset settings, and/or collision objects moving too fast. If this is happening during an animation, the frame rate might be too fast for the motion. Think for a moment how fast someone takes to sit down from a standing position, and ensure there's enough frames to cover this time period, maybe even more. You might think it's only one second when it's actually 2-4 seconds of action.
If the meshes are intersecting, then having too big of a collision offset might cause exploding (you can spot this when starting the simulation as you'll see a ton of " collision "errors" pass in the window before it begins).
Smoothing may add to the problem if the mesh is "thick" or "solid" versus being thin or single surface.
Thanks for all the help.
Just to close the loop on this: It turns out that the pose I used does have the hand intersect slightly - microscopically - with the upper thigh. The second the hand penetrates the leg, the dress explodes. Thanks for EVERYONE who has helped with this.
There ought to be some script or warming message from DForce when this stuff happens. What happens now is that the sim will take 10 seconds a frame until the problem occurs, then the first bad frame takes 3.5 hours, and the dress explodes.
Daz ought to be able to auto-adjust out these intersections.