MHX Properties Can't Be Edited

[Midnight Arrow]

I am testing the MHX rig since it seems better supported than Rigify. But when I link a character into a file many properties are not editable.

‌

The simple IK system also has this behavior, that’s why I stopped using it. Only Rigify displays the correct behavior of allowing all properties to be overridden when linked.

I did not find any info about this in the documentation.

[Thomas Larsson]

The stretch toggle properties call an update function that go into edit mode, to change whether the hand and hand.fk bones are connected. You can’t go into edit mode in a linked file, of course. The properties that update the elbow/knee/toes parents also have the same issue.

I don’t know if there is some way to achieve the same result without changing the armature in edit mode. I think there was some special option in the armature modifier in rigify that had something to do with it, but then I couldn’t find the code again. Changing parents could perhaps be achieved with a child-of constraint, but I would avoid that if possible because it always confuses me.

[Midnight Arrow]

Rigify uses many bone constraints that are edited in pose mode, making them suitable for use in linked files. Changing parents for pole bones is done with an Armature constraint. All potential parent bones are assigned to a constraint on the pole bone. Drivers control which one parent has 1.0 influence, the others are set to 0.0. There is also the Stretch To constraint, it allows you to control the stretchiness of a bone towards its target without needing to parent anything at all.

I don’t know much about Python coding and no idea how the MHX rig works, but I’ll answer any questions you have so that you can remove the need to go into edit mode and make MHX and Simple IK suitable for linked files.

[Thomas Larsson]

Oh, there is an armature constraint too, not just an armature modifier. Will look into that.

[Alessandro Padovani]

Thomas, the armature constraint Midnight is referring to is the bone child constraint you’re trying to avoid. You can add a set of child constraints to the pole bone then drive the influence property. But this always caused issues in our previous tests. May be this time with help by Midnight we can succeed.

[Thomas Larsson]

I think it may actually work now. Both stretchiness and pole target parenting have been reimplemented with constraints, so there is no need to enter edit mode anymore. You need to update both the import_daz and mhx_rts plugins.

[Midnight Arrow]

The armature constraint is the armature constraint. https://docs.blender.org/manual/en/latest/animation/constraints/relationship/armature.html

[Alessandro Padovani]

@Midnight

Yes but it’s not what you use for the pole bones. You use a bone constraint. You said “Changing parents for pole bones is done with an Armature constraint.“ that’s not correct.

@Thomas

I see you use a single constraint for the pole parents. Then change the constraint target when switching parents. I don’t know if this is what you planned but this way the parent is not “animatable” but just “switchable“. That is, this will deliver unexpected results if you switch it inside an animation. While it will work fine if you switch it only at the start of the scene before animating, but this can be done with the mhx creation panel already.

The idea by Midnight was to add all the possible parents to the pole then drive the influence. This should work in animation. But has to be verified since we always had issues with the child constraint.

Otherwise we may as well remove the whole pole parenting from the mhx panel. Or at least warn that pole parenting can’t be used in animation, but only at the start of the scene before animating. In this case the warning could be placed in the tooltip of the update button, may be also coloring the button as red to give the impression it is dangerous.

‌

[Midnight Arrow]

@Alessando

I’m not sure what you mean. Rigify uses an armature constraint as a bone constraint to change the parent of pole bones. You stated the exact reason why, the influence sliders of all seven parent bones can be animated so only one is “activated” at a time, because changing targets cannot be animated. Rigify also uses scripting when changing parents so the bone keeps its position in world space for animation.

[Alessandro Padovani]

I’m not sure what you mean either, I don’t see any way to “use a armature constraint as a bone constraint”. But luckily I’m not the one who has to implement this so it’s Thomas who has to understand.

edit. p.s. I see now your link and understand what you say. I’m not sure what is the advantage of using an armature constraint in this case. Actually Thomas is using bone constraints.

[Midnight Arrow]

Leaving aside the issue of advantages, I am stating this is how Rigify works:

‌

Drivers control the influence so only one parented bone is active at any time.

[Thomas Larsson]

I just realized that there is a serious design flaw with mhx. The controlling properties are armature properties rather than object properties. The idea with this was that since the mhx rig is always an armature, it is not necessary to add a lot of rna properties to other types of objects. However, this means that in order to change the properties in a linked file, the properties must be library editable in addition to library overridable.

Library editable rna properties cannot be keyframed, which is why the corresponding id properties are displayed instead. But we cannot associate update functions with id properties, so they can’t mute constraints. To fix this, all custom properties must be changed to object properties. This will take a while to get right, and since I will be out of town for a few days I will postpone that until next week.

[Alessandro Padovani]

Didn’t understand a thing but I’m not good at rigs either. When I do my simple rigs I just use an armature and eventually some bone constraints never had issues with linking.

[Thomas Larsson]

Several things have changed with the mhx rig.

1. The mhx properties are now object rna properties, before they were armature id properties. This means that bool properties are displayed as checkboxes, descriptions are available, and everything is keyable. And all properties can be accessed in a linked file.
2. I implemented switchable parents for the pole targets which child-of constraints. Perhaps it can be done with armature constraints somehow, but that would break the present implementation of FK-IK snapping. However, switchable parents are disabled by default, because some tools need to set parent inverse, which occasionally crashes Blender.
3. FK-IK snapping seems to be slightly off in some cases (left arm for Base pose kneeling B ). Child-of constraints and hard parenting does not seem to matter.
4. There is a conversion tool for old mhx rigs which shows up in all mhx panels. It is not perfect but handles most cases.

I will write a blog post in a couple of days, if everything seems to work out right.

‌

[Alessandro Padovani]

I’m not the one to test this deep since I rarely use mhx and I’m not a rig expert anyway. But I see you use the child of constraint with the poles parented to the master bone. I’m not sure if this may cause issues but personally I’d use unparented bones for the child of constraint. I mean it barely works for unparented bones go figure if you try to use it with parented bones.

So I’d rather do three child of constraints adding the master bone as a possible parent.

Just a note nothing to report as for bugs.

[Thomas Larsson]

I’m trying with three childof constraints in the last commit, but Blender still crashes sometimes. However, since the possibility to change pole target parents is now clearly marked as experimental, I will leave it like this for the time being.

[engetudouiti]

I really hope if these up-date was needed, please make new MHX-alpha. Because I clear remember, it really took time to snap IK <> FK work perfectly with current MHX structure + usable pole movements. (And as G3 user it need to work G3 specific foot bone relation)

If MHX do same thing as Rigi-fy (bone structure) , Midnight Arrow way should work. but actually MHX rig strcutre is not same as Rig-fy rig. . So there have been both RIg type. MHX rig is more look like DAZ standard rig +add some unique options.

Then Child of constrain was buggy. (actually I request it before, and tried, but it may not work as you expected. many rig maker said and avoid it to use for Rig. Without Blender dev change the way, it may keep to cause issues.

‌

[engetudouiti]

At same time, If You make MHX generate option (which may generate 2 type MHX, as 2 button )

1. generate current MHX (it should show snap correctly, though it may lost some new futures )
2. generate alpha MHX (it may try to add new functions as beta)

I can use def MHX for actual playing. but at same time easy test new functions. and over-ride things.
(I do not believe current blender over-ride system work for complex rig (driver ; constrain + shape keys etc, I see many report about this issue still) so I may wait actually it work stable for most of data.

Current up-date way is really difficult to test each version MHX, because It need to use with Daz importer (It keep up-date, and change version too) ^^;

[engetudouiti]

OK thanks !

with new version, issues seems disappear. I may not test much though.. ( still not try to use new constrain things though)

but I may hope, There should have 2 generate button (for test beta rig, and def rig) about MHX related things.

(so anyone can test all new functions, and can return feed-buck without break other scenes. )

If noone did not notice specific problem but keep generate MHX and new scene >> you up-date daz importer and mhx >> . after that notice problem, most of scene will break..

[Midnight Arrow]

I’m too busy to test anything at the moment. I can close the issue or leave it open, it’s up to Thomas.