Idea: Convert to Rigify, keeping original DAZ rig linked to Rigify one
Issue #1528
resolved
When converting DAZ figure to Rigify there’s an option to “Keep DAZ rig”. That works fine.
It could be useful to have each bone of the original DAZ rig “linked” to the corresponding Rigify bone (DEF, ORG or whatever) using a bone constraint “copy transforms”.
This way, whenever the Rigify rig is posed or animated, the original DAZ one follows and one can export to game engine baked poses and animations using the original DAZ rig.
I tried to study the sources to implement this by myself but didn’t find a way to.
Comments (59)
-
-
- marked as proposal
-
- changed status to open
-
p.s. Anyway “save pose preset“ in the posing panel already bakes the mhx/rigify animation to the daz rig. You can then load the saved preset to the daz rig in daz studio or blender, that’s basically what you’re asking for. So this is already implemented though it requires an additional step.
-
repo owner
Almost all genesis bones are deform bones (except hip and G9 arms and legs), so I suppose one could generate copy transforms constraints instead of renaming vertex groups. Bend and twist bones don’t have the same rest position though, that might complicate things.
-
reporter
I investigated the source code to understand where and how the DAZ original bones are used to create the rigify rig but without success. If you could give some hints I can help, perhaps.
I’ll see the part that “save pose to preset”, perhaps I can find something
-
May it be this is not convenient for performance reasons ? I mean if there’s a lot of constraints to evaluate it may slow down the rig too much.
-
reporter
That’s true but the rigify rig is a pain from Game Engine point of view. Beside, if you rigify a daz figure and then you try to “Import Action” with the importer some bones (specifically the feet toes are not imported anymore.
-
But you have to import action on the daz rig. That is, you keep the daz rig when rigify, then import action back to that.
-
reporter
Consider this scenario:
- DAZ figure imported in Blender
- Worked on it to have the right shapekeys and materials for game engine.
- Converted to Rigify to animate.
- I have various animations done originally in DAZ Studio. I want to use them in NLA with animations done with rigify.
As you say, I can import to the orginal daz rig but I need to be able to combine in a single rig both animations, those done in DAZ Studio and those done with rigify in Blender.
That’s the reason of the idea proposed. If the orginal and igify rigs remain “linked” by bone constrains I can work seamlessly in DAZ Studio or Rigify without problems (or it’s only a matter of baking animations)
-
While on this topic--would there be a way to as LazingInTheHaze says, ‘link’ the original rig to say the rigify metarig so one can regenerate rig if needed? For instance, if one wanted to somewhere down the line edit the metarig or add a feature set and then regenerate it instead of having to import the model all over again, it would be very useful. As far as I know right now, once setting up the Rigify rig, it is a destructive process in the sense that you can’t go back (except with undo action of course). If you select the metarig and then try to regenerate (even if you keep the Daz rig), it says “Original Rig not found.” Unless of course there is a technical reason for this--correct me if I’m wrong.
-
You have to distinguish between rigify IK animations and NLA strips aka baked FK animations. Once you get a good animation with rigify you can bake it and save the pose preset. Then you will use the NLA strips on the daz rig, not on rigify. That is, rigify is the tool that you use to create animations, but once they’re done you have to bake them to NLA strips and use the daz rig.
steps:
- do your animation with rigify and save the pose preset
- import back the pose presets to the daz rig as NLA strips, you can mix both daz and blender animations this way
You may also want to try the simple IK rig which uses directly the daz rig for the deform bones, so it is more precise when you bake. Also it is much easier to customize as needed, and you don’t need to drive a separate daz rig since it is already there.
I guess the simple IK rig is the way to go for games, instead of rigify. See
#1521for an example.
-
repo owner
I implemented this in the last commits, and it works reasonably well. Enable the Keep DAZ Rig and Use DAZ Rig For Deform options when rigify is generated. The daz bones copy the rigify DEF- bones, because that is the lowest level and also because the plugin already keeps track of those, in order to rename vertex groups. Which of course doesn’t happen if the daz rig is used for deform.
The match is not perfect, because genesis and rigify have different bone structures. The spine is particularly problematic. In particular, the genesis hip and pelvis point downward, whereas rigify DEF-spine points up. I tried various ways to setup the copy constraints, and the current setup gives a reasonable match. If somebody has a better suggestion I would be interested to hear about it.
There are also two new buttons in the Posing panel. Bake DAZ Rig bakes the rigify pose to the daz rig and disables the constraints, so you now have a proper pose for a daz rig. Unbake DAZ Rig does the opposite: clear the pose and enable constraints.
-
repo owner
I have only tested with G8F. There will probably be problems with G9, but this is enough for today. It should also be possible to do the same thing for the mhx rig, which might give a better match since it is not so far apart from the original daz rig.
-
repo owner
With the latest updates this feature is probably more or less complete. It works both for mhx and rigify. For mhx it works well, for rigify less well, and in particular the results for G9 are poor. The reason is that the mhx bones are close to the daz bones, but the rigify bones differ as shown for the spine above.
The bake buttons have been renamed to Bake/Unbake Copy Constraints, which better describes what they do.
-
As explained above, there’s always the alternative to save pose presets and load them back on the daz rig. Though this requires an additional step.
As for the conversion quality, do you think that using pose presets would be better than constraints, or are they similar ?
-
Commit 267ac83.
bug. optimize pose. Just tested rigify with optimize pose for ik and the daz rig, below it is what I get that doesn’t seem to work, unless I miss something.
steps:
- import G8F and merge rigs
- convert to rigify with optimize pose for ik and the daz rig
p.s. I suspect this can happen if you apply the rest pose to the def bones, that if we keep the daz rig should never be done.
-
bug. toes deformations. If I use improve ik instead of optimize pose then it seems to work better. But the toes are not weighted right. Also the pectorals are flatted down.
steps:
- import G8F and merge rigs
- convert to rigify with improve ik and the daz rig
-
reporter
Fantastic support!!! Thomas you’re great!!!
I’ll test all as soon as back to office and let you know.
-
update. toes fix.
The distortion with the toes can be fixed by using the local coordinates system to copy rotations. Also I’m not sure it is a good idea to copy locations too, but if you want to then you may use copy transforms instead to get it all with one constraint.
-
repo owner
Copy location constraints are now only generated for the hip and for face bones without location locks. The latter is needed for facial poses.
Face bone copy constraints are now local.
The toe bone is problematic because for some reason the roll angle changes from the metarig to the rigified rig (-112 and +66, respectively). Just making the toe constraint local would therefore make the genesis toe go in the wrong direction. The X an Z directions are inverted to fix this.
-
Commit c761a98.
bug. optimize pose. This is not fixed as explained above. If we use the daz rig then the mesh must not be rested to the def bones when rigify is generated.
bug. ik targets. The ik targets should have copy transforms to keep the position, this may introduce some compression for the joints but at least the target is preserved so we avoid feet slidings. Also ik stretching will work fine this way, otherwise it doesn’t.
design flaw. rigify pivots. I see there’s a misalignment between the daz and rigify bones, that’s required for ik to work fine. But in this case the pivots are changed that’s not good. With the simple rig we use a similar technique for ik but we keep the pivots, that works better when dealing with the daz poses.
This may also contribute for subtract rest pose not working fine with rigify.
-
repo owner
Optimization now comes before the daz rig is save, which means that it is baked into the rest pose. This also seems to fix the pivot issue.
As for IK targets I don’t understand what you mean. The daz rig doesn’t have ik targets, unless it has simple ik and then it cannot be converted to rigify (the plugin should check fo that because now it crashes). If you mean that the feet should copy the location of the rigify feet then I disagree. It will lead to some very ugly deformation which is far worse that sliding feet.
Rigify is not well adapted to the daz rigs, which leads to problems if we want to export a rigify animation out of Blender. That happens both if we save a pose preset for DS, or if we tie the daz rig to rigify and then export the animation as an FBX file, say. MHX gives much better results, because its deform bones are essentially identical to those of the underlying daz rig.
-
Commit 7fdea0f.
The optimize pose bug is fixed.
As for the ik targets yes, I mean the bones used as targets in the IK rig should copy locations too to avoid slidings and for stretch to work fine. As for the “ugly deformations“, that depends how we deal with pivots as noted above.
If we keep the pivots and copy rotations as local, then it doesn’t matter if there’s some difference in the bone orientation because the rotations will be relative to the rest pose. What does matter is that we keep the pivots. This way we can connect bone chains on the rigify and mhx rigs to be compatible with IK, then use the connected bones as deform bones to copy rotations from. This is done in the simple ik rig for example and that’s why it works fine.
Below an example where I connected the bone chains on a clone then copied rotations as local. The bone orientations are different but the mesh overlaps perfectly. That is, the pose is the same.
Let me know if something is not clear.
p.s. Basically what I am saying is that you should use the connected daz bones for the metarig, so we keep the pivots.
-
reporter
Made first tests with MXH.
-
In Setup/Rigging/Convert to MXH: all seems working perfectly. Copy constraints are created. Meshes (also those of clothing) are correctly deformed by original DAZ rig. Posing MHX rig correctly deforms the meshes through bones copy transforms.
- Little glitch: I would recommend to keep the original name for the Original DAZ rig and rename instead the created MXH/Rigify ones adding respectively _MHX and _Rigify suffixes to their names.
-
Importing a pose to MHX Rig using Posing → Import Pose has problems with lHand and rHand Daz Rig bones. It seems the Local Space isn’t enough to copy pose from MHX rig to DAZ Original.
-
If I change to World space in Copy Rotation hand0.L hand pose is correct.
-
But some problems remain in the weird deformation in wrist (see image below: same pose in daz):
-
-
-
-
reporter
More investigation on the wrist deform issue. Driver of JCM is linked to Local space rotation of lHand bone. So changing copy transform to World space isn’t correct, should be Local Space!
So, something should be find when importing the pose to MHX rig: perhaps the importing process set the world space for lHand and rHand bones instead of local space.
-
That’s exactly the ik target and pivot issues I noted above. For rigify they are more evident. To simply test for feet sliding you can animate the hip in mhx or the torso in rigify. You will see that feet (as well as hands) don’t keep their position because ik targets are not locked. Though pose/world space rotations are better, you need a full copy transform in pose space for the targets to work fine.
Of course if you compare with daz be sure to import jcms.
-
reporter
JCMs are imported and working. The fact is that the JCMs are driven by rotation in local space, that is set to zero for lHand and rHand bones.
-
Nope, if you look at the shape keys the hand jcms work fine even with pose/world space. I believe the issue is with the pivots that are not the same for daz and mhx/rigify. That is, the jcms work fine but produce a different deformation because the pivots are not the same. That is, for jcms to work fine we need to keep the pivots.
If you look at the simple ik rig where the pivots are the same the hand jcms work and deform fine. With mhx/rigify they work fine but don’t deform fine.
Unless there’s some other reason ruining the jcms that I am missing.
-
reporter
I found that same myself; but if you inspect the driver, you’ll see that the formula depends on a property of the armature ((["pJCMHandUp_80_L(fin)"] for example))
If you search for pJCMHandUp_80_L property in the LiHRig (this is the rig name in my case), you’ll find:
As you see the x rotation is taken in Local Space.In the case of the pose I tested, the local space rotation of hand.R is all zeroed, because I think that bone gets the rotation from it’s parent.
-
reporter
One question: the meshes are deformed by the Original DAZ rig, but the JCMs drivers are still linked to the MHX/Rigify rig. Is this correct?
-
No it isn’t, the jcms are to be driven by the daz rig if we keep it. This is probably the culprit, or anyway a contribution to wrong pivots.
Let’s wait for Thomas to look at this.
-
repo owner
Some progress but right now I’m stuck on the driver issue. The mhx hand should work now, and the rig names have been changed as Lazing suggested: the mhx rig ends with _MHX and the original rig does not have a suffix.
When the mhx rig is generated shapekeys are driven by the mhx rig and work as expected. Here I moved the ik foot up in order to bend the left thigh.
The Bake and Unbake copy constraints buttons takes care of driver retargeting. Now the daz rig thigh gets a local rotation, but for some reason the driver does not detect it. Why???
-
repo owner
Got it. There is a checkbox called Driver in the driver.
-
repo owner
Now the drivers are enabled and work as expected after the constraints have been baked.
-
Thomas, as I see it the jcms are already working in the daz rig when we create mhx or rigify, so there’s no point transferring them. That is, mhx and rigify should just drive the daz bones, then the jcms will follow on the daz rig. This is also how simple ik works.
Unless I misunderstand what you’re doing.
-
reporter
Perhaps Alessandro is correct. If, while creating the MHX/Rigify rigs, the user asks for keeping and original daz rig and have it driven by the MHX/Rigify one, than the jcms drivers should remain linked exclusively to the daz rig bones. No need to change them with Bake and Unbake buttons.
-
Commit 99746c3.
Tested both mhx and rigify but it doesn’t seem to me that the issues are fixed. The hand jcms don’t work and the ik targets neither.
steps:
- import G8F and merge rigs, then import jcms
- convert to mhx or rigify keeping the daz rig
- test the hand jcms by bending the hands
- test the ik targets and ik stretching by moving around the hip or torso bones
-
repo owner
Now the jcms are always driven by the daz rig. That it didn’t work before was because the internal rig drivers were disabled.
It seems that I can get away with using copy transforms constraints in world space everywhere for mhx, which does away with foot sliding. Unfortunately, that cannot be done for rigify. The daz spine bones must have local copy rotation constraints because it is different from the rigify spine, and if I start using copy transform for the limbs there will be an ugly transition somewhere.
-
Thomas, copy transforms in pose space is only needed for the ik targets. The other bones should have the pivot fixed and copy rotation in local space. The “ugly transition” you see in rigify is because you don’t keep the pivots. Please see my explanations above.
Or let me know if I miss something.
Commit a6b2bb3.
The ik targets work fine. The jcms work but don’t seem to have any effect on the mesh.
update. jcms fix. The jcms don’t affect the mesh because they are muted. It is needed to enable them as also reported below by Lazing.
-
reporter
Tested new handling of jcms drivers. It seems that conversion procedure leaves the drives disabled on mesh.
-
repo owner
Shapekey drivers are now enabled.
The crucial problem with rigify turned out to be the pelvis bone. When the copy constraint on the pelvis was removed completely, things fell into place. The rigify copy constraints are now:
The spine and face have local copy rotations. The face also has local copy location for the face rig to work.
The arms, legs and fingers copy rotation in pose space. That leads to a transition between local and pose spaces at the shoulders and thighs, but I didn’t detect any ugly deformations there.
The twist bones have local copy rotations.
The hands and feet have copy transform constraints in pose space to avoid sliding.
-
Commit 2942cdd works fine here both with mhx and rigify. Thank you Thomas for the nice fixes and all your patient work.
I still believe that you should preserve the pivots for the rig to work better also with daz poses, but didn’t notice any “ugly“ effect. The simple ik rig preserves pivots. If Lazing has nothing to add we may mark as resolved since the daz rig works fine enough now.
-
repo owner
The pivots are preserved, it’s that the default rigify pose is not rest pose. If you put both rigify and daz in rest pose the pivots should be the same.
-
Yes I can confirm that, so the pivots are fine. Thank you for the explanation.
-
Commit 2942cdd
update. pivots bug. The pivots are preserved, but they don’t copy in local space. Below you can see the difference, where the thigh is copied in local space it aligns fine, where it is copied in pose space it doesn’t. This is because, as explained above, when we preserve the pivots the bone orientation may change, so we need to copy in local space that’s relative to the rest pose. This way the pose is preserved.
All bones should be copied in local space, apart ik targets that should be copied in pose space. Unless I miss something.
-
reporter
Quickly tested last commit.
JCMs are ok. Importing action to MHX rig from duf files is ok. Importing pose to MHX rig from duf is ok. Movements seems all ok.
One little note. If you set “not visible” any mesh deformed by the Daz rig before converting to MHX/Rigify (Keep Daz Rig on, Use Daz Rig for deform on), the hidden meshes remain deformed by the MHX/Rigfy rig instead of remaining on the original daz rig.
Baking copy constraints appears to be very long for a 180frames animation, but that’s not a problem.
-
The baking should not be needed. That is, you can bake with the blender tool instead that’s probably faster. Select the daz rig then bake.
object > animation > bake action
-
repo owner
Using local space throughout doesn’t work fine. In particular, something happens at the shoulders which changes the pose of the entire arm. You can see that yourself if you change the spaces for the shoulders.
-
Being able to add/remove a control rig (Rigify or MHX) to/from the daz deformation armature can be a great advantage.
- It could allow a basic character to be rigged, and clothing and accessories to be applied afterwards, using the “change armature” or “merge rig” tools, because the daz armature is preserved. While preparing a character, this would remove the pressure to load up with all imaginable clothing, hair, accessories prior to finalizing the character, as there would always be the option to add those later without having to redo the final control rigging.
- It could also allow MHX or Rigify control rigs to be swapped out after baking animation to the daz armature, depending on the use case.
In Maya, HumanIK works like this. It is essentially a control rig system which constrains the deformation skeleton non-destructively, but it can also be dissociated if no longer needed, once animation is baked to the deformation skeleton.
It is good to have all the JCMs and other driven morphs running off the daz deformation armature to keep all the animation non-destructive to the original rig.
The RigOnTheFly project for Blender takes the flexibility of this philosophy to an extreme, which might make it more complex to use, but it might be interesting to examine.
The daz rig is really weird because the pivots do not line up and the limbs are not coplanar, making IK very difficult to implement, if original JCMs are to be preserved. I have always wondered whether daz have done this deliberately as an obstacle to interoperability. They obviously use their own proprietary IK solver for keeping limbs articulating anatomically and achieving seamless snapping of IK to FK within DS.
Thanks for all the hard work on these tools which somehow make daz rigs more usable.
-
repo owner
Alessandro, thank you for reminding me of the bake action tool. My baking implementation was very slow, because it set the world matrix for each bone, and a scene update was needed to get the local matrix before doing the same thing for children. However, I still think that the custom baking has some merit, since it disables the copy constraints. Therefore I reimplemented it using the built-in Blender tool.
-
reporter
I’m testing deeply the workflow of mixing DAZ Original and MXH animations.
I must say that the “Bake Copy Constraints” and “Unbake copy constraints” commands are a bit confusing. I lost and messup involuntarly various actions: I really don’t know how happend nut I found my self with two different actions made on the MHX mixed and “merged” inside what I thought were two different actions in the DAZ rig.
I think that the best way (also simpler to understand) should be to rename the buttons to “Mute copy constraints“ and “Unmmute copy constraints“ (the button will respectively mute and unmute the copy constraints) leaving to the user the baking of the current animation to a new action.
What I try to say is that if the DAZ original rig is the one to be used in the game engine, the user should be able to bake what is done with MHX/Rigify to new actions, then mute copy constraints, play exclusively with DAZ rig, importing other animations, correcting the ones baked from MHX/Rigify rig, creating NLA strips etc; whenever is needed, the user can Unmute the copy constraints, create a new animation with MHX/Rigify and start over with a new baking to DAZ Rig.
-
repo owner
Some polishing:
- Baking is now optional.
- Better action names.
- There is an option to bake shapekeys to actions, too. If you export the baked animation to a game engine, I suppose that drivers won’t work, so shapekeys would be lost unless there is a separate actoin for those.
-
reporter
For point 3; as far as I tested it, if I bake the animation to an action to the DAZ Rig using the bake command of blender and then export/import to unity, shapekeys animation is correctly imported. Since the shapekeys are driven by the bones that are animated, Blender is smart enough to create the animation also for the shapekeys.
-
I’m not sure to follow. The blender baking tool doesn’t support shapekeys see
#1535. Unless you mean that the unity exporter deals with that. -
reporter
This is what I’ve done.
- Created an action with MHX rig (having Original DAZ Rig controlling the mesh, with copy constraints and with drivers for JCMs linked to Original DAZ Rig bones.)
- Selected in Object mode the DAZ Rig
-
Activated Pose Mode with DAZ rig selected
4. Used “Bake Action”
5. Exported FBX to Unity excluding mhx rig
In Unity I can see the animation correctly and also the animated BlendShapes (Unity name of Shapekeys): the numbers in the figure below change continously.
-
Ok. I believe it’s the fbx exporter that bakes shapekeys.
-
Issue
#1535was marked as a duplicate of this issue. -
- changed status to resolved
- Log in to comment
I never went too deep into how rigify/mhx are handled to fit the daz rig. Also because I’m not good at rigging. But my own vision would be for rigify/mhx to just add a IK layer to drive the original daz rig as the deform and jcms bones. I guess the plugin already does something like that for what is possible. The simple IK rig certainly does.
We can of course always use a retargeting tool from rigify/mhx to the daz rig.
But I’d be interested myself to hear from Thomas why it is not possible or convenient to keep the original daz rig as deform bones for rigify/mhx.