major subdivision bug

[Alessandro Padovani]

tested with daz studio 4.12.0.86, blender 2.82a, plugin commit 4638365

There's a bug when exporting subdivision that affects exported characters in sensible areas such as eyes and teeth. We'll explain why and hopefully find a fix or at least a workaround.

Below we can see the G8F teeth at subd 1 in the daz viewport. Then the G8F teeth always at subd 1 in the blender viewport once imported with the plugin. We can see that the blender version seems to have a much smoother subdivision with rounded teeth.

‌

Now there are diffused rumors in dedicated forums that this is due to a different subdivision used by blender that's softer than daz. Well it's not. The issue is not blender or daz, it's just the plugin. We'll explain what's happening.

Below we can see a simple four poly plane in daz that I converted to subd. Even if the subd level is zero the plane is smoothed anyway. That is, it is not subdivided it's always four polys, but it is smoothed at subd zero.

‌

So what happens is that when the plugin exports a character it reads the smoothed vertices in the viewport and it exports them to blender. Then in blender the subdivision is applied on smoothed vertices so the result is a relaxed subdivision that doesn't match with daz.

Now the fix is simple. To avoid the issue we have to export the character at base resolution. That is, with no subd and no smoothing. Then once the base character is imported in blender we apply the subd modifier and we get a perfect match with daz as shown below.

‌

Now I don't know if there's a way for the plugin to read the base mesh vertices when the character is subdivided. If it is not possible then I guess it's better to warn the user that the character must be at base resolution to be exported correctly.

PLEASE NOTE. Also there's a minor issue when exporting subdivision levels. That is, the daz viewport subdivision is used as render subdivision in blender, while the render subdivision in daz is ignored. Since there are viewport and render subdivision levels both in daz and in blender, it would make sense to export them properly.

[Alessandro Padovani]

This is the four poly plane if it may be useful for tests.

[Thomas Larsson]

This seems to be difficult to fix. The problem arises when the json file for mesh fitting is exported from DS, which you can see if you open the json file in a text editor. The api has several methods to get the geometry. The script uses getCachedGeometry(), which yields the final vertex coordinates including all morphs, but unfortunately also including subdivision. There are alternatives such as getGeometry() or getCurrentGeometry(), but then you lose all morphs as well, and only get the unmorphed vertex coordinates that are already present in the duf files.

So I think that adding a warning in the documentation is the way to go. Is it ok if I use some of your illustrations?

[Alessandro Padovani]

Yes that’s what I feared for. May be one possible solution is if the json exporter can temporarily switch the resolution level to base, as the user would do himself. Then export from cached geometry, that this way would be from base vertices with applied morphs. Then switch back to high resolution. Is this possible ?

As for “my” pictures of course feel free to use them. But I hope the above solution could work since missing to export subdivision is not nice.

‌

EDIT. Also, if switching the subd is too much of a work or not possible, then the json exporter could require the user to manual switch the subd before exporting, that's a one click in the parameters tab. Then the blender addon could read the subd level anyway, that's always available in the duf file, and import it to blender.

This I guess could be a good compromise. Though it requires some work from the user.

‌

[Alessandro Padovani]

Also tested with blender 2.79. Exporting to base resolution works fine there too.

So a quick workaround would be:

1) In DAZ Studio load the scene, select all, use the parameters tab to change everything to base resolution. DO NOT SAVE THE SCENE.

2) Export the json, this way the json will be at base resolution, while the duf file will maintain the original subd levels.

3) Import in Blender and everything should be ok.

The plugin still needs to fix the subd levels as reported in the PLEASE NOTE above.

‌

[Alessandro Padovani]

As for commit 244ed0a this is what I get if I try to import any figure, from an outfit to G2F to G8F etc. I mean a normal import without the workaround above. It seems I can import subd props fine though.

Traceback (most recent call last):
  ..
  File "C:\Users\Alessandro\AppData\Roaming\Blender Foundation\Blender\2.82\scripts\addons\import-daz\files.py", line 74, in parse
    asset = self.parseTypedAsset(gstruct, Geometry)
  File "C:\Users\Alessandro\AppData\Roaming\Blender Foundation\Blender\2.82\scripts\addons\import-daz\files.py", line 247, in parseTypedAsset
    asset.parse(struct)
  File "C:\Users\Alessandro\AppData\Roaming\Blender Foundation\Blender\2.82\scripts\addons\import-daz\geometry.py", line 251, in parse
    self.SubDIALevel = cstruct["current_value"]
KeyError: 'current_value'

location: <unknown location>:-1

‌

[Thomas Larsson]

Sorry, should have tested with more than just the planes. Should be ok now.

[Alessandro Padovani]

Commit 289fba8 seems to work fine, also the workaround seems to work fine. I believe this is enough since it requires very little from the user. Just some notes in the documentation to explain things would do fine I guess.

Marking as resolved.

[Thomas Larsson]

There is some progress on this issue. The export script now temporarily sets SubD level to zero and the SubD algorithm to Bilinear. This makes the test square export correctly, but I still have problems with other meshes.

[Alessandro Padovani]

going to check it out ..

[Alessandro Padovani]

Well it seems I got it. It was pure luck though since my programming days are far away and the daz documentation is hell. Plus I never got into daz scripting before.

I had to use forceCacheUpdate() in the doMesh() function to update the mesh. Below it’s an extract of the source in the relevant section. I also had to pass the node to doMesh() instead of the node name. Please Thomas do check my code since I rushed it out and I do not know if it introduced bugs.

function doMesh (fp, obj, start, node, str1, str2)
{
    var shape = obj.getCurrentShape();
    if (shape == null)
        return false;

    // Set subd algo to bilinear (1)
    var subdlevel = shape.getSubDDrawLevel();
    var subdalgo = shape.getSubDAlgo();
    var levelctrl = shape.getSubDLevelControl();
    var algoctrl = shape.getSubDAlgorithmControl();
    levelctrl.setValue(0);
    algoctrl.setValue(1);

    // update mesh
    obj.forceCacheUpdate(node,false);    

‌

As a side note I don’t like too much changing the subdivision level and algorithm. It would be better to change the resolution level though I have no idea how it can be done. About this I asked for help in the daz forum may be someone will jump in.

https://www.daz3d.com/forums/discussion/399371/how-do-we-read-set-the-resolution-level-via-script

Also I find a little odd to cycle for the whole set of scene nodes in the main loop, since this will access every single bone in every character. Then I understand the selectors filter them out but it’s not too elegant. May Be the main loop could use getDataItemList() instead.

[Alessandro Padovani]

full source attached

[Thomas Larsson]

I think I nailed it now. The key hint was your picture in the daz thread, where I noticed that the resolution level is really called lodlevel, and there is a function that gets the LOD control.

[Alessandro Padovani]

Thomas you’re too fast .. They also replied with some examples in the daz discussion above just in case it can still be useful. Going to check the new commit ..

[Alessandro Padovani]

As for commit a1dacf1 both the old script and the new one seem to work fine. Marking as resolved !

edit. note. See #593 for more subdivision features.