DAZ dForce : Spring of node calculation time [SOLVED] ٩(◕ᗢ◕)۶
hansolocambo
Posts: 649
Two questions about dForce :
1/ I'm trying to convert assets I'm working on to dForce. Properly.
There's something I still don't really understand. Some items with 25K + polygons simulate pretty well and fast out of the box. Like Lully dForce - Flirtatious (although default surfaces aren't properly configured and need some changes or it tends to explode).
Others even with less polygons simulate slowly and have a first step "Spring (XXX) of node "XXX" that takes forever to calculate.
I don't get what's the difference (in terms of DAZ content creation) between dForce items that don't do this first spring/node step (I don't know the name for it sorry), or do it extremely quickly. And others that have that first step running for a lot of time.
I have the feeling that if I add (which I always do) a dForce Modifier Weight Node and paint weights on my clothes then the spring/node step seems a bit faster. But ... well don't quiet understand how to make custom made meshes simulate faster (other than clean toplogy and polycount of course).
2/ Most dForce clothes I've used don't have a dForce modifier Weight Node selectable in the Scene Tab. But, if I create one for the selected clothes and go to Tool Settings > Weight Maps > Influence Weights (Map) then I can see that those Weight were indeed already defined by the content creator.
Is there any other way to see dForce Weight node (red/grey/blue influence) already defined, without having to create a dForce modifier Weight Node ?
How come a dForce item can be saved with Influence Weights even though the dForce Modifier Weight Node is not saved with it ?
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
Hi.
The "Spring (XXX) of node "XXX" message usually means that your dForce item's collision offset (that's in the Materials - Simulation settings) is bigger than the spacing between that item and the item it's supposed to be supported by/laying on (like a space between a dress and a body). And yes, this takes some time to process and can even lead to the items "exploding".
Usually, it's treated by reducing the collision offset to a value that's smaller than that space between the items. Check the numbers in your "Spring (XXX)..." message to see which value you should reduce the offset to.
It can also mean that your newly-dForced item is not whole, i.e. its polygons/vertices are not connected and trying to collide with themselves as with different items, as opposed to self-collision of the same item. In this case, you'd have to connect those faces/vertices somehow, and for that, you'd need some 3d modeling soft like Blender.
As for your second question, I think I have an idea, but I'd like to ask you to upload a screenshot of that Weight Map that appears on the object after you add your own Weight Node.
Ad question 2) Apparently the PAs can save an object without the weightmap node is visible. You will first see the wieghts when you apply a weightmap node.
Technicially it is not stored as a map, but as weights
@feldarzt
Oh ? really. Didn't know that. Interesting. Given the amount of terrible dforce items on the different stores proposing Daz items, I guess this is not an obvious thing !
Although I'm not sure to understand how items such as for example "Palazzo Pants" can define that item's collision offset when pants are super tight around the ass and extra large around the ankles, and when then one Surface only for pants from top to bottom O.o
Well I'll have a look at that to verify as I can't comprehend this assertion without some testing (;¬_¬). Thanks.
Everything pre-fitting in Daz is not an issue. I've been 3D modeling for video games during the first era of PS1 when 300 quads was a lot, so I do very clean and optimized modeling. If I encounter issues, it'll be putting while figuring out an as good workflow as possible to prepare a cloth/armor, etc. once in Daz (although I know a lot about that already). But before that step there's no worry : I trust my 3D topology ;) If something goes wrong it won't be because of some nested wireframe, n-gon or unwelded vertex.
@felis
I didn't even try yet defining weightmap then deleting it and saving the cloth. It might just work. I just wanted to make sure that there was no other way to see the vertex weights than Creating the dForce Modifier Weight Node. Obviously it's useful do paint the weights. But weights will still be there even after the Weight Node is deleted. Unsettling but good to know.
All items do the analysis that can produce the spring messages - they do relate to the offset value, which is a general separation distance in the case of the spring messages it's the edge lengths in the mesh itself that are being reported - edges are treated as springs in a dForce simulation, which is working to minimise the energy stored in each spring; when the edge/spring is shorter than the offset then the spring has to be stretched, which adds more energy, which needs to be diffused across the mesh. If there are a lot of short springs it will extend simulation time to reach reset (because of the extra energy constantly being pumped in) and may simply cause the mesh to explode. Because the analysis of each edge should be quick and processing the event queue takes a noticeable amount of time in comparison the event queue is ignored until the analysis is done - that is why it can't be cacelled, and trying to interact with Studio will cause Windows to say it is not responding.
The dForce weight nodes were originally called dForce weight access nodes - I'm not sure when the access was dropped. The node doesn't own the weight map, the dForce modifier does, and so deleting it has no impact. The nodes are used because there is no selectable node for the dForce modifier, so without them there would be no way to target the weight map for editing.
@Richard Haseltine
Great ;) Thanks for the explanation. For the moment my personal imported assets are calculating pretty fast and simulate damn well. But now I understand a bit more what I will have to change and why (offset value), if/when I'm facing too long spring calculations and I want to optimize that.
I slowly manage to achieve pretty nice stuff out of 3D models I've been working on for Daz. I'm gonna make cool bundles as soon as I overcome the few technical things that are still unclear. Thanks ;)
If I get a long stream of spring warnings I cancel the simulation as soon as possible and then review to see if they are still long enough to work if the offset is reduced, if they are perahps limited to a particular area which could be excluded from the simulation (assuming it isn't already via a weight map), or if the model is potentially problematic. Letting the simulation run and having it explode will probably require a restart to get it working again.
this indeed was more understandable ;)
I found at recently that a default dForce value is often (one of) the culprit for so called explosions : Frames Per Second (FPS) Multiplier (the equivalent of Animation > Play Speed, in Marvelous Designer). This value is sto to 2 by default.
But setting FPS Multiplier to 5 or more (I tried up to 10), the simulation still runs at a good speed but causes way ! less explosions on a lot of bundles and even when the animation's too fast. Calculating at a much lower frame rate helps a lot to get proper results. It's just one of the many values that stabilizes the simulation by giving it more time to compute, and it's cool because easy to set up as it applies, being in the Parameters Tab, to everything and not just 1 surface.
Yes, I'd intended to say that but apparently lost track of my train of thought. Giving it more sub-steps allows it to do a better job of spreading the energy out, reducing the odds of explosion.
Interesting info. Thanks to the op for the great questions and also to everyone who provided answers.
Put into words so even a dummy like myself can understand please...how do you tell if they are still long enough to work?
Thanks,
Pen
If you check the log file all the messages will be there - run your eye down to see if the spring lengths are just a bit shorter than the offset; if they are you can adjust the offset; if they are much smaller then adjusting the offset smal enough may introduce other issues.
That's amazing Richard. Thanks !
Working on a tight dress, with the default :
Collision Offset : 0.20. Spring Node calculation took : 7.5 seconds.
I checked the .log file : Shortest spring had length: 0.0039
So I changed Collision Offset to something much smaller. But not too small either. New Test :
Collision Offset : 0.05. Spring Node calculation : 0 seconds, it was just instantly done !
This is amazing. So many poorly dForced clothes I got rid of, when I could have fixed them....
Thanks for your explanations.
Thanks Richard