dforce error and daz settings

[Alessandro Padovani]

I was curious to try the “daz settings” in the simulation options to see how they work. But I get an error.

steps:

1. check “daz settings” in the simulation options
2. import dforce-4.duf in #410

‌

‌

[Alessandro Padovani]

Thomas could you also add the collision distance to the global settings please ? I’m doing tests and I see that this really makes a difference. For tests it is faster to reimport and run the simulation rather than changing all the values in all the objects.

Or we may add a tool to change the simulation parameters. I mean, we can do presets but not for collision. So a tool same as global settings to affect the whole scene or multiple selections would be handy.

[Thomas Larsson]

Fixed in last commit. Note that if you try daz settings the collision distance is given by the duf file and not affected by the global setting.

[Alessandro Padovani]

Commit b4d48bf works great, and the daz settings seem good too on a first try. Thank you Thomas for the fast fix.

[Alessandro Padovani]

Thomas, I see the collision distance in the global settings doesn’t affect deflectors, it only affects cloth. Since this is intended to be a global parameter it makes sense that it affects all the collisions, including deflectors. Or we may add another global parameter for the deflectors distance.

[Alessandro Padovani]

Then some basic notes about the “daz settings” option, that you may also add to the docs for the user to be aware of.

1. It seems the daz density is converted as vertex mass = gsm / 100. Just as a warning note, this makes little sense because the conversion depends on the vertex density, that may differ largely from mesh to mesh. And also on different parts of the mesh so in general it’s not possible to convert gsm to vertex mass. Then this may make sense for the daz garments if they tend to use a similar vertex density.
2. In daz the simulation parameters are per surface, while in blender they are per object. So I presume the first found surface parameters are used for the blender simulation. Then again this may make sense for the daz garments if they tend to use similar parameters for all the surfaces.

edit. The two notes above, other than the simulation inherent complexity, are the main reason why personally I went for presets rather than trying to convert the daz parameters.

[Alessandro Padovani]

@Thomas Larsson , as for commit d7db89f, the decision of giving up to dforce simulations was unexpected. I rather hoped for it to grow in time possibly with the help of the daz community. I saw the dependency loop but it is just a warning and things are working anyway. My idea was to try with collision collections but didn’t have time to play with it because I rather looked at the hair issues #467 #468.

I mean, to import physics attributes is the same as importing materials or rigs or animation or any other type of data. So we can import cloth and collisions too, and possibly wind. Then I agree there may be tools to better handle it as there are materials and rig tools. But not importing anything and leaving it to the user to recreate the dforce attributes for the whole scene is another thing.

Sure the user can do it alone with the blender tools. We can use the blender simulation instead of importing dforce, the principled shader instead of importing daz materials, rigify instead of importing the daz rig, or use bhv instead of importing the daz animation. If you follow this philosophy then you end up with a obj importer for the mesh and the main textures.

So would you please get back the dforce option ? Personally I believe there’s space to import physics attributes, then we can improve things over time as we do with anything here.

But the decision is yours of course. Let me know what you think so eventually I’ll close this one.

‌

edit. To explain it better, that may be I’m not clear. The idea is not to fully import dforce parameters that we see it’s not always possible as explained above. But rather to import the main dforce structure, that is, the physics types. So we know what’s cloth and collision and wind for example, with the main parameters if possible and/or presets. Then the user can start tweaking from there with the dforce tools, starting from a scene that does have the physics attributes imported.

[Thomas Larsson]

Creating the simulation modifiers during import creates problems, or at least warnings about dependency loops in some cases. I agree that importing simulations is nice, but creating the cloth and collision modifiers at that time is too early. In the last commit dforce information is stored in the mesh objects, and the entire simulation can be restored with the Make Simulation button. So this involves one extra step.

Note that this is quite similar to what we do with hair. Converting the mesh hair to particles during import leads to problems, e.g. if we merge geografts, and therefore the conversion is postponed to the final stage. We could add simulations to the easy import though, to be done as the last step.

Dependency loops arise when you make the simulation for dforce-4.duf. It is something about the top and skirt collision modifiers fighting each other.

edit: If one wants to use the simulation parameters from DS, those could be stored in a collection property during import for later use.

[Alessandro Padovani]

Thank you Thomas, commit c4fd9ad works fine for me and I like the new tools. I’ll mark this one as resolved and eventually open other separate discussions for improvements. Also to make the fixes manageable.

As for the dforce values, you may add an option to use them instead of the presets. In my opinion as I explained above this doesn’t make much sense since gsm is not convertible and dforce values are per material instead of per object. But if these limitations are documented to the user then it’s one more possible choice.