MPFB issues with Rigify 3.1 features

[angavrilov]

There are some issues I noticed immediately:

1. The option to assign generated rig name was removed in Blender 3.1 master, so the code simply crashes. It is necessary to check if it exists now, and assign a proper name to the metarig. There are three possible name patterns: a name containing META has it replaced with RIG, metarig gets replaced with rig, or something containing neither META nor metarig will have RIG- prepended:

   if hasattr(armature_object.data, 'rigify_rig_basename'):
       armature_object.data.rigify_rig_basename = "Human.rigify"
   else:
       armature_object.name = "Human-metarig"

2. The operator to convert legacy face to new style modular face (3.0 feature) was crashing because there is supposed to be a gap between the end of nose.004 and the lips. I fixed the converter to be more robust, but just a heads up.

3. The eye bones are way too long - they are supposed to match the radius of the eye. This leads to some generated controls being way too big in the new style face, and the iris/pupil scale deform bones are in a weird location. The eye bones also have a weird roll, causing some other problems for the eyelid mechanism.

4. Minor nitpick: the teeth bones are angled weirdly, resulting in strange control orientation.

5. Also, the spine/head split is obviously in the wrong position.

Btw, with the new face system it's easy to generate a deform bone for teeth, the convert operator even enables it by default. However the metarig setup is way more complicated since a lot more of rigging is configured in the metarig, see the update operator.

[joepal1976]

Thanks. Yes, the rigify functionality could use a lot more love in MPFB. But a good start will be to not have it crash.

[angavrilov]

To clarify a bit about the names: the field was removed because now you are supposed to just rename the generated rig if you don't like the basic naming scheme. For re-generating in place the metarig now has direct references to the rig, script and widget collection; and if a reference isn't set, a new object is always generated even if such name already exists and it has to add '.001' etc. IIRC a long time ago it wasn't possible to store pointers to other datablocks in python properties, and that's why the name field was implemented.

[angavrilov]

@joepal1976 I'm thinking about maybe looking into fixing the rigify rig myself when I have time and motivation, so is there a brief description somewhere about how things work, and tools and process necessary to e.g. adjust bone locations, or weights? Also, just curious - is it possible to have alternative rigify metarigs, like MH allowing alternative ordinary rigs?

Also, what do you think about switching to the new face, since it's the future and e.g. automatically addresses the teeth problem? The simplest way is to just run the upgrade operator automatically.

[joepal1976]

@angavrilov It would be very, very helpful if you looked into it. I'll help in whatever way I can.

I'll try to get some time to write documentation about this in the weekend, but as a short summary:

• Rigs are defined in JSON files. The rigify rig is defined in https://github.com/makehumancommunity/mpfb2/blob/master/src/mpfb/data/rigs/rigify/rig.human.json, and its weights are listed in https://github.com/makehumancommunity/mpfb2/blob/master/src/mpfb/data/rigs/rigify/weights.human.json. Listed as relative to where the addon is installed, they're under data/rigs/rigify.
• The underlying principle of the rig definition is that bone head/tail is specified as related to a position on the basemesh. The exact coordinate is found through one of three strategies: VERTEX = at the same spot as a vertex, MEAN = geometric mean between two vertex positions, and CUBE = the center of a joint cube.
• On the "developer" tab, you have buttons for loading and saving rig JSON files. If you create a new human from scratch and select it, you can try loading the rigify file above. Note that bones are placed on layers, in case it looks as if not all bones were loaded. When you click "save", it will try to match bone head/tail positions according to the above strategies
• The code for the load and save operators are here https://github.com/makehumancommunity/mpfb2/tree/master/src/mpfb/ui/developer/operators
• In the same place as load/save rig you can also find buttons for loading/saving weights files. The operator code files are in the same directory.

I'm all for using whatever rigify options that solves the problem in the most convenient way. The current rigify solution is mainly an effort to get any rigify support whatsoever in place rather than a final design.

And yes, it'd be perfectly possible to have multiple rigify rigs. Some UI redesign might be required in order to allow selection between different JSON files, but that's no rocket science.

[angavrilov]

@joepal1976 Which character settings is the current json developed under exactly? Basically, how can I make it generate the same exact file without default_position variation as a starting point?

[angavrilov]

@joepal1976 So I started work by tweaking the metarig and associated tools and code: https://github.com/angavrilov/mpfb2/commits/rigify-fixes. I won't submit a pull request until working through weights though, especially since I moved some bones.

Btw, is there any specific reason the Preserve Volume mode of Armature modifier currently isn't used? I'm currently planning to work on weights with it on.

[joepal1976]

The current rigify skeleton was modeled on a default import from makehuman. This was before it was possible to model characters directly in MPFB. I'll attach the original blend file here.

rigify_blend.zip

Possibly, this should be re-done and and the rig with its default positions should instead be based on the default "from scratch" model, or even the raw base mesh. Alternatively, maybe there could be some merge script to avoid cumbersome diffs for the default position.

I don't have any reason either way with the preserve volume setting. I haven't considered it, so it's just at its default setting. If you think it should be enabled, then we can try it that way and see what happens.

[angavrilov]

In my branch I already established a json-centered process for the skeleton, with a json file that doesn't change if you add a Neutral (all defaults) character, load rig via Developer panel and re-save it. It did require a commit that only updated the default positions, but after that preparation step changes make sense.

Re Preserve Volume, I think it's a more easy lazy setting for limb joints, preventing collapse at big bend angles without any additional rigging. On the other hand it has issues with scaling the character, and the non-preserved collapsing behavior may look a bit more natural by accidentally representing squash and stretch of flesh around the joint - at least until the angle goes beyond 90 degrees. A possible alternative is to consider including deformation helpers in the rig for knees/elbows/etc, which would require being able to store constraints in json for ad-hoc rigging (Rigify already can do that with its metarig to python conversion). So this question is probably something that warrants discussion.

About weights: do you remember which parts of the weighting is taken from the original skeletons and should be presumed to be of some quality, and which is auto weights and thus have to be checked and doesn't need to be valued as much?

[joepal1976]

MHX had/has some deformation helpers. They made sense, but also produced strange results in extreme positions. I'd say that it might be a good idea to start without them and then use deformation helpers if it in the end is required to achieve good results. If they're needed, we'll figure it out. Worst case we can have a separate definition file for these alongside the main rig definition.

For the weights, most small bones are auto weighted. For those bones (mainly arms and legs) which coincide with the game engine rig, I think I imported those weights. But the game engine rig weighting is interpolated too, so that's an interpolation of an interpolation.

[angavrilov]

I think helpers are absolutely required for knees, elbows and leg base, because they are joints that can reasonably go beyond 90 degrees rotation, and non-preserve-volume transformation totally collapses in that case. Also maybe arm base, but that is a more limited joint. Through helpers using Armature constraint to blend 50/50 between two adjacent bones it is essentially possible to partially apply Preserve Volume transformation locally around the joint with custom weighting.

[joepal1976]

Ok, I'll take a look at serializing/deserializing helpers. But it'll be a while until I can sit down with that.

In the mean time I have started writing some code documentation, although I did not get as far as I had hoped during this weekend. What exists so far can be found here: http://static.makehumancommunity.org/mpfb/developer.html

The location is in a draft for a new web site structure, so it might change location at some point.

[angavrilov]

Ok, I'll take a look at serializing/deserializing helpers. But it'll be a while until I can sit down with that.

Too late - I already implemented serializing basic constraints (and B-Bone handles while I'm at it) to json in my branch :) https://github.com/angavrilov/mpfb2/commits/rigify-fixes

[joepal1976]

@angavrilov would you be OK with me merging the changes you have made in your fork, or do you consider these work in progress which isn't really relevant for merging?

[angavrilov]

IIRC it needs some weight painting work due to some changes in the bones, but just when I started on that I suddenly had to relocate from Russia to Cyprus which put a stop to it. Maybe it's a good time to resume this work, I've been vaguely meaning to do that for a while now, but couldn't find the right moment.

Edit: in short, I think the code was fine, but in some places the weight situation may become worse if merged without paint fixes.

[joepal1976]

Glad you're back.

There's no hurry whatsoever with these things. Reason I asked was because I was in the same areas of the code fixing some other bugs, and worried that I might cause an unnecessary merge conflict. However, comparing the forks now it doesn't look as if there are any significant problems in that regard.

[joepal1976]

I'm thinking most issues have now been fixed with the merge of https://github.com/makehumancommunity/mpfb2/pull/41

[angavrilov]

Well, things mentioned here were fixed indeed.