- changed status to open
last commit shoulder rotation issue came back
Issue #2203
resolved
Hi,
I compared commit 8fc5646 which was perfect with the last commit:
The issue of the shoulder twist came back.
Thank you,
Comments (45)
-
-
repo owner
No, I cannot reproduce this. Imported G9 with Quaternions both enabled and disabled, and imported the action both to the daz rig and mhx. Nothing strange happens to the twist bones in this animation AFAIU.
-
4.2.1.2299
Same here I can’t reproduce the issue it works fine for me.
my steps:
- easy import victoria 9 with jcms + flexions + correctives
- convert to mhx, tried various options it always works fine
- import the animation and play
In your video I’m not sure how you handled to get two different versions in the same scene, if you appended the figure from another file with different mhx settings then I’m not sure how the runtime behaves, but should be fine.
-
repo owner
Even if don’t see the problem in the present file, I can imagine a situation where it happens for more extreme poses. Namely, if quaternions are disabled in the global settings, the drivers for the twist bones use Euler angles which are subject to gimbal lock. When you convert the rig to mhx the main shoulder and thigh bones become quaternions, but the driven twist bones remain Euler.
So enable quaternions in the global settings. This setting should probably be moved to the debugging section.
Edit: Now it has been moved to debugging, together with the triax options.
-
Thomas, the quaternion conversion should be done when we convert the rig from daz to mhx, including conversions on the daz rig. If we load the daz rig we want it the same as it is in daz studio, that is, without quaternions. When we convert to mhx we always need quaternions for animations to work, so this should not be an option because the rig doesn’t work without.
The daz rig without quaternions may have flippings and gimbal locks, but the same should happen in daz studio which doesn’t use quaternions.
p.s. Then personally I don’t use mhx so this doesn’t concern me directly, in my own rigs I always load the daz rig with eulers then convert to quaternion in the ik rig.
-
reporter
- changed status to invalid
Thank you, i might need do more investigation on this one.
-
reporter
- changed status to open
-
reporter
- attached 艺舞吧月禅01期丝袜高叉抖臀舞_body.vmd
here is the vmd
-
reporter
- changed status to invalid
ok i believe this issue might be because i merged a G9 armature with VIC 9 HD armature in the merge rigs in the correction tab. Might be because of that.
-
repo owner
- changed status to open
-
repo owner
I can confirm that the Quaternion setting matters when you import the character. Consider the transition between frames 618 and 619. First Quaternions disabled, then enabled.
The deformation isn’t great in the latter case either, but at least it is consistent. And the original model performs even worse, with a candy wrapper.
I had introduced a bug in MHX generation where quaternions weren’t generated for upperarms and thighs. It doesn’t have anything to do with this issue because it was introduced yesterday, and it is fixed now.
-
repo owner
It we compare the two first pictures, we see that the deformation at frame 619 is actually better with eulers.
The rotation of upper_arm.fk.L = (0.429, 0.753, -0.480, 0.141).
In YXZ Eulers, this is (30.673, -133.55, 101.57).
The Y_rotation of the twist1 bone (in the Help collection) is -0.75*Y rotation.
If we use Eulers, twist1 = (0, 100.17. 0).
But with quaternions twist1 = (0.933, 0, 0.360, 0) = (0, 42.154, 0) in Eulers.
So the counterrotation of the twist1 bone is 42 degrees rather than 100 degrees. Hm.
-
If it helps. As I see it the priority is to avoid flipping and gimbal locks in animation, that’s quaternions, then comes good jcms as intended in daz studio if it’s compatible. As for twist bones, we can either use decomposition in xz and y, or dumped track. Where decomposition is what daz studio does with eulers so jcms will look better, but unfortunately this tends to break in animation, while dumped track results in the minimum rotation so the deformations are more relaxed, but doesn’t break.
In my rigs I tend to use dumped track even if the deformations may be more relaxed compared to daz studio.
-
To stress test my rigs I use the belly dance animation at mixamo, I loaded it on mhx at it performs quite good overall. Below a comparison with my own custom rigs, the comparison is not fair as I use very different techniques as ik retargeting and corrective smooth for prebended figures, but you may find this animation useful for stress test and eventually improvements to mhx.
-
- attached Belly_Dance.fbx
belly dance at https://www.mixamo.com
-
repo owner
I took the radical step and threw away the daz twist1/2 bones altogether. Instead MHX creates its own bend and twist bones, as it already does for G1 and G2. The bend bone has a damped track constraint and the twist bone a copy transforms constraint, and there are no drivers at all left. In particular, the global quaternion setting doesn’t matter anymore.
This gives a better deformation in your test scene, although not quite as good as your rig.
-
Yes I do the same in my rigs, but mine are much simpler than mhx I don’t have “fk/ik snapping” or “keep daz rig“ features, also I don’t care too much of “daz compatibility“ as I don’t export back to daz studio with “save pose presets”, but only use my rigs in blender. So you may want to be more careful and check all the features when it comes to modifying the daz rig for mhx.
As for retargeting, I retarget directly the ik targets rather than fk bones, using helpers in the source rig to allow for pose fitting as hip hands feet and shoulders, basically with the helpers I can set offsets that are kept in the target rig. This has advantages and disadvantages over fk retargeting. The advantage is that there’s no sliding and the poses tend to fit better for figures with different proportions. The disadvantage is that poses tend to be approximated over the original and less precise.
Again this probably doesn’t fit the purpose of a daz importer, it’s just my way of doing things for blender.
-
I guess my post didn’t go through--I would like to mention (not sure if related) that a similar yet less severe issue occurs in the generated Rigify rig as well:
-
^that is with quanternions enabled in settings when importing as well
-
4.2.1.2300, blender 4.2.1
@Jasper I cannot reproduce the issue with rigify, unless it happens only with a specific figure, or the pose comes from some animation where there may be flippings in nearby keyframes. Below my example where I posed the left arm with fk and the right arm with ik, both work fine here.
my steps:
- import G8F with jcms and flexions
- convert to rigify
- pose the left arm with fk controls
- pose the right arm with ik controls
p.s. If the issue comes with a specific figure, then be sure to import correctives as well, and compare the same pose with daz studio as it may be the PA correctives are just bad.
-
repo owner
The flipping issue only happened for G9 and mhx. With Rigify the twist1,2 bones are deleted and Rigify creates its own bend and twist bones the Rigify way, just as mhx does now.
-
Thomas does this work with “save pose preset” and “keep daz rig“ ? If yes then we can close as resolved if there’s nothing to add.
-
@Thomas Just want clarity--before generating a Rigify metarig in the rig section, a menu pops up with a ‘split shin bone' option (I’ve been selecting it). In your last post you mentioned Rigify creates its own bend and twist bones, so what is the option truly for, and is it ideal for using it in animation staying in Blender? (using G8 and G9 characters if it makes a difference).
-
4.2.1.2300, blender 4.2.1
@Jasper. The genesis rig doesn’t get a twist bone for the shin, the “split shin“ option adds it for rigify. Of course this can’t export to “save pose preset“, and I guess it doesn’t work fine with jcms either since the genesis jcms don’t expect a extra shin twist bone.
@Thomas. bug. optimize pose for ik. The pose for ik doesn’t affect the figure geometry, only the rig.
update. This only happens if we import as dbz, importing as unmorphed works fine.
steps:
- import G8 as dbz
- convert to rigify with “optimize pose for ik“, the figure geometry doesn’t follow the pose for ik
-
@Alessandro Thanks for the clarfication--regarding the ‘optimize pose for IK’ I don’t know if you remember a while back we discussed this and it was said to leave it unchecked when using Rigify (doesnt play well with it). Also rotation limits need to be turned off for animating using rigify to properly use ik/fk snapping (at least with certain feature sets like ik mid arm and leg controllers for elbow/knee pinning).
-
@Jasper It depends what you need. To import daz poses yes, it is best not to use “optimize pose for ik“, otherwise poses don’t load fine. There was an option “subtract rest pose“ that’s recently removed because it didn’t work anyway, for example if we tried to import “kneeling b“ with the rigify “ik pose” it didn’t end well.
On the other side “optimize pose for ik“ is needed to animate in blender, otherwise rigify doesn’t work fine especially with poles, that’s why the option was introduced. That is, you can use rigify with “improve ik“ instead of “optimize pose for ik“, but don’t use poles. The tooltips are pretty clear about this if you read them.
Anyway to import daz poses on any prebended figure, including “optimize pose for ik“, you can use the bvh retargeter which works fine. This way you can use the “ik pose“ for rigify and import daz poses correctly.
@Thomas. bug. retarget selected to active. If we use the bvh retargeter on rigify the pose is imported fine, but the hip location is wrong.
update. Disabling “auto scale“ and “center animation“ the hip location improves a lot, but it is not exact anyway.
steps:
- import G8 and convert to rigify with “optimize pose for ik“
- import another G8 and load a daz pose, for example “kneeling b“
- use “retarget selected to active“ to copy the daz pose to rigify, the pose is fine but the hip location
@Thomas. idea/request. add “optimize pose for ik“ as T-Pose. As explained above, with the bvh retargeter it is possible to copy daz poses on rigify even with “optimize pose for ik“, which didn’t work with “subtract rest pose“. If I understand correctly, it should be possible to add “optimize pose for ik“ as a T-Pose to the retargeter, this way we should be able to load daz poses directly to rigify with “load and retarget“, by also adding duf as a possible file source. Let us know what you think.
p.s. merge the retargeter ? Since the retargeter is needed both to load facs animations and to load daz poses on rigify, you may consider merging it to the main importer module, as the retargeter can’t work alone anyway.
-
repo owner
If we keep the daz rig the G9 twist bones will move, because the corresponding mhx bones don’t exist. This is normally not a problem, but the pose may not be exactly the same if we reexport to DS. Therefore I added an option to keep the G9 twist bones. It is off by default since the flipping problems are back, but might be useful for making pose presets.
Rigify splits the shin bone irrespective of the option; that’s what Rigify does. The option might be called “Split shin vertex group”, because in practise it is what happens.
I cannot reproduce the Optimize IK issue, and I don’t see how it could ever depend on whether the character is imported with mhx or not.
-
4.2.1.2301, blender 4.2.1
Ok I got what it is. It happens only if I save G8F at base resolution without eyelashes, that I usually do to import a simple source for retargeting. Exporting a default G8F works fine. Importing as unmorphed works fine.
steps:
- in daz studio export G8F at base resolution without eyelashes, or use the provided scene g8-base.duf
- import in blender as dbz
- convert to rigify with “optimize pose for ik“, the mesh doesn’t follow the ik pose
-
- attached g8-base.duf
test scene for "optimize pose for ik"
-
repo owner
Fixed in last commit. The plugin made a strange test for a global variable whose value isn’t well defined. AFAIU this test is obsolete so I removed it.
-
Commit a2b2ae3 works fine for the “optimize pose for ik“ bug. Let us know for the “retarget selected to active“ bug.
-
repo owner
The retargeting bug should be fixed now. The plugin scales the hip translation based on the size of the left thigh bone. The idea is that all human rigs should have a left thigh, and using this as the scale should make the stride right. However, in some daz rigs the thigh is split into bend and twist pieces. The plugin used the combined length of both thigh bones for the target rig, but not for the source rig. So when retargeting from G8 all translations became twice as large as they should.
-
bvh b3ef57b
Nope, the scaling is fixed but there’s still an offset same as not using scaling before. Steps as above. I understand this is due to the difference between the source and target hips in rest pose. That is, the hip location is copied to the target as is, instead of being copied with the offset. However it is easy enough to reposition the target by hand in object mode once the retargeting is done.
Let me know if you want to try and fix the hip offset, otherwise we can close as resolved.
Also please let me know if the “t-pose“ idea is interesting to you or feasible at all.
-
reporter
Hi Thomas,
are you sure commit
is not the problem for the flipping return in MHX?
because before it , i believe it was ok.
-
reporter
-
reporter
I can confirm 100% it’s working fine with 8fc5646 ,its the commit i am using now.
we just MUST activate Quaternions in the global settings then import the mesh with that commit it will work fine,i also managed to export the animation with that commit and 0 flipping.
Also for me personally if i can’t export back to daz, i can’t use MHX, and if i activate the twist bones on the new commit i can’t export.
-
importer 4.2.1.2302, mhx 4.2.1.0125, bvh 4.2.1.0053 (latest commits)
I can’t reproduce the issue here, tried both belly dance and the vmd animation they work fine. Be sure to update both the importer and mhx and bvh, then re-export and re-import, that is, don’t use a previous/old scene for testing.
belly dance, blender 4.2:
- import G9 with jcms and flexions
- convert to mhx with G9 twist bones
- load and retarget, works fine there’s no flipping
vmd animation, blender 3.6 since mmd tools doesn’t work fine with blender 4:
- import G9 with jcms and flexions
- convert to mhx with G9 twist bones
- import miku hatsune with mmd tools
- import the vmd animation with mmd tools
- retarget selected to active, works fine there’s no flipping
-
repo owner
“Keep Genesis 9 Twist Bones” was added in order to export the twist bones back to DS. If this option mhx creates its own bend and twist bones which are controlled by constraints. This is the most stable approach but it is not fully compatible with DS.
Driving the bone’s W channel with the Y channel of the same bone resulted in warnings about dependency loops when the rig was converted to mhx. That was the reason for
#6c18399. Though I’m not sure that the dependency loops are real. -
reporter
Alessandro MMD tools works fine in 4.2 if you download it from the official blender extension MMD Tools — Blender Extensions
EDIT: I had to update MHX, i have no issue after updating MHX
if we can export back to DAZ without any issue then this topic can be closed.
-
@Thomas The hip offset also affects the miku dance animation, steps as above, everything else works fine. Let us know if you want to look at this or we can fix it by hand once the retargeting is done. Or perhaps you can add an option to move the hip so the first frame rests on the ground, by looking at the geometry bounding box, that’s essentially what the user would do by hand.
-
repo owner
There was an option called “Center Animation”, which added an offset to the hip animation based on the difference in location in the reference T-pose. This option is now back. We can also choose the range of frames to be retargeted. The “Load and Retarget” button already had such an option, but now the “Retarget Selected to Active” also has it.
-
reporter
Can be closed when Alessandro is ok, because i dont use rigify i can’t test it.
thanks
-
@Thomas. hip offset. I tried “center animation“ but didn’t work here, instead things get worse. Anyway we can fix this by hand quite easy. Let me know if you want to give it a second shot or we can close as resolved.
steps:
- import G8 and convert to rigify with “optimize pose for ik“
- import another G8 and load a daz pose, for example “kneeling b“
- use “retarget selected to active“ to copy the daz pose to rigify, the pose is fine but there’s an offset in the hip location
-
repo owner
No, I don’t have any more ideas, so we can close this.
-
repo owner
- changed status to resolved
- Log in to comment
