duplicated objects don't work

[Alessandro Padovani]

daz studio 4.15.0.2, blender 2.91.2, commit d4c1572

It seems duplicated objects in daz studio can’t get their materials in blender. That is, if I duplicate an object in daz studio then change the materials, the duplicated materials are not imported. This may be a problem for scene files using duplicated objects.

I tried both with dbz and unmorphed unique. Test scene included.

steps

1. make a cube in daz studio
2. duplicate and change the cube color
3. import in blender

Below the test scene first in daz then in blender. In blender both the cubes are blue that’s the color of the first cube in daz.

‌

‌

‌

[Thomas Larsson]

This will take some time to fix. It reveals a basic design flaw, where materials are associated with geometries (= meshes) rather than nodes (= objects).

[Alessandro Padovani]

The odd thing is that if I duplicate figures instead of props, then everything works fine. Below an example where I duplicated a G1F and applied different morphs and materials to the duplicate. The scene imports fine in blender both with dbz and unmorphed unique, where of course unmorphed has no morphs.

Test scene included dupli.duf

‌

edit. As a further test if I convert the G1 figure to prop (edit > figure > rigging > convert to prop), then duplicate and change colors, it breaks again and the duplicate material is lost in blender. So it seems figures work fine while props don’t.

[Alessandro Padovani]

I believe I got it. The issue is not if it is a prop or a figure. The issue is if it is a custom object stored locally in the scene, or a support asset stored in the daz library. Indeed if I save the cube as a support asset then I can duplicate it and change materials and it will work fine in blender.

So this is an issue only for objects stored locally in the scene, while support assets work fine.

I included the test scene cube-2.duf, since the scene uses a support asset it is included as well and you have to install it as a common daz package, that is, unzip the package in the daz library.

steps

1. make a cube in daz studio
2. save as support asset (file > save as > support asset > prop)
3. clear the scene and load the cube from the daz library, that’s the support asset we just created
4. duplicate and change the cube color
5. import in blender

‌

[Alessandro Padovani]

the cube-2 test scene with the cube support asset

[Alessandro Padovani]

Thomas I don’t know, we may mark this issue as resolved or invalid, and make it clear that the plugin is intended to only import support assets. So if the user wants the scene to be imported fine in blender then he must be sure it only contains support assets, that is, assets loaded from the daz library.

On the other side daz studio also creates local assets silently, for example when we fit clothing to a different generation, as a G3 outfit to a G8 figure. Or when we create a primitive as in the cube example. So it may not be easy for the average user to understand when the scene only contains support assets, or when there are some local assets too.

Or make it clear that support to local assets is limited so issues may arise.

[Thomas Larsson]

No, it is definitely a bug, but I think it may be solved now. Instead of storing the materials in the geometries, they are now stored in the geometry nodes. It was easier to change this than I thought. The tricky part was to make this work with geometry shells, but I have a number of test files and they come in correctly now.

[Alessandro Padovani]

As for commit c1d8b16 it seems to work fine for duplicated props. But it seems to fail my test with shells. That is, I created a cube with a shell then I duplicated it. The two cubes are imported fine, but there’s an error on a missing uv set, and the shell nodes are created but not used in blender.

The same happens with a more complex scene, for example using G1F converted to prop instead of a cube.

steps

1. make a cube in daz studio
2. make a shell for the cube, this will create a hierarchy with the cube as parent and the shell as child
3. duplicate the cube with the shell (edit > duplicate > node hierarchies), then change the shell colors
4. import in blender

‌

‌

‌

[Alessandro Padovani]

duplicated cube with shell

[Thomas Larsson]

Think it might be working now. I have imported quite a few files with shells and they seem to come in right.

[Alessandro Padovani]

Commit e5d0ab1 seems to work fine, but there’s something odd with the shell group.

In my example above dupli-shells.duf I used a daz default shader for the shell, that’s formally correct but not practically used. That is, daz artists tend to use the uber shader for the used shell materials with visibility on, and the default shader for the unused shell materials with visibility off.

Now I provide another test dupli-shells-2.duf using the uber shader for the shells and some textures on the cubes to better show the shell transparency. What happens is that, inside the shell group, a daz translucent group is generated for the eevee output, with zero fac but not pruned, and plugging the cycles output into the eevee output. Though there’s no visible issue in rendering since the translucent group gets zero fac so it doesn’t contribute.

‌

‌

[Alessandro Padovani]

shells with uber material

[Thomas Larsson]

The translucent group shouldn’t be there for sure, but are you sure that it is connected to anything? I mean before you touch it. Since it is located on top of several links, Blender tends to create new links at random once you move the node.

Anyway, I will make sure the node is not generated.

[Alessandro Padovani]

Sorry it is my fault, I must have touched the daz translucent group some way. It is not connected.

[Thomas Larsson]

Btw, do you have an example of a node with multiple geometries? In DS, it seems that nodes can have several geometries, since the “geometries” field is a list, like this:

  "id" : "pCube(11cg000)1-2",
  "url" : "#pCube%2811cg000%291",
  "name" : "pCube(11cg000)1",
  "label" : "Cube",
  "geometries" : [
      {
          "id" : "geometry-4",
          "url" : "#geometry-2",
          "name" : "shape",
          "label" : "shape",
          "type" : "polygon_mesh"
      }
  ],

However, I don’t have any example where this list has more than one element, and I would like to make sure that the plugin can handle this case. It would correspond to a Blender object with multiple meshes.

[Alessandro Padovani]

Sorry I have no idea why geometries is a list, personally I can’t find any example with multiple geometries inside the list.

As for commit 70dec56, if I import dupli-shells-2.duf with the principled option, then a unconnected gamma node is generated inside the shell group.

‌

Also I’m a bit confused about the shell influence and displacement nodes.

As for influence I suppose it’s visibility and cutout opacity. But visibility is either zero or one and invisible shells are not generated. So why two values ?

As for displacement I suppose it’s mesh offset, but since we don’t use a real geometry it should only be used to compute the overlay order, that is, the mix order when there are multiple shells. So again I don’t understand what displacement is for and why there are two values.

edit. p.s. If you’re using true displacement to sort out the shell order, instead of sorting the mix order, then displacement doesn’t work with eevee. But you could use a displace modifier instead that works on the geometry, so it works both for cycles and eevee. That is, if I guess what displacement is for.

p.p.s. Either way shells in daz studio are extra geometry and the visible shell areas are not connected to the underlying mesh. So using displacement is not really the same thing. Below an example where I exaggerated the shell offset to show it better. It’s a shell with visibility on for the torso material.

p.p.p.s. I’ll open a separate issue about shells since I see there are bugs.

‌

[Alessandro Padovani]

this is resolved, the shell issues are reported separately in #379