parenting and pivot issues
Issue #217
resolved
Tested with daz studio 4.11, blender 2.90, diffeo 0a895ec
I know this is a pita, especially in relation to instances, so I’m reporting it here just for reference and to explain what the importer does. Then if it can be fixed or improved that’s great.
I did a simple robot in daz studio with some primitives parented together. Test scene included. Then below it is what we get importing with the dbz and unmorphed options.
This is the daz scene where the robot limbs are parented to the torso. Each one with its pivot.
The dbz option imports the shape right, but it loses the pivots.
The unmorphed option imports the pivots right, but the rotation and scale don’t seem to be applied correctly.
Comments (32)
-
repo owner
-
repo owner
Apparently DS and Blender treat scalings differently.
In DS, if you scale the parent (cube) along X, the child (torus) will be scaled along local X i.e. global Y.
In Blender if you scale the parent along global X, the child will also be scaled along global X.
The Daz way is strange if you ask me. It feels strange to change the X scale of the cube and see the torus grow in the Y direction.
-
reporter
Yes I agree it is odd. This means that scale is propagated from parent to child along the child local axes, that's counter intuitive. I guess some conversion is needed to fit it to the blender system. From a math point of view an easy way would be to unparent the objects in daz studio then save the unparented information and the hierarchy information, then reparent the object in blender with parent in place. But this would complicate the exporter. I'm afraid I can't help with more complex math.
-
reporter
As for the dbz option I understand it is easy this way. But the exporter could reserve this option for figures where the figure shape is baked and driven by an armature anyway so the original position rotation and scale don’t matter too much. As for props, possibly parented to an armature bone, the exporter could always use the unmorphed option so to preserve the original position rotation and scale.
An easy workaround though is to export props apart with the unmorphed option then parent them in blender. So I guess there’s no need to complicate the exporter too much.
-
repo owner
This really opened a can of worms. I spent several days on this and couldn’t figure it out, until I had the brilliant idea to check the documentation. But it was worth it, since parenting was very hackish before. There are still a few issues though.
- Armatures that are parented to a bone with dbz fitting. The armature’s child meshes are placed correctly, though.
- The robot arms are sheared. This is very strange, because I write the right world matrix to the object, but after a scene update the world matrix changes.
-
reporter
Yes that’s why I told that scale and rotation seem not applied correctly. The scale issue arises for all rotated objects. Below a second example where I rotated the primitives. The only correct transformation is for the parent cube primitive. All the childs are transformed bad. Commit 0e3c627. Scene included.
Thank you Thomas for looking into this. Unfortunately I can’t help much with angular math apart testing. I can get it right if I unparent then reparent in blender by hand so I guess this has something to do with matrices transformations not considering parenting right.
-
reporter
- attached robot-2.duf
-
repo owner
The bone parenting issue should be fixed now. It turned out that the solution was to put the pivots in the right place, so that is that. However, now the arms are sheared with dbz fitting as well.
-
reporter
As for commit 650219d the dbz option now seems to behave exactly as the unmorphed option. Below the dbz with robot-2. That’s odd since reading absolute vertices coordinates shouldn’t be affected by pivots I guess.
-
repo owner
The world coordinates are stored in the dbz file, but the vertices are shifted with the inverse of the object's world matrix, to put the pivot in the right position. This was necessary in the case that a mesh has an armature which is bone parented (e.g. head bone > earring armature > earring mesh).
The problems with the second robot is most likely the same as the sheared arms in the first one.
In order to determine the transformation, I calculate the global transformation matrix (self.worldmat), and assign it to the object's matrix_world. However, after a viewlayer update, the matrix may change. Here is a code snippet:
ob.matrix_world = self.worldmat print(ob.matrix_world) bpy.context.view_layer.update() print(ob.matrix_world)Here is the output for the original robot's left arm:
<Matrix 4x4 (-0.0919, -0.0000, 0.2083, 0.1500) (-0.0000, 0.1200, -0.0000, 0.0000) (-0.0771, 0.0000, -0.2482, 0.7898) ( 0.0000, 0.0000, 0.0000, 1.0000)> <Matrix 4x4 (-0.0747, -0.0000, 0.1819, 0.1500) (-0.0000, 0.1200, -0.0000, 0.0000) (-0.1143, 0.0000, -0.2952, 0.7898) ( 0.0000, 0.0000, 0.0000, 1.0000)>So the translation part is unchanged after the update, but the the 3x3 matrix changes. This I don't understand. The objects are created in hierarchy order, so the parent's world matrix has already been set.
-
repo owner
I asked the question on BA: https://blenderartists.org/t/viewport-update-changes-world-matrix-why/1259366
-
repo owner
And I got the answer on BA. Everything should work now.
-
reporter
Commit 938ed16 is awesome. That’s a wonderful improvement.
- tested prop hierarchies they work fine
- tested figures with parented props they work fine
There’s an issue with posed figures and the dbz option where the parented props get the pivot misplaced. Below an example with the G1F magus staff. Test scene included. Non posed figures work fine though, so if this can’t be fixed I guess we can be happy anyway. That’s really a great job.
Also there’s an issue with posed figures and the unmorphed option, where the pose seems applied only to the genesis figure and not to the outfit figures. Again non posed figures work fine. I’m wondering, since the dbz option now can correctly export the pivots, if it makes sense to keep the unmorphed options. May it be they work better with instances ?
-
reporter
- attached g1f.duf
-
repo owner
The unmorphed options are useful in some cases, so I dont want to remove them. The unmorphed shared option is useful e.g. to import a bush with many leaves. It gives you many leaf objects sharing a single leaf mesh. The unmorphed unique and dbz options give you one mesh per object, which is unnecessarily wasteful. Also, I usually import environments directly from the duf/dsf file in the Environments folder, instead of spending time exporting a dbz file from DS, and the unique option can be useful in that case.
Only the character is posed in the duf file, so that’s why the clothes come in unposed. However, it should not be hard to copy the pose to its children.
I don’t understand why the staff pivot is wrong. Have to check that.
-
reporter
As for the unmorphed shared option. Do you mean you use a single geometry for all the meshes that are the same, even if they are multiple meshes in daz ? If so could you please explain the difference between instances and unmorphed shared and the interaction between them ? I’m somewhat confused myself so I guess this could be useful to others too.
What is it supposed to happen if we import a scene with instances with the unmorphed shared option ?
What if we import with unmorphed shared a scene with both instances and multiple geometries that are the same ? And how does the plugin understand they are the same ?
-
repo owner
I don’t quite remember, but I think that materials are assigned to the object in DS but to the mesh in Blender. So if you want different materials for the same geometry, you need meshes to be unique. Typical uses:
- Unmorphed shared: Leaves in a bush, multiple objects, same mesh.
- Unmorphed unique: Posters on a wall, same geometry but different materials, must be different meshes in Blender. Not so common.
- DBZ: Something with morphs.
I would use an unmorphed option for environments, which rarely have morphs, and dbz for characters. This illustration is from the docs:
All three options refer to meshes. Instances are a different thing, something with an instancing parameter in DS, and a empty with an instance collection in Blender.
-
reporter
Thank you for the explanation. I’m not sure I get it entirely yet but it’s nice to know that instances are another thing apart.
-
reporter
As for commit 35cb3f2 it works much better with posed figures. The only thing it doesn’t seem to take into account is the main figure tranformations. Below an example where I changed the G1F position rotation and scale, the magus staff gets a wrong pivot. It’s the dbz option. Test scene included.
Changing the figure position rotation and scale may happen to pose figures into the scene. Then again these are great steps forward so if something can’t be done I guess we can be happy and just aware of it.
edit. Also in the test scene the armature bones are not properly scaled, this is most visible in the collar bones that go outside the shoulders, but they’re all the same.
-
reporter
- attached g1f-r2.duf
-
repo owner
I was working on a different file with more complicated parenting in several steps, and after that work the pivot problem was gone. The bone size issue is not strictly a bug but more a matter of aesthetics, since only the head joint and bone matrix matter for posing. In the latest commit the bone is resized after the bone matrix is set to keep the bone length unchanged.
-
reporter
As for commit 2da7996 everything seems to work fine as far as I can test. Also the bones are scaled correctly. The only issue I found is the unmorphed option fails the props location, that’s magus staff and earings. It works fine for the dbz option though. The test scene is always g1f-r2.
-
reporter
With commit 3d5d6e5 the issue above is fixed. Now everything seems good for the standard exporter. Sorry I didn’t test the HD exporter before. There it seems the HD version doesn’t get the new pivots and also fails to position the parented props. The test scene is always g1f-r2.
update. Don’t know if this is relevant, but commit a65b679 doesn’t seem to fix the HD issue for the parented props.
-
repo owner
Should work now
-
reporter
Commit e2bde57 seems excellent. It doesn’t fail any test I did so far. I get an error if I try the unmorphed option with a HD export, also the viewport colors are not used in this case, the figure seems imported fine though. Then since the unmorphed option is not supposed to be used with a HD export, this may be fine.
Please let me know if you want to fix this, otherwise I’ll mark as resolved after a few more tests.
-
reporter
oops .. I didn’t test the more obvious thing. As for commit e2bde57 this is what I get with a standard export (non HD). Test scene g1f-r2. Also the importer creates an empty G1f-r2_HD collection.
-
repo owner
Argh. Forgot to test without HD. Should work now.
-
reporter
As far as I can test commit d677406 seems to work fine. I checked a prop hierarchy, then HD and non HD figures with parented props, both with the dbz and unmorphed options.
As for the HD export actually the importer warns the user if something can’t be converted to HD. Then it adds anyway a HD copy at base resolution, but it is not binded to the armature. Below an example with the g1f-r2 scene where I pose the right arm and the HD jacket doesn’t follow.
This behavior is not wrong per se and we can easily delete what we don’t need and/or move items among collections. Nevertheless when exporting a figure it may often happen that HD and non HD items are mixed together. So may be an option to “keep base HD meshes” would make things simpler for the user. I mean if the user wants to bake normal maps then he keeps the base meshes. If the user wants the multires HD figure then he doesn’t keep the base meshes. Either way generating HD copies not binded to the armature could be avoided.
Again this is not a bug and we can easily adjust things by hand. Please Thomas let me know what you think about this, I’d mark as resolved anyway.
-
reporter
update. Please note that in the example above Earring L2 is not listed in the non HD items and it is converted to multires. This is a bug in my opinion. I mean it is true that the item can be converted to HD by the multires modifier because it has the necessary requirements, since it is a baked subdivided mesh. But it is also true that the item is at base resolution in daz studio so converting it to multires doesn’t make much sense.
-
repo owner
If rebuilding subdivisions succeeds, vertex groups are copied from the base mesh to the HD mesh. If it doesn’t, we would need to export the vertex groups from DS, but that would be extremely costly. E.g., G8F has some 230 vertex groups, mostly from the face rig, and if a typical vertex group involves one tenth of the vertices, that would increase file size and export time by a factor 20 or so, which is not acceptable. So we can only get vertex groups for HD meshes if we can recover them from the base mesh.
-
reporter
Yes I agree on that. What I’m proposing is different.
First check if the mesh is at base resolution in daz studio and if so don’t generate the HD mesh. Then if the mesh is subdivided in daz studio and the HD mesh can’t be generated by the multires for some reason, then warn the user only in this case, and don’t generated the HD mesh either since it will be not binded and it’s not useful this way. When the HD mesh is not generated we keep the base mesh that’s always properly binded.
edit. Not binded HD meshes can be useful for baking normal maps, so even if multires can’t use them for some reason we may keep them. Then a user option to “keep base HD meshes” would also provide a choice for this case.
-
reporter
- changed status to resolved
I believe commit cec2b01 is excellent as for pivots and hierarchies, and a nice cleanup as for base and HD meshes.
Marking as resolved. Thank you Thomas for this great update.
- Log in to comment
The dbz option behaves as expected. The dbz file contains the world coordinates for all verts, so the object location has to be the origin for the verts to end up at the right locations.
The unmorphed option is very strange. The transforms seem correct when you look in the parameter lists (with y-z flipped and some signs), but it is wrong the viewport.