Operations Requiring Daz-Specific Bone Names Fail

Issue #1174 resolved
Midnight Arrow created an issue

Diffeo 1.6.2.1186

The “Convert Prefix to Suffix” button alters bone names so they can be used with Blender’s symmetry options. However, this breaks Simple IK and Save Pose Preset, which require the original Daz name. Therefore it is impossible to create a walk cycle (which requires symmetry) and then export that back into Daz Studio as a series of poses.

Bones should store their original Daz name. Diffeo operations should reference that instead of the current bone name inside Blender.

Comments (12)

  1. Thomas Larsson repo owner

    FK-IK snapping with the simple rig has been fixed. Save Pose Preset already did the conversion, since it was necessary for the mhx rig too.

  2. Midnight Arrow reporter

    It works alright, but now the X-mirrored posing has problems because of another issue with the pole targets. Sometimes if IK is snapped the pole targets are at a 30-45 degree angle to the elbow. Flipping the pose puts them at the other angle, so the elbows don’t turn the same way.

  3. Thomas Larsson repo owner

    IK snapping used to ignore the pole targets completely, so they stayed whereever they were before snapping. Now the pole target is put in the plane defined by the fk bones, which is the same method as is used by mhx. This doesn’t snap the ik bones perfectly, probably because the ik chain has more than two links, but it is approximately right.

  4. Alessandro Padovani

    I am not a rig expert, but I feel it is normal that snapping ik to fk may require to fix the poles by hand for some poses. I mean unless you find a way to automatically pose the poles to always match the fk pose that personally I couldn’t imagine how to do that.

    Or you could use the simple rig without poles and use the fk twist bones to pose the elbows/knee.

    edit. oops .. wrote before the reply by Thomas

  5. Midnight Arrow reporter

    @ Alessando

    Not at all.

    Unless you have locks on the bones then Rigify sets the pole target on the vector created by the elbow/knee (though this doesn’t work properly with Daz models due to the bone rotation problems). It’s just math to calculate the average of which way they’re pointing and move the pole target a set distance along the averaged normal from the bent joint. I disable rotation limits and locks (in both programs) so there shouldn’t be anything stopping them from aligning exactly.

    Not using poles is a terrible idea because the limbs don’t bend properly. You need the elbow control to do complex poses like characters with their arms crossed. And if the elbow control is ruined every time you snap, then it’s just obnoxious to work with.

  6. Alessandro Padovani

    As I see it the fk twist bones can also do. In the past I worked in lightwave where rigs didn’t have poles and that’s how we did it.

    Please mark as resolved if everything is fine.

  7. Midnight Arrow reporter

    It hasn’t been resolved. The pole target needs to be moved into the vector formed by the bent limb. Even if you want to claim it’s a difference in style, mirrored poses don’t work right without it, so it’s still a bug.

  8. Alessandro Padovani

    @Midnight As I understand it the fix by Thomas works the same as mhx now. So do you mean both the simple rig and mhx are affected by this issue, and they should work as rigify instead ? If yes please make some examples with pictures so Thomas could understand better what you’re after and why.

    @Thomas It is not my intention to be a pita so this is just a note. Personally I’m used to parent the poles to the master bone and I don’t expect them to move in animation nor for snapping, unless I keyframe them myself. So if you can make the “automatic poles“ an option, same as mhx, it would be appreciated. But I can live without.

  9. Midnight Arrow reporter

    I misunderstood Thomas’s comment. When he wrote that, I thought that was how pole targets worked in the version I was using. I didn’t realize he made a change because he usually says “fixed in latest commit” when he does.

    I’ll test it out when I get a chance and see, thanks.

  10. Thomas Larsson repo owner

    There are some changes in the latest commit, but I also realized that snapping will never work well. Both mhx and rigify have completely separate fk and ik rigs, and snapping is achieved by matching them. However, that means that a lot of extra bones must be added. The purpose of simple ik is to just add ik to the existing rig, without adding extra bones apart from the ik goals and the pole targets. But that means that after ik snapping, the fk pose is added on top of the ik pose.

    Ik snapping now works like this: the ik hand copies the location of the fk hand, and the elbow pole target is located in the plane of the upper arm and the forearm, on the outside. This gives approximately the right ik pose, but only if the fk pose is cleared. So ik snapping ruins the fk pose. The ik pose is only approximate and I’m not sure why, but one reason could be that the bend and twist bones are not perfectly aligned, unlike mhx and rigify.

    Fk snapping had the problem that the entire rotation was assigned to the bend bone. Now the Y rotation is shifted to the twist bone, which of course is the reason it exists. However, after fk snapping the ik pose is ruined, because there is now again an fk pose that is added to the ik pose.

  11. Midnight Arrow reporter

    I’ve played with the rig a bit and, while it does shift slightly, mirrored poses do work. Still haven’t tested exporting to Daz though.

    For my purposes (visual novel development) it isn’t feasible to export everything to Blender. The exporter is mainly useful to me right now as a posing tool. I need an FK/IK switch rig that exports poses perfectly back to Daz Studio, because Daz Studio doesn’t have enough finesse to fix them. So I’d prefer if the Daz rig had feature-parity with Rigify (including the toggleable poles Alessandro requested). I realize that’d probably be a lot of work though.

    I could make an attempt if you’d rather not.

  12. Alessandro Padovani

    The main issue is resolved and other enhancements may deserve their own discussion for better handling.

    Just trying to keep the tracker clean here.

  13. Log in to comment